I dislike TSIP quite a bit. It's a disaster in my opinion if you are not intimately familiar already with the Trimble binary commands, and exists in a number of inconsistent and non-compatible dialects as far as I know. No way for a human to enter a simple command in a simple text terminal, you have to have everything translated by some application. I know the software folks like binary better than ASCII, because parsing binary commands can theoretically be done with less effort. I think effort == results. There is SatStat, GPSCon, and Ulrich's great Z38xx control program for human readable SCPI commands besides the good old ASCII terminals. HP leads the way with GPIB/SCPI in my opinion. But it's like religion, everyone thinks theirs is the right one, and everyone else is on the wrong path. bye, Said In a message dated 6/26/2014 14:01:35 Pacific Daylight Time, holrum@hotmail.com writes: There are TSIP commands for doing all those things. It should be fairly easy to adapt them to control your hardware and whatever GPS receiver you are using. The nice thing about implementing a TSIP interface is being able to use existing programs like Tboltmon and Lady Heather (over 30,000 lines of code) to monitor and control it. Also NTP knows how to talk TSIP. ---------------- I am planning on the output of at least position, corrected phase error, DAC value, ambient temperature, and a few other things. I also see a need to read and write the PID gain and damping factors, but that may just have to be a custom tty interface. It may be that I need to have a pass-through mode to give direct access to the receiver for triggering site survey, etc. _______________________________________________ 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.

Novatel has two versions of each message one binary (ending with B) and one ASCII (ending with A). That is one way of catering to both the interactive use and the clean software side of the problem. Javad (GRIL now GREIS) is my personal favorite. Your commands are ascii, often very short. The output messages are usually binary but with a prefix and ending linefeed that makes it easy to monitor which messages are active in a plain console terminal. The binary parts are also constructed in such a way that makes it very easy to receive them in normal structs. my two öre. /Björn > I dislike TSIP quite a bit. It's a disaster in my opinion if you are not > intimately familiar already with the Trimble binary commands, and exists > in > a number of inconsistent and non-compatible dialects as far as I know. No > way for a human to enter a simple command in a simple text terminal, you > have to have everything translated by some application. I know the > software > folks like binary better than ASCII, because parsing binary commands can > theoretically be done with less effort. I think effort == results. > > There is SatStat, GPSCon, and Ulrich's great Z38xx control program for > human readable SCPI commands besides the good old ASCII terminals. HP > leads the > way with GPIB/SCPI in my opinion. But it's like religion, everyone thinks > theirs is the right one, and everyone else is on the wrong path. > > bye, > Said > > > In a message dated 6/26/2014 14:01:35 Pacific Daylight Time, > holrum@hotmail.com writes: > > There are TSIP commands for doing all those things. It should be fairly > easy to adapt them to control your hardware and whatever GPS receiver you > are using. > The nice thing about implementing a TSIP interface is being able to use > existing programs like Tboltmon and Lady Heather (over 30,000 lines of > code) > to monitor and control it. Also NTP knows how to talk TSIP. > > > > ---------------- > I am planning on the output of at least position, corrected phase error, > DAC value, ambient temperature, and a few other things. I also see a > need > to read and write the PID gain and damping factors, but that may just > have > to be a custom tty interface. It may be that I need to have a > pass-through > mode to give direct access to the receiver for triggering site survey, > etc. > > _______________________________________________ > 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. >

For a new design I'd re-think the entire architecture. Back in the 1980's It made sense for a small instrument to push data over a cable to a bigger computer where the data could be logged and displayed. The cost and physical size of the computing power to log and display data was large. Times have changed. Now computer power is as cheap as dirt. 32-bit computers cost under $5 and most people have smart phones or other mobile devices. Even 32GB micro SD cards are cheap. I think a modern device would have the all of the data processing done internally but would connect to just about any kind of desktop or mobile device for a user interface. The prime example is the home WiFi router. All of these devices have built-in web servers that you can access from almost any device. It costs almost nothing to add this. USB is PC centric but IP networking is now universal. The software to do this is free and easy to use. Web servers can be very low powered as all the "heavy lifting" is done by the web browser. I would not use a web interface to push data to be logged, there are other network protocols for that (syslog?) That said a user interface using just a blinking LED is enough. Once you get the thing running you almost never need to look at it again. Again, like a WiFi router. On Thu, Jun 26, 2014 at 10:39 PM, "Björn Gabrielsson" <bg@lysator.liu.se> wrote: > Novatel has two versions of each message one binary (ending with B) and > one ASCII (ending with A). That is one way of catering to both the > interactive use and the clean software side of the problem. > > Javad (GRIL now GREIS) is my personal favorite. Your commands are ascii, > often very short. The output messages are usually binary but with a prefix > and ending linefeed that makes it easy to monitor which messages are > active in a plain console terminal. The binary parts are also constructed > in such a way that makes it very easy to receive them in normal structs. > > my two öre. > > /Björn > > > I dislike TSIP quite a bit. It's a disaster in my opinion if you are not > > intimately familiar already with the Trimble binary commands, and exists > > in > > a number of inconsistent and non-compatible dialects as far as I know. > No > > way for a human to enter a simple command in a simple text terminal, you > > have to have everything translated by some application. I know the > > software > > folks like binary better than ASCII, because parsing binary commands can > > theoretically be done with less effort. I think effort == results. > > > > There is SatStat, GPSCon, and Ulrich's great Z38xx control program for > > human readable SCPI commands besides the good old ASCII terminals. HP > > leads the > > way with GPIB/SCPI in my opinion. But it's like religion, everyone > thinks > > theirs is the right one, and everyone else is on the wrong path. > > > > bye, > > Said > > > > > > In a message dated 6/26/2014 14:01:35 Pacific Daylight Time, > > holrum@hotmail.com writes: > > > > There are TSIP commands for doing all those things. It should be fairly > > easy to adapt them to control your hardware and whatever GPS receiver > you > > are using. > > The nice thing about implementing a TSIP interface is being able to use > > existing programs like Tboltmon and Lady Heather (over 30,000 lines of > > code) > > to monitor and control it. Also NTP knows how to talk TSIP. > > > > > > > > ---------------- > > I am planning on the output of at least position, corrected phase error, > > DAC value, ambient temperature, and a few other things. I also see a > > need > > to read and write the PID gain and damping factors, but that may just > > have > > to be a custom tty interface. It may be that I need to have a > > pass-through > > mode to give direct access to the receiver for triggering site survey, > > etc. > > > > _______________________________________________ > > 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 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. > -- Chris Albertson Redondo Beach, California