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 <[email protected]> wrote: > > [email protected] 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
