Re: [time-nuts] GPSDO standard interface?
Reset Enable LED C: Disable LED Command R: none Character 14 led:enabled 0 34 Time interval query C: Even second drift R: Time interval Character 16 Character n ptime:interval? n.n*E[+-]n* 35 Antenna system interface query C: Antenna System query R: Antenna Status String Character 19 Character n antenna:condition? x* Example: Nortel Trimble GPSR command set. There is also an undocumented status page command (syst:stat?) much the same as the HP type GPSDO. However the Predicted uncertainty is locked at 0 (zero). marki -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims Sent: Thursday, 26 June 2014 12:25 PM To: time-nuts@febo.com Subject: [time-nuts] GPSDO standard interface? There is no standard interface for GPSDOs, but the Trimble TSIP interface as used by the Thunderbolt/Lady Heather would be an excellent place to start and include. Make the unit smart enough to run unattended, but add enough monitoring commands so Lady Heather, etc can be used to monitor and tweak it... it will save you a lot of work and Lady Heather's graphing and logging features provide great insights into its operation, performance, and quirks. ___ time-nuts mailing list -- time-nuts@febo.commailto: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.
Re: [time-nuts] GPSDO standard interface?
http://www.ftdichip.com/Products/ICs/VNC1L.htm On 6/26/2014 3:39 PM, time-nuts-requ...@febo.com wrote: USB may be a common interface to a computer but practically useless to another microcontroller. Everything can do serial but not everything can do USB master. In the worst case, use a Serial-USB adapter on your PC. There is no such thing as a Serial-USB master interface and never will there be one. USB is PC centric. Didier KO4BB ___ 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.
Re: [time-nuts] GPSDO standard interface?
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 b...@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, hol...@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 ___ 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.
Re: [time-nuts] GPSDO standard interface?
If you want to see how to generate TSIP message, I can post the code to my Thunderbolt simulator. Its in Visual Basic but it will show you an example. It generates the primary and secondary packets. You can download the software from my web site www.ko4bb.com Didier KO4BB On June 26, 2014 12:01:29 PM CDT, Mark Sims hol...@hotmail.com wrote: Yes I have... I have built several sensor type boards that use an ATMEL chip as the processor. They output data in a TSIP packet format that tricked up versions of Lady Heather can control and monitor. The most complicated one is probably a LED/Battery analyzer device that measures voltages, currents, intensities, color spectrum, etc and can PWM a 90 amp power FET. The TSIP requirements for a GPSDO can be fairly simple. Look in the heathgps.cpp file in the Lady Heather source code to see what messages are important. You don't need to implement all (or even most) of them. The more you implement, the better Lady Heather can control it. Lady Heather basically wants to see the primary and secondary timing messages every second. It uses those messages to trigger requests for other info/status messages... a different message each second. So, start with outputting the primary and secondary timing messages every second.You probably also want to output the lat/lon/alt message. Then add support for other messages that you want to see/control. As far as Windows is concerned... Lady Heather is open source. Feel free to port it to Linux, etc... it should not be too difficult... but many people have said that they would do so, but so far nobody has. If you want to do so, I can send you the code that I have for version 4.0. It has some changes to the plotting code and TSIP parser that make it easier to tweak for different data logging applications (such has my LED analyzer). --- That sounds good but have you figured out how to implement this? ___ 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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ 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.
Re: [time-nuts] GPSDO standard interface?
I am quite familiar with that chip which perfectly illustrates my point. A universal serial/USB Master interface it is not. Didier KO4BB On June 27, 2014 7:14:34 AM CDT, Dan Kemppainen d...@irtelemetrics.com wrote: http://www.ftdichip.com/Products/ICs/VNC1L.htm On 6/26/2014 3:39 PM, time-nuts-requ...@febo.com wrote: USB may be a common interface to a computer but practically useless to another microcontroller. Everything can do serial but not everything can do USB master. In the worst case, use a Serial-USB adapter on your PC. There is no such thing as a Serial-USB master interface and never will there be one. USB is PC centric. Didier KO4BB ___ 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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ 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.
Re: [time-nuts] GPSDO standard interface?
Tom, On 06/26/2014 04:02 AM, Tom Van Baak wrote: 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. SCPI in general is an attempt at creating a standard interface for instruments, and it has a pretty nice structure and logic to it. Building on SCPI one should be able to get a pretty good and stable interface. Jackson lab continues that tradition. 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. We should really see if we could not have LH work for SCPI GPSDOs as well. I won't get GPScon. PS. At EFTF 2014 in Neuchatel, the hotel assigned me room 133, so I feel on time and stable. :) Cheers, Magnus ___ 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.
Re: [time-nuts] GPSDO standard interface?
Much better than room 137. BTW, if you run into a physicist someday who can *calculate* 9192.631770 MHz directly from quantum mechanics, ask them to calculate the other isotopes of cesium. They should be different. But I have no idea how much or little. /tvb PS. At EFTF 2014 in Neuchatel, the hotel assigned me room 133, so I feel on time and stable. :) Cheers, Magnus ___ 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.
Re: [time-nuts] GPSDO standard interface?
On Wed, Jun 25, 2014 at 7:25 PM, Mark Sims hol...@hotmail.com wrote: There is no standard interface for GPSDOs, but the Trimble TSIP interface as used by the Thunderbolt/Lady Heather would be an excellent place to start and include. Make the unit smart enough to run unattended, but add enough monitoring commands so Lady Heather, etc can be used to monitor and tweak it... it will save you a lot of work and Lady Heather's graphing and logging features provide great insights into its operation, performance, and quirks. That sounds good but have you figured out how to implement this?Exactly what data will you pass and you would have to add sensors to get some of it and then you would also have to translate what your GPS is sending and put it into Trimble's format. This is over all harder than building the GPSDO. Then to use it you'd need a Windows PCs with a serial interface do you really want your gPSDO to be feathered to a PC? ___ 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.
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
Re: [time-nuts] GPSDO standard interface?
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, PaulG8GJA -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
Re: [time-nuts] GPSDO standard interface?
Hi One gotcha with TISP - NEMA is that they use different units for things like position. Yes it’s just math to translate them. No it’s not trivial on a little tiny PIC. If the GPS in your GPSDO is a NEMA (or NEMA like) device, you either will have a mix of TISP and NEMA or a lot of translation ... Bob On Jun 26, 2014, at 5:38 AM, REEVES Paul paul.ree...@uk.thalesgroup.com wrote: 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, PaulG8GJA -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
Re: [time-nuts] GPSDO standard interface?
On Wed, Jun 25, 2014 at 11:14 PM, Bob Stewart b...@evoria.net wrote: 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? You almost certainly want to use SCPI which is managed by IVI and is part of the joint IEEE/IEC post 488 spec. Said can probably provide the vendor perspective (ie. price). NMEA is proprietary and all the useful commands are vendor specific. TSIP is only interesting because LH can manage a few versions but besides being proprietary it's device specific. ___ 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.
Re: [time-nuts] GPSDO standard interface?
On Thu, Jun 26, 2014 at 2:38 AM, REEVES Paul paul.ree...@uk.thalesgroup.com wrote: 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 Can you implement TSIP? Just a rough design. That's the problem. You have a UT+ or other interchangeable GPS (The OP wants to be able to swap between three GPS receivers) Can you design a inversion X to TSIP tanslators and a TSIP command inter peter? I think you will find that TSIP depends on having Trimble hardware some of what it reports simply does not exist in a UT+ or other. NMEA is actually not just a GPS interface. other kinds of instruments use NMEA, wind meters, depth finders, logs, magnetic compass and even Inertial systems. radars accept it and so on. It is also easy to translate into NEMA and it's an easy format to work with. There are LOTS and LOTS of software that can plot NMEA sentences, far more than TSIP. We have pretty muh gone past the the possibility of using a tiny 8-bit micro controller. Why not use a Beagle Board or Raspberry Pi as the controller? They cost about $40 but now you can run a multi tasting OS and even the Apache web server and do the user interface as a web page. The web interface is great you can access it on a PC or a phone and from any place on Earth with a Internet connection. Costs only a few dollars more for the controller. T 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, PaulG8GJA -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
[time-nuts] GPSDO standard interface?
Yes I have... I have built several sensor type boards that use an ATMEL chip as the processor. They output data in a TSIP packet format that tricked up versions of Lady Heather can control and monitor. The most complicated one is probably a LED/Battery analyzer device that measures voltages, currents, intensities, color spectrum, etc and can PWM a 90 amp power FET. The TSIP requirements for a GPSDO can be fairly simple. Look in the heathgps.cpp file in the Lady Heather source code to see what messages are important. You don't need to implement all (or even most) of them. The more you implement, the better Lady Heather can control it. Lady Heather basically wants to see the primary and secondary timing messages every second. It uses those messages to trigger requests for other info/status messages... a different message each second. So, start with outputting the primary and secondary timing messages every second.You probably also want to output the lat/lon/alt message. Then add support for other messages that you want to see/control. As far as Windows is concerned... Lady Heather is open source. Feel free to port it to Linux, etc... it should not be too difficult... but many people have said that they would do so, but so far nobody has. If you want to do so, I can send you the code that I have for version 4.0. It has some changes to the plotting code and TSIP parser that make it easier to tweak for different data logging applications (such has my LED analyzer). --- That sounds good but have you figured out how to implement this? ___ 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.
Re: [time-nuts] GPSDO standard interface?
Hi Mark, Thanks for the response. I'll take a look at heathgps.cpp. I had hoped not to have to actually look through code to divine an interface, but if that's the way it is, then OK. 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. If this turns into a bag of worms, I'll just continue to use a modified version of Bert's interface. I'm afraid you'll have to look elsewhere for someone to port LH to Linux. Bob From: Mark Sims hol...@hotmail.com To: time-nuts@febo.com time-nuts@febo.com Sent: Thursday, June 26, 2014 12:01 PM Subject: [time-nuts] GPSDO standard interface? Yes I have... I have built several sensor type boards that use an ATMEL chip as the processor. They output data in a TSIP packet format that tricked up versions of Lady Heather can control and monitor. The most complicated one is probably a LED/Battery analyzer device that measures voltages, currents, intensities, color spectrum, etc and can PWM a 90 amp power FET. The TSIP requirements for a GPSDO can be fairly simple. Look in the heathgps.cpp file in the Lady Heather source code to see what messages are important. You don't need to implement all (or even most) of them. The more you implement, the better Lady Heather can control it. Lady Heather basically wants to see the primary and secondary timing messages every second. It uses those messages to trigger requests for other info/status messages... a different message each second. So, start with outputting the primary and secondary timing messages every second. You probably also want to output the lat/lon/alt message. Then add support for other messages that you want to see/control. As far as Windows is concerned... Lady Heather is open source. Feel free to port it to Linux, etc... it should not be too difficult... but many people have said that they would do so, but so far nobody has. If you want to do so, I can send you the code that I have for version 4.0. It has some changes to the plotting code and TSIP parser that make it easier to tweak for different data logging applications (such has my LED analyzer). --- That sounds good but have you figured out how to implement this? ___ 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.
Re: [time-nuts] GPSDO standard interface?
USB may be a common interface to a computer but practically useless to another microcontroller. Everything can do serial but not everything can do USB master. In the worst case, use a Serial-USB adapter on your PC. There is no such thing as a Serial-USB master interface and never will there be one. USB is PC centric. Didier KO4BB On June 26, 2014 2:13:00 AM CDT, Chris Albertson albertson.ch...@gmail.com wrote: 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
Re: [time-nuts] GPSDO standard interface?
Perhaps the misunderstanding happened when I mentioned two UARTs and two tty interfaces. Using a standard tty interface has nothing to do with how it gets to the monitor hardware once it leaves the board. It's the same physical interface that's used by the receiver boards; whether Adafruit, UT+, LEA-6T, or whatever. Bob From: Didier Juges shali...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, June 26, 2014 2:22 PM Subject: Re: [time-nuts] GPSDO standard interface? USB may be a common interface to a computer but practically useless to another microcontroller. Everything can do serial but not everything can do USB master. In the worst case, use a Serial-USB adapter on your PC. There is no such thing as a Serial-USB master interface and never will there be one. USB is PC centric. Didier KO4BB ___ 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] GPSDO standard interface?
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.
Re: [time-nuts] GPSDO standard interface?
Gosh, all we need to do is define a nice flexible software layer between the GPSDO and the computer, etc. similar to ASCOM for astronomical telescopes. That way, the layer and all its associated drivers do all the work, and anyone's GPSDO or computer program will work if the associated drivers are available or developed. Wow what a deal... Don Mark Sims 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road Huson, MT, 59846 mail: POBox 404 Frenchtown MT 59834-0404 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ 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.
Re: [time-nuts] GPSDO standard interface?
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, hol...@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.
Re: [time-nuts] GPSDO standard interface?
http://adsabs.harvard.edu/abs/1957PhRv..105..590S Cheers, Magnus On 06/26/2014 08:13 AM, Tom Van Baak wrote: Much better than room 137. BTW, if you run into a physicist someday who can *calculate* 9192.631770 MHz directly from quantum mechanics, ask them to calculate the other isotopes of cesium. They should be different. But I have no idea how much or little. /tvb PS. At EFTF 2014 in Neuchatel, the hotel assigned me room 133, so I feel on time and stable. :) Cheers, Magnus ___ 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.
Re: [time-nuts] GPSDO standard interface?
This thread is now ready for the correct answer: http://xkcd.com/927/ /tvb ___ 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.
Re: [time-nuts] GPSDO standard interface?
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, hol...@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.
[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.
Re: [time-nuts] GPSDO standard interface?
Well, I built one of the ve2zaz units, and it has a. Pretty well defined serial interface. On the other hand, the one I use most has a PIC and an LCD, no serial interface. On Jun 25, 2014, at 20:10, Bob Stewart b...@evoria.net wrote: 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.
Re: [time-nuts] GPSDO standard interface?
I have one of Bert's boards, and in fact that's what I made my TIC daughterboard for; though of course I butchered his interface to manage PID gain, etc. So, I was thinking more along the lines of something standard and robust. I've seen Lady Heather mentioned several times as an control/monitor program, but I've never looked into it. Does it just control Trimble GPSDOs, or are there other GPSDO interfaces that it can handle? Or, has everyone just copied/adopted Trimble's interface and it's not a legal issue? Like I said, I have totally neglected this important issue until now. Bob From: bownes bow...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, June 25, 2014 7:35 PM Subject: Re: [time-nuts] GPSDO standard interface? Well, I built one of the ve2zaz units, and it has a. Pretty well defined serial interface. On the other hand, the one I use most has a PIC and an LCD, no serial interface. On Jun 25, 2014, at 20:10, Bob Stewart b...@evoria.net wrote: 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.
Re: [time-nuts] GPSDO standard interface?
On Wed, Jun 25, 2014 at 5:10 PM, Bob Stewart b...@evoria.net wrote: Is there an accepted standard interface for GPSDOs, or is that a murky Microsoft-esque world of patents and lawyers? No. There is no standard and many (most?) don't have any kind of user interface at all, just the 10MHz output BNC connector. The simple thing would be to add some kind of LED that shows activity and a second LED that indicates a lock within some acceptable limit. The Trimble unit is both a GPS receiver and a GPSDO so it has the kind of serial interface you'd expect on a GPS receiver.It would not make sense to copy this because your GPSDO will already have a GPS receiver that will be sending status and accepting commands. One is you likely do NOT want is to force the user to have to connect a PC in order to operate the user interface. Much better to use a self contained $5 LCD display. It is very easy to add a text-only LCD to most any project that uses a micro controller and it is not much harder to add a graphical LCD of the type used on older cell phones. These can do graphics. -- 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.
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] GPSDO standard interface?
There is no standard interface for GPSDOs, but the Trimble TSIP interface as used by the Thunderbolt/Lady Heather would be an excellent place to start and include. Make the unit smart enough to run unattended, but add enough monitoring commands so Lady Heather, etc can be used to monitor and tweak it... it will save you a lot of work and Lady Heather's graphing and logging features provide great insights into its operation, performance, and quirks. ___ 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.
Re: [time-nuts] GPSDO standard interface?
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.
