A couple of times now I've got a pop-up dialogue saying "Flarm data invalid" along with a flarm data string displayed. Clicking to acknowledge this results in the program going back to planning mode.  This has happened on the ground before take-off only and not in the air (so far at least).

Interesting enough I was playing with the set-up in the house with both the tablet and my PC connected to the Airconnect and Skydemon running in navigation mode on both.  Both were using the current latest version - 3.13.3  When I got the error on the tablet the PC continued quite happily with the data with no errors.

If it is a checksum error on a data sentence please, please, please could you just dump that sentence and continue on to the next. I don't really want to know about what is probably a single bit error in the data transfer.  If there are multiple or frequent errors then by all means put up a warning or refuse to use the data stream.  Yes it shouldn't go wrong... but it obviously can do. 

Thanks.

Alastair

I believe this has been discussed on the forum before. What you're seeing is a situation where the checksum passes, but the data is invalid/nonsense. The fact the checksum passes means whatever third-party device you're using has a bug and it sending invalid data.

We think it's the right thing to do, to stop talking to the device at that point and alert the user. Presumably you'll want to return your device and get one that doesn't emit invalid data.

Hi Tim,

I captured the serial data out of the Flarm on the rs232 port at the same time to see where the problem lies. The data from the Flarm at the time of the error on sky demon was fine and didn't show the same corruption as the error from Skydemon  so it's obviously a problem in the Airconnect / wifi TCP/IP device.. I'll recheck at the lower baud rate and see if that problem is also located in the airconnect device. 

I would say this though.  

We are using a wireless link to transfer the data that is unaware of the underlying data format. Any temporary interruption in the wifi connection will result the possibility of  some data packeets being lost since there is no flow control. The TCP/IP protocol will ensure that packets themselves are either delivered or dropped but there is no way to control how GPS sentences get spilt into different TCP/IP packets - therefore it is entirely possible that on a "good" system in a busy wifi area or with interference causing drop outs that partial GPS sentences will be received, quite probably with the next data sentence appended to it.  A simple checksum will not detect all errors and if these errors that are being thrown up have a valid checksum (I haven't checked myself) then I would say the correct response is to dump the sentence on a parsing error and not fail the system hard. I understand your reasoning for the current handling but don't agree with it.  

I'll go log the data into and out of the Airconnect and then go back to TQ/AirAvionics with hard evidence of the problem.   

I think you should reconsider your handling of this particular error and recognise that a wireless connection is inherently unreliable - therefore consider how it will fail and how best to handle it - without causing the user additional problems by dropping out of navigation mode on a single error. 

Regards,

Alastair