Lady Heather for homebrew GPSDO
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.
The lazy bastard way would be cramming so proprietary NMEA sentences into a NMEA-like stream.
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.
Heather really likes to see a device that sends regular time packets every second without having to request them. Sending device status / TIC readings, temperature, etc is also a good thing.
Mark,
I haven't had the time to look at the LH code yet, but is there a sort of natural interface that would most easily fit? I'm speaking about both sides of the conversation: receiving data streams and sending commands. It seems a bit strange to me that NMEA would be the preferred type of data stream. And it should be obvious that giving direct access to the receiver would cause many problems.
As far as emulating a Motorola: the Ublox is quite a bit different from the Motorola. Synergy have spent quite a lot of time and money to produce their SSR-T boards that allow a Ublox receiver to look exactly like a Motorola. I certainly wouldn't want to replicate that effort.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Mark Sims <holrum@hotmail.com>
To: "time-nuts@febo.com" time-nuts@febo.com
Sent: Saturday, December 17, 2016 7:28 PM
Subject: [time-nuts] Lady Heather for homebrew GPSDO
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.
The lazy bastard way would be cramming so proprietary NMEA sentences into a NMEA-like stream.
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.
Heather really likes to see a device that sends regular time packets every second without having to request them. Sending device status / TIC readings, temperature, etc is also a good thing.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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