Anomalous GPS & OLED Display interactions

Adafruit Ethernet, Motor, Proto, Wave, Datalogger, GPS Shields - etc!

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
XMBfDn42
 
Posts: 27
Joined: Mon Jan 31, 2022 4:49 pm

Anomalous GPS & OLED Display interactions

Post by XMBfDn42 »

I'm working on a project that includes a GPS and OLED display among other boards; the CPU is the Feather M4. I have observed numerous occasions where the GPS will not update values when the display is updated "too often." The attached code will initialize the display, GPS, and OLED, and then enter a loop updating the display at a 1Hz rate with the latest GPU data, including UTC, latitude, longitude, altitude, quality, and #satellites.

Many times this works just fine. However, on some runs of the code, UTC (and other data) will not update every second. The loop iteration throbber (dot in upper-right corner) will indicate the loop is executing at perhaps 10Hz or more, however UTC will remain unchanged for 2, 5, and even 10 seconds before it updates. Restarting the code will often cause the anomaly to clear and the code return to proper execution.

In debugging this behavior, I noticed that the problem is most likely to occur when I update every value (i.e., all 5 lines) of the display on a 1Hz interval. The problem does not occur if I only display (or update) the time on a 1Hz interval. To test this, I added the ability to always update UTC wile only updating latitude, longitude, altitude, quality, #satellites when those values change. This effectively eliminates the anomaly. I can restart the code many times and the anomaly will not appear. If I re-enable all display updates on a 1Hz interval, the anomaly will sometimes appear.

The "ALWAYS" variable controls the display update; if true the values are displayed every 1Hz (and the anomaly may appear); if false the values are only updated when they change from the previously displayed value (and the anomaly is not observed).

Again, the throbber in the upper-right indicates gps.update() is being called at a sufficiently high rate (~10Hz?). You can observe the display updates (whether the anomaly is active or not) as a momentary pause in the throbber when the display is updated.

I did try always issuing a warm-start to the GPS when the program starts, but that had no impact on the issue. I've also considered enabling the GPS only when needed via the EN pin, but haven't yet added that wiring.

Updating the GPS data only when it changes is acceptable for my intended usage. However, there are other devices in the system and I would like to understand the root cause in case there are other anomalous GPS interactions down the road.

I haven't yet looked at the GPS code to see what's going on. Perhaps something with the SW UART?

Is this a known issue? Has this been observed by others?
Comments are most welcome.
Attachments
code-gps.py
(4.67 KiB) Downloaded 6 times

User avatar
adafruit_support_mike
 
Posts: 67454
Joined: Thu Feb 11, 2010 2:51 pm

Re: Anomalous GPS & OLED Display interactions

Post by adafruit_support_mike »

Check the raw NMEA sentences. You may be getting an occasional one without a good fix, or a garbled transmission between the GPS module and the microcontroller. Those happen occasionally.

User avatar
XMBfDn42
 
Posts: 27
Joined: Mon Jan 31, 2022 4:49 pm

Re: Anomalous GPS & OLED Display interactions

Post by XMBfDn42 »

The has_fix element is typically True during the anomalous behaviors; there's an explicit check for that.

Code: Select all

    if not gps.has_fix:
        line1.text = 'NOFIX: {}'.format( math.trunc( tm - t0 + 0.5 ) )
        continue
Observing the GPS' fix LED confirms the fix isn't lost. I'm typically getting 12-18 satellites from my patio.

Is there a way to look at the raw sentences in CircuitPython while the GPS is being used as expected?
Perhaps the "debug" value? How is that used?

To be clear, the values from the GPS object appear valid, they're just not being updated without any indication.

User avatar
adafruit_support_mike
 
Posts: 67454
Joined: Thu Feb 11, 2010 2:51 pm

Re: Anomalous GPS & OLED Display interactions

Post by adafruit_support_mike »

XMBfDn42 wrote:Is there a way to look at the raw sentences in CircuitPython while the GPS is being used as expected?
Use .nmea_sentence():

https://github.com/adafruit/Adafruit_Ci ... #L322-L324

User avatar
XMBfDn42
 
Posts: 27
Joined: Mon Jan 31, 2022 4:49 pm

Re: Anomalous GPS & OLED Display interactions

Post by XMBfDn42 »

Per the above, I put this into the loop just before displaying the 1 second interval data:

Code: Select all

    print( f'>{gps.nmea_sentence}<' )
And here's the edited (I obscured lat & lon) output showing stalled updates, particularly at 182617. Again, this anomaly is only present if I update all data on the OLED every iteration; the anomaly is not present if I only partially update the OLED every iteration.

Code: Select all

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
>$PMTK001,220,3,1000*1D<
>$GNRMC,182554.000,A,3348.xxxx,N,11804.xxxx,W,0.27,1.46,110622,,,D*60<
>$GNRMC,182555.000,A,3348.xxxx,N,11804.xxxx,W,0.15,1.46,110622,,,D*60<
>$GNRMC,182556.000,A,3348.xxxx,N,11804.xxxx,W,0.13,1.46,110622,,,D*64<
>$GNRMC,182557.000,A,3348.xxxx,N,11804.xxxx,W,0.04,1.46,110622,,,D*63<
>$GNRMC,182558.000,A,3348.xxxx,N,11804.xxxx,W,0.01,1.46,110622,,,D*6A<
>$GNRMC,182559.000,A,3348.xxxx,N,11804.xxxx,W,0.02,1.46,110622,,,D*68<
>$GNRMC,182600.000,A,3348.xxxx,N,11804.xxxx,W,0.06,1.46,110622,,,D*63<
>$GNRMC,182600.000,A,3348.xxxx,N,11804.xxxx,W,0.06,1.46,110622,,,D*63<
>$GNRMC,182602.000,A,3348.xxxx,N,11804.xxxx,W,0.57,1.46,110622,,,D*65<
>$GNRMC,182603.000,A,3348.xxxx,N,11804.xxxx,W,0.44,1.46,110622,,,D*64<
>$GNRMC,182604.000,A,3348.xxxx,N,11804.xxxx,W,0.53,1.46,110622,,,D*64<
>$GNRMC,182605.000,A,3348.xxxx,N,11804.xxxx,W,0.29,1.46,110622,,,D*67<
>$GNRMC,182605.000,A,3348.xxxx,N,11804.xxxx,W,0.29,1.46,110622,,,D*67<
>$GNRMC,182605.000,A,3348.xxxx,N,11804.xxxx,W,0.29,1.46,110622,,,D*67<
>$GNRMC,182608.000,A,3348.xxxx,N,11804.xxxx,W,0.18,1.46,110622,,,D*60<
>$GNRMC,182609.000,A,3348.xxxx,N,11804.xxxx,W,0.41,1.46,110622,,,D*6D<
>$GNRMC,182609.000,A,3348.xxxx,N,11804.xxxx,W,0.41,1.46,110622,,,D*6D<
>$GNRMC,182609.000,A,3348.xxxx,N,11804.xxxx,W,0.41,1.46,110622,,,D*6D<
>$GNRMC,182609.000,A,3348.xxxx,N,11804.xxxx,W,0.41,1.46,110622,,,D*6D<
>$GNRMC,182613.000,A,3348.xxxx,N,11804.xxxx,W,0.02,1.46,110622,,,D*61<
>$GNRMC,182614.000,A,3348.xxxx,N,11804.xxxx,W,0.34,1.46,110622,,,D*60<
>$GNRMC,182614.000,A,3348.xxxx,N,11804.xxxx,W,0.34,1.46,110622,,,D*60<
>$GNRMC,182614.000,A,3348.xxxx,N,11804.xxxx,W,0.34,1.46,110622,,,D*60<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182617.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182635.000,A,3348.xxxx,N,11804.xxxx,W,0.05,1.46,110622,,,D*60<
>$GNRMC,182636.000,A,3348.xxxx,N,11804.xxxx,W,0.16,1.46,110622,,,D*60<
>$GNRMC,182636.000,A,3348.xxxx,N,11804.xxxx,W,0.16,1.46,110622,,,D*60<
>$GNRMC,182636.000,A,3348.xxxx,N,11804.xxxx,W,0.16,1.46,110622,,,D*60<
>$GNRMC,182639.000,A,3348.xxxx,N,11804.xxxx,W,0.10,1.46,110622,,,D*69<
>$GNRMC,182640.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182640.000,A,3348.xxxx,N,11804.xxxx,W,0.07,1.46,110622,,,D*61<
>$GNRMC,182642.000,A,3348.xxxx,N,11804.xxxx,W,0.60,29.85,110622,,,D*50<
>$GNRMC,182643.000,A,3348.xxxx,N,11804.xxxx,W,0.62,28.31,110622,,,D*56<
>$GNRMC,182643.000,A,3348.xxxx,N,11804.xxxx,W,0.62,28.31,110622,,,D*56<
>$GNRMC,182643.000,A,3348.xxxx,N,11804.xxxx,W,0.62,28.31,110622,,,D*56<
>$GNRMC,182643.000,A,3348.xxxx,N,11804.xxxx,W,0.62,28.31,110622,,,D*56<
>$GNRMC,182643.000,A,3348.xxxx,N,11804.xxxx,W,0.62,28.31,110622,,,D*56<
>$GNRMC,182643.000,A,3348.xxxx,N,11804.xxxx,W,0.62,28.31,110622,,,D*56<
>$GNRMC,182649.000,A,3348.xxxx,N,11804.xxxx,W,0.07,28.31,110622,,,D*5C<
>$GNRMC,182649.000,A,3348.xxxx,N,11804.xxxx,W,0.07,28.31,110622,,,D*5C<
>$GNRMC,182649.000,A,3348.xxxx,N,11804.xxxx,W,0.07,28.31,110622,,,D*5C<
>$GNRMC,182649.000,A,3348.xxxx,N,11804.xxxx,W,0.07,28.31,110622,,,D*5C<
>$GNRMC,182649.000,A,3348.xxxx,N,11804.xxxx,W,1.07,28.31,110622,,,D*5C<
Please advise.

User avatar
adafruit_support_mike
 
Posts: 67454
Joined: Thu Feb 11, 2010 2:51 pm

Re: Anomalous GPS & OLED Display interactions

Post by adafruit_support_mike »

Throw some diagnostic print statements into the module’s _read_sentence() function:

https://github.com/adafruit/Adafruit_Ci ... ps.py#L346

It has a lot of escape clauses that return None if it doesn’t see a correctly formed sentence. My guess is that you’re getting drop-out data between the successful reads.

User avatar
XMBfDn42
 
Posts: 27
Joined: Mon Jan 31, 2022 4:49 pm

Re: Anomalous GPS & OLED Display interactions

Post by XMBfDn42 »

While not-valid and checksum errors do sometimes occur with good updates, e.g., 15:55:53-15:55:54,, here's a run with non-updated data and error returns in _read_sentence(), e.g., 15:55:57

Code: Select all

>$GNRMC,155552.000,A,3348.xxxx,N,11804.xxxx,W,0.04,65.46,120622,,,D*5E<
>$GNRMC,155553.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*59<
actual(001c) != expected(007c)
>$GNRMC,155554.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*5D<
actual(0000) != expected(007e)
>$GNRMC,155555.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5F<
>$GNRMC,155556.000,A,3348.xxxx,N,11804.xxxx,W,0.03,65.46,120622,,,D*5D<
actual(0020) != expected(007d)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
not valid
actual(0017) != expected(0050)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0017) != expected(0054)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0015) != expected(005d)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(004b) != expected(005d)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0010) != expected(0058)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0017) != expected(005f)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0011) != expected(0059)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0013) != expected(005b)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0010) != expected(0058)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0015) != expected(005d)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(001b) != expected(0053)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(001b) != expected(0053)
>$GNRMC,155557.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
actual(0048) != expected(007a)
>$GNRMC,155610.000,A,3348.xxxx,N,11804.xxxx,W,0.10,65.46,120622,,,D*5F<
actual(0021) != expected(0070)
>$GNRMC,155611.000,A,3348.xxxx,N,11804.xxxx,W,0.47,65.46,120622,,,D*5B<
>$GNRMC,155612.000,A,3348.xxxx,N,11804.xxxx,W,0.12,65.46,120622,,,D*5F<
actual(0037) != expected(0076)
>$GNRMC,155613.000,A,3348.xxxx,N,11804.xxxx,W,0.04,65.46,120622,,,D*59<
actual(0052) != expected(007d)
>$GNRMC,155614.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*5B<
actual(0069) != expected(0072)
>$GNRMC,155615.000,A,3348.xxxx,N,11804.xxxx,W,0.04,65.46,120622,,,D*5F<
>$GNRMC,155616.000,A,3348.xxxx,N,11804.xxxx,W,0.03,65.46,120622,,,D*5B<
actual(0027) != expected(0070)
>$GNRMC,155617.000,A,3348.xxxx,N,11804.xxxx,W,0.03,65.46,120622,,,D*5A<
actual(0028) != expected(0070)
>$GNRMC,155618.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*57<
actual(004a) != expected(0071)
>$GNRMC,155619.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*55<
actual(0028) != expected(007b)
>$GNRMC,155620.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5F<
actual(0079) != expected(0075)
>$GNRMC,155621.000,A,3348.xxxx,N,11804.xxxx,W,0.04,65.46,120622,,,D*58<
actual(0011) != expected(0073)
>$GNRMC,155622.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*5E<
actual(006c) != expected(0072)
>$GNRMC,155623.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5C<
>$GNRMC,155624.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5B<
actual(002e) != expected(0074)
>$GNRMC,155625.000,A,3348.xxxx,N,11804.xxxx,W,0.02,65.46,120622,,,D*5A<
actual(0048) != expected(0077)
>$GNRMC,155626.000,A,3348.xxxx,N,11804.xxxx,W,0.03,65.46,120622,,,D*58<
>$GNRMC,155627.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*5B<
actual(0078) != expected(0079)
>$GNRMC,155628.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*54<
>$GNRMC,155629.000,A,3348.xxxx,N,11804.xxxx,W,0.01,65.46,120622,,,D*55<
actual(0048) != expected(0070)
>$GNRMC,155630.000,A,3348.xxxx,N,11804.xxxx,W,0.03,65.46,120622,,,D*5F<
>$GNRMC,155631.000,A,3348.xxxx,N,11804.xxxx,W,0.03,65.46,120622,,,D*5E<
>$GNRMC,155632.000,A,3348.xxxx,N,11804.xxxx,W,0.00,65.46,120622,,,D*5E<
actual(007d) != expected(0072)
I increased the GPS update rate to 2Hz and while the errors continued, GPS data were updated

Code: Select all

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
>$GNRMC,160754.000,A,3348.xxxx,N,11804.xxxx,W,0.00,257.18,120622,,,D*60<
actual(0034) != expected(007f)
>$GNRMC,160755.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*60<
actual(001a) != expected(0064)
>$GNRMC,160756.000,A,3348.xxxx,N,11804.xxxx,W,0.00,257.18,120622,,,D*62<
actual(000d) != expected(007d)
>$GNRMC,160757.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*62<
actual(0020) != expected(0067)
>$GNRMC,160758.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6D<
actual(0016) != expected(0068)
>$GNRMC,160759.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6C<
not valid
>$GNRMC,160800.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6F<
>$GNRMC,160801.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6E<
actual(0014) != expected(006a)
>$GNRMC,160802.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6D<
actual(0018) != expected(006a)
>$GNRMC,160803.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6C<
actual(0040) != expected(0068)
>$GNRMC,160804.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6B<
actual(0038) != expected(006d)
>$GNRMC,160805.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*69<
actual(0052) != expected(006c)
>$GNRMC,160806.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*6A<
actual(0053) != expected(006c)
>$GNRMC,160807.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*68<
actual(0013) != expected(006d)
>$GNRMC,160808.000,A,3348.xxxx,N,11804.xxxx,W,0.00,257.18,120622,,,D*66<
actual(0049) != expected(0079)
>$GNRMC,160809.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*66<
actual(0043) != expected(0063)
>$GNRMC,160810.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6E<
actual(0015) != expected(006b)
>$GNRMC,160811.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*6C<
actual(007e) != expected(0068)
>$GNRMC,160812.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6D<
actual(0016) != expected(0068)
>$GNRMC,160813.000,A,3348.xxxx,N,11804.xxxx,W,0.00,257.18,120622,,,D*6D<
actual(0054) != expected(0073)
>$GNRMC,160814.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*68<
actual(0013) != expected(006d)
>$GNRMC,160815.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6A<
actual(0034) != expected(0075)
>$GNRMC,160816.000,A,3348.xxxx,N,11804.xxxx,W,0.00,257.18,120622,,,D*68<
actual(0012) != expected(006c)
>$GNRMC,160817.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*6B<
actual(0070) != expected(0077)
>$GNRMC,160818.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*64<
actual(001c) != expected(0062)
>$GNRMC,160819.000,A,3348.xxxx,N,11804.xxxx,W,0.00,257.18,120622,,,D*67<
actual(001d) != expected(0063)
>$GNRMC,160820.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6C<
actual(0078) != expected(0069)
>$GNRMC,160821.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*6E<
actual(0020) != expected(0072)
>$GNRMC,160822.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6E<
not valid
>$GNRMC,160823.000,A,3348.xxxx,N,11804.xxxx,W,0.01,257.18,120622,,,D*6F<
actual(004b) != expected(006a)
>$GNRMC,160824.000,A,3348.xxxx,N,11804.xxxx,W,0.02,257.18,120622,,,D*6B<
not valid
As expected, reducing the OLED updates cause the _read_sentence() errors to cease.

OLED updates can be the most time-consuming activities of my project, so I suppose the CPU is just too busy for the SW UART to keep up.
I suppose the WA is Don't Do That! :)

User avatar
adafruit_support_mike
 
Posts: 67454
Joined: Thu Feb 11, 2010 2:51 pm

Re: Anomalous GPS & OLED Display interactions

Post by adafruit_support_mike »

Hmm… OLED updates should only last a few milliseconds. I wouldn’t expect that to cause any problems at 1Hz or 2Hz.

In general though, the trend in programming is to do as little as necessary as late as possible. If you already have code that updates at need, stick with that. It will give you more flexibility for further development.

User avatar
XMBfDn42
 
Posts: 27
Joined: Mon Jan 31, 2022 4:49 pm

Re: Anomalous GPS & OLED Display interactions

Post by XMBfDn42 »

OLED updates take a surprising amount of time, at least from CircuitPython; that's what led to the display optimization.
From 102 trials on a Feather M4 driving the 128x96 monochrome OLED, updating 5 labels with 67 characters, Avg: 0.240s, min: 0.138s, max: 0.669s, StdDev: 0.0878s

These trials again confirmed that the anomaly may be present at 1Hz GPS updates but wasn't observed with 2Hz updates.
This currently appears sufficient for my project.

Thanks!!!!
--
dnl

User avatar
adafruit_support_mike
 
Posts: 67454
Joined: Thu Feb 11, 2010 2:51 pm

Re: Anomalous GPS & OLED Display interactions

Post by adafruit_support_mike »

Glad to hear things are working for you.. happy hacking!

Locked
Please be positive and constructive with your questions and comments.

Return to “Arduino Shields from Adafruit”