They can as long as all the required data is provided.
What does this actually mean? The data stream is NMEA, is standard, and the data is whatever the receiver computes. For example the TAS6xxA IM has this table
103,110,111,112,370 can be extracted from any GPS.
203 comes from an altitude encoder, possibly via a GTX330 or some such if available only as gray code.
110,111 are identical bit for bit to 310,311 (except for the label); I have just written the code to do all these. If ADS-B IN needed higher resolution than these, they could have made these mandatory
but they haven’t, 20m is clearly enough.
166,174 are not needed (if 103,112 are provided). No idea about 247.
136,146 seem optional, but they also come out of the GPS data.
Peter wrote:
They can as long as all the required data is provided.What does this actually mean? The data stream is NMEA, is standard, and the data is whatever the receiver computes. For example the TAS6xxA IM has this table
Compare the list of labels provided by ARINC 429 on a GNS 430 (TSO C129) or GNS 430W (TSO C146) verses those provided on a GNS 480 (TSO C146) which includes ARINC 743A labels. The GNS 480 provides the ARINC labels needed for a compliant ADS-B source via an ARINC 429 port, the GNS 430 and 430W do not. The GNS 430W and GNS 480 provide the needed data on a serial port set to ADS-B Out+. The GNS 430 could have supported the needed data via either ARINC 429 or via a serial port, but it did not, because there wasn’t an ADS-B Out requirement prior to them being discontinued from production and engineering support.
All these GPS position sources provide latitude/longitude, ground speed, true track angle, and gps altitude in one form or another, but only the GNS 480 and the GNS 430W also provide the HPL, VPL, HFOM, VFOM, HAE, and position to the required precision needed. TSO C129 and TSO C196 stand alone position sources are used in high end business aircraft and by air carrier as position source input to FMS systems. There are those that are programmed to provide the required data and therefore can be used also as an ADS-B Out position source. There are use restrictions that the pilot needs to consider before flying into rule airspace with these non WAAS position sources. Here is a link to an FAA order with guidance on using non WAAS position sources local copy
I found this in the GNS480 / CNX80 IM
and sure enough they are outputting both Coarse and Fine GPS data. I guess they wanted to create maximum compatibility with other stuff – unlike the big names which look at which other boxes they want to sell, first.
I’ve been looking at label 136 (and 247). It supports a huge range. Surely there is normally some max value which is required for ADS-B?
247 goes up to 16nm!
HFOM is what is used for the accuracy measurement and an ADS-B Out system will convert it to NACp code. HPL is the integrity value used to set the NIC code. In the US, inside of the rule airspace, one needs a NACp of 8 or greater and a NIC of 7 or greater in order to be admitted into the airspace. NACp of 8 is an HFOM or accuracy of .05 NM. A NIC of 7 is a containment radius or HPL of <0.2 NM. Regardless of the local NIC or NACp, the value is broadcast by an ADS-B Out unit. NACp can have a code that ranges between 0 and 11 which represents an HFOM between >10 NM and 3 meters. NIC is a code that ranges between 0 and 11 and represents an HPL > 20 NM to 7.5 meters. Usually a non compliant position source will not provide HPL or HFOM, so the ADS-B out system broadcasts zero for both NACp and NIC, or iOW unknown accuracy and containment radius. As a side note, WAAS GPS systems are supposed to display HFOM and VFOM on the satellite page to the pilot. Most pilots don’t have a clue what they mean. HPL and VPL are not normally displayed to the pilot, but the GNS480 does display it.
Thank you. I’ve been digging around for what sort of values would be required for the GPS data feeding an ADS-B IN device, and found some examples.
NACP of 8 is 93m which is trivial to get from any GPS once it has a reasonable fix, and this would correspond to an HFOM (label 247) of 0.05nm.
But, working from NMEA, you don’t get HFOM or VFOM. You get HDOP and VDOP. Somehow HFOM is calculated from HDOP.
I have not found much about VFOM, other than it can be calculated as VDOP *12 so this is simple, from NMEA.
As a note, HDOP and VDOP are purely satellite geometry numbers and would be the same for any type of GPS, at a given location and at a given moment.
Could perhaps be used for an analogue radio altitude input to an autopilot such as SPZ200 or maybe to output 40mV/mile DME distance for an FMS.
There can’t much meat left in that King Air business now, surely?
It is very easy to do though. I could knock this up in an hour with the board I have here.
What is harder is going analog to ARINC429. One needs to know about the application and what is expected.
@wigglyamp what would be the DME label? I found the RADALT label is 164.
I’ve had more fun with ARINC429 
This PCI card, from c. 2004, turned up on Ebay in Germany, for about 500.
The damage was spotted after it arrived (repaired under a microscope). I didn’t think something that obscure would ever sell, especially without any software, so I offered him €150. No reply. I even asked a friend in Germany to make an offer No reply. And sure enough it didn’t sell. 8 months later he dropped it to €200 so I bought it.
Amazingly the existing software mentioned above works with this PCI card, even installing the drivers automatically. The company, MAXT, still supports it, too.
Like the PCMCIA card it does four channels but the free license opens just one channel (tx and rx). And here it is working:
All those labels are generated, at 5Hz, from a U-BLOX WAAS/EGNOS GPS module, for £10, RS232 in, 38400 baud As before, STM ARM 32F417 running at 168MHz. Cube IDE, all in C, under FreeRTOS. The CPU is also running ethernet, USB, all kinds of other crap.
