Mark, Bob, > If you are going to a GPSDO interface, I would bite the bullet and recommend > the Trimble > TSIP / Thunderbolt commands. It has its warts, but has commands for doing > just about > anything a GPSDO should do. Doing a decent job would not be easy... Nobody > seems to > have done a decent job emulating a Motorola receiver, and that is an easier > thing to do.
I second the TSIP recommendation. Mostly you want to avoid this: https://xkcd.com/927/ > The lazy bastard way would be cramming so proprietary NMEA sentences into a > NMEA-like stream. NMEA is a fine interface, widely used, easy to play with. There's no need to be pejorative. > Polled interfaces like the Z3801A are horrible things for a computer to talk > to. If you miss a > response or one gets garbled it can be difficult to recover from. The Z801A > is the worst > possible interface... it's responses to requests have nothing in them to > identify what request > the values are in response to. Well, maybe here we part ways. The hp SCPI method is highly organized and nearly self-documenting. It's also in use across all sorts of instrumentation by multiple vendors for decades. Nothing wrong with that. I don't know what your problem is with the Z3801A. If you keep your transmit and receive state machine clean there should not be issues. Millions of LabView projects work just fine with SCPI-based instruments for decades. No need to throw mud on it. > Heather really likes to see a device that sends regular time packets every > second without > having to request them. As they say, "there's your problem". Most operating systems provide a way for a computer program to send serial packets out in a timely or regular basis. Yes, it may be convenient if the device does the timing for you, but surely a program can be written to work well either way. > Sending device status / TIC readings, temperature, etc is also a good thing. Yup. Note that both TAC32 and TBoltmon allow for GPSDO and TIC on different serial ports and they integrate the results. Handling environmental sensors is a natural extension of this. Some of these sensors use request / response protocols; others are periodic and talk-only. Their rates are rarely ever 1.000 Hz like GPS. So this is all the more reason to re-consider your LH architecture and not assume or not depend on the input(s) being externally timed or paced at exact multiples of 1 s. In fact, you could use the sidereal clock problem that we've talked about off-list as the test case for separating the pacing of data collection(s) from the pace of screen updates. As LH continues to evolve into a mini- TimeLab or LabView you may find this separation valuable. My 2c worth. /tvb _______________________________________________ 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.
