Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I tell why the encoder didn't process my sentences? #102

Open
RandyPfeifer opened this issue May 6, 2022 · 13 comments
Open

How can I tell why the encoder didn't process my sentences? #102

RandyPfeifer opened this issue May 6, 2022 · 13 comments

Comments

@RandyPfeifer
Copy link

RandyPfeifer commented May 6, 2022

Hi, New to this whole Arduino scene....
I am running tinyGPSPlus on a Seeeduino XIAO platform with I2C connected to a display and a compass module in addition to the NEO-6M GPS module.

when running the example programs everything works just fine so it would seem that I've wired things Ok.

When I integrate the .h files into my larger program and then try to do the same functions, I almost never get anything to be printed by displayinfo(); (as utilized from the DeviceExample). I'm using D9, D8 and 9600 baud software serial. I've ported over all of the setup() and other declarations from the examples (kitchensink.ino primarily although I've toyed with all of the examples).

This snippet of code from DeviceExample.ino:
while (ss.available() > 0)
if(gps.encode(ss.read()))
displayInfo();

produces no Serial.printf() output from displayInfo().

I added some code just after the above code to grab the text and print them myself:

delay(2000); // let the encoder get the first available sentence and print the next one myself.
while (ss.available() > 0) {
char character = ss.read();
Serial.print(character);

This snippet of code generates output on the serial monitor (1 line per cycle of the loop()) that looks legit (based on my reading of a couple NMEA sentence definitions I found. There is apparently something wrong with it but I can't tell what is afoul. Here's what that output looks like on the serial monitor (ignore the x:, y:, z:, etc stuff - it's output from the compass and other calculations in reset of my program).

21:15:44.607 -> $GPRMC,021543.00,A,4335.24758,N,09005.07362,W,0.182,,060522,,,A x: 722,y: -1513,z: 868,Target: 295.53,Measurement: 295.51,Error: -0.02,Cumulative Error: 6.09
21:15:46.738 -> $GPRMC,021545.00,A,4335.24759,N,09005.07421,W,0.064,,060522,,,A x: 726,y: -1514,z: 865,Target: 295.53,Measurement: 295.62,Error: 0.08,Cumulative Error: 6.17
21:15:48.550 -> $GPRMC,021547.00,A,4335.24754,N,09005.07421,W,0.238,,060522,,,A x: 728,y: -1519,z: 865,Target: 295.53,Measurement: 295.61,Error: 0.07,Cumulative Error: 6.24
21:15:50.702 -> $GPRMC,021549.00,A,4335.24748,N,09005.07482,W,0.468,,060522,,,A x: 720,y: -1514,z: 854,Target: 295.53,Measurement: 295.43,Error: -0.10,Cumulative Error: 6.14
21:15:52.561 -> $GPRMC,021551.00,A,4335.24748,N,09005.07554,W,0.716,,060522,,,A x: 719,y: -1518,z: 864,Target: 295.53,Measurement: 295.34,Error: -0.19,Cumulative Error: 5.95
21:15:54.662 -> $GPRMC,021553.00,A,4335.24724,N,09005.07558,W,0.529,,060522,,,A x: 726,y: -1510,z: 868,Target: 295.53,Measurement: 295.68,Error: 0.14,Cumulative Error: 6.10
21:15:56.595 -> $GPRMC,021555.00,A,4335.24727,N,09005.07596,W,0.548,,060522,,,A x: 728,y: -1513,z: 867,Target: 295.53,Measurement: 295.70,Error: 0.16,Cumulative Error: 6.26

So my question is, is there a good way to tell why the encoder didn't successfully encode the above sentences and allow the displayInfo() routine to successfully print anything?

It seems more likely that I did something wrong instantiating TinyGPSPlus into my program given the same hardware is used in both the example code and my program... But I just don't see what's wrong here.

Any help/suggestions would be much appreciated. I don't doubt that the encoder found something reprehensible (or that I'm using it wrong) but I can't figure out what it is. I really don't want to try to parse these sentences myself.

Thanks in advance.

should you be interested, the code that includes this issue is here: [https://github.com/RandyPfeifer/Compass-Error-Tracker/blob/main/src/CET%2BGPS-WIP.cpp]

Screen Shot 2022-05-05 at 9 00 26 PM
]

@cyberman54
Copy link

to debug, use methods that are described here in section "Debugging": http://arduiniana.org/libraries/tinygpsplus/

@RandyPfeifer
Copy link
Author

Thanks for the quick response. I've updated my code to count failed checksums and look for overflow... I have no bad checksums but do have SS overflow. I would expect this because I have a loop that is a couple seconds long.

I changed the order of some of the code to service the GPS module serial port before attempting to feed the encode...

while (ss.available() > 0)
Serial.write(ss.read());

//delay(20);

while (ss.available() > 0)
if(gps.encode(ss.read()))
displayInfo();

Serial.print("Sentences that failed checksum=");
Serial.println(gps.failedChecksum());
Serial.print("Sentences with fix=");
Serial.println(gps.sentencesWithFix());

// Testing overflow in SoftwareSerial is sometimes useful too.
Serial.print("Soft Serial device overflowed? ");
Serial.println(ss.overflow() ? "YES!" : "No");

This shows all the checksums are good... But no sentences with a fix and Overflow (as I would expect)...

Screen Shot 2022-05-06 at 8 10 29 AM

Am I not "servicing" the overflow or emptying the GPS module's buffer properly to allow for proper encoding? But I don't see anything wrong with the $GPRMC sentences printed...

Thanks again for your quick response.

@RandyPfeifer
Copy link
Author

Oh but when I added a processed character counter it wasn't incrementing very fast. after a few other changes it is now incrementing in bursts. Checksum errors are also occurring on occasion (but not as frequently as the character count is increasing.

I'll keep poking at it.

Thanks again for your guidance.

@cyberman54
Copy link

cyberman54 commented May 6, 2022

Your display routine displayInfo() prints only data, if gps got a fix. But it seems it doesn't have one: "sentences with fix=0". Thus, nothing is printed.

Bursts are normal with NMEA protocol, since gps data is coming in cyclic.

@RandyPfeifer
Copy link
Author

"Sentences with fix=0" yet there are clearly sentences with date, time and position data in them that are passing the checksum and are incrementing the processed character count (albeit in bursts)....

@RandyPfeifer
Copy link
Author

Confirm something for me... If I read this code right displayInfo() will be called for every character received from the GPS module. Or does gps.encode only return true if it completes a sentence?

while (ss.available() > 0)
if(gps.encode(ss.read()))
displayInfo();

@RandyPfeifer
Copy link
Author

NVM it looks like displayInfo() is invoked only when a sentence is encoded (not every character)

@cyberman54
Copy link

encode returns true, after a valid sentence was processed, not every character.

@RandyPfeifer
Copy link
Author

After looking some more I think I have more fundamental problems. while the example Tinygpsplus_sample.ino runs and reports good results, when I print out characters processed, failed checksums and sentences with a fix, I get a lot of errors:
Screen Shot 2022-05-06 at 10 03 39 AM

The number of checksum errors are close to the number of sentences with a fix. Both numbers increase about once per second and every so often the Fix count goes up by one and the checksum fail count doesn't.... So now my question (for me to figure out) is why doesn't even the example code run well....

@cyberman54
Copy link

Check your timing, wiring, serial interface, and configuration of gps chip. This won't be an issue of Tinygps, it usually runs smooth and stable.

@RandyPfeifer
Copy link
Author

Very good. Thanks again for your attention and support.

much appreciated.

@mikalhart
Copy link
Owner

All good here, @RandyPfeifer? Good rule of thumb is don't put any delay()s in your processing loop and do as little Serial.print...ing as possible.

@uzi18
Copy link

uzi18 commented Jul 31, 2024

This is real solution for serial buffer overflow at the time of debugging this lib.
Add these lines as first in sketch:

#define SERIAL_TX_BUFFER_SIZE 256
#define SERIAL_RX_BUFFER_SIZE 256

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants