Important: These forums are for discussions between SkyDemon users. They are not routinely monitored by SkyDemon staff so any urgent issues should be sent directly to our Customer Support.

Flarm data / checksum error causes exit from navigation mode on Android


Author
Message
Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
I'm using 3.13.3.0 on an Android tablet - Samsung S2 - with data from a Powerflarm via an Airconnect wifi interface. 

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


Tim Dawson
Tim Dawson
SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)
Group: Forum Members
Posts: 7.8K, Visits: 8.4K
Could you please post a screenshot or the exact error you saw? "Flarm data invalid" is not a message in SkyDemon so we don't know exactly what is happening from your post.

We do not halt navigation mode on receipt of an invalid checksum.

Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
Tim Dawson - 1/20/2020 10:42:23 AM
Could you please post a screenshot or the exact error you saw? "Flarm data invalid" is not a message in SkyDemon so we don't know exactly what is happening from your post.

We do not halt navigation mode on receipt of an invalid checksum.

Sorry you are right. I mis-remembered the exact error message.  It was actually "Unexpected GPS data encountered:" Here is the screen dump. It looks like a block of data has got lost somewhere. 

Build is 16732
Anyway it dumps Skydemon out of Nav mode and I can reproduce it but just leaving it sitting in navigation mode static on the ground. 
The extra error messages regarding lack in internet connection appear after the error has occurred and it has dropped back into planning mode.  The wifi connection is still up when the error occurs. 

Regards,
Alastair 

Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
Alastair Mutch - 1/20/2020 1:57:16 PM
Tim Dawson - 1/20/2020 10:42:23 AM
Could you please post a screenshot or the exact error you saw? "Flarm data invalid" is not a message in SkyDemon so we don't know exactly what is happening from your post.

We do not halt navigation mode on receipt of an invalid checksum.

Sorry you are right. I mis-remembered the exact error message.  It was actually "Unexpected GPS data encountered:" Here is the screen dump. It looks like a block of data has got lost somewhere. 

Build is 16732
Anyway it dumps Skydemon out of Nav mode and I can reproduce it but just leaving it sitting in navigation mode static on the ground. 
The extra error messages regarding lack in internet connection appear after the error has occurred and it has dropped back into planning mode.  The wifi connection is still up when the error occurs. 

Regards,
Alastair 

Hmmm....
When I connect to the airconnect wifi with my PC and capture the port 2000 data output to a log file using telnet I can see frequent data errors in the data stream due to what looks like missing bytes / blocks of data..   I'll investigate further to see what my actual problem is.  This is with a single device connect to the airconnect and the serial interface from flarm to airconnect only runnng at 19200baud. 

If it is possible to get Skydemon to not exit navigation mode on a datastream error that would still be good.

Alastair


Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
Alastair Mutch - 1/20/2020 5:03:40 PM
Alastair Mutch - 1/20/2020 1:57:16 PM
Tim Dawson - 1/20/2020 10:42:23 AM
Could you please post a screenshot or the exact error you saw? "Flarm data invalid" is not a message in SkyDemon so we don't know exactly what is happening from your post.

We do not halt navigation mode on receipt of an invalid checksum.

Sorry you are right. I mis-remembered the exact error message.  It was actually "Unexpected GPS data encountered:" Here is the screen dump. It looks like a block of data has got lost somewhere. 

Build is 16732
Anyway it dumps Skydemon out of Nav mode and I can reproduce it but just leaving it sitting in navigation mode static on the ground. 
The extra error messages regarding lack in internet connection appear after the error has occurred and it has dropped back into planning mode.  The wifi connection is still up when the error occurs. 

Regards,
Alastair 

Hmmm....
When I connect to the airconnect wifi with my PC and capture the port 2000 data output to a log file using telnet I can see frequent data errors in the data stream due to what looks like missing bytes / blocks of data..   I'll investigate further to see what my actual problem is.  This is with a single device connect to the airconnect and the serial interface from flarm to airconnect only runnng at 19200baud. 

If it is possible to get Skydemon to not exit navigation mode on a datastream error that would still be good.

Alastair


I fixed it by increasing the serial interface speed between the Flarm and Airconnect from 19k2 up to the maximum of 56k7 baud. It looks like a problem in the Flarm firmware in how it handles multiple messages getting queued up when it gets busy.  I'm on the approach ot Edinburgh airport so the rate of messages increases when Mode C / ADSB stuff is going past but it should still be able to handle the data at 19k2 but seems to be overwriting buffers or FIFO data. There are warnings in the flarm manual about losing data if there are too many messages for the baud rate. .  
. .  
I've left it running for an hour whilst monitoring the data on my PC and it all looks good - no missing data.  Problem solved.  

Alastair


Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
Alastair Mutch - 1/20/2020 7:47:28 PM
Alastair Mutch - 1/20/2020 5:03:40 PM
Alastair Mutch - 1/20/2020 1:57:16 PM
Tim Dawson - 1/20/2020 10:42:23 AM
Could you please post a screenshot or the exact error you saw? "Flarm data invalid" is not a message in SkyDemon so we don't know exactly what is happening from your post.

We do not halt navigation mode on receipt of an invalid checksum.

Sorry you are right. I mis-remembered the exact error message.  It was actually "Unexpected GPS data encountered:" Here is the screen dump. It looks like a block of data has got lost somewhere. 

Build is 16732
Anyway it dumps Skydemon out of Nav mode and I can reproduce it but just leaving it sitting in navigation mode static on the ground. 
The extra error messages regarding lack in internet connection appear after the error has occurred and it has dropped back into planning mode.  The wifi connection is still up when the error occurs. 

Regards,
Alastair 

Hmmm....
When I connect to the airconnect wifi with my PC and capture the port 2000 data output to a log file using telnet I can see frequent data errors in the data stream due to what looks like missing bytes / blocks of data..   I'll investigate further to see what my actual problem is.  This is with a single device connect to the airconnect and the serial interface from flarm to airconnect only runnng at 19200baud. 

If it is possible to get Skydemon to not exit navigation mode on a datastream error that would still be good.

Alastair


I fixed it by increasing the serial interface speed between the Flarm and Airconnect from 19k2 up to the maximum of 56k7 baud. It looks like a problem in the Flarm firmware in how it handles multiple messages getting queued up when it gets busy.  I'm on the approach ot Edinburgh airport so the rate of messages increases when Mode C / ADSB stuff is going past but it should still be able to handle the data at 19k2 but seems to be overwriting buffers or FIFO data. There are warnings in the flarm manual about losing data if there are too many messages for the baud rate. .  
. .  
I've left it running for an hour whilst monitoring the data on my PC and it all looks good - no missing data.  Problem solved.  

Alastair


I spoke too soon. I got an Unexpected GPS error after a couple of hours.  The data stream looks clean and I can't spot the error in the log file captured on the PC but obviously it still has a very occasional error GPS sentence.   

Any chance of getting this handled less "hard" in Skydemon please? 

I don't have any expectation of the Flarm firmware getting improved to completely eliminate the error - assuming that is the source.  One error in the data stream every couple of hours is not ideal but the current handling of the error is likely to cause more problem than the data error itself. 

Alastair


Tim Dawson
Tim Dawson
SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)
Group: Forum Members
Posts: 7.8K, Visits: 8.4K
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.

Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
Tim Dawson - 1/21/2020 11:01:59 AM
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
 

 

Tim Dawson
Tim Dawson
SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)SkyDemon Team (617K reputation)
Group: Forum Members
Posts: 7.8K, Visits: 8.4K
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?

Alastair Mutch
A
Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)Too Much Forum (66 reputation)
Group: Forum Members
Posts: 17, Visits: 0
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

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search