Bug in lejos.addon.gps??

[skoehler]

Thanks!!

You're welcome. Thanks for testing and providing the input. I'm happy the problem is fixed.

output debug has dissapeared and running BTGPS program for 10 mins and counting and hasn't crashed yet (in LCP mode)
tomorrow will test in raw mode.

You should definitely try raw mode!

[Pgeorge]

I'm testing RAW/LCP/PACKET mode now in 3 diferent NXT with 3 GPS's, all same model

Each of the NXT has the BTGPS program with some diferences (connection mode)

TEST1
NXT1-GPS1-RAW -- Updates every 2sec - 30sec
NXT2-GPS2-PACKET -- Updates every 1-2 secs
NXT3-GPS3-LCP -- Updates every 1sec (sometimes 2 secs)
Different gps time between RAW NXT and the other NXT because of the delays in the refresh
LCP and PACKET NXT hava almost same gps time

TEST2
NXT1-GPS1-RAW -- Updates every 2sec - 30sec
NXT2-GPS2-RAW -- Updates every 2sec - 30sec
NXT3-GPS3-RAW -- Updates every 2sec - 30sec
Different time in each NXT

TEST2
NXT1-GPS1-LCP -- Updates every 1sec (sometimes 2 secs)
NXT2-GPS2-LCP -- Updates every 1sec (sometimes 2 secs)
NXT3-GPS3-LCP -- Updates every 1sec (sometimes 2 secs)
Almost same gps time info in each NXT, could see almost all seconds in each display at same time (unless a gps lose satellite sync, i'm inside a building with the gps in the window)

So, in conclusion, with my gps model the best mode is LCP (i know, i should use RAW), but is faster.

[skoehler]

So, in conclusion, with my gps model the best mode is LCP (i know, i should use RAW), but is faster.

It's not a matter of what is faster and what is not. RAW is correct, LCP is wrong due to the additional two byte header that it requires. None of the GPS devices will send that two byte header. Or did you see any two byte headers when sniffing the data using hyperterminal? I bet you didn't
It's purely an accident that this works with LCP enabled. If updates in RAW mode are slower, there is probably another problem in some area of leJOS that needs to be discovered. Using LCP, you should (and probably will) see errors at some point. It is already the case, that internally, without you noticing, broken/wrong lines are being processes. Basically, using LCP will result in character loss. For example, instead of "030212" the date could become "0312". Probably you're not interested in the date. But I bet you'd care if some digits were missing from the value of the longitude?

[gloomyandy]

An easy way to work out what is going on here is to write a program that opens the device in RAW mode and simply reads all of the bytes from the device and then displays them using something like the USB based RConsole, that way you can see exactly what is being sent from the device and read by the NXT... As Sven said if you are having problems with RAW mode then this almost certainly means there is some other sort of problem, probably in the parsing code. Using the above test program should soon tell you how fast the data can be read from the device...

Andy

[skoehler]

I took a look at SimpleGPS.getNextString(). Turns out, the method doesn't respect the usual InputStream semantics (i.e. no checking of the return value of read(byte[]) whatsoever). The result must be mangled lines and whatnot. Also no usage of BufferedReader.readLine() (which probably did not exist at the time of writing that class). It might work better in LCP mode, since the read(byte[]) calls might properly fill the array (almost) every time. In RAW mode the read() calls may only partially fill the array. I'm not amused and reluctant to fix that since I don't own a GPS.

Can you take a look at that, Andy?

[gloomyandy]

Hi Sven,
OK I'll try and dig out my old Bluetooth GPS over the weekend. Can you let me know what exactly the method has to do (I assume you've worked it out already!)... What exactly is the definition of a String in this case?

Andy

[skoehler]

Hi Sven,
OK I'll try and dig out my old Bluetooth GPS over the weekend. Can you let me know what exactly the method has to do (I assume you've worked it out already!)... What exactly is the definition of a String in this case?

I believe the method is supposed to return a line of text. At the moment, it searches for the $ character in the stream and assumes that $ is the start of a new line and return the line including the leading $ character and maybe even the trailing new lines. However, I believe it safe (and probably less strange?) to simply split by (CR)LF.
The lines returned by getNextString() are then checked whether they start with $GPGGA, $GPVTG, etc. so the leading $ is definitely included.

[skoehler]

Pgeorge: please try 0.9.1. There is a bazillion of fixes concerning the lejos.addon.gps-package included in 0.9.1. It might work much better than the last snapshots you tried.

[skoehler]

@Pgearge: ping? Did the issues with your GPS go away with 0.9.1?

[Pgeorge]

Sorry, forgot to post here (busy weeks)

I couldn't try deeper the new version because of weather and other tasks in the calendar but with the tests that i've done , i can tell that this version works better than the older. (In Raw mode time updates every second and works during a long time (more than 10min without any exceptions) but test have been done inside the building and GPS signal is very bad there)

I hope next week to try GPS outside (if weather is good...) and make more tests and post the results

[skoehler]

That sounds promising.
Looking forward to the results of your future tests.