did you try outside or indoor only?
1 Like
Yes, I do.
When I use an example code of GPS then it work . But when I use this code it was “0” all the time…
Help me please…
You tell us.
When your code decides there is a new GPS fix\update and assigns the variables flat and flon from the GPS library what are these values ?
You are printing them out ?
You need to be sure the values you are getting from the GPS and sending are valid, before you need worry about what appears in the TTN console.
1 Like
There is a complete worked example of a TTN GPS tracker described here;
In this case the data is sent from TTN into Cayenne and displayed on a map.
First I want to say that TinyGPS will not be my first choice library for tracker application. It lacks most of the validation required to ensure a high accuracy.
That said, for regardless of the library used, there is usually a delay in getting GPS coordinates the first time. If this doesn’t complete, it is likely you will get all zeros as values. Frankly I see a number of issues with your sketch especially in the “get_coords();” function. The function was designed to receive data from a GPS device and not necessarily determine if there is a lock and the quality of the lock before transmitting that data to the application. I believe accuracy is essential for a tracker application. Take a look at the following:
- This line …
Seems to run the loop for approximately 1second. That is too short a time to acquire values unless there was a GPS lock previously. You may want to parse values only after you have a valid GPS lock. Since you do not know how long this will take, I suggest you leave out that for loop entirely.
- The loop starting here …
means that while (for as long as) data is coming into the the serial port, which in the case of a GPS device is for as long as it takes to send a burst of data. That could be an infinite loop if the bursts come fast enough or it could be for just one sentence, both of which are undesirable outcomes. I believe you only want to run a loop until valid data is received in which case you may want to replace that with while(newData == False){ And then set newData to true after you have received a valid fix.
- Finally here …
gps.encode confirms a valid sentence is received from the GPS device. It doesnt necessarily mean you have a lock or valid data. I am unable to find a TinyGPS key to return true when there is a valid lock so this can be confirmed before accepting and parsing the data. On confirmation of a valid lock, you can set newData to true and then proceed to parse the received data.
At this point, I am compelled to make the following suggestions.
-
You could consider another library NeoGPS GitHub - SlashDevin/NeoGPS: NMEA and ublox GPS parser for Arduino, configurable to use as few as 10 bytes of RAM . It is much more detailed and fine grained. With it, you can decide to accept the data when a certain degree of accuracy is achieved. Below is a code snippet which will return values only when there is a valid GPS Lock.
while (newdata == false) {
if (gps.available( gpsPort )) {
fix = gps.read();
digitalWrite(ledPin, HIGH); // turn the LED on (HIGH is the voltage level)
if (fix.valid.location) {
Serial.println();
Serial.println(F(“GPS Signal aqcuired.”));
Serial.print( F(“Location: “) );
Serial.print( fix.latitude(), 6 );
Serial.print( ‘,’ );
Serial.println( fix.longitude(), 6 );
myData.latitude = fix.latitude();
myData.longitude = fix.longitude();
newdata = true;
}
Serial.print(”.”);
}
} -
Try calling “get_coords();” first from inside setup() to get current location. After that I expect retrieving coordinates afterwards will take less time and unlikely to disrupt your sending sequence.
-
If you wish to obtain greater accuracy, you could consider this code which allows you specify a minimum fix quality before “newData” is set to “True”. Note that the ability to attain the quality is dependent on your GPS hardware. For example, with the Quectel L80R GPS module, I can get a speed fix error below 25mm/s in a few minutes from cold start while with a NEO-6M I am not able to get that minimal error level even after 30mins.
void getlocation(){ bool newdata = false; while (newdata == false) == false) { int fixed = 0; if (gps.available( gpsPort )) { fix = gps.read(); if (fix.valid.location) { myData.latitude = fix.latitudeL(); myData.longitude = fix.longitudeL(); fixed++; } if (fix.valid.altitude) { myData.elevation = fix.alt.whole; fixed++; } if (fix.valid.speed) { myData.speed = fix.speed_kph()*10; fixed++; } if (fix.valid.heading) { myData.heading = fix.heading(); fixed++; } //newdata = true; // To return values when there is a valid GPS fix if (fixed >= 4 && fix.spd_err_mmps < 25) { //To return values of higher accuracy newdata = true; } } } }
I hope this helps.
I would dissagree completly, TinyGPSplus is well capable of ‘high accuracy’.
Do remember that standard GPSs are at best going to be within 2-5M or so.
I did take the trouble to check how accurate TinyGPSplus was at reading the GPS and calculating the distance between waypoints. Consider the photograph below;
In the middle, between the two devices is a brass nail, its actually an Ordnance survey referance point, its location is known to a very high accuracy;
Passive GPS station: Swanbridge - C1ST1667
OS-Net | Ordnance Survey
N 51 23’59.105955", W 3 11’,47.413031
51.399751654166664, -3.196503619722222
The transmitter on the right is programed to transmit the location of the reference point over LoRa. The receiver on the left picks up this location and taking the receivers location from its own GPS, calculates the distance from where the receiver thinks it is (from its GPS) to the reference point.
The calculation using standard floating point and the TinyGPSplus library calculation is that the reference is 2M away. I would suggest that is accurate and well within the accuracy limits of the GPS.
3 Likes
Eh ?
The ‘accuracy’ of the GPS is an estimate based on probability. You can only know the degree of accuracy the GPS is reporting if you know its actual position ?
From the code posted for the TTN GPS tracker above, the code waits for a valid updated fix from the GPS, I do often use a similar one that timesout after a defined number of seconds;
boolean gpsWaitFix()
{
Watchdog_Pulse(); //pulse LED in case we have a watchdog connected
while (GPSserial.available() > 0)
gps.encode(GPSserial.read());
if (gps.location.isUpdated() && gps.altitude.isUpdated())
{
return true;
}
else
{
return false;
}
}
You can ommit the check on the Altitude bieng updated if you like.
TinyGPSplus is different from TinyGPS. I believe the library he used in his sketch is TinyGPS.
What exactly is the basis for the disagreement?
The function calls you mentioned as available for TinyGPSplus do not exist for TinyGPS. This goes to confirm what I was saying.
A GPS has a fix first on Lat and Lon within a certain accuracy limit. The fix on speed and altitude take a little longer. When I said greater accuracy, I was not implying the software makes the hardware more accurate rather that it is able to calculate to a greater accuracy the exact location in 3D as well as speed.
If you monitor Lat, Lon, Speed, and Alt of a stationary GPS node from cold start, you will notice Lat and Lon stabilize first before speed and last altitude. Being stationary the actual speed is know so that can be used to verify accuracy just like you referenced the brass nail.
The altitude of most places are also known or can be easily obtained from maps. With this you can tell when the accuracy of the fix in 3D has improved. That is why in the code you referenced, if (gps.location.isUpdated() && gps.altitude.isUpdated()) altitude isUpdated is used.
In my case I used the fix.spd_err_mmps. In many applications 2-5m resolution on lat and lon is sufficient (e.g if you were tracking a car) while in others altitude and speed are required (e.g tracking UAV).
Finally in mission critical operations where there is need to track an object in an unknown location, you have no way to determine the accuracy of received data therefore these other parameters are required to more effectively determine the margin of error.
Well, I will confess to missing that the OP was using the original TinyGPS. Its not been updated for 6 years, suprised its still being used.
The plus versions are updated and do now work with the modern Ublox GPSs. A sensible upgrade for the 6 year old library.
I dont ‘get’ NeoGPS at all, even though I have read a great many posts from the author as to how much better NeoGPS is than other libraries. To me the library seems to overcomplicate what is a simple process, reading the GPS, and returning latitude longitude and altitude. In this respect I find TinyGPS plus very much easier to understand and use.
I do agree with you totally. Better to leave the complexity out when its not required. Also saves space on the microcontroller.
It might do, but the GPS can still only estimate the accuracy of its fix.
I have monitored a lot of different GPSs at startup and the ‘first fix’ can be significantly in error, I have seen examples of 50 - 200M, occaisionaly more. The absolute accuracy does often drop to 5-10M within the first minute, but I would not be assuming the GPS is giving out its first fix with an assurance its to a particular accuracy level.
There are hand held GPS trackers that indicate the ‘accuracy’ of the location fix they are showing and using, 5M is typical, but that is just a statistical estimate, the GPS could actually be 30M or (much) more out.
For a tracker the GPS you use will have a major affect on battery life.
The best, lowest power, performance I have come across so far is the Ublox SAM 8Q. The Quectel L80 is not far behind, and is a fraction of the price of the Ublox.
Details of real world GPS power consumption for a range of GPSs are here;
2 Likes
Everone this is my sketch… Check my sketch please . The original sketch is https://github.com/Teumaat/ttn-tracker/blob/master/src/ttn-tracker.ino
GPS (2).txt (9.6 KB)
And this is my pay load
GPS payload.txt (417 Bytes)
I have got this sketch and payload format form here https://www.thethingsnetwork.org/labs/story/gps-tracker
Check it for what ?
2 Likes
My data was show lat and lng = 0 all time. I think my payload format was incorrect. But I don’t know where I’m wrong .
You can use paxcounter with an TTGO T-Beam.
It has ready-to-go TTNmapper integration.
Neither do I.
I have played with trackers a lot. It is absolutly essential to be sure the GPS is providing valid data in the first place. That it the reason I posted this response earlier;
> And why my result does not work ???
You tell us.
When your code decides there is a new GPS fix\update and assigns the variables flat and flon from the GPS library what are these values ?
You are printing them out ?
You need to be sure the values you are getting from the GPS and sending are valid, before you need worry about what appears in the TTN console.