I've search and found many references to TinyGPS for parsing nmea strings from a gps. I've got the strings on the serial but the script example that comes with the library don't return info.
my gps works on 38400 bps and i can get the raw nmea string. when running the example script only output:
Testing TinyGPS library v. 9
by Mikal Hart
Sizeof(gpsobject) = 103
any tips or simple routines for parsing? Thank you.
the example sketch uses 4800 baud, did you try it with:
nss.begin(38400)
if you did and it still doesn't work, try modifying the feedgps function as follows so you can see the gps output on the serial monitor.
bool feedgps()
{
while (nss.available())
{
char c = nss.read();
Serial.print(c); // this sends the gps data to the serial monitor
if (gps.encode(c))
return true;
}
return false;
}
i've checked to change the speed [ nss.begin(38400); ]
with your sugested modification, i'm getting raw nmea , just like not using the lib. This means that the parsing can't be done at 38.4k ?
Anyone with sucessful 38.4k parsing? tinygps or not... BTW, tried also with another lib, nmea.h, but later realised that can't work on a Duamilenove 
tks for the feedback!
Yeah I've used TinyGPS at 38400, but I got some weird results.. like, altitude and speed were at 1,000,000 .. but they were normal when I read the data via USB. But the long/lat were exactly right, didn't really check anything else.. time was right as well.
I never did try it on the hardwired serial to see if the results were different.
ok... did it work for you at 38.4k without changing the code? I'm very fresh to C coding so i'm a bit lost on that. can you please post an working sketch (just long/lat output) other than the standard example?
tks
no one?
i'm getting raw nmea , just like not using the lib.
can you say more clearly what you mean. When you view incoming data does it look like correctly formed nmea sentences? Perhaps you can post some example data.
well, what a mean is that using the changed code it will output the complete setences, some times without breakline. So no parsing occurs, just raw output. My initial tought was about the high speed, since 99% of the uses and example sketchs are using 4.8 or 9.6k but a user below confirmed using TinyGPS with a 36.4k GPS.... so a bit lost on the software part..
here the output with our change to 'test_with_gps_device' sketch. No sat fix (indoor):
Testing TinyGPS library v. 9
by Mikal Hart
Sizeof(gpsobject) = 103
$GPGGA,000002.999,0000.0000,N,00000.0000,E,0,00,50.0,,M,,,,0000*1E
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.,00299,,0000,N00000,,,050,,*E
$GPGGA,000003.999,0000.0000,N,00000.0000,E,0,00,50.0,,M,,,,0000*1F
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.,00399,00000,,00.00,,,254,,*F
$GPGGA,000004.998,0000.0000,N,00000.0000,E,0,00,50.0,,M,,,,0000*19
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.,00499,,0000,N00000,,,050,,*9
$GPGGA,000005.998,0000.0000,N,00000.0000,E,0,00,50.0,,M,,,,0000*18
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.000598V00000,,00.00E,,254,N78
I think user CaptainObvious was using USB instead of NSS at 38.4k (perhaps he can confirm).
If you are dropping characters then perhaps NSS is marginal on your arduino board at 38.4. The parser does not know or care about the data rate, only that the data is valid.
by valid data, do you mean well formed or sat fix? As you can see on the dump, the $GPGGA is showing, although without valid lat/long (indoor).
I am no expert but those sentences don't look like any kind of real world data. It may be more meaningful to test when the GPS has a fix.