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