dhertzog, sorry, the alt V4 ID is 0xEC. We've just updated the manual to reflect this.

Jack, that will not damage the sensor, and should show a reading.

Thanks, Bill.

I noticed today that I can tell the difference between the basement and the living room upstairs too. That helps...

Jack

Originally Posted by billpa

dhertzog, sorry, the alt V4 ID is 0xEC. We've just updated the manual to reflect this.

Jack, that will not damage the sensor, and should show a reading.

Thanks Bill, that got it working. Does it matter if I use the 4-wire cable or the 4 pins coming directly off the altimeter? Both gave the same readings but I seem to have problems with the 7-segment display showing new altitudes when I used the 4-wire cable (even after power cycling).
-David

Hi Bill,
I've got my arduino board reading the altimeter v4 (using code from turnale and nakki5)...but I'm getting odd readings. It outputs a value of 2817, and the value increases as I apply suction, but it goes up only in increments of 256 (e.g. 2817...then to 3073...then to 3324). If I do the math on these values (assuming they're decimeters and setting the initial value to zero), they seem to match the altitude shown on the 7-segment display...but that would indicate an altitude resolution of only 25.6 meters. Seems like I must be doing something wrong here.

I looked at what it was outputting for the 2 bytes of data and the first byte is always 1, while the second byte changes with pressure...which makes sense that the output then is close (within 25.6m) of the altitude shown on the 7-segment display. So i can't figure out why the first byte is always "1"... my code (arduino) for reading the values is:

// Tell sensor we're going to write to it
Wire.beginTransmission(ALT_ADDRESS);
Wire.send(I2C_WRITE_BIT);
Wire.endTransmission();

// Send the read data command to the sensor (0x07)
Wire.beginTransmission(ALT_ADDRESS);
Wire.send(0x07);
Wire.endTransmission();

// Read the altimeter's response
Wire.requestFrom(ALT_ADDRESS,2);
if (Wire.available()) {
data= Wire.receive();
}
if (Wire.available()) {
data |=Wire.receive() << 8;
}
return data;

Hi, I'm not sure what would cause that. You might want to experiment with different transfer rates, and/or different polling rates. Looking at the traffic with a logic analyzer/scope may be necessary.

Originally Posted by nakki5

Hello turnale,

based on your code example (thanks for sharing!!) I was able to get out 16-bit value for pressure from my new airspeed sensor V3. My sensor is working in normal mode (no third party) and it gives about 1570 value ±5. I tested it by blowing to high pressure side and I got about 13800 value max, which corresponds 7-segment reading 530km/h.

I am pretty sure that the values are differential pressures measured in Pa (Pascal). A speed of 530 km/h corresponds to around 13800 Pa, than you can calculate the incompressible speed by using Bernoulli's equation: v = sqrt(2*pdiff/rho), where pdiff is the reading (I assume that the initial value of 1570 in your case is an offset and needs to be subtracted) and rho the air density (1.225 kg/m^3 for standard atmosphere at ground level). The result is m/s, to get km/h just multiply by 3.6

In this example it will give 508 km/h, which is a little bit different from the 530 above, but they may have some different assumptions about the air density. To implemented compressibility correction, the equation looks like v = sqrt(2*pdiff/(rho*(1+0.25*Ma^2))) where Ma is the Mach number Ma = v/a (a speed of sound). Of cause, this requires an iterative solution.

Hope that helps

Edit: Compressibility correction is only necessary if you fly with more than around 350 km/h ...

Hello Bill, I have the ALT-V4's 3-party mode working with my uC. The decimeter data is stable, perhaps only 1 bit of short term wandering. I can see smooth elevation changes as I move the ALT-V4 up and down and the data closely mimics my movements. So that part seems to be Ok.

However, there is something odd going on. My data is not zero referenced. Instead, it is offset by about 4080 decimeters at my location (I'm about 200 feet ASL). I tried another ALT-V4 with the same results.

Is this normal? The 3rd-party data sheet says that the ALT-V4's data should be zero referenced. But that's not what I am seeing, so the reason for my tap on your shoulder.

Thanks,
Thomas

Anyone managed to make this work with an Arduino?

Thanks

Itay

Hi Thomas,

Yes, there was an error in the altimeter V4 documentation. The altimeter V4 returns the actual barometric altitude (not zero referenced) + a 3000 decimeter offset. The manual is now updated to reflect this. Sorry about that!

The altimeter V4 returns the actual barometric altitude (not zero referenced) + a 3000 decimeter offset.

Hi Bill, Thanks for the reply. It drove me nuts trying to find the reason for the unexpected values. So it's a relief to hear that my code is fine.

Pardon if I missed it in the documentation, but what is the ALT-V4's update rate for each new data sample?


.

Hi Billpa,

would you also make the i2c protocoll for the guardian module available to us?
Then i definitly would buy one or two of them :-)

Best regards
Christian

Dear Billpa, any comments regarding availabillity of the protocol for the guardian module yet?
Thanks!

Hello, I'm using a Rs232-I2C Adapter to obtain the data from the Altimeter v4.

The data i recive in Hexadecimal when i read 6 bytes (if i read more, the next are always [00]) is like this:

[76][00][FF][FD][00][B9]

The two bytes that changes in time are [FF][FD], so i suposed that are the two bytes of the sensor data. But in this example the altitude would be:

FDFF which in meters doing the convertion mentioned in the manual is 6202.

I don't now what i'm doing wrong, any help would be apreciated.

Thanks

Hi, you should only need to read two bytes. See if the first two bytes change when you move the sensor at least one foot higher or lower.

Hey,
Will the 3rd party mode Airspeed sensor work with my computer if I attach it to the computer via a USB-serial connector?

Thank you