[ntp:questions] Sure Electronics GPS board: Amazing performance. :-)

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Sat Apr 2 09:15:03 UTC 2011


David J Taylor wrote:
>> I've done some more careful inspection of the Sure GPS comms trace:
>>
>> It really looks like the GPS does _not_ listen to commands by default,
>> instead the controlling program sends a solitary '0' char to ask for
>> "permission to talk".
>>
>> About 200 ms later the GPS boards drop the CD (Carrier Detect) line,
>> and then the gps.exe program sends the private NMEA message.
>>
>> As soon as the ending <CR><LF> arrives the GPS turns CD back on and
>> restarts the configured NMEA messages.
>>
>> If this sequence is required by default, then it must also be possible
>> to turn off such very non-standard GPS behavior, right?
>>
>> Terje
>
> Fascinating! I wonder whether that GPS "chip" is really intended for
> talking to a on-board microprocessor, and we're seeing the raw
> behaviour? As the board can forget any baud rate changes (although NTP
> works correctly at the default 9600 baud), perhaps it might forget any
> programming changes as well? Presumably, you didn't get the programming
> manual as yet?

No, that partial PDF listing is my only resource, along with the 
SURE-supplied programs.

There are more tweaks to the comms protocol:

If the program sends a zero ('0') the GPS turns off CD (as reported 
above) after 200 ms.

If the GPS then doesn't get any commands within the next 100 ms, it 
reasserts CD and goes on as before.

(The gps.exe program will send pairs of '0' chars every once in a while, 
only the first zero results in the CD toggle, the second one a little 
bit later is ignored.)

It also looks like the program has to wait for a lull in the NMEA stream 
before sending that '0': The gps sends all configured strings 
back-to-back, then waits until the next second, while the program seems 
to wait until it sees a 40-50 ms gap of silence before trying that '0' 
attention request.

I.e. the proper programming setup seems to be:

1: Listen to incoming chars.

2: After a CRLF sequence, start a timer: If a new char arrives within 
less than 40 ms, goto 1.

3: Send '0', start timer waiting for CD to drop.

4: If CD drops before any new chars arrive, we are ready to send our 
command, so send it out before the 100 ms gps timeout.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list