+x

 

Alastair Mutch - 1/23/2020 1:18:06 PM

+x

 

Tim Dawson - 1/23/2020 11:19:10 AM

I think the situation you describe is easily detected and avoided by TCP/IP itself and the existing checksum mechanism.

If you look at the error you posted, it does not fall into the category of what you just described. It is a whole and complete sentence, but with invalid (broken) fields. Wouldn't you agree?

Err. No. 

In the screenshot above it's a partial GPS sentence with an incomplete Flarm PFLAU sentence appended to it.  The checksum belongs to the Flarm sentence - which is missing its $ prefix.  If it were a CRC checksum then it would be much easier to determine that is was complete and uncorrupted prior to parsing but that boat sailed a long time ago. 

After further investigation I agree that the Airconnect data transfer is what one might call "fragile" or perhaps just "broken" with output data not matching input data.   I'm working with them to see if they can get it a bit better... or even correct.  The serial data output from the Flarm itself looks OK. 

The Airconnect device does detect the LF at the end of a sentence in the data stream and uses this to trigger a TCP/IP wifi packet with a single sentence in it so the example I gave above should never actually happen.  It still seems a bit nasty to the poor user to dump them out of nav mode on a single GPS data error - but it's just a suggestion to change this. 

For me it would be *so* much simpler if Skydemon could accept a BT serial data stream with GPS and Flarm traffic data.  I used to think BT was the spawn of the devil but the current implementations seem to work fairly reliably and it would save all the faffing about with wifi and switching networks. 

Alastair