Quote:
Quote:
Quote:
The required timeout is currently set to 150 ms, I guess I could reduce that. Can you make a short video that I can use to see/measure how long the pauses are?
Also, is that last block way longer? It looks far too long to send in 1 second at 4800 baud.
Yes, the last block is longer. I wondered about this, so I experimented by setting the GPS to send different sentences.
Sending only GGA, GSA and RMC didn't work at 4800 baud but is fine at 9600 baud [the three sentences are around 190 characters]
$GPGGA
$GPGSA
$GPRMC
<pause>
Interestingly, sending only GGA and GSA works fine at 4800 baud - the NMEA data flag becomes active and GPS lock is reported. [The two sentences are around 121 characters]
$GPGGA
$GPGSA
<pause>
It seems then that this issue may indeed relate to the number of characters sent / available time during pauses?
As standard this GPS seems to send at 4800baud using the NMEA sentences I described in my previous post. The longest block (9 lines) seems to be around 569 characters which may be an issue?
Its seems that 4800 baud is not uncommon for these types of devices, so it would be nice if it worked straight out of the box.
Does ST need NMEA every second with the requisite pause as a marker? I.e. would an the long blocks be an issue?
I would be interested to test with a timeout value that is less than 150ms.
569 * 8 / 4800 = 0.948 seconds, so that would mean that the pause is at most 50 ms. That's not much... especially since on Windows the data is typically processed in burst. And yes, we do need *something* to indicate that a new block of data arrives, to link it in time to the audio pulses. I don't think that there is any standard "first line" or something that's sent, otherwise we could have used that. Maybe something like "the first line that contains a new time stamp" would work, but that's tricky and might fail in other cases.
How did you make it send less data?
I delved into some manufacturer specific info. The GPS uses a SiRF chipset, the associated demo software allows you to change the config of the device (e.g. baud rate, sentences, switch between NMEA mode and SiRF protocol, etc.). From what I have read, the device setup (e.g. baud rate) can also be changed by sending a serial command.
This seems to vary per manufacturer, but to change to 9600 for SiRF, it would be something like: $PSRF100,1,9600,8,1,0*0D
(SetSerialPort). The $PSRF103*** set of commands is seemingly used to enable/disable certain messages
(Query/Rate Control).
It doesn't seem like there is a standard across devices though? Seems to be specific to the manufacturer / chipset etc.? Some info here for three chipsets including SiRF.
https://learn.sparkfun.com/tutorials/gp ... s-receiver
At one point I thought I lost GPS lock but that may have just been a transient issue. I need to test a bit more but I imagine sending only a limited number of NMEA sentences (e.g. just GGA), or using a higher baud rate, will leave a good margin for the pauses. I'm had hoped there would be a simple cover-all solution for the use of generally available USB GPS units, but now I'm not so sure.
Register
Login
FAQ
Search
