Chris, NMEA is a good 'general purpose' interface for GPS units but I thought this thread was about the GPSDO interface. Not quite the same - TSIP/SCPI would make rather more sense here, especially with all those Thunderbolts about :-) Most GPS receivers still supply at least one serial interface even if a USB interface is included too. Consumer grade 'very small' navigation type GPS units may dispense with the serial ports but we are not too worried about those devices, surely? I don't see why a serial to USB converter would be needed - serial ports are still available on a reasonably large number of motherboards, especially if you are using mini-ITX or similar for embedded projects, and a hardware UART is a much more reliable interface. USB/serial adaptors 'still' give erratic results and scanning usb ports for new devices is also a bit of a lottery at times. A serial interface is also the easiest to convert to a more 'robust' physical media for electrically 'unpleasant' environments .... and DB9/25 connectors are a LOT more reliable than USB connectors too!
regards, Paul G8GJA -----Original Message----- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Chris Albertson Sent: 26 June 2014 08:13 To: Bob Stewart; Discussion of precise time and frequency measurement Subject: Re: [time-nuts] GPSDO standard interface? If you want a common interface for GPS receivers it's "NMEA" and it's relatively easy to implement. I certain would NOT translate to TSIP as that is rather obscure. NMEA is a very common standard and many GPSes can output NMEA. Also you talked about "serial". I hate to say it but "who in 2014 wants a serial device? USB is the only reasonable interface to a computer. If you used serial then you would just need to buy a serial to USB adapter so you may as well build that into your controller. In 2014 those old DB9 and DB25 connectors should be banned from all new designs. Realistically the user interface in most home made gear is a few "#ifdef" in the code at the top of the file. You change those and recompile and send the new software to the controller. It's not bad having to re-compile in order to support a different GPS receiver. You would not want to swap the brand of GPS in a user interface. You do that with solder and wires and recompiling On Wed, Jun 25, 2014 at 8:14 PM, Bob Stewart <b...@evoria.net> wrote: > After reading Chris's response, it dawned on me that I'm treading a > different path from what I've seen on the list. It's not so much a GPSDO > as a general purpose GPSDO engine. It uses a number of ideas from Bert's > board, like the dual-rail op-amp output, but it also has a TIC, so it will > have sawtooth correction. I have included 2 TTY ports: one for the > receiver and one for the PC interface. I'm going to use the DAC on the > dsPIC, but there will be an SPI port that can be used to drive an off-board > DAC, instead. There's also the possibility of switching some stuff around > and having an I2C port, and the ICSP header could also hook up to an > additional thermistor or two, or perform other digital functions. > > > So, there will be some minor user fiddling, like with Bert's board, due to > the flexibility of the OCXO. But, I'll be using the P and D from the PID > control system, so it shouldn't be difficult to setup. There will be a > power LED, an output enable LED, and a bi-color LED to signify status, but > only the status would be necessary. I'll do what I can to make it smart > enough to plug and play for most circumstances, but I only have the one > OCXO brand to test with at the moment. I do have 3 receivers to test with > now: Adafruit, UT+, and LEA-6T. Keep in mind that I don't expect this to > be a lucrative commercial business venture, so my budget is almost > nonexistent. > > > I'll look into both SCPI and TSIP, and therein lies the reason for my > original post. Essentially, have they been patented, and if so, have those > patents expired? Some companies guard their interfaces very rigorously to > forestall competitive disruption. I don't want to suddenly get a cease and > desist letter or a notice of lawsuit over a hobbyist kit. It's one thing > to provide open source software to monitor/control a successful product. > It's an entirely different thing to provide an alternative product with an > identical user interface. > > I just ordered the first prototype boards today, but the software should > be just a rewrite of what I did for the TIC on Bert's board, with a lot of > extras thrown in. Not that that doesn't mean a lot of work, of course. > > > Bob > > > > ________________________________ > From: Tom Van Baak <t...@leapsecond.com> > To: Discussion of precise time and frequency measurement < > time-nuts@febo.com> > Sent: Wednesday, June 25, 2014 9:02 PM > Subject: Re: [time-nuts] GPSDO standard interface? > > > Bob, > > A couple of different ideas: > > 1) No UI at all. The surplus GPSDO favorites over the years (like the HP > SmartClock's and Trimble Thunderbolt) work with no UI. Yes, there is a PC > program you can use to monitor and control it, or even debug it, but it is > completely optional. Many GPSDO work out of the box. Maybe, like HP, have > one green LED to say all-is-well. > > 2) A very simple 9600 baud command set that you can use with any terminal > program. Adding LCD is fine too. But make sure everything on the LCD is > also available over RS232. Not everyone wants to visually monitor the LCD > of every piece of gear on their bench; let a PC log and archive all the > data, check for problems, make plots, etc. > > 3) Mimic enough of HP's SCPI command set so that GPScon and other tools > like that can be used, transparently. I forget if your GPSDO includes a > receiver or not. > > 4) Mimic enough of Trimble's TSIP so that LH and other tools like that can > be used, transparently. > > Please write enough code so that the GPSDO, by default, can work "out of > the box". I'm evaluating a prototype GPSDO right now that requires all > sorts of user input just to get it started and to keep it going. That gets > old. My bias is: time spent creating clever adaptive algorithms to make a > human unnecessary is better than time spent creating an elaborate UI that > requires a user (and operation manual) and constant monitoring or adjusting. > > /tvb > > > ----- Original Message ----- > From: "Bob Stewart" <b...@evoria.net> > To: "Discussion of precise time and frequency measurement" < > time-nuts@febo.com> > Sent: Wednesday, June 25, 2014 5:10 PM > Subject: [time-nuts] GPSDO standard interface? > > > In an offline communication, I suddenly realized that I hadn't given any > thought to the user interface for my GPSDO. Is there an accepted standard > interface for GPSDOs, or is that a murky Microsoft-esque world of patents > and lawyers? > > > Bob - AE6RV > > > _______________________________________________ > 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 _______________________________________________ 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.
