AirConnect protocol about softrf HOT 9 CLOSED

AirConnect is one of several inactive experimental features that I still not decided what to do with - either advance or deprecate.
So far as it is not an enabled feature - no any bugs are applicable for it.

AirConnect protocol is fading away now and is giving a way to Garmin GDL90 even on the EU market.

Current implementation of the AirConnect in SoftRF is fine to me since it works Ok with XCSoar and SkyDemon. It is not enabled by default because of:

1. TCP on ESP8266 is weak and not very reliable when SoftwareSerial operation (GNSS read) is in progress ;
2. On ESP32 it works better, but shows low flow performance with Android version of XCSoar app (Linux and Windows are fine).

I may give one more chance to the AirConnect few month later. Will see if it works better with AsyncTCP on ESP32.

UDP transfer is of my own preference. GDL90 works good with SkyDemon. And AirNav Pro is known to have kinda "hidden" support for this Garmin protocol: https://github.com/0sander/stratux_air_nav_pro

Current SoftRF implementation of AirConnect has one-way flow only. As I said before, it is Ok for XCSoar and SkyDemon. Other apps may require to do a handshake, say, to enter a pin number: https://www.air-avionics.com/support/Connect_Manual_EN.pdf or something else.
Even a FLARM data link connected device (like LX Nano3) may expect to do some handshake prior to actual data transfer, see this ticket: #19

Sure you are free to fork a copy of my repo and make yourself happy by doing your own development in there. If I will see something valuable there - we may talk then about pull requests & integration....

If you are ready to participate in advancement of AirConnect in the SoftRF - I will re-assign this ticket back to you. If not - please, close it.

from softrf.

I'll have a look into it, please assign to me!

from softrf.

I implemented the correct handshake now but Air Navigation Pro is still not working. Seems it has to do with the GPRNC/GNRNC NMEA sentences but I'll need to do a complete record of a working connection to a real AirConnect device with Air Nav Pro. So still on it...

from softrf.

Was a problem with a missing "\n". The AirConnect protocol waits for four digits and then starts sending the NMEA output if password is correct. Implemented in PR #34 .

from softrf.

Try out this commit: c0038e1

It works for me:

And, please, double check that no any CRs or LFs after PASS? and AOK are actually in use in genuine AirConnect. Because I would prefer to see a better look in the monitor window.

from softrf.

In genuine AirConnect no CRs or LFs are used. It only sends "PASS?" and waits for either LF or exactly four bytes of data without LF and then sends "AOK" if password is/was correct. After that directly the NMEA data is sent. So I don't know if your version will work 100% as it doesn't count the four bytes but instead has a timeout. I'll try!

from softrf.

My opinion that this is an Air Navigation Pro's issue.
SkyDemon is smart enough - when it already sees NMEA sentences in the input stream - there is no need to enter pass codes anymore.
XCSoar does not care about handshake at all.

I am definitely not going to break compatibility with XCSoar, LK8000 and SeeYou as most of glider pilots use this software on daily basis, just in order to make few AirNav Pro users happy.

from softrf.

I'll try with Air Nav Pro and most probably it's supposed to work with the timeout solution even if it's not the correct AirConnect protocol standard. So I can't tell you where the issue is exactly located. Let's find a solution to make all app's users happy.

from softrf.

Works with Air Nav Pro. But ANP still says "Bad GPS for navigation", probably something with GPRMC vs. GNRMC. But that's another problem.

from softrf.