Lady Heather for homebrew GPSDO
If you go digging in the Ladt Heather code, you will find references to a "luxor" device. This is a LED / power analyzer device that I built. It runs on a ATMEGA 2561 and uses the TSIP protocol. I've also implemented the same TSIP protocol code on a '328 with 32kB of program memory. It's not that hard to do. At the lowest level it doesn't take much more code than a NMEA processor. The code sends and receives properly formatted TSIP sentences. What gets really fiddly is all the details of trying to faithfully emulate an existing GPSDO.
Binary or NMEA you need routines like send_msg_start, send item (like integer, float, double), send_msg_end. For received messages you need things like get_message, get_item_from_message, etc. The code to do that is not much more complicated for a binary protocol or an ASCII one like NMEA.
Binary messages have the little complication of what byte ordering does the CPU and protocol use. Heather has a find_endian routine that determines the CPU ordering for getting values from the received messages and re-ordering the bytes to what the CPU expects and the output routines reformat CPU values into the byte order that the receiver wants.
Writing and debugging a binary protocol is a lot more involved than a serial stream. You
can argue that code it code and it’s all trivial.
On Sun, Dec 18, 2016 at 1:06 PM, Mark Sims holrum@hotmail.com wrote:
Binary or NMEA you need routines like send_msg_start, send item (like
integer, float, double), send_msg_end. For received messages you need
things like get_message, get_item_from_message, etc. The code to do that
is not much more complicated for a binary protocol or an ASCII one like
NMEA.
One factor that leads me to prefer NMEA is that my GPS already produces it,
so all I would have to do for the satellite, time, and other GPS data would
be to send the NMEA sentences from the GPS to the host port, no parsing and
reformatting required. In order to inject GPSDO data into this stream, I
would have to implement an NMEA multiplexer and construct the new
sentence(s) as you describe above.Of course I would still need an NMEA
parser in order to interpret commands from the host, but in the Arduino
world there is TinyGPS++, a very handy open source library for this.
I see that although the Z3801A's SCPI messages would be pretty easy to
implement, there are several inconvenient or limiting aspects to this
interface. (please correct me if I am wrong on these)
--It does not stream data the way NMEA does, so the host has to keep asking
for data.
--As has been mentioned earlier, most of the responses have no identifier,
so both ends have to be careful not to get out of sync.
--The EFC value is given as an integer percent -100 to 100, so there is not
enough resolution to really tell what the DAC is doing.
-- It does not have the satellite position and C/N data that is reported in
the NMEA GSV sentence, so LH can't make its nice satellite plots.
One thing I like about the Z3801A's format is the way the TCOD message
includes brief status and alarm information, so the data doesn't get
clogged with routine data but the host can tell when to request detailed
information.
--
--Jim Harman
Hi Jim,
--The EFC value is given as an integer percent -100 to 100, so there is not
enough resolution to really tell what the DAC is doing.
Sounds like you're using :DIAG:ROSC:EFC:REL? which gives percent.
Instead try :DIAG:ROSC:EFC:ABS? which gives absolute DAC value.
-- It does not have the satellite position and C/N data that is reported in
the NMEA GSV sentence, so LH can't make its nice satellite plots.
Use the SS column of :SYST:STAT? for this.
Remember before LH there was GPScon. See tons of information on the Z3801A at:
https://www.realhamradio.com/GPS_Frequency_Standard.htm
This random one has nice examples of what you can do given the data from SCPI:
https://www.realhamradio.com/z3801a-turning-point.htm
If Mark is looking for a winter project, he can turn LH into this:
https://www.realhamradio.com/GPS_websites_list.htm
/tvb