Does anyone know what gps.encode() actually does? I mean in detail.
If you went to this site GitHub - mikalhart/TinyGPSPlus: A new, customizable Arduino NMEA parsing library and looked here TinyGPSPlus/src at master · mikalhart/TinyGPSPlus · GitHub you could open up TinyGPSPlus/TinyGPS++.cpp at master · mikalhart/TinyGPSPlus · GitHub and scroll to this function bool TinyGPSPlus::encode(char c) and see for yourself.
If only...
Ok, I'll do that. Thanks.
Just looked at the code you linked me to. I asked for detail and you gave it to me.
Is there a high level description of what the detail achieves?
I did not look.
Well, it's in C code. I won't be able to work out what it does. A high level description would be helpful.
gps.encode() processes just one character. What does it do with that character? How does it form sentences? How does it extract fields from the sentences.
Did you ask the code author?
Yes. Only one hour ago.
One thing I wanted to know is what gps.encode() returns. By examining the bool procedure you pointed me to, I think it returns true when a valid sentence has been received, otherwise false.
That's something I haven't seen explained before.
If the character is a comma, asterisk, Newline, or Return/Enter it signals the end of a 'term' and endOfTermHandler() is called. The library processes the term based on which message type (term 0) is in progress and which term just ended. The asterisk indicates that the next term is the checksum so the next time endOfTermHandler() is called (Newline, or Return/Enter) the checksum is checked and endOfTermHandler() returns 'true' if the checksum was correct or 'false' if the checksum was incorrect. That true or false is passed back to the caller to indicate if a full, valid message has been processed.
The various fields are set as they appear but are only committed (become the current value) when the checksum is found to be correct.
Thanks, jw. I looked at the detail of the code and was able to get the gist of it . Do you think the code is always executed fast enough to avoid serial buffer overflow? That is, it always executes faster than the rate that data is put on to the buffer from the GPS?
While I won't be able to answer your question myself, the answer would depend on the processor and clock rate you are running it on, as well as the GPS unit you are using (unless that rate is standardized).
1 Like
For a GPS running at 9600 baud the library has about 16000 instruction cycles for each character. The library should have no trouble keeping up with GPS input. Problems usually come when a sketch does far too much processing when a complete message arrives or produces so much output that the Serial output throttles (runs out of buffer). The latter can usually be fixed by increasing the Serial baud rate. I like 115200. Some like 250000. The hardware is capable of 2,000,000 baud
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.