[time-nuts] TymServe 2100 was: The GPS 1995 problem and the Heol Design solution.

Bob Camp kb8tq at n1k.org
Tue May 19 21:38:48 UTC 2015


HI

I’d bet that the ACE is supplying full time / date info to the TS2100. That’s what 
every module I’ve seen does. No reason to play with the GPS weeks if you don’t
have to. Use the date from the receiver. 

Assuming that’s correct. You have a lot more to do than flip one bit in at one point 
in one string. Also remember - you need to delay all of the week / hour / minute switch
points by the number of leap seconds that the ACE does not know about. 

Bob

> On May 19, 2015, at 4:14 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> 
> kb8tq at n1k.org said:
>> The complexity is not in the data translation, it’s in the timing of the
>> whole thing. The firmware in the TS2100 was designed and tested with a
>> particular order of sentences and timing between them and the pps output of
>> the Trimble ACE. Upset that timing (by delaying the data) and you may up
>> upset the firmware’s expectations about when the data ...
> 
> It would probably take some experimentation to figure out what fields the 
> TS2100 actually uses.
> 
> Assuming you know what it needs, my expectation is that the serial data 
> stream would be delayed by one character time.  Mostly, it's just read a 
> character from the input UART and copy it to the output UART.  Then you have 
> to watch the data stream and find the sentences you want to modify.  If it's 
> just the week number, that's as simple as add 0x?? to byte ?? of sentence 
> type ??.  If the date used by the TS2100 is in year/month/day format, then 
> it's replace several bytes with the precomputed correct data.  There is most 
> of a second to do that computation.
> 
> If there is a checksum, that will have to be corrected on the fly.  That 
> shouldn't be hard.
> 
> -----
> 
> Things get interesting if the local clock used by the output UART is slightly 
> slower than the clock used to send to your input UART.
> 
> The output is probably double buffered.  That extra character will support 
> some clock skew.  The critical factor is how long the data stream is between 
> pauses.  If the worst case clock difference is 200 ppm (100 ppm each), it 
> takes a 5000 character burst to overrun a 1 (extra) character buffer.  9600 
> baud is 1000 characters per second so that's a 5 second burst.
> 
> (Ethernet hubs/repeaters have the same problem.  They have to buffer up 
> enough data before starting to transmit so that the buffer doesn't run dry if 
> the clocks are off in one direction and the buffer has to be big enough to 
> hold the extra if the clocks are off in the other direction.  Both scale with 
> the max packet length.)
> 
> Another approach would be to hack the transmit baud rate to be slightly fast, 
> say 9602 so it won't be slower at the worst case clock speed difference.
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




More information about the Time-nuts_lists.febo.com mailing list