Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Factory reset GNSS_MODEL_MTK GPS modules with PCAS10,3 #3388

Merged

Conversation

titan098
Copy link
Contributor

Problem

Some low-cost GPS modules may not respond to the Ublox factory reset command when a factory reset is requested (those identified as GNSS_MODEL_MTK). It can be useful to perform a factory reset of the module in particular if it has been used before to ensure the module will just emit the expected NMEA0183 sentences.

Proposal

For a device that identifies as GNSS_MODEL_MTK perform a factory reset with $PCAS10,3*1F when requested.

Example

  1. An AT6558-5N-31 gps module that identifies as GNSS_MODEL_MTK as the device responds to $PCAS06,0*1B\r\n
  2. The module was pre used and was configured to emit UBX messages (which this one supports).
  3. When subsequently used with Metastatic the module does not respond to the Ublox Factory Reset packet but will get configured to emit RMC and GGA messages: https://github.com/meshtastic/firmware/blob/master/src/gps/GPS.cpp#L288
  4. The gps module then emits NMEA0183 sentences and also UBX messages.
  5. The microcontroller at the very least will have to filter out the extra data being sent by the module to process the NMEA0183 sentences.
DEBUG | ??:??:?? 0 Enter state: BOOT
DEBUG | ??:??:?? 0 [GPS] Probing for GPS at 9600
DEBUG | ??:??:?? 1 [GPS]
3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3C
...
3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3C
DEBUG | ??:??:?? 4 [GPS]
DEBUG | ??:??:?? 4 [GPS]
L76K GNSS init succeeded, using L76K GNSS ModuleC3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280CC
DEBUG | ??:??:?? 5 [GPS]
�b������b4��������`F��mP�>��'<B�b �����������b���`F��mP�>��n
�b���'A�Range Test Module - Disabled
INFO  | ??:??:?? 5 [PowerFSM] Initialise the NimBLE bluetooth module
DEBUG | ??:??:?? 6 [GPS] $GNGGA,,,,,,0,00,25.5,,,,,,*64
$GNRMC,,V,,,,,,,,,,N*4D
�b����U�b4��������`F��mP�>��'(.�b �����������b���`F��mP�publishing pos@0:2, hasVal=0, Sats=0, GPSlock=0
...
DEBUG | 14:25:04 13 [GPS] $GNGGA,142504.000,,,,,0,00,25.5,,,,,,*7C
$GNRMC,142504.000,V,,,,,,,110324,,,M*53
�bP�Mj�b4P�s        	b���
'\�꠆'���b P�s        	��bP�b���
'\�꠆�:�bP�'�$GNGGA,142505.000,,,,,0,00,25.5,,,,,,*7D
$GNRMC,142505.000,V,,,,,,,110324,,,M*52
�b8�9��b48�s        	b���
'\�꠆'v��b 8�s        	墵b8�b���
'\�꠆���b8�'|$GNGGA,142506.000,,,,,0,00,25.5,,,,,,*7E
$GNRMC,142506.000,V,,,,,,,110324,,,M*51
�b �%��b4 �s        	b���
'\�꠆'b��b  �s        	�^�b �b���
'\�꠆��b �'k�$GNGGA,142507.000,,,,,0,00,25.5,,,,,,*7F
$GNRMC,142507.000,V,,,,,,,110324,,,M*50
��&�b�s     	b���
'\�꠆'Nu�b�s          	���b���
'\�꠆u~��'WT$GNGGA,142508.000,,,,,0,00,25.5,,,,,,*70

Testing

  1. A AT6558-5N-31 module configured to emit UBX messages by gpsd and then connected to a microcontroller running Meshtastic.
  2. Update the device config to enable the gps module to trigger a factory reset of the module.
  3. The module only emits NMEA0183 sentences once reset with CAS10,3
DEBUG | ??:??:?? 4 [GPS] 3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280CC
L76K GNSS init succeeded, using L76K GNSS ModuleC3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280C3FCB280CC
WARN  | ??:??:?? 5 [GPS] GPS FactoryReset requested
INFO  | ??:??:?? 5 [GPS] GNSS Factory Reset via PCAS10,3
INFO  | ??:??:?? 6 [GPS] Saving /prefs/db.proto
DEBUG | ??:??:?? 6 [GPS]
$GNGGA,141405.000,,,,,0,00,25.5,,,,,,*7F
$GNRMC,141405.000,V,,,,,,,110324,,,M*50
�b���b4�<           	C�B�
6\�꠆'���b �<         	rt�b�C�B�
6\�꠆��b�'C�$GPTXT,01,01,02,MA=CASIC*27
$GPTXT,01,01,02,HW=ATGM336H,0003031036735*17
$GPTXT,01,01,02,IC=AT6558-5N-31-0C510800,BMBTCKJ-D2-023286*46
$GPTXT,01,01,02,SW=URANUS5,V5.3.0.0*1D
$GPTXT,01,01,02,TB=2020-04-28,13:43:10*40
$GPTXT,01,01,02,MO=GB*77
$GPTXT,01,01,02,BS=SOC_BootLoader,V6.2.0.2*34
$GPTXT,01,01,02,FI=00856014*71
NMEA GPS time 2024-03-11 14:14:05
....
DEBUG | 14:14:08 9 encoding toPhone packet to phone variant=7, 2 bytes
DEBUG | 14:14:08 9 [GPS] $GNGGA,,,,,,0,00,25.5,,,,,,*64
$GNGLL,,,,,,V,N*7A
$GPGSA,A,1,,,,,,,,,,,,,25.5,25.5,25.5*02
$BDGSA,A,1,,,,,,,,,,,,,25.5,25.5,25.5*13
$GPGSV,1,1,00*79
$BDGSV,1,1,00*68
$GNRMC,,V,,,,,,,,,,N*4D
$GNVTG,,,,,,,,,N*2E
$GNZDA,,,,,,*56
...

References

  1. L67K: https://files.waveshare.com/upload/b/b1/Quectel_L76KL26K_GNSS_%E5%8D%8F%E8%AE%AE%E8%A7%84%E8%8C%83_V1.2.pdf (pg26)
  2. CASIC Protocol Spec: https://espruino.microcosm.app/api/v1/files/68b597874e0a617692ebebc6a878032f76b34272.pdf (pg31)
  3. Module under test (AT6558-5N-31) https://www.icofchina.com/d/file/xiazai/2018-01-08/9c186bd617e127ca162479c480092300.pdf

@titan098 titan098 force-pushed the mtk_gps_factory_reset_with_pcas10_3 branch from b2d9bd7 to a8e3c37 Compare March 12, 2024 09:33
@titan098 titan098 marked this pull request as ready for review March 12, 2024 09:54
@thebentern
Copy link
Contributor

@GPSFan I'd like your perspective on this as well

@GPSFan
Copy link
Contributor

GPSFan commented Mar 12, 2024

I'm curious as to how gpsd was able to configure an AT6558 to send ubx protocol. I can't find anything in the CASIC spec or the datasheet for the AT6558 that says it supports ubx.
The $CAS10 command is the correct way to reset the L76K (not L76B) to factory defaults.
I will do some research into that module supporting ubx protocol.

@GPSFan
Copy link
Contributor

GPSFan commented Mar 12, 2024

It's not really u-blox ubx protocol, it shares a similar format and has many of the same Class & ID identifiers. Similar to the AllyStar Tau1202. The Message header is different, B5 62 for u-blox, BA CE for the AT6558, and F1 D9 for AllyStar. The more recent u-blox receivers have depracated most of the ubx protocol commands in favor of the VALSET/VALGET/VALDEL command structure as found on the M10 modules.
We may be able to use this in the future to unify some of the setup for different manufacturer modules.

@thebentern thebentern requested a review from GPSFan March 13, 2024 00:49
Copy link
Contributor

@GPSFan GPSFan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The command is correct for the CASIC protocol.
However, the L76K is not an MTK device, the L76B is an MTK device and uses $PMTKxxx commands.
For a Factory reset, one would use the $PMTK104 message: PMTK_CMD_FULL_COLD_START. Meshtastic currently does not have any code to support the L76B, so until there is a desire to support the L76B this PR is fine the way it is. I haven't had time to do an audit of the complete init process for other than u-blox parts, it's on the list...

@titan098
Copy link
Contributor Author

Thanks for the insight, this resulted from my particular edge case (using custom dev builds and spare hardware). So if this is something that is not generally beneficial to folk and could be addressed with broader changes later on please feel free to close this.

As it stands this only really has minor benefit for me and everything does work as is without issue :)

@GPSFan
Copy link
Contributor

GPSFan commented Mar 13, 2024

Meshtastic has a lot of use cases and the off the wall DIY projects can lead to new commercial or semi commercial products, so supporting a variety of GPS modules is eventually a benefit to all.

@caveman99
Copy link
Member

@GPSFan L76B support is on my todo list for today, as part of a new pico board support.

@GPSFan
Copy link
Contributor

GPSFan commented Mar 14, 2024

@caveman99 I don't have an L76B to test with, DayJob & RealLife bogging down progress ;>(
I should have a couple of AllyStar Tau1202's soon.

@thebentern thebentern merged commit 611f291 into meshtastic:master Mar 16, 2024
67 checks passed
upchui added a commit to upchui/firmware-Meshtastic-Unleashed that referenced this pull request Mar 16, 2024
* (1/3) Support L76B GNSS chip found on pico waveshare shield. Original work by @Mictronics

* NodeInfo broadcast ensure default on 0 and enforce 1 hour minimum (meshtastic#3415)

* NodeInfo broadcasts ensure defaults on 0 and enforce 1 hour minumum

* Doh!

* Hey that's not on config!

* We don't use Lorawan (meshtastic#3417)

#warning "Persistent storage not supported!" [-Wcpp]

* [create-pull-request] automated change (meshtastic#3418)

Co-authored-by: thebentern <thebentern@users.noreply.github.com>

* fix compilation

* don't fix this to a hardware model.

* new Accelerometer lib (meshtastic#3413)

* new Accelerometer lib

* Use our fork till upstreasm merges changes.

* that PR escalated quickly

* resurrect display flip

* that should work now

* (2/3) Add Slow Clock Support for RP2040 platform. This will disable USB Softserial.

* More comprehensive client proxy queue guards (meshtastic#3414)

* More comprehensive MQTT thread and queue guards

* Consolidate logic

* Remove channel check

* Check for map_reporting_enabled as well

* Update message

* Remove channel check from here as well

* One liner

* Start the mqtt thread back up when channels change and we want mqtt

* fix for I2C scan getting stuck (meshtastic#3375)

* refactor: add delay for T-Echo peripherals setup

* comment out `PIN_POWER_EN1`

* [create-pull-request] automated change (meshtastic#3419)

Co-authored-by: thebentern <thebentern@users.noreply.github.com>

* Handle for heartbeat toradio packets (meshtastic#3420)

* Factory reset GNSS_MODEL_MTK GPS modules with PCAS10,3 (meshtastic#3388)

Co-authored-by: Ben Meadors <benmmeadors@gmail.com>

* [create-pull-request] automated change (meshtastic#3422)

Co-authored-by: thebentern <thebentern@users.noreply.github.com>

* (3/3) Add variant for pico with waveshare and GPS hat (meshtastic#3412)

* (3/3) Add variant for pico with waveshare and GPS hat, utilizing slow clock.

* Not everybody has Serial2

* Trunk

* Push it real gud

* No init

---------

Co-authored-by: Ben Meadors <benmmeadors@gmail.com>

---------

Co-authored-by: Thomas Göttgens <tgoettgens@gmail.com>
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: thebentern <thebentern@users.noreply.github.com>
Co-authored-by: Andre K <andrekir@pm.me>
Co-authored-by: David Ellefsen <93522+titan098@users.noreply.github.com>
@titan098 titan098 deleted the mtk_gps_factory_reset_with_pcas10_3 branch April 1, 2024 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants