- Example scripts from the provided library [https://github.com/sparkfun/Qwiic_Ublox ... r/examples](https://github.com/sparkfun/Qwiic_Ublox_Gps_Py/blob/master/examples)
Script notes:
- The "dead_reckoning_ex3.py" copy [https://github.com/Nilles3D/mower/blob/ ... cker150.py](https://github.com/Nilles3D/mower/blob/main/dead_reckoning_ex3_Nacker150.py) (Script 1) script used is a combined version of [https://github.com/sparkfun/Qwiic_Ublox ... rds_ex1.py](https://github.com/sparkfun/Qwiic_Ublox_Gps_Py/blob/master/examples/geo_coords_ex1.py) and [https://github.com/sparkfun/Qwiic_Ublox ... ing_ex3.py](https://github.com/sparkfun/Qwiic_Ublox_Gps_Py/blob/master/examples/dead_reckoning_ex3.py). The combination was made to concurrently test if some NAV-PVT solutions were being made and some weren't. It has added checks before the terminal messages reference the returned class objects to avoid requesting attributes from None objects.
- The "geo_coords_ex1.py" copy [https://github.com/Nilles3D/mower/blob/ ... ounting.py](https://github.com/Nilles3D/mower/blob/main/geo_coords_ex1_counting.py) (Script 2) script takes the idea of Script 1 a step further by recording how many messages are received as expected and how many come back empty. It displays messages as they come in over the set amount of time and displays the results to the user upon the end of program runtime. The quantity of valid messages per unit time is hereafter referred to as "message yield."
Expected behavior:
- System powers on and is given 30 seconds to warm up.
- Script 1 is run, and the terminal shows (nearly) continuous messages of orientations and coordinates.
Actual behavior:
- System powers on and is given 30 seconds to 2 minutes to warm up
- Script 1 is run, and messages in the terminal show that Poll requests *mostly* come back empty. The time between most messages (~2.5 seconds) leads to the conclusion that no response was had from the module.
Steps to reproduce:
- Align and assemble the GPS module onto the GPIO pins of the RPi.
- Provide power to the RPi board.
- Run either Python script.
- Note the messages in a terminal window (see Figure 1).
Do note that the settings on the GPS module were reset to their defaults for all testing mentioned here.
Observations:
- Adjusting the "timeout" value for the Serial objection initialization was modified with values between and including 0.1 and 10. No significant effect on message rate or yield was observed. Multiple short-term tests (20 seconds to 4 minutes) were conducted.
- Script 2 was left to run twice for an hour each.
- The first run had 2268 messages come back successful; not a bad result considering that's 63% of the number of seconds the script ran.
- The second run was much less successful. If the assumption (based solely on default update time of the IC) was that a message should be received at an average of once per second, there was a success rate of 15%: only 540 messages were not None.
- The disparity between the two long-term tests does not provide the sense of message transfer consistency.
- Identical coordinates were seen between a few messages. The module does not seem to be denying a Poll request if the solution has not changed since the last request.
- The module's NAV solutions can be viewed updating once per second in U-Center (v23.08), and the solutions presented concur with expected values.
- The module reports a higher than expected amount of bytes skipped over the UART1 port in UBX-MON-COMMS (see Figure 2).
- U-Center indicates that the module is:
- using the expected and matching UBX-CFG-PRT baud rate of 38400 over UART1 (see Figure 3), and
- has UBX messages enabled both in and out of the module.
- Additional baud rates of 9600 and 115200 were tried. No change was observed.
- The RPi's Remote GPIO, Serial, and SPI communication interfaces are enabled. All others are disabled.
TL;DR
Is the **message response rate expected** to be missed/skipped as low as this? If not, **what should I change in the module's settings** to achieve a higher yield rate on returned messages?
The UART communication was received from the module (see Figure 4), and only the NMEA sentences were interpreted correctly by standard codecs (as I should have assumed based on UBX being proprietary). The time between viewable NMEA sentences was on the order of seconds. All other messages came back as undecipherable or gibberish (see Figure 5) and were removed from Figure 4’s output. They were many and seemed to be passing in second or sub-second intervals (see Figure 6).
Was this what you intended by use of a remote terminal? I fear I over-complicated it.
aliarifat794:
You can increase the timout incrementally and test.
Thank you for the suggestion, @aliarifat794, but my application needs a quicker response time than what I'm currently seeing. I'd also rather not have to change the timeout value in the source code.
