Location Status goes to all 0's, then back to actual location

[kusznir]

Hello:

First, thanks for an awesome project!

I was testing using the sparkfun breakout Zed F9P, and all was good and stable, but that is a prototype board....I wanted something more permanent. I'm using a Raspberry Pi, so I found:

https://www.waveshare.com/zed-f9p-gps-rtk-hat.htm

And just switched over to it. It is using the /dev/serial interface, and I have run the configure GNSS button from the UI. On the status screen, all looks good, with good signal levels (same as the old board), but every random interval of seconds (10-45), the location will switch to all 0's briefly (and the map will zoom way out), but within a second, the location repopulates to the correct one again.

What causes this? It should be the same GPS chip, so only thing I can see is using /dev/ttyS0 instead of the usb-serial adapter....

Supposidly this gps board is wired for I2C, but I haven't seen any docs for how to set rtkbase and the Zed F9P up for I2C, if that's even an option, or if that is something that would help...

Only thing I can think of is 115200 is too fast for onboard serial driver?

Thanks for your support!

[kusznir]

Some more info: I confirmed that the same issue happens with the gps board when plugged in via USB (its a pi-hat, so its designed to use serial, but has a micro-USB port on the side too). I also confirmed that when I have all services but the main one turned off, I get the documented behavior. If I turn on any other services, then it just stays at all 0's all the time (but does display signal bar graphs for the satellites in view).

This almost seems like an issue with software / CPU Load or something like that. However, I switched back to the Sparkfun board, and it worked like it was supposed to. The only difference I noticed in the settings information was the problem board is identified as U-blox_ZED-F9P - 1.12 while the sparkfun board is identified as U-blox_ZED-F9P - 1.13. I assume the version is the firmware...Not sure if that's all there is to it or not.

[Update] Ok, it is firmware, and I did upgrade to the latest version. Initially, no change in behavior. I used u-blox to download the config from the sparkfun and upload it to the waveshare board, and with USB, it is stable. However, if I use the serial pins from the GPIO header on the pi (/dev/serial0 / /dev/TTYS0), I still have the reliability issues.

I did notice one more detail when closely examining the boards: the sparkfun board uses ZED-F9P-02b-00 while the waveshare board uses the ZED-F9P-01B-00 board. I could not find anything on the difference between these two boards, and the -01B part doesn't even appear to exist on the u-blox website. Of course, I have not tried soldering pins onto my breakout and hooking the rs232 pins of the sparkfun up to the header ports of the pi, so at this point, the common configuration is working the same for both boards. I would like to not have to have a USB cable coming out from my not-fully-attached case, and plugging into the pi's usb port when all the IO is available on the GPIO header that is already attached...Perhaps I2C is a better option? If so, I have no idea how to set it up (especially with respect to rtkbase)

[jdhuangx]

The simplest solution I can think of is to add the following lines to filter out the msg={} case. This way, the coordinates won’t jump to (0, 0, 0).

    if(Object.entries(msg).length==0){
        return;
    }