Go Down

Topic: GPS: set update frequency (Read 21003 times) previous topic - next topic

petterg


Also if you read the "Usage" section on the TinyGPS++ page you'll see there are new methods that the example code isn't using, such as:

Code: [Select]

if (gps.altitude.isUpdated())
   Serial.println(gps.altitude.meters());


Using the isUpdated() does require that encode() is ran before. If the encode() takes longer to process than the time between sentences that will still cause problems.


Might be an easier way to go.  Or if you're so inclined you should be able to tell the GPS what sentences to output and that would help as well (or at least decrease the number of updates you see).


With the observation with the echo-sketch I totally agree that reducing the number of sentences will make a significant performance boots. But how?

wildbill

You'll need to decide which sentences to pass to the tinyGPS encoder and throw the rest away.

Figuring out which you want would be easier if you cast the int you're getting from read to char thus:
Code: [Select]

    Serial.print((char)Serial1.read());


You could likely get rid of all the code relating to 5000 in this circumstance too.

petterg


You'll need to decide which sentences to pass to the tinyGPS encoder and throw the rest away.

Figuring out which you want would be easier if you cast the int you're getting from read to char thus:
Code: [Select]

    Serial.print((char)Serial1.read());


You could likely get rid of all the code relating to 5000 in this circumstance too.


The reason for the 5000 is to make it possible to copy the text from the serial monitor. I'm to slow to mark and copy within 50ms.


Casted result:
Code: [Select]
next
next
next
next
next
$GPGGA,213127.000,5915.5411,N,01027.5115,E,1,8next
,1.23,0.6,M,41.0,M,,*53
$GPGSA,A,3,20,04,10,23,0next
2,07,09,08,,,,,1.52,1.23,0.90*0F
$GPGSV,4,1,13,1next
3,73,093,,10,72,249,16,23,42,083,26,02,42,270,26next
*73
$GPGSV,4,2,13,07,42,174,19,04,32,216,22,16,2next
4,063,,05,22,296,*7A
$GPGSV,4,3,13,33,19,209,,0next
8,14,189,24,29,14,336,,09,12,197,21*7A
$GPGSV,4,next
4,13,20,05,131,17*49
$GPRMC,213127.000,A,5915.54next
18,N,01027.5115,E,0.00,261.16,041013,,,A*6F
next
next
next
next
next
next
next
next
next
next
next
$GPGGA,213128.000,5915.5411,next
N,01027.5115,E,1,8,1.23,0.6,M,41.0,M,,*5C
$GPGSAnext
,A,3,20,04,10,23,02,07,09,08,,,,,1.52,1.23,0.90*next
0F
$GPGSV,4,1,13,13,73,093,,10,72,249,16,23,42,0next
83,26,02,42,270,26*73
$GPGSV,4,2,13,07,42,174,19next
,04,32,216,22,16,24,063,,05,22,296,*7A
$GPGSV,4next
,3,13,33,19,209,,08,14,189,24,29,14,336,,09,12,19next
7,21*7A
$GPGSV,4,4,13,20,05,131,17*49
$GPRMC,2next
13128.000,A,5915.5411,N,01027.5115,E,0.00,261.16,next
041013,,,A*60
next
next
next
next
next
next
next
next
next
next
next
$GPGGA,213129.000,5next
915.5411,N,01027.5115,E,1,8,1.23,0.6,M,41.0,M,,*next
5D
$GPGSA,A,3,20,04,10,23,02,07,09,08,,,,,1.52,1next
.23,0.90*0F
$GPGSV,4,1,13,13,73,093,,10,72,249,1next
6,23,42,083,26,02,42,270,26*73
$GPGSV,4,2,13,07next
,42,174,19,04,32,216,23,16,24,063,,05,23,296,*7A
next

$GPGSV,4,3,13,33,19,209,,08,14,189,24,29,14,336,next
,09,12,197,21*7A
$GPGSV,4,4,13,20,05,131,17*49
next

$GPRMC,213129.000,A,5915.5411,N,01027.5115,E,0.0next
0,261.16,041013,,,A*61
next
next
next
next
next
next
next
next
next
next
next
$GPGGA,213130.000,5915.5411,N,0next
1027.5115,E,1,8,1.23,0.6,M,41.0,M,,*55
$GPGSA,Anext
,3,20,04,10,23,02,07,09,08,,,,,1.52,1.23,0.90*0F
next

$GPGSV,4,1,13,13,73,093,,10,72,249,16,23,42,083next
,27,02,42,270,26*72
$GPGSV,4,2,13,07,42,174,19,0next
4,32,216,23,16,24,063,,05,23,296,*7A
$GPGSV,4,3,next
13,08,14,189,24,29,14,336,,09,12,197,21,40,09,12next
2,*75
$GPGSV,4,4,13,20,05,131,18*46
$GPRMC,2131next
30.000,A,5915.5411,N,01027.5115,E,0.00,261.16,041next
013,,,A*69
next
next
next
next
next
next
next
next
next
next
next
$GPGGA,213131.000,5915.5411,N,01027.5115,Enext
,1,8,1.23,0.6,M,41.0,M,,*54
$GPGSA,A,3,20,04,10next
,23,02,07,09,08,,,,,1.52,1.23,0.90*0F
$GPGSV,4,1next
,13,13,73,093,,10,72,249,16,23,42,083,27,02,42,27next
0,25*71
$GPGSV,4,2,13,07,42,174,18,04,32,216,23next
,16,24,063,,05,23,296,*7B
$GPGSV,4,3,13,08,14,18next
9,24,29,14,336,,09,12,197,21,40,09,122,*75
$GPGnext
SV,4,4,13,20,05,131,18*46
$GPRMC,213131.000,A,59next
15.5411,N,01027.5115,E,0.00,261.16,041013,,,A*68
next

next
next
next
next
next
next
next
next
next
next
$GPGGnext
A,213132.000,5915.5411,N,01027.5115,E,1,8,1.23,0.next
6,M,41.0,M,,*57
$GPGSA,A,3,20,04,10,23,02,07,09next
,08,,,,,1.52,1.23,0.90*0F
$GPGSV,4,1,13,13,73,09next
3,,10,72,249,16,23,42,083,27,02,42,270,25*71
$GPnext
GSV,4,2,13,07,42,174,18,04,32,216,23,16,24,063,,next
05,23,296,*7B
$GPGSV,4,3,13,08,14,189,24,29,14,3next
36,,09,12,197,21,40,09,122,*75
$GPGSV,4,4,13,20next
,05,131,18*46
$GPRMC,213132.000,A,5915.5411,N,01next
027.5115,E,0.00,261.16,041013,,,A*6B
next
next
next
next
next
next
next
next
next
next
next
$GPGGA,213133.000,5next
915.5411,N,01027.5115,E,1,8,1.23,0.6,M,41.0,M,,*5next
6
$GPGSA,A,3,20,04,10,23,02,07,09,08,,,,,1.52,1next
.23,0.90*0F
$GPGSV,4,1,13,13,73,093,,10,72,249,1next
6,23,42,083,27,02,42,270,25*71
$GPGSV,4,2,13,07,next
42,174,18,04,32,216,23,16,24,063,,05,23,296,*7B
next

$GPGSV,4,3,13,08,14,189,23,29,14,336,,09,12,197,next
21,40,09,122,*72
$GPGSV,4,4,13,20,05,131,18*46
next

$GPRMC,213133.000,A,5915.5411,N,01027.5115,E,0.0next
0,261.16,041013,,,A*6A
next
next
next
next
next
next
next
next
next
next
$next
GPGGA,213134.000,5915.5411,N,01027.5115,E,1,8,1.next
23,0.6,M,41.0,M,,*51
$GPGSA,A,3,20,04,10,23,02,0next
7,09,08,,,,,1.52,1.23,0.90*0F
$GPGSV,4,1,13,13,7next
3,093,,10,72,248,17,23,42,083,27,02,42,270,25*71next

$GPGSV,4,2,13,07,42,174,18,04,32,216,24,16,24,0next
63,,


Any way to make it send only one of the senteces?

wildbill

I found a manual for the device which says this:
Quote
The SkyNav SKM53 module supports the following NMEA-0183 messages: GGA, GLL, GSA, GSV, RMC VTG, ZDA and DTM. The module default NMEA-0183 output is set up GGA, GSA ,GSV, RMC and default baud rate is set up 9600bps


Which kind of implies that it can be set to emit a different set of sentences. No clue how in that document though - do you have any better paperwork? The alternative of course is to do some initial parsing of the data yourself and only pass the sentences you're interested in to the encoder.

petterg


I found a manual for the device which says this:
Quote
The SkyNav SKM53 module supports the following NMEA-0183 messages: GGA, GLL, GSA, GSV, RMC VTG, ZDA and DTM. The module default NMEA-0183 output is set up GGA, GSA ,GSV, RMC and default baud rate is set up 9600bps


Which kind of implies that it can be set to emit a different set of sentences. No clue how in that document though - do you have any better paperwork? The alternative of course is to do some initial parsing of the data yourself and only pass the sentences you're interested in to the encoder.


That document is the only I have. Maybe there is some standard defining how to send instructions to any gps chip?

PaulS

Quote
Maybe there is some standard defining how to send instructions to any gps chip?

There is not. Contact the manufacturer. Ask them how to tell the GPS to send only useful information.
The art of getting good answers lies in asking good questions.

petterg

Mail sent to Skylab, requesting more documentation.

Brad Burleson

#37
Oct 05, 2013, 02:44 am Last Edit: Oct 05, 2013, 03:08 am by Brad Burleson Reason: 1

Using the isUpdated() does require that encode() is ran before.


Of course.  I was just showing an easy way to know when you had updated data (but not necessarily changed).

Quote

If the encode() takes longer to process than the time between sentences that will still cause problems.


I really doubt that is your problem.  I've never used the new version but I've done quite a bit of work with the older versions and never had that sort of issue (and I was one of the original beta testers).

BTW I'd ditch the delay and the "next"... can you see how "next" is being printed before the end of each line?  (each sentence should end with an "*" and a two digit checksum followed by the end of line character(s)).  

As an example, one complete sentence is being output like this:

Code: [Select]
$GPGGA,213127.000,5915.5411,N,01027.5115,E,1,8next
,1.23,0.6,M,41.0,M,,*53


Regards,

Brad
KF7FER

EDIT: I should have added that if you want to capture the output of your GPS, don't use the serial monitor - use a terminal emulator and simply open it's capture buffer before you power up your arduino.  Plus you don't have to cut and paste :-)

petterg



Using the isUpdated() does require that encode() is ran before.


Of course.  I was just showing an easy way to know when you had updated data (but not necessarily changed).

Quote

If the encode() takes longer to process than the time between sentences that will still cause problems.


I really doubt that is your problem.


What would you think the cause of problem could be?
All I really need in "real time" is a "way point reached" warning. Basically read the position, compare to the position of a way point, make a beep when current position is within a given distance from the way point. The best I've got so far is a 20 second delay, which in best case would give a "way point passed 20 seconds ago" warning.



I've never used the new version but I've done quite a bit of work with the older versions and never had that sort of issue (and I was one of the original beta testers).

Maybe you happen to know how to change which messages that the gps module outputs then?


BTW I'd ditch the delay and the "next"... can you see how "next" is being printed before the end of each line?  (each sentence should end with an "*" and a two digit checksum followed by the end of line character(s)). 

As an example, one complete sentence is being output like this:

Code: [Select]
$GPGGA,213127.000,5915.5411,N,01027.5115,E,1,8next
,1.23,0.6,M,41.0,M,,*53


Thanks for pointing that out.
As far as I can tell, the fact that "next" occur in the middle of an sentence also indicates that "Serial1.available() > 0" may return false while a sentence is being transmitted. To me that is an unexpected behavior. Does this indicate that the buffer is full?


use a terminal emulator

Thanks. I have a lot to learn about this.

PaulS

Quote
Basically read the position, compare to the position of a way point, make a beep when current position is within a given distance from the way point. The best I've got so far is a 20 second delay, which in best case would give a "way point passed 20 seconds ago" warning.

We've posted corrections to your code. You've said that you've integrated them. But, clearly, you've gone a lot further than that. Now, you are having problems with the code you haven't posted. Can you, perhaps thinking outside the box, come up with a solution to our dilemma?
The art of getting good answers lies in asking good questions.

petterg


Quote
Basically read the position, compare to the position of a way point, make a beep when current position is within a given distance from the way point. The best I've got so far is a 20 second delay, which in best case would give a "way point passed 20 seconds ago" warning.

We've posted corrections to your code. You've said that you've integrated them. But, clearly, you've gone a lot further than that. Now, you are having problems with the code you haven't posted. Can you, perhaps thinking outside the box, come up with a solution to our dilemma?


I'm sorry for telling you why I want to read position with less than 20 seconds delay. It must have been very confusing.


Code was posted here

wildbill

Quote
As far as I can tell, the fact that "next" occur in the middle of an sentence also indicates that "Serial1.available() > 0" may return false while a sentence is being transmitted. To me that is an unexpected behavior. Does this indicate that the buffer is full?


Serial data transmission is slow and asynchronous and 9600 is a pretty slow baud rate. The arduino is very quick by comparison; it can pull a character from the buffer and do a whole bunch of work before the next one arrives. It is a very very common misconception that you'll get all the serial data you want in one continuous read. If you're in the middle of a sentence and there's nothing to read, it does not mean that the buffer is full, on the contrary, it means it's empty.

If you're sending serial data, that's slow too and has a small buffer. If you send more than enough to fill the buffer, the arduino will wait until there's space in the buffer again. In this circumstance, the act of sending more than 64 (varies by arduino) characters can delay you enough that your serial reads appear to pull a whole packet at once. In the case of a GPS sentence though as they can be quite long, you may well fill the read buffer and start dropping incoming data during the send delay.

As to ignoring sentences, you may get lucky and get better data from the manufacturer. If not, another possibility is to take a look at the tinyGPS library. Without looking, I assume it's hardcoded to some extent as to which sentences it can parse. It might be plausible to create a hacked copy that only 'knows' the ones you want.

PaulS

Quote
I'm sorry for telling you why I want to read position with less than 20 seconds delay. It must have been very confusing.

You can stuff the attitude. The GPS is, you've said, giving you good data, as often as can reasonably be expected. You are then doing something with that data, and that something results in a long delay. If you want help solving the problem, we need to see what you are seeing. That is the code and the serial output.

Quote
Code was posted here

Here? Where the hell is "here"?
The art of getting good answers lies in asking good questions.

petterg


Quote
As far as I can tell, the fact that "next" occur in the middle of an sentence also indicates that "Serial1.available() > 0" may return false while a sentence is being transmitted. To me that is an unexpected behavior. Does this indicate that the buffer is full?


Serial data transmission is slow and asynchronous and 9600 is a pretty slow baud rate. The arduino is very quick by comparison; it can pull a character from the buffer and do a whole bunch of work before the next one arrives. It is a very very common misconception that you'll get all the serial data you want in one continuous read. If you're in the middle of a sentence and there's nothing to read, it does not mean that the buffer is full, on the contrary, it means it's empty.


So if I get you right, the occurrences of "next" in the middle of a sentence shows the characters that the gps managed to put into the buffer during the 50ms delay + loop processing time?


If you're sending serial data, that's slow too and has a small buffer. If you send more than enough to fill the buffer, the arduino will wait until there's space in the buffer again.

The sender will wait if the receivers buffer is full?
Meaning, if the MPU is not reading the buffer fast enough, the gps will queue messages waiting for the MPU to free up buffer? Assuemed the GPS also has a buffer, this would totally explain why I see delayed data!


In this circumstance, the act of sending more than 64 (varies by arduino) characters can delay you enough that your serial reads appear to pull a whole packet at once. In the case of a GPS sentence though as they can be quite long, you may well fill the read buffer and start dropping incoming data during the send delay.

From this I think I learned that buffer behavior is to drop new data when full rather than saving the last 64 bytes received. Is there a way to flip this behavior so that when buffer is full, the oldest data is dropped, allowing new data to always be written?


As to ignoring sentences, you may get lucky and get better data from the manufacturer. If not, another possibility is to take a look at the tinyGPS library. Without looking, I assume it's hardcoded to some extent as to which sentences it can parse. It might be plausible to create a hacked copy that only 'knows' the ones you want.

Thats one possibility. Another could be to monitor the datastream, waiting for the start of the wanted message, then collect the full message and pass it to the encode().

petterg


You can stuff the attitude.

Mirrors can be harsh. If you can't stand what you see in the mirror, the target for improvement should not be the mirror.


The GPS is, you've said, giving you good data, as often as can reasonably be expected. You are then doing something with that data, and that something results in a long delay. If you want help solving the problem, we need to see what you are seeing. That is the code and the serial output.

The output looks exactly as expected, except for the delay of 20 seconds. It doesn't tell anything if you don't watch it in real time while moving around.


Quote
Code was posted here

Here? Where the hell is "here"?


In the quote, if you quote correctly, there is a statement with timestamp and link that will take you to the posting where the quote is from.

Go Up