[time-nuts] Lady Heather for homebrew GPSDO

[Mark Sims]

Probably... the manual does not go into exact details of what they are sending.

-

>  If the hex number isn't the DAC output voltage, what is it?  The code 
being fed to the DAC?
___
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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Charles Steinmetz]

Mark wrote:


The Z3801A does have a request for getting/setting the DAC value as a absolute 
(hex) number.
Neither format tells you what you really want to know...  the actual DAC 
voltage.


If the hex number isn't the DAC output voltage, what is it?  The code 
being fed to the DAC?


Just curious.

Charles


___
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.

[time-nuts] Lady Heather for homebrew GPSDO

[Mark Sims]

Heather can pretty much do that now.  It has the ability to do screen dumps to 
a file (or series of files) on a scheduled basis.   Heather doesn't do the 
"spit out an html file thing",  but I know of several people that have scripts 
on their machine that take the screen dump images and serve them up on the web. 
 That way they can format/process/display the images in their desired form.  
Heather can also dump log files on a scheduled basis and those can be read, 
processed, served, and displayed however one wants.




> If Mark is looking for a winter project, he can turn LH into this:

https://www.realhamradio.com/GPS_websites_list.htm

___
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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Tom Van Baak]

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
___
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.

[time-nuts] Lady Heather for homebrew GPSDO

[Mark Sims]

The Z3801A does have a request for getting/setting the DAC value as a absolute 
(hex) number.  Heather uses the percentage version of the message.  Neither 
format tells you what you really want to know...  the actual DAC voltage.  
There is nothing to prevent you from sending a DAC percentage with 10 digit 
resolution...

Heather gets the Z3801A satellite position/signal level info by requesting the 
"SYST:STAT?" message once a minute at xx:xx:33  and parsing out the values from 
the status screen (ugh... another reason the Z3801A was never intended to have 
a computer monitor and control it).   This takes the receiver 3 seconds to 
send.  During that time no time codes, etc come in and you can't request any 
other information.  At least the device has a (kludgy) way of getting the 
information... the Datum StarLoc II says all sats are at az/el 0,0 ... at least 
it does give a signal level.


-
> 
--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.
___
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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Jim Harman]

On Sun, Dec 18, 2016 at 1:06 PM, Mark Sims  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
___
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.

[time-nuts] Lady Heather for homebrew GPSDO

[Mark Sims]

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. 
___
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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Bob Camp]

Hi

If your GPSDO is based on an quad core 1.8 GHz with 4 GB of RAM, you can 
implement 
a lot of things. Effectively your GPSDO has more horsepower than a lot of the 
computers 
people are using to monitor GPSDO’s. Given the economics of silicon, that’s 
still not a 
crazy expensive CPU to use.

If you are trying to cram your GPSDO into a PIC 16, coming up with complex 
structures for
the i/o is likely to be a bit of a challenge. Most of the poor little beast is 
already tied up trying
to keep up with the main work of the device. 

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. It’s also been argued that 
coming up with a 
fully working GPSDO is a 10 minute project. 

I don’t have a GPSDO project hidden somewhere under all this junk on the bench. 
I’m not
planning to do one any time soon. I’m just a casual observer in all this. To me 
dumping stuff
into an already existing NMEA message parser seems to be the more universal way 
to go.
It’s not without it’s issues. Based on doing this from scratch on a few hundred 
times on 
various devices, it’s generally been the quicker and easier way to go. It’s 
certainly not the 
only way….

Bob


> On Dec 18, 2016, at 12:02 AM, Mark Sims  wrote:
> 
>> NMEA is a fine interface, widely used, easy to play with. There's no need to 
>> be pejorative.
> 
> Not being perjorative...  just commenting that it would be a lot easier to 
> implement than TSIP... probably not as good, but a lot easier to code... the 
> lazy bastards way...  I'm a lazy bastard, too.
> 
> 
>> I don't know what your problem is with the Z3801A
> 
> SCPI is good interface.  The main problem with the Z3801A implementation is 
> that it does not tag its responses with some kind of identifier as to what 
> the response is.  This is a HUGE mistake that only a novice protocol designer 
> would make.  It barely makes sense if only a person at a keyboard would be 
> sending commands.   If anything hiccups the communications a computer can 
> wind up interpreting the data improperly is that response a DAC voltage?  
> a temperature?  yeah, I asked for a DAC voltage but you sent me the 
> temperature I asked for last time...  they look identical...   there's no way 
> to tell FOR SURE what I actually got...   No amount of state machine foo can 
> get around it.
> 
> 
>> 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.
> 
> Heather does not depend upon a 1 Hz update message.  I've tested it with 1Hz 
> to 50 Hz receivers (things do get a bit wonky at over 20 Hz... too much data 
> coming over too small of a USB/serial pipe).  Heather uses the message that 
> contains the time code to decide when to update the display... it's a GPS 
> monitoring program after all and GPS is all about time.It could just as 
> easily be set up to use any message or event or timer or mule kick.  The 
> receiver time code message is the most universally consistent thing across 
> all the devices Heather works with, so that's what gets used.
> 
> 
> 
> 
> ___
> 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.

___
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.

[time-nuts] Lady Heather for homebrew GPSDO

[Mark Sims]

>  NMEA is a fine interface, widely used, easy to play with. There's no need to 
> be pejorative.

Not being perjorative...  just commenting that it would be a lot easier to 
implement than TSIP... probably not as good, but a lot easier to code... the 
lazy bastards way...  I'm a lazy bastard, too.


> I don't know what your problem is with the Z3801A

SCPI is good interface.  The main problem with the Z3801A implementation is 
that it does not tag its responses with some kind of identifier as to what the 
response is.  This is a HUGE mistake that only a novice protocol designer would 
make.  It barely makes sense if only a person at a keyboard would be sending 
commands.   If anything hiccups the communications a computer can wind up 
interpreting the data improperly is that response a DAC voltage?  a 
temperature?  yeah, I asked for a DAC voltage but you sent me the temperature I 
asked for last time...  they look identical...   there's no way to tell FOR 
SURE what I actually got...   No amount of state machine foo can get around it.


> 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.

Heather does not depend upon a 1 Hz update message.  I've tested it with 1Hz to 
50 Hz receivers (things do get a bit wonky at over 20 Hz... too much data 
coming over too small of a USB/serial pipe).  Heather uses the message that 
contains the time code to decide when to update the display... it's a GPS 
monitoring program after all and GPS is all about time.It could just as 
easily be set up to use any message or event or timer or mule kick.  The 
receiver time code message is the most universally consistent thing across all 
the devices Heather works with, so that's what gets used.




___
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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Tom Van Baak]

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 -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Bob Stewart]

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 <hol...@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.


   
___
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.

[time-nuts] Lady Heather for homebrew GPSDO

[Mark Sims]

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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Bob Stewart]

Hi Jim,
A couple of years ago, I asked the group if there was a standard UI that I 
should use for the GPSDO that I was developing.  Everyone said no, just do what 
works.  I don't think it occurred to anyone, certainly not to me, just how big 
a role that LH plays in the world of GPSDOs.  So, here I am at the end of the 
development cycle, and this question has become very important to me.  
Obviously, I'm very interested in where this thread goes.  

Mark, if you decide to handle this offline, could you make me a part of that 
discussion?
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Jim Harman <j99har...@gmail.com>
 To: time-nuts@febo.com 
 Sent: Saturday, December 17, 2016 1:22 PM
 Subject: [time-nuts] Lady Heather for homebrew GPSDO
   
Hi all,

I have experimented with LH 5 just monitoring a GPS receiver and am very
impressed with the results.

As a next step, I would like to use LH to monitor a homebrew GPSDO, and I
think it would be easier to modify the GPSDO firmware to emulate an
existing device rather than customize LH to work with the logging data that
my system currently produces.

In addition to NMEA data from the GPS, my system can output the DAC and TIC
(phase error) values as well as the temperature, Since I control the
firmware, I can produce pretty much any data format as long as it is
clearly documented, but I would prefer a text-based rather than binary
protocol and not to have to reformat all the NMEA data.

Does this approach make sense, and if so which of the several standard
GPSDOs would it be best to emulate?

Thanks in advance for your insights

-- 

--Jim Harman
___
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.


   
___
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.

Re: [time-nuts] Lady Heather for homebrew GPSDO

[Bob Camp]

Hi

There are a pretty small number of things that a GPSDO worries about that are
not in the standard NMEA data structures:

1) DAC
2) Temperature
3) Lock state
4) Time error 
5) Maybe a “quality of lock” metric

A lot of GPSDO’s put out more than that in their status messages. There is a 
lot of repetition between NMEA messages and that carries over to the custom
stuff. 

More or less anything that starts with $P is considered a specialized / custom
message. You could easily have a $PTNT (for TimeNuts of course not for blowing
things up) message or set of messages. If you added a “version” field to the 
list above, and
a “number of fields to follow”, you probably would have a useful string to use. 

$PTNT,1,5,32768,27.232,1.1.3,+22.868, -13.45,100 would be version 1, 5 fields, 
DAC 32768 out
of who knows how many (hmm…), State 1.1.3 (out of how many), Temp 22.868 C, 
time error -13.45 ns, lock 
quality 100%.

You could take care of the dac issue by going to a float with a defied range of 
0 to 1. State
is a bit more difficult. It depends a lot on how things are implemented. We 
probably would need 
it a bit better defined or put it in another message. 

Bob

> On Dec 17, 2016, at 2:22 PM, Jim Harman  wrote:
> 
> Hi all,
> 
> I have experimented with LH 5 just monitoring a GPS receiver and am very
> impressed with the results.
> 
> As a next step, I would like to use LH to monitor a homebrew GPSDO, and I
> think it would be easier to modify the GPSDO firmware to emulate an
> existing device rather than customize LH to work with the logging data that
> my system currently produces.
> 
> In addition to NMEA data from the GPS, my system can output the DAC and TIC
> (phase error) values as well as the temperature, Since I control the
> firmware, I can produce pretty much any data format as long as it is
> clearly documented, but I would prefer a text-based rather than binary
> protocol and not to have to reformat all the NMEA data.
> 
> Does this approach make sense, and if so which of the several standard
> GPSDOs would it be best to emulate?
> 
> Thanks in advance for your insights
> 
> -- 
> 
> --Jim Harman
> ___
> 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.

___
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.

[time-nuts] Lady Heather for homebrew GPSDO

[Jim Harman]

Hi all,

I have experimented with LH 5 just monitoring a GPS receiver and am very
impressed with the results.

As a next step, I would like to use LH to monitor a homebrew GPSDO, and I
think it would be easier to modify the GPSDO firmware to emulate an
existing device rather than customize LH to work with the logging data that
my system currently produces.

In addition to NMEA data from the GPS, my system can output the DAC and TIC
(phase error) values as well as the temperature, Since I control the
firmware, I can produce pretty much any data format as long as it is
clearly documented, but I would prefer a text-based rather than binary
protocol and not to have to reformat all the NMEA data.

Does this approach make sense, and if so which of the several standard
GPSDOs would it be best to emulate?

Thanks in advance for your insights

-- 

--Jim Harman
___
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.