I am kind of fighting with slow gps module. I use 7M Neo and in order to get the speed, position etc, it needs around a 1000ms to get all the data together.
This will significantly slow down the main process. So I decided to move this task to another arduino, and connect it to the primary one via I2C.
But now: How do I regularly get the data from this secondary unit. I would better not use interrupt on the main unit, because it has kind of precise timing schedule to do all its own tasks.
My idea is to run the secondary unit and store the data regularly and then, when the main unit asks, it would simply return the stored/cached data. Let say every 1000ms.
Do I have to use interrupt on the secondary unit ? Or is there another way?
#include <SoftwareSerial.h>
#include <TinyGPS.h>
#define TX 3
#define RX 4
TinyGPS gps;
SoftwareSerial swSerial(RX, TX);
void setup() {
Serial.begin(115200);
swSerial.begin(9600);
}
void loop() {
bool newData = false;
// incoming data
for (unsigned long start = millis(); millis() - start < 1000;) {
while (swSerial.available()) {
char c = swSerial.read();
//Serial.write(c); // dump received data
// validate
if (gps.encode(c)) {
newData = true;
}
}
}
// if there is new set of data to work with
if (newData) {
// get position, speed, etc ...
}
delay(1000);
}
srnet: Yes, the default configuration for a lot of GPSs is to provide position updates once per second.
I am most probably hitting a ceiling of my current knowledge. But I thought that it is necessary to wait on the serial until the gps set gives newdata (and then the calculation is quite quick).
the way you put it - it seems to me, it would be possible to simply ask every 1000ms and the gps module responds quickly (did not test, do not have the unit at work, so i can try later )
Increase the GPS update rate.
Reduce the number of sentences the GPS puts out.
Increase the GPS baud rate.
Configure the GPS so that it only provides data when you ask for it.
Can you give us some idea of what the main arduino is doing that needs such precise timing?
As for I2C, the main arduino sends a request to the secondary unit, typically a requestFrom(), which does involve an interrupt on the secondary unit.
In reference to your code, drop that while loop. Each time through loop, check for swSerial.available(), and feed data to tinyGPS. tinyGPS has a function to tell you when new data has been completely received, at that point you process it. No waiting for the complete message.
dave and srnet - thanks, I will look at this one as soon I have the hardware at hand today
david - primary task of the main unit is to maintain information about approach speed and data from gyro/acc.
The data from gps are another piece to the primary data set. I thought (apparently wrong that the gps is able to serve the data about speed and position only once per second AND (again possibly wrong assumption) it takes almost 1sec to calculate this data.
What people usually do is to read characters from the GPS when they are available and then pass them to the library to process. At 9600 baud, those characters will arrive infrequently, so you will have plenty of time to do other things.
If speed of response is an issue, best to avoid using software serial, it can and does drop characters, giving an unreadable sentence, if there is other stuff going on in the program.
Serial.prints() in particular are an example of doing other stuff and a very big no no if your expecting softwareserial to be reading the GPS in the background.
Hi everyone. Thanks to all, once again. I switched from tinygps to tinygpsPlus. Used better external antena, and everything seems to work just fine (as you adviced).
I am playing with the examples and again, everything seems to be working at the moment.
@srnet understand, since i switched to mega, it is possible to use hw serial, so i ad this to my todo list
