T-Beam V1.2 not communicating correct GPS data to Stratux

[mpfusion]

When using the ogntracker stratux recognises GPS signals correctly, the number of satellites is reported and the GPS button lights up green:

However, when I flash to GXAirCom (using the command install-GxAirCom-Stratux-firmware.sh from stratux, the output is as follows:

The GPS location and altitude is reported, though. So some communication takes place. In the GXAirCom GUI the data is all there:

So it appears the hardware is okay and GXAirCom can read out the values just fine, but doesn't transmit them to stratux in the correct way.

If you need further information or logs, please let me know.

Hardware: RPi 4B PMU: AXP2101 MCU: ESP32 GNSS: u-blox NEO-M8N LoRa: SX1261

Software: Stratux v1.6r1-eu032 (ff1f01dc41) GXAirCom-v5.3.5-stratux-eu029 build-date: Jul 10 2023 05:46:54

[VirusPilot]

No worries, your T-Beam is correctly providing GPS data to Stratux as you can see with "3D GPS" in your second picture. GXAirCom does not provide detailed satellite info ($GNGSV), therefore there is nothing to display in Stratux.

[mpfusion]

Thanks for the blazing fast reply.

But this begs the question “why doesn't it do that”? Since the GPS button it not lit, stratux seems to expect that info (GPS based AHRS is unavilable) and the hardware provides it (as can be seen in the GXAirCom GUI) and SoftRF and ogntracker also send that info.

[VirusPilot]

Well, it is up to the maintainer of this repo which GPS sentences are provided. I might consider creating a Stratux-compatible fork which would resolve this issue.

[rvt]

You properly need this one : https://github.com/rvt/GXAirCom https://github.com/rvt/GXAirCom

The build scripts in stratux are configured here : https://github.com/b3nn0/stratux/blob/master/Makefile#L90 https://github.com/b3nn0/stratux/blob/master/Makefile#L90 It’s simple to setup the github actions and create a release, see : https://github.com/rvt/GXAirCom/actions https://github.com/rvt/GXAirCom/actions This way Adrian can generate stratux versions together with your version of GxAirCOm.

The guy behind GxAircom is super friendly and helpfull if you need something special or have some ideas.

I don’t have time to maintain this combination any longer

Cheers, Ries

On 25 Oct 2024, at 22:23, VirusPilot @.***> wrote:

Well, it is up to the maintainer of this repo which GPS sentences are provided. I might consider creating a Stratux-compatible fork which would resolve this issue.

— Reply to this email directly, view it on GitHub https://github.com/gereic/GXAirCom/issues/172#issuecomment-2438728852, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFP7LUREWAL7UABIR2WXCLZ5KSEHAVCNFSM6AAAAABQTTTGH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYG4ZDQOBVGI. You are receiving this because you are subscribed to this thread.

[mpfusion]

You properly need this one : https://github.com/rvt/GXAirCom https://github.com/rvt/GXAirCom

I used the version supplied by stratux, which seems to be that very repository, if I understand it correctly. There's no mention of the differences between https://github.com/rvt/GXAirCom and https://github.com/gereic/GXAirCom in the README. If that's the version supplied by stratux (correct me if I'm wrong), I should already have that version, no? Else, what's the deal with that version? How does it differ? Does it fix the GPS issue?

The build scripts in stratux are configured here : https://github.com/b3nn0/stratux/blob/master/Makefile#L90 https://github.com/b3nn0/stratux/blob/master/Makefile#L90 It’s simple to setup the github actions and create a release, see : https://github.com/rvt/GXAirCom/actions

Before building a custom version, I think I'd first raise an issue on the stratux issue tracker to report that their supplied version is misconfigured.

I don’t have time to maintain this combination any longer

Sorry to be ignorant (I'm a new user, bought the device two days ago), but are you suggesting that GXAirCom (which is listed as “experimental” on the stratux site) is deprecated now? The gereic/GXAirCom repo seems to be active as far as I can see.

To get back to the issue: @VirusPilot seems to indicate that GXAirCom could emit the required messages. Instead of creating a fork what would be the downside of enabling those messages by default? Or if that's not desirable, adding a configuration option to enable them on request?

[VirusPilot]

To get back to the issue: @VirusPilot seems to indicate that GXAirCom could emit the required messages. Instead of creating a fork what would be the downside of enabling those messages by default? Or if that's not desirable, adding a configuration option to enable them on request?

If I find time, I can make an upstream PR to add a dedicated platformIO target for Stratux purposes.