OGN tracker Lilygo Lora32

[Lukáš Jukl]

Hello, I do have a Lilygo Lora 32 board with a VK2828U7G5LF.

Does anyone have advice of a working firmware, that I could flash on it so it can work as an OGN?

If been trying the following one, but I did not manage to build it.

https://github.com/pjalocha/esp32-ogn-tracker

Thanks for help.

[Moshe Braner]

Hi, and welcome to this group!

What kind of board is it?  What is the MCU type?  All the Lilygo boards (other than the T-Echo) I have worked with were types of the T-Beam, which has an ESP32 MCU and a different type of GNSS module.  I have replaced use of the on-board (Ublox 6) GNSS module on some T-Beams with an added-on VK2828U7 module because the on-board module seemed to have died, or worked poorly.  The VK2828U7 has a Ublox 7 chip and works well in my experience.  And it only costs about $10.  (See my documentation for instructions on how to do that.)

But, if the board is not a T-Beam then some work will need to be done to make my source code compile correctly for it.  Mainly it is a matter of specifying which GPIO pin does what on this board, and compiling for the type of MCU.  It takes significant work to get it all done.  For a quick path to a working device it is easier to buy a T-Beam (which only costs about $40) and flash my firmware and go fly.  :-)  But you do need to arrange a case for it.  There are 3D printable designs, including one in my github repo.

[Lukáš Jukl]

I tried to build with the T-BeamV10.cfg.

However, when I run make flash, it eds up throwing the following errors.

Which I dont know, how to overcome.

App "esp32-ogn-tracker" version: 42e0e36-dirty
CXX build/main/hal.o
/root/esp32-ogn-tracker/main/hal.cpp: In function 'void CONS_UART_Init()':
/root/esp32-ogn-tracker/main/hal.cpp:677:3: warning: missing initializer for member 'uart_config_t::flow_ctrl' [-Wmissing-field-initializers]
   };
   ^
/root/esp32-ogn-tracker/main/hal.cpp:677:3: warning: missing initializer for member 'uart_config_t::rx_flow_ctrl_thresh' [-Wmissing-field-initializers]
/root/esp32-ogn-tracker/main/hal.cpp: In function 'void RFM_TransferBlock(uint8_t*, uint8_t)':
/root/esp32-ogn-tracker/main/hal.cpp:792:13: warning: unused variable 'ret' [-Wunused-variable]
   esp_err_t ret = spi_device_transmit(RFM_SPI, &Trans); }
             ^~~
/root/esp32-ogn-tracker/main/hal.cpp: In function 'int ADC_Init()':
/root/esp32-ogn-tracker/main/hal.cpp:1518:23: warning: unused variable 'val_type' [-Wunused-variable]
   esp_adc_cal_value_t val_type = esp_adc_cal_characterize(ADC_unit, ADC_atten, ADC_WIDTH_BIT_12, ADC_Vref, ADC_characs); // calibrate ADC1
                       ^~~~~~~~
/root/esp32-ogn-tracker/main/hal.cpp: In function 'void IO_Configuration()':
/root/esp32-ogn-tracker/main/hal.cpp:1610:3: error: 'uart_set_rx_full_threshold' was not declared in this scope
   uart_set_rx_full_threshold(GPS_UART, 24);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~
/root/esp32-ogn-tracker/main/hal.cpp:1610:3: note: suggested alternative: 'uart_set_wakeup_threshold'
   uart_set_rx_full_threshold(GPS_UART, 24);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~
   uart_set_wakeup_threshold
/root/esp32-ogn-tracker/main/hal.cpp:1646:3: warning: missing initializer for member 'i2c_config_t::<anonymous>' [-Wmissing-field-initializers]
   } ;
   ^
/root/esp32-ogn-tracker/main/hal.cpp: In function 'int SPIFFS_Info(size_t&, size_t&, const char*)':
/root/esp32-ogn-tracker/main/hal.cpp:1919:7: warning: unused variable 'Ret' [-Wunused-variable]
   int Ret = f_getfree("0:", &FreeClusters, &FS);
       ^~~

Dne čtvrtek 23. ledna 2025 v 20:29:09 UTC+1 uživatel Moshe Braner napsal:

[Lukáš Jukl]

The Board is Lilygo T3_V1.6.1 if that helps.

Dne čtvrtek 23. ledna 2025 v 21:18:21 UTC+1 uživatel Lukáš Jukl napsal:

[Moshe Braner]

Nice little board, the old "paxcounter".  You can run my OGNbase software on it (or the current T3S3 model) to make a cheap and easy OGN ground station!  But not a great choice for running SoftRF: besides the necessary work to adapt the code, also this board does not have PSRAM.  SoftRF needs a lot of RAM especially if you want to run the web interface and/or bluetooth.  Also with the PSRAM on the T-Beam and with my latest version of SoftRF you can record an IGC flight log.  The RAM size is only a few hundred kb, splintered into different segments, while the PSRAM is 8 mb (of which 4 mb is easy to use, the other 4 mb a different story).

[Lukáš Jukl]

So shall I rather get something like this T-Beam?

https://www.aliexpress.com/item/1005005252748010.html?spm=a2g0o.productlist.main.53.72236a24IlnTrs&algo_pvid=65362b90-4136-48ee-ab58-c182037afa10&algo_exp_id=65362b90-4136-48ee-ab58-c182037afa10-26&pdp_npi=4%40dis%21CZK%211101.99%21837.53%21%21%2144.67%2133.95%21%40211b813b17377053856147926e4e14%2112000038681527000%21sea%21CZ%211806326127%21X&curPageLogUid=bUVPlnq7u3e3&utparam-url=scene%3Asearch%7Cquery_from%3A

Or is there some more suited board?

Dne čtvrtek 23. ledna 2025 v 22:38:29 UTC+1 uživatel Moshe Braner napsal:

[VirusPilot]

So first of all, the tracker repository "esp32-ogn-tracker" is no longer maintained (since 2 years), you should use https://github.com/pjalocha/ogn-tracker instead if you want to build an OGN tracker that transmits OGN, ADS-L, FANET and PilotAware. You have to identify which of the PlatformIO targets fits best with your board and if you are lucky, your VK2828U7G5LF GPS might work as well.

[Moshe Braner]

Yes that's the regular old T-Beam, which I would recommend.  Be sure to select the version for the correct frequency band, 868 MHz in Europe.  My code does not work with the "T-Beam Supreme", which would require some work (ESP32-S3 needs "upgrade" of the board support libraries, then the binary won't fit in the flash space...).  And I personally do not see any advantage to the "Supreme".

On Friday, January 24, 2025 at 3:02:29 AM UTC-5 jukli...@gmail.com wrote:

So shall I rather get something like this T-Beam?

https://www.aliexpress.com/item/1005005252748010.html?spm=a2g0o.productlist.main.53.72236a24IlnTrs&algo_pvid=65362b90-4136-48ee-ab58-c182037afa10&algo_exp_id=65362b90-4136-48ee-ab58-c182037afa10-26&pdp_npi=4%40dis%21CZK%211101.99%21837.53%21%21%2144.67%2133.95%21%40211b813b17377053856147926e4e14%2112000038681527000%21sea%21CZ%211806326127%21X&curPageLogUid=bUVPlnq7u3e3&utparam-url=scene%3Asearch%7Cquery_from%3A

Or is there some more suited board?

Dne čtvrtek 23. ledna 2025 v 22:38:29 UTC+1 uživatel Moshe Braner napsal:

Nice little board, the old "paxcounter".  You can run my OGNbase software on it (or the current T3S3 model) to make a cheap and easy OGN ground station!  But not a great choice for running SoftRF: besides the necessary work to adapt the code, also this board does not have PSRAM.  SoftRF needs a lot of RAM especially if you want to run the web interface and/or bluetooth.  Also with the PSRAM on the T-Beam and with my latest version of SoftRF you can record an IGC flight log.  The RAM size is only a few hundred kb, splintered into different segments, while the PSRAM is 8 mb (of which 4 mb is easy to use, the other 4 mb a different story).

On Thursday, January 23, 2025 at 3:19:32 PM UTC-5 jukli...@gmail.com wrote:

The Board is Lilygo T3_V1.6.1 if that helps.

...

[Moshe Braner]

Depending on what you fly and where, the FLARM-compatible radio protocol ("Latest" in my version of SoftRF, not supported by the "ogn-tracker") is important, to see and be seen by gliders.  That protocol is also received by OGN ground stations, so there is no need to transmit in the OGN protocol.  (Although my next version, being tested by a few people now, has an option to transmit in OGNTP once every 16 seconds, for greater tracking range.)  SoftRF can also work in the FANET and PilotAware protocols.  Not ADS-L - I could add that (Linar's version has it) but it seems to not have any practical benefit at this time.

[Lukáš Jukl]

Is there any significant difference between the versions  SMA GPS-NEO-6M and  IPEX GNSS-NEO-M8N, or btween the two cpu options?

Dne pátek 24. ledna 2025 v 14:28:38 UTC+1 uživatel Moshe Braner napsal:

[Moshe Braner]

All the plain T-Beams (but not the "Supreme") have the same CPU, a plain ESP32.  There are two choices for the GNSS module,  NEO-6M ("U6") and NEO-M8N ("U8") as you noted.  The U8 is significantly better, but is only available with the IPEX antenna connector not SMA (for the radio module - the GNSS antenna connector is always IPEX).  The IPEX is fragile and difficult to work with - likely to break if you disconnect it several times.  Although the pigtail connecting it to an SMA connector offers flexibility on where to mount the antenna.  Another choice is between the sx1276 and sx1262 radio modules, the 1262 is theoretically a little better in receiving weak signals, but that is not important in an airborne device meant for collision avoidance and nearby traffic awareness.  The transmission power is limited by regional law, so is the same, thus reception by ground stations is the same.

[David S]

Yes, the IPEX connector is officially rated for only 30 connect/disconnect cycles, but my experience suggests the actual value is about 5.  After that, the connector comes apart with the slightest bump, whereas a new connector takes so much force to disconnect the first time that you fear breaking it.  Far less effort and no such fear the second time.  And it's all downhill from there.

   ...david

[Nigel Bray (SoftRF)]

Hello,

May I ask here if anyone has a T-Beam-AXP2101-V1.2 GNSS:NEO-M8N LoRa:SX1262 that works with SoftRF_MB?

My old T-Beam-AXP192-V1.1 GNSS:NEO-M8N LoRa:SX1262 with SoftRF_MB served me well last year.

On Friday, January 24, 2025 at 8:02:29 AM UTC Lukáš Jukl wrote:

So shall I rather get something like this T-Beam?

https://www.aliexpress.com/item/1005005252748010.html

I bought a T-Beam-AXP2101-V1.2 GNSS:NEO-M8N LoRa:SX1262 from the aliexpress item/1005005252748010  link but ran into an issue where the GNSS doesn't give a fix.  It did not have SoftRF firmware and I loaded SoftRF_MB versions in parallel with my 2 year old T-Beam-AXP192-V1.1 GNSS:NEO-M8N LoRa:SX1262 that did work.  I gather meshtastic uses a Ublox protocol rather than NMEA and tells the GNSS to make those changes and that's not changed back to NMEA after re-flashing.

This has taken some time, so my immediate solution is to order https://lilygo.cc/products/t-beam-softrf?variant=43170139701429 cheaper at $41.65 instead of $50.92.  With luck I'll avoid the courier fee, but in any case the time saved would be worth it.

Best regards Nigel

PS. May I ask for recommendations?  I am looking for a small NRF52840 + LoRa:SX1262 no GNSS board, less than 25mm wide.

[Lukáš Jukl]

Currently, I do have the T-Beam v1.2 with  GNSS:NEO-M8N.

However, even with an upgraded GPS antenna, I cannot get any fix.

I have also tried to flash a GPS reset firmware as advised at https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/tree/master/firmware/GPS_Reset

However, It still does not catch any signal.

Don't understand why.

Dne neděle 23. února 2025 v 13:38:46 UTC+1 uživatel Nigel Bray (SoftRF) napsal:

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 12:50:22 PM UTC Lukáš Jukl wrote:

Currently, I do have the T-Beam v1.2 with  GNSS:NEO-M8N.

However, It still does not catch any signal.

Don't understand why.

 

You have the same issue as me.  Either:

1. The units from AliExpress are faulty, or
2. We need a GNSS reset back to Factory defaults or set NMEA protocol

To decide that they units are not faulty I think we should Flash and test with different Firmware.  I have tried Meshtastic, since that is what I assume the unit was shipped with.  Unfortunately the Meshtastic firmware for ESP32 gave me no insight when using the Android app.  It seemed only to support bluetooth, no WiFi hotspot and regularly disconnect.

To reset back to an NMEA protocol I think it needs firmware to do that which supports the new power management IC AXP2101in V1.2.  You tried GPS_Reset that is for the older AXP192 in V1.1.

Best regards Nigel

[Nick Bonniere]

On a T-Beam, an indication that the gnss is locked is when it flashes the red LED once per second. This will happen even if the GNSS is at the wrong baud rate and/or on the wrong protocol, i.e. u-blox versus NMEA.

Ublox provides software called u-center to connect to their GNSS module. On a T-Beam, loaded with SoftRF-MB, you can select the mode 'GNSS bypass' instead of 'Normal' and then run the u-center software and select the proper COM-port with the T-beam USB connected, and you can connect to the GNSS directly with u-center. U-center will show the data from the gnss and lock status and the satellite constellation. You can then select its parameters, which should be 9600 baud and NMEA protocol, and then save to EEPROM.

[Moshe Braner]

Connect a USB-serial terminal app (on a PC) to the T-Beam (via USB cable) and see what it reports about the GNSS during booting and also during a "reset GNSS" operation after that is triggered via the web interface.  You will be able to see whether any communications with the GNSS is happening, and whether the "reset GNSS" seems to work.

Ublox offers a Windows app called "U-Center" for managing the
configuration of the module.  To let it reach the GNSS module inside
the T-Beam, put SoftRF into GNSS Bridge mode - and (probably) 9600
baud speed.

Any new T-Beam you order now may arrive with the AXP2101 PMU (v1.2) rather than the older AXP192, regardless of what the product description says.  SoftRF works on both, but some older GNSS reset .bin apps may not.

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 1:46:41 PM UTC Moshe Braner wrote:

Connect a USB-serial terminal app (on a PC) to the T-Beam (via USB cable) and see what it reports about the GNSS during booting and also during a "reset GNSS" operation after that is triggered via the web interface.  You will be able to see whether any communications with the GNSS is happening, and whether the "reset GNSS" seems to work.

It seems Reset GNSS has no effect.  With:

$ screen -L /dev/ttyACM0  38400

I get....

...

Memory available in PSRAM before FlightLog_setup(): 4189075
Memory available in PSRAM after FlightLog_setup(): 4189075
SX126x RFIC is detected.
Pin 14 now reserved for Buzzer
Pin 15 now reserved for Buzzer
INFO: TTGO T-Beam rev. 12 is detected.
Connecting to internal GNSS
Flash memory ID: EF4016
ublox_query()...
... re-sending UBX command
... re-sending UBX command
... time out
WARNING: no NMEA and Ublox GNSS not detected!
range.txt does not exist
Hostname: SoftRF-847294
...
Detected MODEL_PRIME_MK2
hw_info.revision: 12

CPU Freq = 160 MHz
 ...

$PFLAU,0,0,0,1,0,,0,,,,*63
$PFLAU,0,0,0,1,0,,0,,,,*63
Factory Reset GNSS...
Rebooting...


SPIFFS mounted, total space: 173441, used space: 2761

SoftRF ESP32 FW.REV: MB155 DEV.ID: 847294

...

Pin 15 now reserved for Buzzer
INFO: TTGO T-Beam rev. 12 is detected.
Connecting to internal GNSS
Flash memory ID: EF4016
ublox_query()...
... re-sending UBX command
... re-sending UBX command
... time out
WARNING: no NMEA and Ublox GNSS not detected!
range.txt does not exist
Hostname: SoftRF-847294
Can not connect to WiFi station. Go into AP mode.

...

[Nigel Bray (SoftRF)]

If I then switch to bridge mode, I only see 

....

BT: OFF

GPS bridge mode
Turning off radio

....

geoid,0
leapsecs,18        # leap seconds - automatic
debug_flags,000000

�^ ��a[B��...

Then only spurious characters on the tty regardless of baud rate selected from:

# 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000

[Nick Bonniere]

Spurious character are positive in that GNSS is sending something, but protocol is UBX not NMEA.  Need to use u-center software, or alternately send a ublox factory-reset command at various baud-rates until reset takes hold. These HEX values need to be converted to ASCII values :  B5 62 06 09 0D 00 FF FB 00 00 00 00 00 00 FF FF 00 00 05 19 6C

see attached file.

[Nick Bonniere]

u-center config page view.

[Nick Bonniere]

Actually, the baud rate can be changed on the terminal, but it won't change the internal baud rates in the T-Beam. The main baud rate can be changed in config to match the terminal baud rate, but I'm not sure it will change the baud rate on the GNSS to follow this baud rate when in 'GNSS bridge mode'. Not so simple unfortunately.

[Nigel Bray (SoftRF)]

Excellent, thank you.

Since a windows machine is not to hand, I'd either poke it with this over the serial or try other firmwares that might tell me the unit is not faulty.

I did switch to GNSS bridge and tried my luck with this:

$ stty < /dev/ttyACM0

speed 38400 baud; line = 0;

min = 100; time = 2;

-icrnl -imaxbel

-opost -onlcr

-isig -icanon -echo

$ cat ~/Downloads/UBX_Reset.bin > /dev/ttyACM0

I am still getting

WARNING: no NMEA and Ublox GNSS not detected!

After a reset, but should investigate sending the sequence at different baud rates or more elegantly look into handling the UBX protocol.... [unless I build or borrow a Windows machine.]

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 4:10:33 PM UTC Nick Bonniere wrote:

Actually, the baud rate can be changed on the terminal, but it won't change the internal baud rates in the T-Beam. The main baud rate can be changed in config to match the terminal baud rate, but I'm not sure it will change the baud rate on the GNSS to follow this baud rate when in 'GNSS bridge mode'. Not so simple unfortunately.

I think the UBLOX output being piped through the USB serial will be at a certain baud I just need to guess on  my /dev/ttyACM0.

I've noticed that the serial output produces 38400 text from the ESP32 when the Web page is accessed after switching the GNSS bridge:

�c�handleRoot()...

Free memory: 131328

Status page size: 3820 out of allocated: 4500

��

I saw on the schematic there is some double connection to the USB uart from both ESP32 and UBLOX Rx and Tx pins (one resistors, the other inductors).  Could there be some contention on the Tx out from ESP32 and UBLOX and can the two devices operate at different baud through the same USB-Serial IC at the same time?

Best regards Nigel

[Nick Bonniere]

The two UART are completely independent so there is no contention ever. The data is 'bridged' from one to the other by software so a baud rate difference is irrelevant. Although the UART baud rate can be changed on the USB-serial side (default 38400), the UART baud rate on the GNSS side is at 9600. I've got U-centre running and I can change the (softrf-mb config) USB-serial rate from the default 38400 to 19200 and match the terminal on the PC to 19200, the baud rate to the GNSS stays at 9600 and I'm getting data bridged over OK.

By default the Ublox GNSS is at 9600/NMEA-protocol, but it could have been changed (by meshtatic for example) to 57600/Ublox-protocol or whatever. With the baud rate stuck at 9600, the reset command won't get through if the GNSS baud is not 9600.

[Lukáš Jukl]

For me, the mesages UBX CFG PRT show this.

Shall I then change the baud rate to 9600 and set both, the protocol in and out as NMEA and hit send?

S

Dne neděle 23. února 2025 v 18:37:54 UTC+1 uživatel Nick Bonniere napsal:

[Lukáš Jukl]

But still, at any selected baud rate, the u-center does not seem to show any metrics, I believe, that I have the correct serial seleted as it is the same one that I have been flashong the board through.

Also I do have the softRF swiched to the bridge mode

Dne neděle 23. února 2025 v 19:09:00 UTC+1 uživatel Lukáš Jukl napsal:

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 6:21:00 PM UTC Lukáš Jukl wrote:

But still, at any selected baud rate, the u-center does not seem to show any metrics, I believe, that I have the correct serial seleted as it is the same one that I have been flashong the board through.

Also I do have the softRF swiched to the bridge mode

Dne neděle 23. února 2025 v 19:09:00 UTC+1 uživatel Lukáš Jukl napsal:

For me, the mesages UBX CFG PRT show this.

Shall I then change the baud rate to 9600 and set both, the protocol in and out as NMEA and hit send?

Dne neděle 23. února 2025 v 18:37:54 UTC+1 uživatel Nick Bonniere napsal:

The two UART are completely independent so there is no contention ever. The data is 'bridged' from one to the other by software so a baud rate difference is irrelevant. Although the UART baud rate can be changed on the USB-serial side (default 38400), the UART baud rate on the GNSS side is at 9600. I've got U-centre running and I can change the (softrf-mb config) USB-serial rate from the default 38400 to 19200 and match the terminal on the PC to 19200, the baud rate to the GNSS stays at 9600 and I'm getting data bridged over OK.

By default the Ublox GNSS is at 9600/NMEA-protocol, but it could have been changed (by meshtatic for example) to 57600/Ublox-protocol or whatever. With the baud rate stuck at 9600, the reset command won't get through if the GNSS baud is not 9600.

@Nick Sorry, I misread the schematic, the UBLOX signals with the USB are not connected.  So the USB serial baud is only that which works with the ESP32: speed 38400 baud; in my case.

@Lukáš So for bridge mode, if the SoftRF internal serial link speed is at 9600 on the ESP32 and UBLOX is set to something else, we have a problem.

Next steps could be:

- Temporarily disconnect the backup battery from UBLOX (after checking that might work) as I saw suggested somewhere.  I worry that UBLOX will take its settings from the 24AA32A Serial EEPROM and still not work with SoftRF.

- Branch  Meshtatic with a patch to set the baud to the same as SoftRF (after checking what baud SoftRF uses).

- Branch SoftRF with a patch to reset UBLOX using the same baud that Meshtastic uses.

- Find some other code that sets or resets UBLOX.

I'd like to know if my board 'works'.  So first I am tempted to search for other firmwares that might cope with the state of the board as it is, or find a way to use Meshtastic and see the UBLOX give a fix.

Best regards Nigel

[Lukáš Jukl]

can the little battery be disconnected?

To me it seem to be quite mpermanently connected

Dne neděle 23. února 2025 v 19:55:55 UTC+1 uživatel Nigel Bray (SoftRF) napsal:

[Nick Bonniere]

I assume you have selected 'GNSS bridge' mode, and changed the baud rate (see attached my settings with bridge mode and baud rate changed to 57600) and matched the baud rate in u-center (in my case 57600). Although you are connecting on the COMport at various rates on the USB-serial port, the GNSS serial port in the T_Beam is stuck at 9600, but the GNSS is probably not at 9600. So even when select the txt console or the binary console, nothing will show.

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 7:01:45 PM UTC Lukáš Jukl wrote:

can the little battery be disconnected?

To me it seem to be quite mpermanently connected

 

It would need delicate de-soldering.  Before taking that step, I would want to be sure, a. that my board was working (not faulty), and b. that erasing the volatile memory in UBLOX would reset it to factory defaults and UBLOX would ignore its Serial EEPROM.

[Lukáš Jukl]

To be honest, I'm quite lost in this topic, I'm not much of a technical guy.

Anyway, I'm posting of how my basic settings looks right now.

Is there anything, that I should change about it?

Or else, is there anything, that I should do in the u-center?

Dne neděle 23. února 2025 v 20:10:18 UTC+1 uživatel Nigel Bray (SoftRF) napsal:

[Nick Bonniere]

That's right. Disconnecting the battery and disconnecting the EEPROM is not so simple and would have to be re-connected while live to update their contents. I've mentioned to Moshe about matching baud rates when in GNSS bridge mode, as a software work-around is simplest.

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 7:18:13 PM UTC Lukáš Jukl wrote:

To be honest, I'm quite lost in this topic, I'm not much of a technical guy.

Anyway, I'm posting of how my basic settings looks right now.

Is there anything, that I should change about it?

Or else, is there anything, that I should do in the u-center?

You may wish to wait and someone may highlight a way to recover these (for now) bricked devices.

I will play a bit more to try and find something.

[Nick Bonniere]

Yes, that's the way to select bridge mode and select the baud rate.

To check that the GNSS module is working, I would use a voltmeter to first make sure there is 3.3V going to it, and then I would put it in a location that allows for a good sky view, and after a few minutes the GNSS should lock and the red LED should flash indicating good satellite reception and a PPS pulse-per-second signal.

[Lukáš Jukl]

The GNSS LED is flashing

Dne neděle 23. února 2025 v 20:40:23 UTC+1 uživatel Nick Bonniere napsal:

[Nick Bonniere]

Very good, that means the GNSS module is OK. It is now just a question of making sure the baud rate defaults to 9600 and that the protocol is NMEA, and SoftRF will work. Hopefully the bridge mode can be changed to adjust the baud rate so that the reset command can be sent.

[Moshe Braner]

Very good idea Nick.  If you've suggested it before, I missed that, sorry.  I'll try and arrange it so that in GNSS Bridge Mode it will use the same baud rate in the internal serial connection to the GNSS module as it uses on the serial connection to the USB port.  (Those are completely independent, and the internal one is always at 9600 baud.)  That way you can try various rates until you find the right one.  Or does the Meshtastic documentation say what baud rate they use internally to connect to the GNSS?  And, does U-Center allow you to choose any baud rate you want?  (Looks that way from the screenshot juklicek posted.)

I intend to post a new version soon anyway, fixing the bugs in SD card file deletions, so I'll try and include this idea too.

Everybody: don't de-solder that tiny battery, it's difficult, and will be difficult to undo.  If you remove all power from the board (including the 18650 cell if you use one) that tiny battery will be empty by the next day anyway!  But the GNSS module also has its own little flash memory chip and that's probably where the bad configuration is stored.

BTW that "Factory Reset GNSS..." message comes from the SoftRF web interface code, but the actual attempts to reach the GNSS module fail, otherwise there would be messages such as "Ublox factory reset..." and "cleared flash config" and eventually "... done" or "... failed".  Probably it was never recognized by the SoftRF code as a Ublox module at all, since it did not respond to test UBX commands - sent at 9600 baud.  The code in GNSS.cpp reset_gnss() does not print "Ublox factory reset..." nor call ublox_factory_reset() unless it has already been recognized as a U6, U7 or U8.

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 9:28:31 PM UTC Moshe Braner wrote:

Very good idea Nick.  If you've suggested it before, I missed that, sorry.  I'll try and arrange it so that in GNSS Bridge Mode it will use the same baud rate in the internal serial connection to the GNSS

It seems I can get NMEA sentences from UBLOX NEO-M8N via the ESP32->USB serial. (using T-Beam-AXP2101-V1.2 GNSS:NEO-M8N LoRa:SX1262)

To do that I built https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/tree/master/examples/GPS/UBlox_Recovery

It:

 - finds the baud rate by trying each one

- sends the UBLOX recovery codes on the found baud rate

- drops into a loop echoing NMEA sentences from UBLOX to USB

in the code they say:

@note      This sample file is intended to restore the UBLOX GNSS module to the factory default value, and the default output baud rate is 9600

What I cannot see in the code is where it changes the baud rate back to 9600 (I looked for that as it still doesn't work with SoftRF_MB).

From that I got:

$ screen -L /dev/ttyACM0 115200

$GNVTG,,,,,,,,,N*2E

$GNGGA,213249.00,,,,,0,00,99.99,,,,,,*77

$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E

$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E

$GPGSV,4,1,15,01,52,118,08,02,40,128,07,03,82,044,16,04,40,175,18*70

$GPGSV,4,2,15,06,13,299,,09,16,197,21,12,03,349,,17,53,259,22*7F

$GPGSV,4,3,15,19,39,300,22,22,07,259,,28,18,060,,31,16,086,*7C

$GPGSV,4,4,15,32,05,036,,36,27,150,,49,31,172,*43

$GLGSV,3,1,10,66,09,037,,67,61,046,,68,62,204,,69,12,213,*6F

$GLGSV,3,2,10,74,01,300,,75,12,346,,76,04,040,,82,44,139,*64

Then I reflashed with MB155 and still get:

[Moshe Braner]

Very good, so that LilyGo tool is set up to work with the AXP2101 (T-Beam v1.2). At which baud rate did that LilyGo tool succeed in doing a "recovery"?  I.e., for each baud rate is should say:

    "Try use nnnn bps recover gps."  (with the baud rate listed where I put "nnnn")

followed by either

     "recover gps successfully"

or

    "GPS baudrate: nnnn bps failed"

I *think* (not sure) that a successful "recovery" (which means wiping out the stored configuration, resulting in the factory settings) includes reverting to 9600 baud.  So I would have expected it to include this line before the "return" following a successful recovery:

     SerialGPS.updateBaudRate(9600);

You can add that line to be sure that when it returns from the setup() and goes to the loop() it'll be testing the NMEA output at 9600 baud.

Note that the SerialGPS.updateBaudRate() does not change the GNSS module's baud rate, it only changes the baud rate that the ESP32 uses on its serial port connected to the GNSS.

The loop() in that tool is exactly what SoftRF's "GNSS bridge" mode does.  And the "recovery" code in SoftRF is based on this tool too.  But without the trying of different baud rates.  So I'll try to add that in.  What is better - one manually chosen baud rate at a time, or a loop over baud rates as in this tool?

[Nick Bonniere]

The github code send 3 config strings. The first clears the BBR (battery-backed-ram), the second clears the Flash (clear mask only), and the third loads the saved config from BBR/Flash.

The T-beam seems to have an EEPROM, not Flash(?)

The ublox UBX protocol document says that to be permanent the save mask must be used.

The Current Configuration can be made permanent (stored in a non-volatile memory) by saving it
to the "Permanent Configuration". This is done by sending a UBX-CFG-CFG message with an
appropriate saveMask (UBX-CFG-CFG/save).
The Permanent Configuration is copied to the Current Configuration during start-up or when a
UBX-CFG-CFG message with an appropriate loadMask (UBX-CFG-CFG/load) is sent to the u-blox
receiver.
The Permanent Configuration can be restored to the u-blox receiver's Default Configuration by
sending a UBX-CFG-CFG message with an appropriate clearMask (UBX-CFG-CFG/clear) to the ublox
receiver. This only replaces the Permanent Configuration, not the Current Configuration. To
make the u-blox receiver operate with the Default Configuration which was restored to the
Permanent Configuration, a UBX-CFG-CFG/load command must be sent or the u-blox receiver
must be reset.
The mentioned masks (saveMask, loadMask, clearMask) are 4-byte bitfields. Every bit represents
one configuration sub-section. These sub-sections are defined in section "Organization of the
Configuration Sections". All three masks are part of every UBX-CFG-CFG message. Save, load and
clear commands can be combined in the same message. Order of execution is: clear, save, load.

I would say that the 'save mask should be used' in the first two commands and that the EEPROM should be used instead of Flash.

Using the u-centre config page, this would result in:

B5 62 06 09 0D 00 FF FF 00 00 FF FF 00 00 00 00 00 00 01 19 90

B5 62 06 09 0D 00 FF FF 00 00 FF FF 00 00 00 00 00 00 04 1C 93

B5 62 06 09 0D 00 00 00 00 00 00 00 00 00 FF FF 00 00 05 1F B5

[Nick Bonniere]

After more research, the 'save mask' is not needed in the case, however the EEPROM probably is, so the commands probably need to be:

B5 62 06 09 0D 00 FF FB 00 00 00 00 00 00 00 00 00 00 01 17 71

B5 62 06 09 0D 00 FF FB 00 00 00 00 00 00 00 00 00 00 04 1A 74

B5 62 06 09 0D 00 00 00 00 00 00 00 00 00 FF FF 00 00 05 1F B5

[Lukáš Jukl]

So, can it be re-set just by flashing the UBlox_Recoveryy.ino file via an esp flash tool and then re-flashing back the softRF.

Or is there some configuration necessary to be done via u-center? 

Dne pondělí 24. února 2025 v 5:07:47 UTC+1 uživatel Nick Bonniere napsal:

[Lukáš Jukl]

In the ucenter it seems, that you can view any baud rate, even some custom values.

In the messages ubx cfg prt, there it seems, that you can choose just from some offered values.

Dne neděle 23. února 2025 v 22:28:31 UTC+1 uživatel Moshe Braner napsal:

[Nigel Bray (SoftRF)]

On Monday, February 24, 2025 at 4:07:47 AM UTC Nick Bonniere wrote:

After more research, the 'save mask' is not needed in the case, however the EEPROM probably is, so the commands probably need to be:

B5 62 06 09 0D 00 FF FB 00 00 00 00 00 00 00 00 00 00 01 17 71

B5 62 06 09 0D 00 FF FB 00 00 00 00 00 00 00 00 00 00 04 1A 74

B5 62 06 09 0D 00 00 00 00 00 00 00 00 00 FF FF 00 00 05 1F B5

Thank you @Nick, I recompiled LilyGo-LoRa-Series/examples/GPS/UBlox_Recovery/UBlox_Recovery.ino after your help.

- I replaced cfg_clear1 (was clear FLASH) with your message that clears the EEPROM.  (... 04 1A 74)

- before and after this change the baud rate search loop only found the NEO-M8N at 115200 bps every time.

- each time UBLOX comes up with the same baud rate 115200 bps - is it being reset to that, or not being reset?

I have reflashed with SoftRF_MB and again got:

[Nick Bonniere]

According to the Ublox neo-8 manual the baud rate defaults to 9600.

Since the modified INO still didn't work, something is not working. Try 2 commands setting the baud to 9600, and then saving.

B5 62 06 00 14 00 01 00 00 00 10 00 00 00 80 25 00 00 03 00 02 00 00 00 00 00 D5 17

B5 62 06 09 0D 00 58 2D 77 05 03 00 00 00 68 2D 77 05 07 38 E9

[Nick Bonniere]

Yes, you can use any baud rate you want, but there are two UARTs involved and you are only changing one, the other stays at 9600, so communication across the bridge between the two UARTs fails. A new version of softrf-mb will be released shortly to make the second UART change baud rate as well, so both baud rates are the same which should fix the problem when the baud rate is not 9600.

[Nigel Bray (SoftRF)]

On Sunday, February 23, 2025 at 11:34:00 PM UTC Moshe Braner wrote:

Very good, so that LilyGo tool is set up to work with the AXP2101 (T-Beam v1.2). At which baud rate did that LilyGo tool succeed in doing a "recovery"? 

115200 bps or no change is the result after all UBX-CFG-CFG/clearMask messages for non-volatile memory, Flash and EEPROM

 

I *think* (not sure) that a successful "recovery" (which means wiping out the stored configuration, resulting in the factory settings) includes reverting to 9600 baud.  So I would have expected it to include

Yes, @Nick agrees, I do not know why UBX-CFG-CFG/clearMask commands do not appear to work, since the "default" should be 9600 according to the manual.

 

The loop() in that tool is exactly what SoftRF's "GNSS bridge" mode does.  And the "recovery" code in SoftRF is based on this tool too.  But without the trying of different baud rates.  So I'll try to add that in.  What is better - one manually chosen baud rate at a time, or a loop over baud rates as in this tool?

What is known is that the loop ```for ( int i = 0; i < sizeof(baudrate) / sizeof(baudrate[0]); ++i)``` in LoRaBoards.cpp to try different baud rates has worked every time, so my preference would be to include that in SoftRF_MB for 'bricked' V1.2 devices with NEO-M8N.

My next step would be to try a Lilygo pre-programmed SoftRF NEO-M8N T-Beam, before and after SoftRF_MB155 to confirm that 'rogue' firmware changed the state of NEO-M8N to stop it working with SoftRF.

I'd leave any further investigation into the behaviour of UBX-CFG-CFG/clearMask for another time.

Again, thank you Mosh for your version of SoftRF!

[Nigel Bray (SoftRF)]

As a temporary fix, my 'bricked' TTGO T-Beam rev. 12 now sees 12 satellites!

"GNSS type found: U8"

I changed 1 line in Moshe's code:

$ git diff software/firmware/source/SoftRF/SoftRF.h
diff --git a/software/firmware/source/SoftRF/SoftRF.h b/software/firmware/source/SoftRF/SoftRF.h
index 904c7d30..bed18008 100755
--- a/software/firmware/source/SoftRF/SoftRF.h
+++ b/software/firmware/source/SoftRF/SoftRF.h
@@ -93,7 +93,7 @@
  * for most of GNSS modules
  * being used in SoftRF project
  */
-#define SERIAL_IN_BR      9600
+#define SERIAL_IN_BR      115200
 #endif
 #if !defined(SERIAL_IN_BITS)
 #define SERIAL_IN_BITS    SERIAL_8N1

I used the above change only for the T-Beam rev. 12 and used Moshe's MB155 code unchanged for the T-Beam rev. 8

The below lines are now identical, between the original "INFO: TTGO T-Beam rev. 8 is detected." and "INFO: TTGO T-Beam rev. 12 is detected."

$ screen -L /dev/ttyACM0  38400

Connecting to internal GNSS
Flash memory ID: EF4016
ublox_query()...
INFO: UBLOX GNSS module HW version: 00080000
INFO: UBLOX GNSS module FW version: EXT CORE 3.01 (107900)
GNSS type found: U8
Pin 37 now reserved for GNSS PPS
range.txt does not exist

[Moshe Braner]

The word from LilyGo is that the default baud rate on the Ublox Neo-8 is 115200.  That is surprising, since all the previous Ublox modules had a default of 9600, and the official documentation for the -8 says (on page 466) that the default is 9600.  But we have seen that "clearing" its settings (to "factory defaults") did return to 115200 each time, at least on Nigel's board.

So, I'll try to implement one of the following in SoftRF:  Either add code to change the module's baud rate to 9600, once, saving it to its nonvolatile storage, so that in later power-ups it will be at 9600.  Or, detect the baud rate during every boot and adjust it on the SoftRF side to fit the Ublox module.  That is simpler, but will make booting a little slower on such boards.

[Nigel Bray (SoftRF)]

Oh, I just saw this after I found out the same from a friend, Tom!  " I think I have been here before!  The bit where it says that the default baud rate is 9600 is incorrect!"

[Lukáš Jukl]

Does that mean that for the T-Beam using Ublox Neo-6 the problem would not be present?

Dne úterý 25. února 2025 v 15:26:34 UTC+1 uživatel Moshe Braner napsal:

[Nigel Bray (SoftRF)]

It could be a different issue, but I have one report of a TBeam 1.2 with a Neo-U6 Gns chip which is working with GXAircom and gives a serial output at 115200 but can't get that working with SoftRF.

One hypothesis is that suppliers have shipped some devices where the 'default' baud has been reprogrammed from 9600 to 115200 and a reset will bring it back to 115200 instead of 9600.  That is ok for Meshtastic and GXAircom but not us.

Now we know what we can do to solve our issue, further reading of the UBlox manual is less interesting!

[Lukáš Jukl]

Thank you, looking forward for the new softRF version

Dne středa 26. února 2025 v 14:35:39 UTC+1 uživatel Nigel Bray (SoftRF) napsal:

[Lukáš Jukl]

So I have just updated to the MB156 version and right after the update, the device is reporting to have a valid fix.

So hopefully everything should be alright.

Thanks a lot guys.

Dne úterý 25. února 2025 v 15:26:34 UTC+1 uživatel Moshe Braner napsal:

The word from LilyGo is that the default baud rate on the Ublox Neo-8 is 115200.  That is surprising, since all the previous Ublox modules had a default of 9600, and the official documentation for the -8 says (on page 466) that the default is 9600.  But we have seen that "clearing" its settings (to "factory defaults") did return to 115200 each time, at least on Nigel's board.

[Nigel Bray (SoftRF)]

I can confirm LilyGo delivered with 115200 set.  

Today a new TBeam_V1.2 M8N  already flashed with SoftRF 1.3 arrived.

SoftRF did not 'see' the GPS.  On installing MB156 it worked.

The log showed discovery of 115200:

Connecting to internal GNSS
Flash memory ID: EF4016

No GNSS NMEA at 9600 baud
Trying baud rate... 115200
... got NMEA!

ublox_query()...
INFO: UBLOX GNSS module HW version: 00080000
INFO: UBLOX GNSS module FW version: EXT CORE 3.01 (107900)
GNSS type found: U8
Pin 37 now reserved for GNSS PPS
range.txt does not exist

[Moshe Braner]

Thanks Nigel.  So the original version of SoftRF installed by LilyGo would not actually run?!