PilotAware
British Forum => General Discussion => Topic started by: rodent0_2 on October 29, 2015, 12:34:24 pm
-
Hi Lee
should this just be plug and play or does something need configuring, status page still reads 1013 after fitting the board, got the ardfruits board with the 5v supply.
Nick.
-
No worries Lee, its now reading 1016 QNH so all good.
Nick
-
No worries Lee, its now reading 1016 QNH so all good.
Nick
Hi Nick
One of the other members reported very strange nmbers coming from the adafruit bmp, please keep an eye on this, I use the hobbytronics version
Thx
Lee
-
Hi Lee
Its been running an hour or so with SD sitting in the window at work, reading 1015 at the mo and ties in with our calibrated standard baro within a few mbar, work is on the southern end of the peak district seen plenty of traffic reported by the paw and ties in with flight radar 24, nothing seen on the ARF but not a surprise there I suppose.
cheers
Nick.
-
Further update Lee, Got the QNH from east mids driving home 1011, PAW 1015mb 4 mb difference, I suppose 120' isn't too bad for something costing us £9.00
Nick.
-
Yes, I championed the Adafruit baro a while ago but I have started seeing odd QNH values from it with 3 out of 4 PAWs I have fitted them too :( :(
It's odd as the 4th one is fine, so it's hard to believe there in an inherent problem with using it but 3 / 4 bad is not good.
Keep an eye on the QNH values reported when the whole system is running especially over time. My bad ones tend to drift upwards over time, the 4th is steady at a comparable METAR QNH !
Good if yours is giving sensible results!
-
I need to double check mine again, but the hobbytronics version was absolutely bang on correct
Thx
Lee
-
Yes, I championed the Adafruit baro a while ago but I have started seeing odd QNH values from it with 3 out of 4 PAWs I have fitted them too :( :(
It's odd as the 4th one is fine, so it's hard to believe there in an inherent problem with using it but 3 / 4 bad is not good.
Keep an eye on the QNH values reported when the whole system is running especially over time. My bad ones tend to drift upwards over time, the 4th is steady at a comparable METAR QNH !
Good if yours is giving sensible results!
Does the Adafruit breakout have pull-up resistors on the I2C bus? - as noted elsewhere, the Pi already has I2C pull-ups, and if the breakout adds them in parallel this can reduce the pull-up resistance to the point that I2C becomes unreliable - I've seen this when using other break-outs, including Adafruit ones, with the Pi.
With an Arduino-type setup that these breakouts are intended for, the intrinsic pullups on the microcontroller can be disabled, but as far as I'm aware you can't do this with the Pi (I believe there is a second I2C bus available without them, but this isn't available on the main GPIO connector...)
-
I believe there are pull-ups on the adafruit module......very interesting......might be worth desoldering said beasts and re evaluate.
-
Curious - I tried mine with the case off and the baro moved away from the rest of the innards and the values became more sensible!
Moved the baro chip to the other side of the SOPod board from the ARF and it seems much more stable now.
-
I have built my second unit without the Baro Sensor as I now believe it to be an unnecessary complication.
Using cockpit static the baro sensor will be variable in an airborne aircraft and in reality the GPS altitude is accurate enough for collision avoidance purposes. Any altitude difference of less than 1000 feet will certainly require horizontal action to deconflict.
I do have the Hobby Electronics sensor in my first unit and it is surprising how accurate it is, but it is avoidance of conflict which is the aim rather than accurate detection of altitude variation from transponding aircraft.
-
Just run the unit today and I am seeing a +7mb difference on East Mids QNH, hopefully going to try it in the aircraft tomorrow, also managed to get hold of a hobby craft version, I'll see how the Ardfruit plays out before I swap it.
-
Is this the QNH from the web screen? Does it calculate QNH from the baro and GPS altitudes? I've found the GPS altitude varies. I was watching it the other day as it went from 200ft+ to about 100ft (on the ground) and subsequently the calculated QNH varied with it.
-
Just run the unit today and I am seeing a +7mb difference on East Mids QNH, hopefully going to try it in the aircraft tomorrow, also managed to get hold of a hobby craft version, I'll see how the Ardfruit plays out before I swap it.
After some more testing I am beginning to think it is more about location inside the case / heat than the sensor type. Heat perhaps ?
-
Is this the QNH from the web screen? Does it calculate QNH from the baro and GPS altitudes? I've found the GPS altitude varies. I was watching it the other day as it went from 200ft+ to about 100ft (on the ground) and subsequently the calculated QNH varied with it.
I should probably explain, the pressure sensor can be configured to provide either altitude or pressure. I configure the sensor to provide altitude, and then perform a conversion to generate the QNH, based upon the altitude provided by the GPS.
The conversion rate I use is 27.7 ft/mb but of course in reality the rate is not constant and changes dependant upon the altitude.
So the important figure is the pressure altitude, rather than the QNH figure.
Thx
Lee
-
Lee,
How do you confiqure the Pressure sensors? I use the hobbytronics ones straight out of the packet.
Steve
-
Lee,
How do you confiqure the Pressure sensors? I use the hobbytronics ones straight out of the packet.
Steve
Hi Steve
When I say configure, I am referring to the software configuration.
There are lots of registers which need to be initialized to certain values during the software startup
Thx
Lee
-
I have the HT sensor attached to my PAW unit and the QNH seems to be wandering around from 1027 to 1034
I am between London City and Stansted who are both reporting QNH 1029 on the current TAF
Is anyone else seeing these wandering values on a HT baro board?
I have quite a long ribbon cable attached, I wonder if this might be causing an issue?
-
Looks like it might be down to the amt of satellites that can be seen at any one time which is causing the gnss altitude to change?
-
I think so, I think the calculated QNH relies on the GPS altitude. The GPS altitude with the GPS dongles doesn't seem to be that accurate.
-
This is correct the QNH is estimated by comparing the GPS Altitude and Barometric Altitude.
So the important figure is actually the Barometric Altitude
-
Can the browser display be updated to have the barometric pressure displayed in the field as well as what's currently there? Just a thought!
-
Can the browser display be updated to have the barometric pressure displayed in the field as well as what's currently there? Just a thought!
At the moment it prints the following
Pressure Altitude (BMP) | Enabled (Auto) QNH=1025mb QNE=-124ft GNSS=229ft
As already discussed the QNH is estimated based upon the relative GPS/Baro Altitude.
Are you asking for the Barometric pressure from the sensor ?
If so that is not easy, the sensor is modal, and can be configured for Altitude, or Pressure.
So it would need re-initializing and then require settling time to perform the calculations for each reading
so in effect you would need to do the following
Initialize for Altitude
Settle ...
Read Altitude
Initialize for Pressure
Settle ...
Read Pressure
That would take quite some time I think, I guess it could be run in a separate thread so as not to impact the main thread.
What is the reasoning behind the question ?
-
Ok, didn't realise that. I was thinking about just calculating it to display it! :)
The thoughts were about having a reference value displayed to avoid confusion with the calculated QNH. Just as a troubleshooting/for interest item.
-
so far so good with this Ardfruit thing. Fit the gps dongle the other day all worked first time.