[time-nuts] GPSDO standard interface?

Chris Albertson albertson.chris at gmail.com
Fri Jun 27 18:50:05 UTC 2014


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



More information about the Time-nuts_lists.febo.com mailing list