MicroPython_ESP32_psRAM_LoBo icon indicating copy to clipboard operation
MicroPython_ESP32_psRAM_LoBo copied to clipboard

gps.getdata() function doesn't refresh date/time without GPS fix

Open capedra opened this issue 7 years ago • 11 comments

Hello Lobo, first of all, congratulations for this great development of MicroPython!

I followed your tutorial from https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo/wiki/gps and here it's what I'm facing: The gps.getdata() function always returns ((1900, 1, 1, 0, 0, 0, 1, 1), 0.0, 0.0, 0.0, 0, 0, 0.0, 0.0, 0.0) The only difference from your example is that I'm using a GPS module which only outputs GNGGA and GNRMC instead of GPGGA and GPRMC. Could you please fix it and publish a new firmware (esp32_psram_all_bt) to download?

Thanks a lot and Best Regards!

capedra avatar Oct 09 '18 06:10 capedra

Could you, please, post the output of gps.read() or gps.read(1500) containing the GNRMC and GNGGA sentences.

loboris avatar Oct 09 '18 08:10 loboris

Could you, please, post the output of gps.read() or gps.read(1500) containing the GNRMC and GNGGA sentences.

Hello Lobo. Sure, I will send it. So, I was testing today and I found out that the getdata function only displays the correct information whenever the GPS module gets more than 3 satellites, and this way, the latitude and longitude. The real issue here is that the getdata function doesn't return the correct date/time before the GPS gets the fix and even after the GPS loses the fix.

Besides that, the read function displays old data from the buffer before getting the fresh data with the fix. Here's the output after the GPS got the fix:

>>> gps.read()
'$GNGGA,,,,,,0,00,99.99,,,,,,*56\r\n'
>>> gps.read()
'$GNRMC,,V,,,,,,,,,,N,V*37\r\n'

After a few readings, I get the correct information:

>>> gps.getdata()
((2018, 10, 10, 5, 20, 23, 4, 283), etc ... )

I even tried setting the parameter buffer_size=0 on the UART constructor: uart = UART(2, rx=26, tx=25, baudrate=115200, bits=8, parity=None, stop=1, timeout=1500, buffer_size=0, lineend='\r\n'), but this new issue persists.

capedra avatar Oct 10 '18 05:10 capedra

So, it actually works as expected.

The sentence's valid field must be set for data to be parsed.

gps.getdata() always returns the last valid data received (background service must be running or the data must be manually read for data structure to be populated).

gps.read() and gps.read_parse() reads the sentences from UART buffer in order thay are received. You have to repeat the read until an empty string is received to read all the sentences from the buffer.

The normal operating mode is to activate the background service, either in a constructor, in gps.init() or with gps.startservice(). After the service is activated, the sentences will be read and parsed in background and gps.getdata() will always return the latest data.

This is all documented in the Wiki

loboris avatar Oct 10 '18 08:10 loboris

Then how may I run the background service and still get the correct timestamp without acquiring some fix?

capedra avatar Oct 10 '18 22:10 capedra

Currently, the timestamp is updated if GGA sentence has Number of satelites > 0 and Fix quality > 0. It could be changed in a way that the timestamp is populated even without fix, with only 1 satelite. It could be useful if the time cannot be updated via NTP and you cannot get the GPS fix.

I'll test it and probably implement in the next update.

loboris avatar Oct 11 '18 09:10 loboris

Currently, the timestamp is updated if GGA sentence has Number of satelites > 0 and Fix quality > 0. It could be changed in a way that the timestamp is populated even without fix, with only 1 satelite. It could be useful if the time cannot be updated via NTP and you cannot get the GPS fix.

I'll test it and probably implement in the next update.

Exactly. People have bad GPS signals sometimes. I have a very bad signal here at my living room and it will be a great feature for you to add. I look forward for it. Thanks a lot, my friend!

capedra avatar Oct 11 '18 19:10 capedra

Friend, my ESP32 keeps resetting after a long time running the GPS service. After the ESP32 reboots, I stop the GPS service and it doesn't reboot anymore. Here's the output of the reset:

>>>
>>> ets Jun  8 2016 00:22:57

rst:0x8 (TG1WDT_SYS_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5868
load:0x40078000,len:7756
ho 0 tail 12 room 4
load:0x40080000,len:6016
entry 0x40080324
W (91) boot: PRO CPU has been reset by WDT.
W (91) boot: WDT reset info: PRO CPU PC=0x400985fa
W (92) boot: WDT reset info: APP CPU PC=0x40081e21
I (98) boot: ESP-IDF v3.1-rc1-53509c7b 2nd stage bootloader
I (104) boot: compile time 13:17:40
I (110) boot: Enabling RNG early entropy source...
I (114) boot: SPI Speed      : 40MHz
I (118) boot: SPI Mode       : DIO
I (122) boot: SPI Flash Size : 4MB
I (126) boot: Partition Table:
I (130) boot: ## Label            Usage          Type ST Offset   Length
I (137) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (145) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (152) boot:  2 MicroPython      factory app      00 00 00010000 00240000
I (160) boot:  3 internalfs       Unknown data     01 82 00250000 00100000
I (167) boot: End of partition table
I (172) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x70d28 (46                                                                                        2120) map
I (342) esp_image: segment 1: paddr=0x00080d50 vaddr=0x3ffc0000 size=0x05808 ( 2                                                                                        2536) load
I (351) esp_image: segment 2: paddr=0x00086560 vaddr=0x3ffc5808 size=0x00000 (                                                                                             0) load
I (351) esp_image: segment 3: paddr=0x00086568 vaddr=0x40080000 size=0x00400 (                                                                                          1024) load
I (358) esp_image: segment 4: paddr=0x00086970 vaddr=0x40080400 size=0x096a0 ( 3                                                                                        8560) load
I (382) esp_image: segment 5: paddr=0x00090018 vaddr=0x400d0018 size=0x19eb4c (1                                                                                        698636) map
I (977) esp_image: segment 6: paddr=0x0022eb6c vaddr=0x40089aa0 size=0x16034 ( 9                                                                                        0164) load
I (1013) esp_image: segment 7: paddr=0x00244ba8 vaddr=0x400c0000 size=0x00664 (                                                                                          1636) load
I (1014) esp_image: segment 8: paddr=0x00245214 vaddr=0x50000000 size=0x0098c (                                                                                          2444) load
I (1041) boot: Loaded app from partition at offset 0x10000
I (1041) boot: Disabling RNG early entropy source...
I (1042) spiram: SPI RAM mode: flash 40m sram 40m
I (1047) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (1054) cpu_start: Pro cpu up.
I (1058) cpu_start: Starting app cpu, entry point is 0x400816cc
I (0) cpu_start: App cpu up.
I (1919) spiram: SPI SRAM memory test OK
I (1919) heap_init: Initializing. RAM available for dynamic allocation:
D (1920) heap_init: New heap initialised at 0x3ffaff10
I (1925) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
D (1931) heap_init: New heap initialised at 0x3ffd2038
I (1936) heap_init: At 3FFD2038 len 0000DFC8 (55 KiB): DRAM
I (1942) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1949) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
D (1955) heap_init: New heap initialised at 0x4009fad4
I (1960) heap_init: At 4009FAD4 len 0000052C (1 KiB): IRAM
I (1967) cpu_start: Pro cpu start user code
I (1972) spiram: Adding pool of 4096K of external SPI memory to heap allocator
D (1987) clk: RTC_SLOW_CLK calibration value: 3368550
I (208) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
D (210) heap_init: New heap initialised at 0x3ffe0440
D (214) heap_init: New heap initialised at 0x3ffe4350
D (219) MicroPython: Entry
D (1222) MicroPython: SPIRAM: Enabled
D (1231) nvs: nvs_flash_init_custom partition=nvs start=9 count=6
D (1262) MicroPython: Configure stack
D (1262) nvs: nvs_open_from_partition MPY_NVM 1
D (1262) nvs: nvs_get MPY_StackSize 4
D (1263) nvs: nvs_get_str_or_blob MpyTimeZone
D (1267) MicroPython: MPy stack: 0x3ffd7198 - 0x3ffdc1a0 (20488)
D (1273) MicroPython: Configure heap
D (1277) nvs: nvs_get MPY_HeapSize 4
D (1280) MicroPython: MPy heap: 0x3f80001c - 0x3fb0005c (3145728)
D (1287) MicroPython: Main task exit, stack used: 1436
I (1296) MicroPython: [=== MicroPython FreeRTOS task started (sp=3ffdc0f0) ===]


Internal FS (SPIFFS): Mounted on partition 'internalfs' [size: 1048576; Flash ad                                                                                        dress: 0x250000]
----------------
Filesystem size: 956416 B
           Used: 5632 B
           Free: 950784 B
----------------
GPS service configured!
Mounting SD card!
---------------------
 Mode: SPI
     Name: SS08G
     Type: SDHC/SDXC
    Speed: default speed (25 MHz)
SPI speed: 40 MHz
     Size: 7580 MB
      CSD: ver=1, sector_size=512, capacity=15523840 read_bl_len=9
      SCR: sd_spec=2, bus_width=5

I (2386) phy: phy_version: 3960, 5211945, Jul 18 2018, 10:40:07, 0, 0
main entered
Hello World From main.py!!!
MicroPython ESP32_LoBo_v3.2.24 - 2018-09-06 on ESP32&psRAM board with ESP32
Type "help()" for more information.

capedra avatar Oct 12 '18 04:10 capedra

The reset is caused by the watchtog timer on core 0, so it is probably not related to the MicroPython code (which runs on core 1). How long is "long time running the GPS service"? Can you provide the log at the time of the reset (running from esp-idf monitor)? What else was running at the time of the reset?

loboris avatar Oct 12 '18 09:10 loboris

@loboris Running like an hour or so without even running anything. I have no idea how to run the esp-idf monitor. I reactivated the GPS service because that's not the main problem. I've switched all the pins of the components so now I'm currently testing what the issue should be. For example, I heard you should not use UART2 if you have an ESP-32 with PSRAM.. but I'm currently using this UART2 for my GPS (using pins 32 and 33, instead of 16 and 17). So, I'm trying to solve it.

capedra avatar Oct 13 '18 07:10 capedra

The board randomly resets without a specific time, without running any commands and with this same error code: TG1WDT_SYS_RESET. I'm now testing the firmware without the bluetooth.

capedra avatar Oct 13 '18 07:10 capedra

Hello @loboris ! I have a NEO-6M module connected to a T-Call TTGO board. In my case, I have this problem:

>>> gps.startservice()
True
>>> gps.getdata()
((1900, 1, 1, 0, 0, 0, 1, 1), 0.0, 0.0, 0.0, 0, 0, 0.0, 0.0, 0.0)
>>> gps.stopservice()
True
>>> gps.read()
''

The constructor I declared it as follows:

uart = machine.UART(2, rx=12, tx=15, baudrate=9600, bits=8, parity=None, stop=1, timeout=1500, buffer_size=1024, lineend='\r\n')
gps = machine.GPS(uart)

I have seen that I do not have any kind of response from the UART

>>> uart.read()
b''

This program, I test on other firmware and works.

Could you guide me where the problem is?

ciror00 avatar Dec 30 '20 18:12 ciror00