Hi,

I try to use SD together with TRX-1500 Flarm and Airconnect. On almost every flight I get an "Unexpected GPS data encountered" messages popup. It always complains about PFLAA and PFLAU sentences which as far as I can tell are position reports Flarm receives.

Unfortunately it is quite annoying that SD seems to open up 3 to 10 popups (the amount seems random...) about the same sentence and simultaneously kicks itself out of navigation mode. In my opinion this behavior does not contribute to flight safety since you have to fiddle around to much to get SD back and running! And as a side affect, the flight log is broken which means that if I used one of the time tracking functions, they won't spit out a usable result after the flight.

I noticed that behavior on all SD versions since I installed my Flarm in summer last year until today. I am running SD under Android 4.2.2 on a Samsung Galaxy Tab 2.

I also noticed that the more aircraft are in the vicinity which likely have Flarm, the more quickly the  popups appear. So the is a linear trend of Flarms flying around and SD complaining about broken sentences.

SD-Team, can you please change the way SD handles data sentences it deems to be broken in a way that allows the pilot to continue his/her duty of  navigating and to observing traffic. If you still want to track broken sentences, I suggest write them down into a log file for example. In my opinion, it is better for flight safety, to just quietly drop a sentence here and there than waiting for the user to close multiple popups and restart navigation mode.

If there is anything I can do to help you in fixing this issue, please let me know!

Florian

What you are describing is a significant problem with the traffic receiver you have chosen. We have hundreds of customers using that device without any problem, so you should really consider contacting the manufacturer.

If a traffic device starts behaving not to protocol, we immediately shut down communications with it because that is dangerous. That is our policy and it ultimately results in a higher integrity of data, and a more trustworthy experience. You could argue that we could quietly ignore a misbehaving traffic device, but it sounds like yours is behaving really badly and I don't have a problem with what we are doing.

If you like, we could borrow the device to ascertain the exact nature of the failures and report them to its manufacturer, but if you can grab some screenshots that will accomplish the same thing.

Hi Tim,

ok, but how much do you know about the TRX.-1500 and Airconnect? The question now is, are the corrupt sentences produced by the TRX-1500 or is it the Airconnect messing them up?

Might it help if I connect my notebook into the WIFI and log the communication?

Florian

I don't know which product is at fault. We have a TRX1500 and Airconnect in the office for testing, and we have never managed to reproduce the data errors you are seeing.

Certainly a log might be helpful, because we could then run that through our parsers to identify the nature of the corrupt data.

Hi Tim,

let me see, what I can produce next weekend when I am out flying. I will try to document everything as thorough as I possibly can!

Florian

Hi Tim,

so far I could not any tests in. The weather was to bad to get enough other FLARM traffic airborne.

Anyway, I worked through the screenshots I took over the ast few month in order to find anomalies within the data. In the attached spread sheet (Libre Office) you can find different sentences which were rejected by SD. They are pares into the spreadsheet like the CSV import would do (fields would be comma separated).

The column headers are the data structure from FLARM's latest data port interface control document(FTD-012, V7.10). I used current firmware for the TRX-1500and FLARM and the latest SD-Version in Google Play for all tests. So I assume that the FTD-012 document applies to the TRX-1500, too, since it is essentially a PowerFLARM working within.

What I see at first glace is that first, all of the PFLAA targets are quite far away. Also in all sentences the amount of fields does not correspond to the specification and that the order of the fields seems to be messed up.

Anyway, the checksums are still valid.

With better weather approaching I will continue to find out, who messes up the data. The FLARM inside the TRX-1500, the TRX itself, the AirConnect or SD.

Another approach I will try is to drastically limit FLARM's range since all invalid targets seem to be far away and so all seem to be ADSB-Out targets. Thinking of the weather and the amount of GA traffic at these times, I even suspect, these were IFR airlines.

I will let you know, if I find out more.

Florian

thank you very much for your investigations.

Hope you and SD will find the bug.

Peer

Thanks Florian, that's really helpful. Just testing with the first sentence it's obvious that your device is sending very bad data. The checksum is correct, which means the data was NOT corrupted in transit (SkyDemon would have ignored it in that case).

$PFLAA,0,-14084,-259068,-10144,4187,1,3C60D4,129,,209,10.0,8*55

The sixth field in that sentence has a value of 4187. That field is called IDType, and is supposed to have a value from 0 to 3.

We are correct to not only reject that data, but to do so forcefully. A device outputting such bad data has obviously got itself into a very poor state and goodness knows what other bad data it will be putting out.

Let me guess, you are flying in German airspace? Did you check whether this is a windmill obstacle? There is increasing trouble with windmills and other stations getting equipped with non-standard transmitter.