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