PilotAware
British Forum => General Discussion => Topic started by: Moffrestorer on September 03, 2015, 12:23:29 pm
-
Hi Lee,
I think your Pilotaware Initiative is brilliant, especially as visibility of non-transponder equipped aircraft will at last be possible if your device gains wide acceptance.
My question concerns altitude accuracy of "targets" on the GPS display. If the displayed target is from an ADS- B transponder, the encoding altimeter is referenced to QNE (1013mPa), and the data relates to Flight Level (FL). If the target is transmitting via P3I, then the altitude will be derived from the GPS unit. This depends on the user dialling in an offset, such as altitude of departure airfield in Easy VFR, to "calibrate" the GPS altitude against the WGS84? geoid. As such, both targets altitude display will be independent of air pressure changes that will affect altimeter settings.
Does your software convert FL to altitude without taking into account the barometric pressure e.g.FL 25x100ft is taken simply as 2500'altitude? Or is it the GPS software that converts this? The P3I targets should presumably be on the same reference as each other, the geoid. Do GPS and Glonass and whatever Europe comes up with, use the same geoid?
If the altitudes from the various targets sources cannot be directly related, caution will need to be used when interpreting the display. At least we will know that there is something out there,in which direction to look, and an approximation of height differences!
Regards,
Chris
-
Hi Chris,
Interesting, I may need to think on this a little ...
For now, altitude is taken directly from the Location Services API on the iOS device, so it is completely independant of PilotAware.
The data is basedupon whatever iOS uses as its reference, this could be the internal GPS, or it could be an external GPS, such as Garmin Glo or BadElf.
I would hoped that the engineers at Apple (and indeed Google/Android) would have taken this into account when interfacing the GPS information through their Location Services API.
In the case of ADS-B, I am not sure how this would relate I have to be honest.
Just to clarify, are you saying that If I connect my GPS source to my transponder, then the altitude component is filtered out, and replaced by the altitude calculated by the transponder, and therefore some mismatch can occur - I think this is what you are saying ?
Thx
Lee
-
I think what Chris is saying is that the altitude reported by Mode-S will be based on the standard pressure of 1013hPa. If the real pressure is different (more likely than not!) then altitude will not be accurate unless adjusted based on 78ft per hPa (if I remember my Met correctly). GPS altitude should not be affected by pressure. So the scenario could be that an ADS-B target is shown as above/below when in fact it is at the same level as you.
Cheers,
Tim
-
One hectopascal is about 30 feet
-
Oops, you're absolutely correct of course! :o For 78ft read 28ft!
-
Hi Lee,
I think it's most likely regarding ADS-B, that the altitude component will be filtered out.
Our Becker mode S has an encoding altimeter that is connected to the aircraft static port, and provides serial data to the unit. This data will be transmitted to ground stations and other aircraft. I'm certain that whether Mode C or S, the output of any transponder will be relative to QNE pressure setting i.e. Flight Level. The GPS input seems to relate solely to airborne/surface position messages, airborne velocity message and extended squitter aircraft status message (this will be the unique aircraft identifier code).
For every 1mPa difference in regional pressure there will be 30 feet error. Assuming a QNH of 1030mPa then this is an altitude difference of 500 feet.
Maybe this isn't too significant in the overall scheme of things, because for my own purposes, I want to know which area of sky I need to look at to see conflicting traffic. (I have a Zaon MRX that gives target alerts based on timing transponder and Flarm transmissions to give relative height, distance and whether target is climbing descending, but crucially it doesn't give azimuth or bearing info. I believe the more expensive XRX model only gives quadrants of azimuth as a bearing.)
Regards,
Chris
-
Found this description
http://www.faa.gov/nextgen/programs/adsb/faq/
In fact, ADS-B reports two kinds of altitudes: barometric and geometric. Barometric or pressure altitude is the one pilots know best – this is the altitude that is displayed on the altimeter in the aircraft. Geometric altitude is calculated by GPS (Global Positioning Satellites) as the height of the aircraft above the earth ellipsoid. These two altitudes are not the same, but having both allows for applications that require one or the other as an altitude source and provides a means of verifying correct pressure altitude reporting from aircraft.
SBS1 allegedly reports the Geometric, so this would seem to be the same value used at both ends
Although I think this requires further investigation
Thx
Lee
-
I have never found GPS GEOID altitude to be hugely different to QNH, it's usually within about 200ft. Although quite rightly altitude isn't something that GPS is good at unless using WAAS/EGNOS correction (DGPS).
I suppose one of the interesting points is that if you are reporting FLs back to SD (as you'd be receiving from ADS-B transponder altitude encoder - pressure referenced to 1013mB), then you need to have a way of correcting it for QNH (just like NATS do with their radar)... because on SD you'd be comparing a FL (not QNH) to a GPS GEOID (a psuedo QNH).. this could introduce considerable error, especially on days with exceptionally low or high pressure.
If ADS-B has Geometric altitude available, this would be the one to take and feed back to the tablet.
Very good point Chris!
although I suppose at the end of it all, pilotaware is there to give a reasonable early warning... you should have either spotted it by eye or with the help of pilotaware by then (otherwise time for a new pair of specs!)
rgds
Andy
-
Hi All,
Having read up on this I believe this to be the current position.
ADS-B transponders can supply Barometric and GNSS altitude, in other words the altitude
based upon QNE 1013.25mb, and also altitude reported by the GNSS.
In many cases it appears that the GNSS component is missing from the data, BUT the QNE is always
present.
I have provided an entry in the http interface to allow you to enter the QNH, this is then used to translate
the barometric altitude reported by ADS-B to the equivalent GNSS altitude.
This is a first step solution.
In parallel, I am in the process of adding a barometric pressure sensor to my Prototype board, so that
this calculation can be managed without the user having to dial in the QNH.
The http interface can be maintained to provide backwards compatibility to early versions without a
pressure sensor.
Thx
Lee
-
Bad Elf Pro+ allows you to use either GPS derived height or barometric using it's on-board sensor, but it's a bit convoluted to calibrate it each time so I tend to stick with GPS.
Certainly be keen to see a bar sensor on the PilotAware and with the 'Slice Prototype board' there is plenty of space and pads to add things like this, and depending how it's interfaced to the Pi, the connectivity is already there.
-
Hi All,
OK, Solution implemented for this issue, I now have a version of PilotAware with a Barometric Pressure Sensor fitted, and just completed the software/kernel modifications.
So height from PilotAware -> ADS-B traffic will use the Pressure altitude based upon 1013.25mb. This can either be calculated by the use of the builtin Barometric Pressure Sensor, or if no pressure sensor is available, it will use the QNH value (entered through the web interface) to calculate the Pressure Altitude based upon the QNH/GNSS
Height calculations from PilotAware -> PilotAware is always done using GNSS
Pressure sensor used is this one
Thx
Lee
-
Hi Lee
I am presuming there is no room in the existing box to fit the additional barometric pressure sensor - that is the curvy side one pictured. I guess it will need new headers etc? I don't think we have much room in our boxes anyway!
I see there are 'standard' barometric units for use in arduino and Raspberry Pi on the net - I think one is BM180?
dave t
-
Hi Lee
I am presuming there is no room in the existing box to fit the additional barometric pressure sensor - that is the curvy side one pictured. I guess it will need new headers etc? I don't think we have much room in our boxes anyway!
I see there are 'standard' barometric units for use in arduino and Raspberry Pi on the net - I think one is BM180?
dave t
This will easily fit in the standard box, it is tiny
-
Stupid question
Does this mean that if you have an ADSB equipped transponder already fed by an Altitude Encoder the barometric pressure sensor isn't needed - because it is only used if feeding data from pilotaware into a mode s transponder, or is the situation as below
In order for altitudes shown on Skydemon to be comparable with a received ADSB signal the pilotaware will require a barometric sensor (or the QNH updated manually in the web page)?
Dave T
-
Lee
Spoken with the boss (John Parker) - we are going to add the barometric sensor into all our boxes - when you are able to give us the pin outs etc. We have ordered the magic bit (x10)!!!!!!!
Dave t
-
Lee
Spoken with the boss (John Parker) - we are going to add the barometric sensor into all our boxes - when you are able to give us the pin outs etc. We have ordered the magic bit (x10)!!!!!!!
Dave t
Hi Dave,
Its pretty simple actually, it uses the i2c interface, so only 4 wires to connect from the sensor,
GND
GPIO pin 6, 9, 14, 20, 25 - take your pick !
3.3v
I have used the 3.3v from the GPIO header pin 1 (for expediency), this is only rated at 50mA, so
I would recommend using the 3.3v from the regulator if you are able.
SCL
GPIO pin 5
SDA
GPIO pin 3
I1
unconnected
I2
unconnected
Let me know if that is clear. I will update the build guide at some point.
Thx
Lee
-
Have ordered two to add to my built boxes - this will fit quite happily to the Slice of Pod board. Again, happy to test the software when I get these installed (5 min jobbie )
The module says its temperature compensated - is there an issue with this getting baked on the instrument panel coaming?
Mark.
-
Hi Dave,
Does this mean that if you have an ADSB equipped transponder already fed by an Altitude Encoder the barometric pressure sensor isn't needed - because it is only used if feeding data from pilotaware into a mode s transponder, or is the situation as below
In order for altitudes shown on Skydemon to be comparable with a received ADSB signal the pilotaware will require a barometric sensor (or the QNH updated manually in the web page)?
Complicated, isn't it ???
This is nothing to do with the Altitude you are transmitting through your transponder, it is about comparing
relative heights between yourself and surrounding traffic.
ADS-B contains the Pressure Altitude, so altitude based upon an altimiter setting of 1013.25mb.
In order to correctly compare to ADS-B altitude against our own altitude, we need to either
1. Adjust the GNSS altitude using the given QNH
2. Use our own Pressure Altitude
The heights of traffic passed to SD, RunwayHD etc are relative +/- heights to our own position, not absolute heights.
So in order to calculate those relative height differences, in the case of ADS-B, we compare to our Pressure Altitude
in the case of PilotAware we use our GNSS Altitude.
The Navtool simply receives a message indicating the relative traffic height.
I hope that is clear
Thx
Lee
-
Have ordered two to add to my built boxes - this will fit quite happily to the Slice of Pod board. Again, happy to test the software when I get these installed (5 min jobbie )
The module says its temperature compensated - is there an issue with this getting baked on the instrument panel coaming?
Mark.
I did some hand calculations, and I was not too concerned about the total impact it would have on the altitude figure.
What we are trying to do here is make the figures more accurate, they are never going to be within 30cm which is the
claim on the datasheet.
Unless you know something I don't ?
-
hi Lee
perfectly clear, pin outs simple - but how to dismantle our IDE connector and insert extra cables I'm not too sure. We have the digole module all soldered and glued so don't want to disturb soldered cable on the digole board. Unfortunately we cut off unused cable on the ribbon! Damn!
I'm sure we'll sort it somehow
Will implement as soon as the devices come. We have 7 working Pilotaware but I can, as yet, only confirm 2 with successful arf transmissions - progress is being made.
Fenland have a LAA and ultralight fly in this weekend (19th Sept) John Parker is suggesting we also use it as a PilotAware hotspot and meet up? What do you think - if OK I'll put a topic on the forum
we will have 2 in planes by then not sure about the rest of them - we are still in initial ground testing
dave t
-
Cool - ordered a couple of MPL3115A2 s. Looking forward to the s/w update.
-
The majority of the GA fleet (being old) will have a best altitude encoder resolution of 100ft (GRAY code 1bit = 100ft). More modern serial encoders MAY report to 25ft if set up to do so. As there is no way of knowing which encoder is fitted to a target aircraft 100ft (minimum) has to be assumed. Built in barometers in devices not connected to pitot will also suffer from cockpit air compressive effects. So that's really 100ft at best AND if the encoder has been properly calibrated. Some encoding altimeters can also be way out. Just walk around a hanger......
I don't think vanilla FLARM has a barometer but it is only looking at other FLARM for collision so they have a known calibration and resolution playing field. PowerFLARM definitely does have a pressure sensor.
So in our case we have a number of differing possible sources for reported FL to contend with.
For my 2p if it reports closer that 300ft above or below I'd consider it as a threat even with a barometer fitted inside our boxes.
-
Great Post,
I had no idea some Pressure Sensors were so inaccurate.
The Sensor I have been using seems very good, it claims 30cm of accuracy, which is way above what is required.
My understanding was that Mode S transponders had altitude reporting in steps of 25ft, I cannot find any
information regarding calibration inaccuracy.
Bear in mind that PilotAware is only using information from Mode S using ADS-B or other PilotAware units, so I
was under the assumption that the Mode S figures would be reasonably accurate.
There are situations where Aircraft fitted with both ADS-B and PilotAware would be transmitting 2 Altitude figures
1. The ADS-B Pressure Altitude
2. the P3I GNSS Altitude
At the receiving end, I use ADS-B in preference to PilotAware, in other words I receive 2 records of information with the
same ICAO code, lets say 0x40abcd
0x40abcd (ADSB) Pressure Altitude
0x40abcd (P3I) GNSS Altitude
If I wanted I could change the Altitude transmitted by P3I to be the Pressure Altitude, or even send GNSS & Pressure
altitude on alternating packets with an indicator to identify what is being reported.
I need to think on this a little further to decide which is the best piece of information to use
-
There are plenty of Mode S Garmin transponder upgrades out there that retained a pre-installed GRAY encoder. The ubiquitous Ameri-King AK-350 is 100ft.
I note OGN's tracker protocol has a bit to declare whether altitude is Geo or pressure. I also read OGN refuse to play the traffic avoidance game at all.
http://wiki.glidernet.org/ogn-tracking-protocol (http://wiki.glidernet.org/ogn-tracking-protocol)
I know it's a moot point with you Lee but have you thought about cooperation. For me today FLARM or OGN targets are a much greater risk to us than the current very sparse ADS-B stuff. 5 years time perhaps..
-
Been thinking about the connections for the MPL3115A2 with the Slice of POD.
I think this would be correct (?) ...
-
For ref: the other side of the SOP ...
-
Been thinking about the connections for the MPL3115A2 with the Slice of POD.
I think this would be correct (?) ...
This is the version I used
https://www.sparkfun.com/products/11084
Your version looks slightly different, do you have a datasheet ?
It looks like it also has a 3.3v Regulator on board, and the 3.3v is labeled 3vo - is this an output ?
If so I would say it probably requires 5v input rather than 3.3v input - difficult to say without a
datasheet
Thx
Lee
(UPDATE)
Found the Adafruit description
Using the sensor is easy. For example, if you're using an Arduino, simply connect the VDD pin to the 5V voltage pin, GND to ground, SCL to I2C Clock (Analog 5 on an UNO) and SDA to I2C Data....
So this already has a regulator built in - I wonder what it can supply on its 3.3v output ?
-
Ah yes - got that diagram slightly wrong - will remove it and correct it later.
Yea - I wonder whether it would drive the ARF - academic with the SOP board but curious.
-
Corrected SOP diagram with 5v connections to the Adafruit MPL3115A2.
EDIT: Added it as described in my diagram and on the new software build it indicates it is working :)
-
Our MPL 3115A2 have arrived
Will install next week
Can I get on and wire up without a updated operating system?
dave T
-
Our MPL 3115A2 have arrived
Will install next week
Can I get on and wire up without a updated operating system?
dave T
Yes the current version will simply ignore the hardware, the new version which I can give you early access
will configure and use this in preference to the manual value in the web interface
Thx
Lee
-
Just to muddy the waters a little more wrt altitude accuracy, although these I2C sensors are very accurate, in a light aircraft with an enclosed cockpit the sensor will be indicating cabin pressure. This could be quite different to static pressure. Totally useless in a pressurised cabin of course.
-
Corrected SOP diagram with 5v connections to the Adafruit MPL3115A2.
EDIT: Added it as described in my diagram and on the new software build it indicates it is working :)
Sorry if this is a stupid question, but just to check (as I know nothing), your diagram and text indicate that the power supplied to the MPL3115A2 is 5v, but the device specs seem to state a max of 3.6v and the units I have, have 3.3v printed against the power pin 2. Is it safe to get the 3.3v from the RPi IDC pin 1 or should it be taken from the Digole (and from where?)
-
Ian is using a different module.
There are two. One (hobbytronics type - http://www.hobbytronics.co.uk/mpl3115a2-pressure-temp-sensor ) is 3v3 supply. The type that Ian has used which is the Adafruit one ( https://shop.pimoroni.com/products/adafruit-mpl3115a2-i2c-barometric-pressure-altitude-temperature-sensor ) is 5V supply but also has a (weedy) voltage regulator on board that can supply 3v3 - your choice as they both do the same thing but my preference is for the hobbytronics one as there really is no need when using the SoP board to use 5V and the regulator is superfluous.
The Baro module is very low power so you can use the 3v3 supply directly off the RPi without issue - or take it off the Digole if that's what you are using (sorry, thought you were using the SoP board).
-
Thank you for such a clear and speedy answer.
-
Lee
MPL 3115A2 added and seen in the web interface, status changes to on when go flying is selected.
When will the next update of the software be issued?
regards
Steve
-
Just to muddy the waters a little more wrt altitude accuracy, although these I2C sensors are very accurate, in a light aircraft with an enclosed cockpit the sensor will be indicating cabin pressure. This could be quite different to static pressure. Totally useless in a pressurised cabin of course.
Aaahhh yes, I was wondering when somebody was going to notice that one
(apologies to Capt. Mainwaring)
Yes clearly you are right.
I think in this instance, there are only two potential solutions
1. PilotAware needs to be outside the pressurized cabin.
2. The BMP sensor needs to be overriden and use GNSS with a dialled in QNH
this is already supported through the web interface, except when the system recognizes
a BMP sensor, it ignores the dialled in pressure :-\
seems like the dialled in pressure needs an 'auto' select capability
-
For those of us lucky to have our own Permit to Fly aircraft who can legitimately tinker with the aircraft systems...
Would putting the barometric board in a separate, sealed box that we then attach into the aircraft's static source be the proper solution?
With this in mind is there a maximum length for the lines between the barometer board in its 'sealed' box and the GPIO / Slice of Pi etc.
-
In an ordinary light aircraft will it really make that much difference ?
I doubt we'll see many pressurised aircraft with PAs - if you have one it will probably have full ADS-B in/out + Mode S already or if not, soon.
-
Hello Lee,
I have sourced the baro sensor could you please point me in the direction of wiring diagrams and implementation of the baro unit?
Many thanks
Steve
Hi All,
OK, Solution implemented for this issue, I now have a version of PilotAware with a Barometric Pressure Sensor fitted, and just completed the software/kernel modifications.
So height from PilotAware -> ADS-B traffic will use the Pressure altitude based upon 1013.25mb. This can either be calculated by the use of the builtin Barometric Pressure Sensor, or if no pressure sensor is available, it will use the QNH value (entered through the web interface) to calculate the Pressure Altitude based upon the QNH/GNSS
Height calculations from PilotAware -> PilotAware is always done using GNSS
Pressure sensor used is this one
Thx
Lee
-
It's pretty simple.
If you have the 3.3v baro sensor as described by Lee:
3.3v -> Baro Vin
GND -> Baro GND
GPIO SDA (pin 3) -> Baro SDA
GPIO SCL (pin 5) -> Baro SCL
If you have the 5v Adafruit baro sensor (as I used):
5v -> Baro Vin
GND -> Baro GND
GPIO SDA (pin 3) -> Baro SDA
GPIO SCL (pin 5) -> Baro SCL
Note that the Adafruit baro has a Vo (3.3v output), not to be confused with the 5v Vin !
-
Re: pressure sensor, I have fitted the 3.3v unit, bu tit's not being picked up.
Apart from the physicl connections is there anything else that needs doin? (I am using the 3.3v from the GP10 Connector (Pin 1), is this ok?)
Software is 200151003, though for some reason in the config it shows as 20151005 which I presume is just a typo?
-
First get everything running inc SkyDemon or similar end to end, then check the config at 192.168.1.1 - it might be ok
If not I'd take the 3.3v from your ARF 3.3v supply and check with multimeter
-
Cheers Ian, I have checked it and it is definately not being picked up, I'll try your suggestion of the using the 3.3 from my regulator.
-
Cheers Ian, I have checked it and it is definately not being picked up, I'll try your suggestion of the using the 3.3 from my regulator.
Hi Russ,
You say it is not picked up, is this because you are looking in the web interface ?
Try connecting your Nav device to PAW first, then refer back to the web interface.
I think until the BMP device is read (as a request from the NAV device) it does not update the web interface
Thx
Lee
-
Tried that Lee, but it still says "unavailable using manual"
Iv'e triple checked the wiring, think i may have a duff Baro sensor, ordering another to check
-
Tried that Lee, but it still says "unavailable using manual"
Iv'e triple checked the wiring, think i may have a duff Baro sensor, ordering another to check
Russ,
Which baro have you got, I know there are 2 types, one which takes a 3.3v supply, and one which takes a 5v supply, and OUTPUTS a 3.3v supply
Thx
Lee
-
Lee, it's the 3.3v one, Looking at it this morning I may have blown it with some dodgy soldering,( Injured my shoulder, last week and my soldering skills were bad enough before.)
Luckily evrything else is still working
got one coming on the pi shield from John now, so will be ready for when im back up flying
cheers mate
-
Lee, it's the 3.3v one, Looking at it this morning I may have blown it with some dodgy soldering,( Injured my shoulder, last week and my soldering skills were bad enough before.)
Luckily evrything else is still working
got one coming on the pi shield from John now, so will be ready for when im back up flying
cheers mate
My soldering skills are still sharp, its my eyesight that is the problem on some of the very small footprints!
-
Hi All,
I've fitted the pressure sensor today, how do I know if it's working???
-
I've got "Pressure Altitude (BMP) - Enabled (Auto) QNH=1025 QNE-1131ft GNSS=95ft" so I am assuming that's working and I don't need to do anything else? Do we need to add the pertinent QNH issued manually or is this calculated automatically comparing pressure altitude to GNSS?
-
I've got "Pressure Altitude (BMP) - Enabled (Auto) QNH=1025 QNE-1131ft GNSS=95ft" so I am assuming that's working and I don't need to do anything else? Do we need to add the pertinent QNH issued manually or is this calculated automatically comparing pressure altitude to GNSS?
Great! Siunds like you have it working.
You only add the manual value when the bmp is not present
Thx
Lee
-
I'm using the JCurtis shield with built in barometric sensor. I'm getting:
Pressure Altitude (BMP) - Enabled (Auto) QNH=1013 QNE-0ft GNSS=263ft"
The pressure according to another barometer I have in the room here, at this altitude, was 1012 yesterday and 1009 today. But I'm not getting anything different reading out here. Do I have a duff board? Or do I need to enable something?
Ah, I just read this bit on the previous page:
Try connecting your Nav device to PAW first, then refer back to the web interface.
I think until the BMP device is read (as a request from the NAV device) it does not update the web interface
I don't have a nav data device at the moment (can you persuade the authors of Air Nav Pro on Android to support it?).