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