Thanks to a helpful suggestion by user DanP, I have increased the effective resolution of the latitude and longitude values returned in TinyGPS. The get_position method now returns values in units of 10-5 degrees, a 10-fold increase in resolution. Note that if you use use the old get_position, you will have to make some minor changes to your code if you upgrade to version 8.
Thanks DanP!
Mikal
reto
15 years ago
Hi Mikal. I dl your TinyGPS and it works like a charm! For your information, I use a LocoSys LS20031 GPS board spitting 2Hz GGA and RMC nmea sentences over NSS at 38400 bds to my ArduPilot autopilot board (open source project http://www.diydrones.com). Your TinyGPS will help me a lot accessing preprocessed data like speed and altitude, etc.
Well, this is fine for a start, but now, I’d like to implement some specific functions. I intend to send a composite set of NMEA sentences to my video on screen display (OSD) which needs GGA, RMC but also 2 other NMEA sentences I’ll assemble from other data (waypoint RTE, etc).
My problem is following:
I need to send the “raw” GGA and RMC sentences read and checked by TinyGPS to my OSD over NSS. Is there a way to get those raw sentences as *char variables from TinyGPS library somehow? If that would be possible, then I would assemble the “artificial” NMEA sentences the OSD also needs and finally send all bunch of sentences over NSS to the OSD avery second or so.
I would be very glad if you could help me getting the “raw” GGA and RMC into some variables. Thanks a lot and many thanks for the very handy library.
Mikal
15 years ago
Hi reto–
Thanks for the kind comments. I’ve been watching the activity over on diydrones.com with NewSoftSerial and TinyGPS. Way to go!
Part of what makes TinyGPS “tiny” is the fact that it never stores a complete NMEA sentence. You could patch your own copy to do that, but since you’re already in control of the serial stream, I think I’d do something like this:
char buf[100]; int index = 0; void loop() { ... if (nss.available() > 0) { int c = nss.read(); buf[index++] = c; if (tinygps.encode(c)) { ... do something with the gps data } if (c == '\n') // newline { buf[index] = '\0'; // terminate the string in buf index = 0; // start collecting the next sentence ... here buf contains a complete raw NMEA sentence ... do what you want with it } } }reto
15 years ago
Hey Mikal, I didn’t expect you bring me that far!!! Thanks much, I’ll go the suggested path.
By the way, I got a question concerning the NSS (it’s not quite the right place, but well…). Is it possible that NSS library is somewhat sensible to the source powering the board? I got quite different results with NSS tests at 57600 (I know it’s not 100% at that speed) when running on Duemilanove or on ArduPilot boards. In fact, I patched the library to be able to carry out reading tests on nmea stream from gps. The patch enabled me to specify bitdelay and delta parameters (like nss.begin(57600, -5, 49)) in specific ranges to see which setting gives best result (counting good chars vs. bad ones). For example, on my ArduPilot the best settings for 38400bds are -5 and 49 to read some 50-60 chars. Could the different optimal settings be caused by power source? I wonder because the same code running when Duemilanove running from USB did not give expected results when powered from a 9v battery block!!! I had to change the bitdelay and delta (can’t remeber the figures now) and then it was ok again. Would be interested in your opinion.
Mikal
15 years ago
reto–
Thus far my use of the various software serial libraries has been limited to low baud rates when under battery power. At higher speeds I’ve always used “wall” power.
Now, I’m not a hardware guy, but I do know that at higher speeds software serial is going to be increasingly susceptible to small variations in clock. Does the ardupilot use an external clock? I read somewhere that the internal clock on the ATmega chips is relatively poor. Perhaps that in conjunction with the battery power skews your results?
Good for you for adding the capability to fine tune your settings programmatically. I’ve toyed with the idea of adding a tuning function to NSS.
Is it possible in your app to turn off the timer interrupt using the new enable_timer0(false)? I would doubt it. Almost all the problems I’ve seen at high baud rates stem either from overflow or that timer tick.
By the way, NewSoftSerial 8 should be easier to tune than previous versions.
Mikal
John G
15 years ago
Wow nice job on TinyGPS, you reduced my expected weekend of coding into a single evening – Thanks!
I’m having a problem with the altitude reporting in TinyGPS though. TinyGPS always reports an altitude of 999999999 using the standard functions and 10000000.00 when using the inline functions. The GPS displays the correct altitude of 1052m (105,200cm). Any thoughts why I’m not getting the correct altitude reading from TinyGPS? Bug?
Mikal
15 years ago
John,
Thanks for the kind words about TinyGPS. I’m rather pleased with it myself. :)
Can you send me some of the NMEA sentences that TinyGPS is processing? That’s the only way I can tell for sure whether there is a bug or not. If you just echo the serial data that comes in through the GPS back to the Arduino serial monitor, you should be able to copy them.
It could be a bug, or it could be that your GPS sends data in a quirky way that I haven’t anticipated. Are you using software serial to acquire the data from the GPS? If your GPS is high speed, you may be suffering from serial overflow. This would cause truncated NMEA sentences to be discarded. If you are acquiring with NewSoftSerial v.7 or later, you can tell if you have an overflow by examining nss.overflow().
The “all 9s” return value means that TinyGPS doesn’t think it’s ever seen a valid altitude. Do latitude and longitude work on the same installation?
Mikal
Ken Worster
15 years ago
First of all, thanks for writing the TinyGPS library. It saved me a lot of time in implementing some features in my new project. I’m programming in C (avr-gcc) on a Mega128, so I took your code and “unC++ified” it. I also disabled the millisecond timing as I didn’t need the functionality and didn’t want to write my own millis() function. I’d like to put my edited version on the projects section at avrfreaks.net if that’s ok with you. Thanks again for your effort on this.
Ken
Mikal
15 years ago
Sure, Ken, if you don’t mind keeping the attribution intact with a link to the original post, I’m delighted for you to post your mods. Send me a link when you’re done and I’ll crosslink you.
Thanks,
Mikal
Daniel Wilson
15 years ago
Hi Mikal,
First of all, good work on the TinyGPS library!
Just wondering if it would be possible/easy to modify the library to output PDOP values?
Regards,
Dan
Mikal
15 years ago
Hi Daniel–
It’s not too hard to add new values to the code. My suggestion is to find a similar-as-possible value that is already supported and then mimic what I did for that.
Mikal
simone garino
15 years ago
Hi
i have a question: it’s possible to return the “lat” an “long” resolution of 10^6 degrees?
compliments for the good work on TinytGPS library
Simone
Mikal
15 years ago
Simone,
I assume you mean 10^-6 degrees? GPS units report latitude and longitude with (up to) 9 digits: 3 for degrees and 6 for minutes. The six minutes digits are interpreted as MM.MMMM, so the smallest possible resolution is 1/10000 of a minute or 1/600000 of a degree. This is not quite 10^-6 degrees, but pretty close. The values returned by TinyGPS’s get_position and f_get_position simply return whatever is reported by the GPS.
Does that answer your question?
Mikal
simone garino
15 years ago
thanks for the answer
So if i had understand you say that “flat” or “flon” have the higher resolution? that depends of the gps unit?
Mikal
15 years ago
The floating point version of the function (f_get_position) doesn’t have any better resolution. It simply converts the decimal value to floating point. The precision will never be greater than 1/10000 of a minute.
Mikal
simone garino
15 years ago
thank you
Cyberteque
14 years ago
Hi!
I’m trying to run your example on an Arduino Mega with a Sparkfun GPS shield and EM-406A.
Beyond the demo startup message, I’m not seeing squat!
I have the UART/dlink switch in the dlink position, RX is on pin 3, TX on pin 2, GPS baud rate is 4800.
There is an option on the Sparkfun shield to route the GPS serial pins in through another UART, As the Mega has more than 1 UART is this a better way to do it?
Any idea’s what I’m doing wrong?
Mikal
14 years ago
Andrew,
Without seeing your setup or code, my best guess is that you have swapped RX and TX. Remember that RX on the GPS is TX on the board, and if you’re using NewSoftSerial the RX pin is first in the constructor. Are you using NewSoftSerial?
Mikal