Initial version GxAirCOM compatibility geared towards usign FLARM

[rvt]

This requires a modified version of GxAircom Allows to set Address, Pilot name and Aircraft Type Enables FLARM and Fanet Uses the GxAirCom GPS for navigation

[b3nn0]

Is it finished/should I review? or work in progress?

[b3nn0]

Actually, just looked over it and seems fine to me, I like the other stuff too (non-root handling etc). Only thing I noticed is, that some of the indentations are messed up (gen_gdl90.go and gps.go). Mind fixing those?

[rvt]

Will take a look it the indentations.. One additional thing I will be adding is similar to OGN, is adding the correct firmware to Stratux so users can program the t-beam from bash.

[b3nn0]

Ah, I just noticed that this will only work with your fork of GxAircom (or if your PR over there is merged, but it doesn't seem to be too active with merging PRs..), correct? Would it be possible to also allow changing the "Address Type" then? it is kinda important: two received aircraft with same address, but different address type are regarded as two different aircraft. So if someone sets his transponder ID in there, but the address type is "FLARM", then most traffic receiver will not merge the two transmissions.

[rvt]

I have submitted a PR to GxAirCom but ofcourse we will have to see if it get's accepted. But it does allow to set the pilot name and address and aircraft type from stratux, and stratux will query it's setting to ensure GxAirCom will be put in a state suitable for Stratux to ensure both mode-s and FLARM Id are the same.

[b3nn0]

yes, the ID might be the same, but if the "address type" is different, then it will still be detected as different aircraft. The user needs to specify if the configured address is just a random one he chose (e.g. because he doesn't even have a transponder), a registered FLARM address (unlikely I guess), a registered OGN address or a registered ICAO address. FLARM address AABBCC is not the same as ICAO address AABBCC.

[b3nn0]

Added some tweaks.. two things remaining for me right now:

• On my ancient Ublox M6 T-Beam, it kinda works, the hotspot comes up, but NMEA output over serial is disabled by default (could this be changed?). However, when I enable it, I just get

  [I][main.cpp:4349] setupUbloxConfig(): ublox: Trying baudRate=9600 0/5
  [I][main.cpp:4349] setupUbloxConfig(): ublox: Trying baudRate=19200 1/5
  [I][main.cpp:4349] setupUbloxConfig(): ublox: Trying baudRate=38400 2/5
  [I][main.cpp:4349] setupUbloxConfig(): ublox: Trying baudRate=57600 3/5
  [I][main.cpp:4349] setupUbloxConfig(): ublox: Trying baudRate=115200 4/5
  [E][main.cpp:4354] setupUbloxConfig(): ublox: Could not connect to GPS with any baudRate

  OgnTracker has no problem opening the GPS. It reports TaskGPS: 57600bps

EDIT: never mind about this one, had to select the correct board type. However, it then reboots, and all settings are gone, I.e. no output over serial again...

• On my newer Ublox 8 T-Beam, I simply get nothing. No NMEA, no hotspot, not even some ogging via serial (baud 115200). It's completely dead until I flash OGNTracker again

What am I doing wrong? If I can't get it to work, users surely won't be able to either...

[rvt]

• I will add a option to enable/disable serial out with the $PGXCF string.

• On why your UBLox 8 T-Beam is not working is hard to tell. I never seen these issues on my t-beam and they where always booting up correctly. But I can see if I can switch to OGN and switch back to see if I can replicate your situation.

What am I doing wrong? If I can't get it to work, users surely won't be able to either... That depends on what is going on, hopefully I can get some insight on it when I do some testing switching between OGN/GxAirCom and perhaps some other firmware to see if I can get myself into that specific situsation.