[fdlamotte]

Following #3684 I'll work here on refactoring GPS management

The idea is to keep LocationProvider as the interface to the loop, but adding GpsDriver class to manage low-level things

I also tried to pull all i2c RAK GPS related things out of EnvironmentSensorManager ... this was huge and I hope I didn't do any mistake as I don't have i2c rak gps ... if someone can help me with testing ...

periodic wakeup has been added, and a command is available for the repeater CLI, will make a GPSPrefs class to share gps command between repeater and companion

Still a long way to go (as I've seen lots of bad things in current code with active waits on gps frames for instance !)

[cwichura]

This is exciting to see. Please make sure to factor in the NMEA auto-baud selection from #3729. This fixes GROVE GPS modules from M5Stack, for example. And it would also be good to fold in #3736.

Also, does the common virtual API of the base class facilitate devices like the Thinknode M1 that have a physical on/off switch that relies on the firmware to actually disable/enable the GPS (as opposed to a switch that physically disconnects power from the GPS module)?

[fdlamotte]

This is exciting to see. Please make sure to factor in the NMEA auto-baud selection from #3729. This fixes GROVE GPS modules from M5Stack, for example. And it would also be good to fold in #3736.

Yes, #3729 can easily be implemented in GpsDriver, I think #3736 would better sit in LocationProvider

Also, does the common virtual API of the base class facilitate devices like the Thinknode M1 that have a physical on/off switch that relies on the firmware to actually disable/enable the GPS (as opposed to a switch that physically disconnects power from the GPS module)?

Are you sure the physical button on M1 is not an hw switch as on M5 ?

I've just refactored both to use the same path (because if switch is HW there is no need to poll) but your comment make me think maybe I'm wrong (and I still don't have the M1 to test that)

edit: I have confirmation the switch is purely software on M1 ... too bad. I should probably take care of sw gps switch in the driver then (to keep coherent with the gps state)

[cwichura]

I own a v1 M1. The switch is just a GPIO input; it does not physically disconnect/power down the GPS module in the M1.

[fdlamotte]

Ok, the refactoring has been ported to all ports.

I think I now need some feedbacks on what I possibly have broken ;)

I'm doing tests on my side with what I have ...

The feedback I'd need would be on:

• any RAK board with i2c gps
• Nano G2 Ultra
• MeshTracker X1
• Heltec Tracker
• both Muzi SuperIO radios
• ThinkNode M1
• Heltec Mesh Solar
• MeshAdventurer

I've notice a build issue with meshsolar companions, this predates this PR (also happens in dev)

[cwichura]

I just saw #3760 got opened, which suggests it too has a software GPS switch. (I don't own this hardware, so can't check, myself.)

[IoTThinks]

Look like the new GPS module is coming.
Great.

[fdlamotte]

I just checked the rak serial nmea gps path using a modified variant using rak classes and it works

Still need some input from people using rak with i2c gps module

[nGoline]

Tested on a Muzi Base Uno + SuperIO, following up on #3760.

As-is, the Muzi GPS gets no data: the refactor no longer calls Serial1.setPins() on nRF52, and the Muzi variant.h had PIN_SERIAL1_RX/TX swapped (main only worked because setPins(PIN_GPS_TX, PIN_GPS_RX) swapped them back). Any other nRF52 variant whose PIN_SERIAL1_* doesn't match its real GPS wiring will break the same way, so it may be worth a check.

The new switch handling works well: off at boot in the middle position, on at the top, and both the switch and the UI toggle power the GPS down and back up correctly.

PR with the pin fix and the ATGM336H NMEA re-enable on top of your branch: fdlamotte#1

[fdlamotte]

Tested on a Muzi Base Uno + SuperIO, following up on #3760.

As-is, the Muzi GPS gets no data: the refactor no longer calls Serial1.setPins() on nRF52, and the Muzi variant.h had PIN_SERIAL1_RX/TX swapped (main only worked because setPins(PIN_GPS_TX, PIN_GPS_RX) swapped them back). Any other nRF52 variant whose PIN_SERIAL1_* doesn't match its real GPS wiring will break the same way, so it may be worth a check.

The new switch handling works well: off at boot in the middle position, on at the top, and both the switch and the UI toggle power the GPS down and back up correctly.

PR with the pin fix and the ATGM336H NMEA re-enable on top of your branch: fdlamotte#1

Thank you very much ...

So I'll check for lost assignations I could have missed in the process ;)

[fdlamotte]

I'm restoring setPins

Think I found some way to simplify things too