Go Down

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

Brad Burleson


Here's the modified code: (replaced "nss" with "Serial1", commented out softwareserial)


You'd be much better off looking at the example code provided with TinyGPS as opposed to someone else's modified version.

Check out the examples included at http://arduiniana.org/libraries/tinygps/.

FWIW,

Brad
KF7FER


petterg


How are you measuring that?

date/time is part of the printed information. I'm counting 3 lines with the same seconds value, hence I know the printing is performed about 3 times per second.


The gps.encode() function get called only when a complete sentence has arrived. Since that happens roughly once a second, it should not cause the buffer to overflow, since the GPS will be quiet for a while after the end of the sentence has arrived, before it starts sending the next one.

How do you know it's sending data only once per second?
As far as I understand the datasheet it's sending 10 times per second.


Doubling the baud rate halves the time it takes to receive the data, not doubles it.


I think 0.0665 is closer to half than double of 0.13.

petterg


You'd be much better off looking at the example code provided with TinyGPS as opposed to someone else's modified version.

Check out the examples included at http://arduiniana.org/libraries/tinygps/.


Thanks. I didn't know there was an official site for the library.

PaulS

Quote
As far as I understand the datasheet it's sending 10 times per second.

Where did you get that? The link in your first post says, on the middle of page 2:
Quote
Navigation Data Update Rate 1Hz

That's once a second.
The art of getting good answers lies in asking good questions.

petterg


Quote
As far as I understand the datasheet it's sending 10 times per second.

Where did you get that? The link in your first post says, on the middle of page 2:
Quote
Navigation Data Update Rate 1Hz

That's once a second.


I read 10Hz somewhere. Might have been some other place.



Check out the examples included at http://arduiniana.org/libraries/tinygps/.


Thanks to that link I found the library TinyGPS+. Thing speeded up quite a bit using that. Printing is now 7-10 times per second. Position updates are still lagging a bit thou. If I walk, stop, walk, stop, the printout shows exactly that I've walked, stopped, walked, stopped. It has a delay of about 15-20 seconds. I didn't get to test this very well yet as the weather is not equipment friendly at the moment (windy and rain). How can I figure out whats causing the delay? Is it the gps, the buffer or something else?

petterg

From http://arduino.cc/en/Serial/Flush I read:
Quote

Waits for the transmission of outgoing serial data to complete. (Prior to Arduino 1.0, this instead removed any buffered incoming serial data.)


What's the best way now to empty the buffer for incoming data like flush() did prior to Arduino 1.0?

(For testing I'd like to empty the buffer prior to reading data to make sure it's dealing with fresh data)

petterg



Quote
As far as I understand the datasheet it's sending 10 times per second.

Where did you get that? The link in your first post says, on the middle of page 2:
Quote
Navigation Data Update Rate 1Hz

That's once a second.


I read 10Hz somewhere. Might have been some other place.


Guess I mixed up the bandwidth and navigation data update rate

PaulS

Quote
Printing is now 7-10 times per second.

Why? Once a second the GPS tells you where you are. Why would you print the same data 7 to 10 times?
The art of getting good answers lies in asking good questions.

petterg


Quote
Printing is now 7-10 times per second.

Why? Once a second the GPS tells you where you are. Why would you print the same data 7 to 10 times?


I'm telling what it does. If it did what I wanted there wouldn't be any need for this thread. I guess it's parsing/printing as long as there is data to parse/print. I'd like it to process THE LATEST data only when needed. I consider it pointless to spend cpu time to process data continuously just to trow away the results. I also consider it pointless to let the buffer fill up, and process old data when a reading is wanted. Hence my questions how the buffer behaves when full, how to throw away all buffered data without processing (to make sure the next data to read and process is fresh), or how to make the gps only send data when it will be used for something., or as topic says: how to control how often the gps send updates.

wildbill

Time to post your code by the sound of it.

petterg

From http://arduiniana.org/libraries/tinygpsplus/
Example code, edited to use Serial1 at 9600 baud

Code: [Select]

#include <TinyGPS++.h>
//#include <SoftwareSerial.h>
/*
   This sample sketch demonstrates the normal use of a TinyGPS++ (TinyGPSPlus) object.
   It requires the use of SoftwareSerial, and assumes that you have a
   4800-baud serial GPS device hooked up on pins 4(rx) and 3(tx).
*/
//static const int RXPin = 4, TXPin = 3;
static const int GPSBaud = 9600;

// The TinyGPS++ object
TinyGPSPlus gps;

// The serial connection to the GPS device
//SoftwareSerial ss(RXPin, TXPin);

void setup()
{
  Serial.begin(115200);
  Serial1.begin(GPSBaud);

  Serial.println(F("DeviceExample.ino"));
  Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
  Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
  Serial.println(F("by Mikal Hart"));
  Serial.println();
}

void loop()
{
  // This sketch displays information every time a new sentence is correctly encoded.
  while (Serial1.available() > 0)
    if (gps.encode(Serial1.read()))
      displayInfo();

  if (millis() > 5000 && gps.charsProcessed() < 10)
  {
    Serial.println(F("No GPS detected: check wiring."));
    while(true);
  }
}

void displayInfo()
{
  Serial.print(F("Location: "));
  if (gps.location.isValid())
  {
    Serial.print(gps.location.lat(), 6);
    Serial.print(F(","));
    Serial.print(gps.location.lng(), 6);
  }
  else
  {
    Serial.print(F("INVALID"));
  }

  Serial.print(F("  Date/Time: "));
  if (gps.date.isValid())
  {
    Serial.print(gps.date.month());
    Serial.print(F("/"));
    Serial.print(gps.date.day());
    Serial.print(F("/"));
    Serial.print(gps.date.year());
  }
  else
  {
    Serial.print(F("INVALID"));
  }

  Serial.print(F(" "));
  if (gps.time.isValid())
  {
    if (gps.time.hour() < 10) Serial.print(F("0"));
    Serial.print(gps.time.hour());
    Serial.print(F(":"));
    if (gps.time.minute() < 10) Serial.print(F("0"));
    Serial.print(gps.time.minute());
    Serial.print(F(":"));
    if (gps.time.second() < 10) Serial.print(F("0"));
    Serial.print(gps.time.second());
    Serial.print(F("."));
    if (gps.time.centisecond() < 10) Serial.print(F("0"));
    Serial.print(gps.time.centisecond());
  }
  else
  {
    Serial.print(F("INVALID"));
  }

  Serial.println();
}

wildbill

#26
Oct 04, 2013, 07:51 pm Last Edit: Oct 04, 2013, 08:52 pm by wildbill Reason: 1
This looks interesting:
Code: [Select]
  // This sketch displays information every time a new sentence is correctly encoded.

I wonder how many different sentences your device is emitting. I'd suggest you copy that sketch and reduce it to a simpler one that just echoes whatever is read from the gps to serial so you can find out.

Brad Burleson


I wonder him many different sentences your device is emitting. I'd suggest you copy that sketch and reduce it to a simpler one that just echoes whatever is read from the gps to serial so you can find out.


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());


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).

Regards,

Brad
KF7FER

PaulS

At the very least. sharing the serial output would be useful. According to the datasheet, each sentence is updated once a second. There may, as has been mentioned, more than once sentence type. We can't see what you are seeing.
The art of getting good answers lies in asking good questions.

petterg

#29
Oct 04, 2013, 10:44 pm Last Edit: Oct 04, 2013, 11:42 pm by petterg Reason: 1

This looks interesting:
Code: [Select]
 // This sketch displays information every time a new sentence is correctly encoded.

I wonder how many different sentences your device is emitting. I'd suggest you copy that sketch and reduce it to a simpler one that just echoes whatever is read from the gps to serial so you can find out.


That was a good idea!
Edit2: bug fixed. Fixed code/results to follow

Running code:
Code: [Select]

void loop()
{
 while (Serial1.available() > 0 && i < 5000) {
   i++;
   Serial.print(Serial1.read());
 }
 if(i < 5000)
   Serial.println("next");
 delay(50);
}



Edit 3: human readable output posted in this post.


So it seems like the gps is sending 7 sentences, and there is a delay of 12x(50ms+looptime) between the blocks of sentences. With 7x 50ms during the sentences this backs up the datasheets/PaulS statement of update frequency of 1Hz.

How many of these sentences is the buffer able to store?

Go Up