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

[Lizeth Norman]

I've got an NO 24 that I bought for a ts-2100 that died on the table.

Anyone interested in a trade or ??
Norm n3ykf

On Tue, 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.