Re: [time-nuts] 1PPS users?
Hi Scott, I do understand the reasons that these users want this quality of output. It's who these users are, what fields, industries, etc, that I didn't quite understand. Bob - AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info From: Scott Stobbe To: Bob Stewart ; Discussion of precise time and frequency measurement Sent: Sunday, December 18, 2016 8:22 PM Subject: Re: [time-nuts] 1PPS users? Part of the reason 1PPS needs to be so clean is because you are continuously integrating phase noise of the LO (hopefully an OCXO). While 10 uS is pretty trivial off a gps receiver. Without gps, 10 us over 24 hrs with a plane jane AT-cut crystal subject environmental dynamics becomes ludicrous. More than likely the short term stability of GPSDO is cleaner than it needs to be for many applications, but that is so holdover over an hour or day remains reasonable. On Sun, Dec 18, 2016 at 6:16 PM, Bob Stewart wrote: One thing I've never really understood is who actually uses the high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on developing my GPSDO without a whole of thought to the user base. It was just a quest for the best result I could obtain with a particular technology. The frequency standard users was a no brainer. Everyone who wants a frequency standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good frequency standard. And then Tom prodded me a bit and showed me the shortcomings of what I was doing, and I did something about it. So, if an NTP user can get his time fix directly from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS pulse? Bob - AE6RV - -- -- AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/ GFS-GPSDOs/info __ _ 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] Lady Heather for homebrew GPSDO
Heather can pretty much do that now. It has the ability to do screen dumps to a file (or series of files) on a scheduled basis. Heather doesn't do the "spit out an html file thing", but I know of several people that have scripts on their machine that take the screen dump images and serve them up on the web. That way they can format/process/display the images in their desired form. Heather can also dump log files on a scheduled basis and those can be read, processed, served, and displayed however one wants. > If Mark is looking for a winter project, he can turn LH into this: https://www.realhamradio.com/GPS_websites_list.htm ___ 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] Lady Heather for homebrew GPSDO
Hi Jim, > --The EFC value is given as an integer percent -100 to 100, so there is not > enough resolution to really tell what the DAC is doing. Sounds like you're using :DIAG:ROSC:EFC:REL? which gives percent. Instead try :DIAG:ROSC:EFC:ABS? which gives absolute DAC value. > -- It does not have the satellite position and C/N data that is reported in > the NMEA GSV sentence, so LH can't make its nice satellite plots. Use the SS column of :SYST:STAT? for this. Remember before LH there was GPScon. See tons of information on the Z3801A at: https://www.realhamradio.com/GPS_Frequency_Standard.htm This random one has nice examples of what you can do given the data from SCPI: https://www.realhamradio.com/z3801a-turning-point.htm If Mark is looking for a winter project, he can turn LH into this: https://www.realhamradio.com/GPS_websites_list.htm /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.
[time-nuts] Lady Heather for homebrew GPSDO
The Z3801A does have a request for getting/setting the DAC value as a absolute (hex) number. Heather uses the percentage version of the message. Neither format tells you what you really want to know... the actual DAC voltage. There is nothing to prevent you from sending a DAC percentage with 10 digit resolution... Heather gets the Z3801A satellite position/signal level info by requesting the "SYST:STAT?" message once a minute at xx:xx:33 and parsing out the values from the status screen (ugh... another reason the Z3801A was never intended to have a computer monitor and control it). This takes the receiver 3 seconds to send. During that time no time codes, etc come in and you can't request any other information. At least the device has a (kludgy) way of getting the information... the Datum StarLoc II says all sats are at az/el 0,0 ... at least it does give a signal level. - > --The EFC value is given as an integer percent -100 to 100, so there is not enough resolution to really tell what the DAC is doing. -- It does not have the satellite position and C/N data that is reported in the NMEA GSV sentence, so LH can't make its nice satellite plots. ___ 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] 1PPS users?
preilley_...@comcast.net said: > I would like to get better than the +-10 nS that the better receivers > provide. A GPSDO generally avoids the sawtooth offset. -- These are my opinions. I hate spam. ___ 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] 1PPS users?
Part of the reason 1PPS needs to be so clean is because you are continuously integrating phase noise of the LO (hopefully an OCXO). While 10 uS is pretty trivial off a gps receiver. Without gps, 10 us over 24 hrs with a plane jane AT-cut crystal subject environmental dynamics becomes ludicrous. More than likely the short term stability of GPSDO is cleaner than it needs to be for many applications, but that is so holdover over an hour or day remains reasonable. On Sun, Dec 18, 2016 at 6:16 PM, Bob Stewart wrote: > One thing I've never really understood is who actually uses the > high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, > and money on developing my GPSDO without a whole of thought to the user > base. It was just a quest for the best result I could obtain with a > particular technology. The frequency standard users was a no brainer. > Everyone who wants a frequency standard eventually understands they need to > get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good > frequency standard. And then Tom prodded me a bit and showed me the > shortcomings of what I was doing, and I did something about it. So, if an > NTP user can get his time fix directly from a noisy receiver, who actually > needs a time-accurate, low jitter 1PPS pulse? > Bob - AE6RV > - > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > ___ > 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] Performance of TDC7200
Hi Thanks for the info. The fpga baesed TDC is something I am interested in. However, I am a beginner of fpga programming. Maybe next year I will spend sometime study this project. VHDL is quite difficult for a C programmer :(. Regards Li Ang BI7LNQ ---Original--- From: "Attila Kinali" Date: 2016/12/16 02:00:32 To: "Discussion of precise time and frequency measurement"; Subject: Re: [time-nuts] Performance of TDC7200 On Fri, 9 Dec 2016 21:29:34 +0800 "Li Ang" <379...@qq.com> wrote: > I've done some tests with TDC7200 and TDC_GP22 few months > ago.(https://www.febo.com/pipermail/time-nuts/2016-May/098170.html) Thanks for the report. It's interesting to see that the TDC7200 performs slightly better than the GP22. BTW: If you are using a large FPGA like the EP4CE22, then you might want to consider using it directly as a TDC. You can fit four ring oscillator based TDC easily and have more than enough space for your control logic (we did a 4 TDC system with an NIOS2 core and some glue and still had space spare). The bin with is in the order of 22ps, with excursions up to 100ps. The code we used was based on the tdc-core by CERN[1] and can be found on my git server [2]. Special thanks to Florian Huemer who got it working properly. Attila Kinali [1] http://www.ohwr.org/projects/tdc-core/wiki [2] http://git.kinali.ch/attila/nios2_clocksync/tree/master/fpga/cores/tdc -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ 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] Lady Heather for homebrew GPSDO
On Sun, Dec 18, 2016 at 1:06 PM, Mark Sims wrote: > Binary or NMEA you need routines like send_msg_start, send item (like > integer, float, double), send_msg_end. For received messages you need > things like get_message, get_item_from_message, etc. The code to do that > is not much more complicated for a binary protocol or an ASCII one like > NMEA. > One factor that leads me to prefer NMEA is that my GPS already produces it, so all I would have to do for the satellite, time, and other GPS data would be to send the NMEA sentences from the GPS to the host port, no parsing and reformatting required. In order to inject GPSDO data into this stream, I would have to implement an NMEA multiplexer and construct the new sentence(s) as you describe above.Of course I would still need an NMEA parser in order to interpret commands from the host, but in the Arduino world there is TinyGPS++, a very handy open source library for this. I see that although the Z3801A's SCPI messages would be pretty easy to implement, there are several inconvenient or limiting aspects to this interface. (please correct me if I am wrong on these) --It does not stream data the way NMEA does, so the host has to keep asking for data. --As has been mentioned earlier, most of the responses have no identifier, so both ends have to be careful not to get out of sync. --The EFC value is given as an integer percent -100 to 100, so there is not enough resolution to really tell what the DAC is doing. -- It does not have the satellite position and C/N data that is reported in the NMEA GSV sentence, so LH can't make its nice satellite plots. One thing I like about the Z3801A's format is the way the TCOD message includes brief status and alarm information, so the data doesn't get clogged with routine data but the host can tell when to request detailed information. -- --Jim Harman ___ 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] 1PPS users?
There was a discussion here a while ago about synchronizing radio telescopes that were separated by some miles. The 1PPS from GPS was suggested as a possibility. I am working on a project to do location by triangulation that uses the 1PPS signal. I would like to get better than the +-10 nS that the better receivers provide. Pete. On 12/18/2016 6:16 PM, Bob Stewart wrote: One thing I've never really understood is who actually uses the high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on developing my GPSDO without a whole of thought to the user base. It was just a quest for the best result I could obtain with a particular technology. The frequency standard users was a no brainer. Everyone who wants a frequency standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good frequency standard. And then Tom prodded me a bit and showed me the shortcomings of what I was doing, and I did something about it. So, if an NTP user can get his time fix directly from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS pulse? Bob - AE6RV - AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info ___ 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] 1PPS users?
For amateur use, PPS comparison requires less equipment and can be more accurate than trying to measure RF rates like 10 MHz. When comparing two PPS signals, phase slips are very infrequent so you can observe drift rate over minutes/hours/days with an oscilloscope or simple time interval counter to get much better resolution than most frequency counters can provide. (Of course, a GPS works as well for this as a GPSDO, albeit with more short term jitter.) John On 12/18/2016 08:33 PM, Bob Stewart wrote: Hi Jim, Thanks Jim, So, what I'm seeing so far, assuming I'm interpreting it correctly, is big budget commercial and government applications, generally clustering around time-controlled multiplexing, as well as the niche that is the space industry. Then there's the hobbyist, such as Eric who wants to control a Fedchenko clock, or similar type of application, such as whatever sort of spread spectrum that ham radio may morph into, or perhaps the low S/N EME guys. Any others? Bob From: jimlux To: time-nuts@febo.com Sent: Sunday, December 18, 2016 6:56 PM Subject: Re: [time-nuts] 1PPS users? On 12/18/16 3:16 PM, Bob Stewart wrote: One thing I've never really understood is who actually uses the high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on developing my GPSDO without a whole of thought to the user base. It was just a quest for the best result I could obtain with a particular technology. The frequency standard users was a no brainer. Everyone who wants a frequency standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good frequency standard. And then Tom prodded me a bit and showed me the shortcomings of what I was doing, and I did something about it. So, if an NTP user can get his time fix directly from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS pulse? Anyone who needs to trigger events at a precise time or log the occurrence of an event uses the 1 pps - the serial port (or other interface) gives you the "at the tone the time will be" message, and the edge of the 1pps is the "tone". I've got several systems flying in space (or soon to fly in space) that use the 1pps from GPS to calibrate their internal clocks and/or to provide an absolute time reference (along with the aforesaid time message). For example, one needs to have your carrier frequency within a certain tolerance for communications with the ground stations: you can either fly a precision oscillator with an oven (big, heavy, high power) or you can measure a not-so-precision oscillator (small, cheap, low power) against a 1pps, and adjust your frequency that way. I grant you that this is really more like *building* a GPSDO than *using* a GPSDO. I've used the 1pps from a GPSDO as a common trigger to synchronize timing and timestamping for separate systems. ___ 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.
Re: [time-nuts] HP Z3801a piezo oscillator does work
Bob I think Mark was suggesting that. As I explained its a odd package. Regards Paul WB8TSL On Sun, Dec 18, 2016 at 7:13 PM, Bob Camp wrote: > Hi > > Can you pull the crystal? sure. > > Does your MV-89 have a 5 MHz crystal (the frequency doubled version) or a > 10 MHz crystal? (sub harmonics viewed on a > spectrum analyzer are a really good way to tell). > > Is the crystal the same size / pinout? Probably not. HP used an odd > package. You might be able to make a spacer. > > Will it hit the right frequency? Likely not without changing some parts …. > > Bob > > > > On Dec 18, 2016, at 5:55 PM, Mark Sims wrote: > > > > I have a wonky Morian MV-89... probably the well know output cap > failure. I wonder if one could pull the crystal out of that and stick in > the HP10811? Something tells me Bob would know ;-) > > ___ > > 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.
Re: [time-nuts] 1PPS users?
Hi Jim, Thanks Jim, So, what I'm seeing so far, assuming I'm interpreting it correctly, is big budget commercial and government applications, generally clustering around time-controlled multiplexing, as well as the niche that is the space industry. Then there's the hobbyist, such as Eric who wants to control a Fedchenko clock, or similar type of application, such as whatever sort of spread spectrum that ham radio may morph into, or perhaps the low S/N EME guys. Any others? Bob From: jimlux To: time-nuts@febo.com Sent: Sunday, December 18, 2016 6:56 PM Subject: Re: [time-nuts] 1PPS users? On 12/18/16 3:16 PM, Bob Stewart wrote: > One thing I've never really understood is who actually uses the high-quality > 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on > developing my GPSDO without a whole of thought to the user base. It was just > a quest for the best result I could obtain with a particular technology. The > frequency standard users was a no brainer. Everyone who wants a frequency > standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. > And that's all I thought I had: a good frequency standard. And then Tom > prodded me a bit and showed me the shortcomings of what I was doing, and I > did something about it. So, if an NTP user can get his time fix directly > from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS > pulse? Anyone who needs to trigger events at a precise time or log the occurrence of an event uses the 1 pps - the serial port (or other interface) gives you the "at the tone the time will be" message, and the edge of the 1pps is the "tone". I've got several systems flying in space (or soon to fly in space) that use the 1pps from GPS to calibrate their internal clocks and/or to provide an absolute time reference (along with the aforesaid time message). For example, one needs to have your carrier frequency within a certain tolerance for communications with the ground stations: you can either fly a precision oscillator with an oven (big, heavy, high power) or you can measure a not-so-precision oscillator (small, cheap, low power) against a 1pps, and adjust your frequency that way. I grant you that this is really more like *building* a GPSDO than *using* a GPSDO. I've used the 1pps from a GPSDO as a common trigger to synchronize timing and timestamping for separate systems. ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
drkir...@kirkbymicrowave.co.uk said: > I assume it wont start until it has tracked sufficient number of satellites. There is a chicken-egg problem with getting started. The satellites tell you where they are, but you need to know where they are and where you are in order to calculate the Doppler offset so you know what frequency to listen to. The difference between warm start and cold start is that for a warm start the receiver has a 32KHz clock and has saved its last position and the satellite orbit data in battery backed RAM. -- These are my opinions. I hate spam. ___ 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] 1PPS users?
Who uses 1PPS? In industry they are used to phase lock various oscillators. I would bet most of those oscillators are used in the telecommunications industry both for bit rate clocks and for carrier frequency synthesis. We also see a lot of 1 PPS used for NTP servers that in turn are used to keep computer internal time of day clocks running at the correct rate. On Sun, Dec 18, 2016 at 3:16 PM, Bob Stewart wrote: > One thing I've never really understood is who actually uses the > high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, > and money on developing my GPSDO without a whole of thought to the user > base. It was just a quest for the best result I could obtain with a > particular technology. The frequency standard users was a no brainer. > Everyone who wants a frequency standard eventually understands they need to > get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good > frequency standard. And then Tom prodded me a bit and showed me the > shortcomings of what I was doing, and I did something about it. So, if an > NTP user can get his time fix directly from a noisy receiver, who actually > needs a time-accurate, low jitter 1PPS pulse? > Bob - AE6RV > - > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > ___ > 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] HP Z3801a piezo oscillator does work
Hi Can you pull the crystal? sure. Does your MV-89 have a 5 MHz crystal (the frequency doubled version) or a 10 MHz crystal? (sub harmonics viewed on a spectrum analyzer are a really good way to tell). Is the crystal the same size / pinout? Probably not. HP used an odd package. You might be able to make a spacer. Will it hit the right frequency? Likely not without changing some parts …. Bob > On Dec 18, 2016, at 5:55 PM, Mark Sims wrote: > > I have a wonky Morian MV-89... probably the well know output cap failure. I > wonder if one could pull the crystal out of that and stick in the HP10811? > Something tells me Bob would know ;-) > ___ > 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] HP Z3801a piezo oscillator does work
Mark I tend to agree with you on Bob. But that said the 10811 crystal is a bit odd. Its actually a copper cylinder with a screw on top. I believe to insure correct even heat distribution. There are pix's of it on one of the sights. Maybe the crystal comes out of the copper. The 10811 used in the Z3801 is a bit different from standard 10811 in the tuning sensitivity and I may believe that stability of the steps. But thats a guess. Some of the sites mention this. My goal was to simply confirm the rest of the 3801 boards were good and it is. So I have a spare for my operating 3801. Though it seems to be doing a fair job as compared to a TBolt I am using as a reference. I have messed with the bad 10811 checking caps, resitors, and temperature and its still 50 Hz low. May dive back into that though I have exhausted pretty much anything thats possible. Need to clean things up by a lot. Then go searching for the com ports stalls that sort of started this journey. Regards Paul WB8TSL On Sun, Dec 18, 2016 at 5:55 PM, Mark Sims wrote: > I have a wonky Morian MV-89... probably the well know output cap failure. > I wonder if one could pull the crystal out of that and stick in the > HP10811? Something tells me Bob would know ;-) > ___ > 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] 1PPS users?
Speaking as an owner of a well-behaved mechanical clock: Clock rate performance over time can be done based on time interval measurements anchored to a solid frequency standard. No 1pps needed per se. Bring a clock to time is simplified with a timescale-accurate 1pps source. > On 2016 Dec 18, at 18:16 , Bob Stewart wrote: > > One thing I've never really understood is who actually uses the high-quality > 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on > developing my GPSDO without a whole of thought to the user base. It was just > a quest for the best result I could obtain with a particular technology. The > frequency standard users was a no brainer. Everyone who wants a frequency > standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. > And that's all I thought I had: a good frequency standard. And then Tom > prodded me a bit and showed me the shortcomings of what I was doing, and I > did something about it. So, if an NTP user can get his time fix directly > from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS > pulse? > 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] 1PPS users?
Hi Roughly 99% of all GPSDO’s are only used for the PPS output. They go into cell sites and the reason they exist is to sync up the Gold Codes on CDMA. That’s also why you see a *lot* of PPS only Rb’s on the surplus market. The ones that don’t get used for cell towers, mostly go into other com systems that for some reason need to have accurate time (also involves codes …). Bob > On Dec 18, 2016, at 6:16 PM, Bob Stewart wrote: > > One thing I've never really understood is who actually uses the high-quality > 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on > developing my GPSDO without a whole of thought to the user base. It was just > a quest for the best result I could obtain with a particular technology. The > frequency standard users was a no brainer. Everyone who wants a frequency > standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. > And that's all I thought I had: a good frequency standard. And then Tom > prodded me a bit and showed me the shortcomings of what I was doing, and I > did something about it. So, if an NTP user can get his time fix directly > from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS > pulse? > Bob - AE6RV > - > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > ___ > 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] 1PPS users?
On 12/18/16 3:16 PM, Bob Stewart wrote: One thing I've never really understood is who actually uses the high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on developing my GPSDO without a whole of thought to the user base. It was just a quest for the best result I could obtain with a particular technology. The frequency standard users was a no brainer. Everyone who wants a frequency standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good frequency standard. And then Tom prodded me a bit and showed me the shortcomings of what I was doing, and I did something about it. So, if an NTP user can get his time fix directly from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS pulse? Anyone who needs to trigger events at a precise time or log the occurrence of an event uses the 1 pps - the serial port (or other interface) gives you the "at the tone the time will be" message, and the edge of the 1pps is the "tone". I've got several systems flying in space (or soon to fly in space) that use the 1pps from GPS to calibrate their internal clocks and/or to provide an absolute time reference (along with the aforesaid time message). For example, one needs to have your carrier frequency within a certain tolerance for communications with the ground stations: you can either fly a precision oscillator with an oven (big, heavy, high power) or you can measure a not-so-precision oscillator (small, cheap, low power) against a 1pps, and adjust your frequency that way. I grant you that this is really more like *building* a GPSDO than *using* a GPSDO. I've used the 1pps from a GPSDO as a common trigger to synchronize timing and timestamping for separate systems. ___ 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] 1PPS users?
b...@evoria.net said: > So, if an NTP user can get his time fix directly from a noisy receiver, who > actually needs a time-accurate, low jitter 1PPS pulse? Most kernels have an option to capture a time stamp from a PPS signal at interrupt time. That is much more accurate than the timing you get from user mode on a serial data stream. There is also a mode where the whole NTP PLL processing is done in the kernel. I don't see why that should make as much of a difference as it does, but I haven't tracked down the details. (It's not in the typical Linux kernel. You have to build your own.) Most low cost GPS receivers have crappy timing on the serial port. Really crappy. It wanders with a time scale of hours so you can't filter out the jitter by averaging for a minute or two. PPS on that sort of unit makes it much more interesting. -- These are my opinions. I hate spam. ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
It is looking much better now. I 1) Powered off 2) Left off for 30 s 3) Pulled antenna out. 4) Powered on 5) Connected antenna, making sure if was firmly screwed in. It then got GPS lock in a few minutes. It is running at reduced accuracy, with the survey only 9.7% complete, but it is looking more hopeful. I can't help feeling there should have been more informative status available by the LEDs. The fact it is locked, but at reduced accuracy, should really be visable from the front panel IMHO. Anyway, it seems to be getting there - see below. scpi > SYSTEM:STATUS? --- Receiver Status --- SYNCHRONIZATION [ Outputs Valid/Reduced Accuracy ] SmartClock Mode ___ Reference Outputs ___ >> Locked to GPS: stabilizing frequency TFOM 3 FFOM 1 Recovery 1PPS TI -15.9 ns relative to GPS Holdover HOLD THR 1.000 us Power-up Holdover Uncertainty Predict 432.0 us/initial 24 hrs ACQUISITION [ GPS 1PPS Valid ] Tracking: 6 Not Tracking: 3 Time _ +1 leap second pending PRN El Az SS PRN El AzUTC 22:39:23 18 Dec 2016 2 28 87 86 6 20 48GPS 1PPS Synchronized to UTC 12 57 70 11924 24 137ANT DLY 0 ns 14 39 287 10631 27 303Position 25 76 284 96 MODE Survey:9.7% complete 29 37 194 79 32 39 249 109 AVG LAT N 51:39:04.205 AVG LON E 0:46:36.347 ELEV MASK 10 deg AVG HGT +42.42 m (MSL) HEALTH MONITOR . [ OK ] Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK scpi > ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
On 18 December 2016 at 18:19, Dan Rae wrote: > On 12/18/2016 9:34 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > >> >> *12 -- ---MODE Survey: 0% >> complete >> >> > If it's still showing that after being on for five hours, maybe it needs > to be explicitly told to start a survey? > > dr > I seem to be having some issues now with this. I've reset it, and entered the approximate latitude, longitude, height, as well as date and time. The commands below were executed, although NOT necessarily in the order give. E-113> GPS:INIT:DATe 2016,12,18 E-113> gps:init:time 19,18,35 E-113> SYSTEM:PRESET scpi > DIAG:LOG:READ:ALL? Log status: 2 entries Log 001:19970504.00:00:00: Log cleared Log 002:19970504.00:00:00: System preset The receiver seems to find satellites fairly quickly, tries to track them, and is showing reasonable values for the things I set, like date, time, position etc. However, the receiver doesn't seem able to track any satellites, so not surprisingly the survey never starts. I assume it wont start until it has tracked sufficient number of satellites. scpi > SYSTEM:STATUS? --- Receiver Status --- SYNCHRONIZATION ... [ Outputs Invalid ] SmartClock Mode ___ Reference Outputs ___ Locked TFOM 9 FFOM 3 Recovery 1PPS TI -- Holdover HOLD THR 1.000 us >> Power-up: GPS acquisition Holdover Uncertainty Predict -- ACQUISITION .. [ GPS 1PPS Invalid ] Tracking: 0 Not Tracking: 12 ___ Time PRN El Az PRN El Az UTC 21:57:41 [?] 18 Dec 2016 6 20 67 12 76 56 GPS 1PPS Invalid: not tracking * 7 -- --- 14 32 307 ANT DLY 0 ns * 8 -- --- 24 42 129 Position * 9 -- --- 25 58 259 MODE Survey: 0% complete *10 -- --- *31 10 299Suspended: track <4 sats *11 -- --- 32 45 274 INIT LAT N 51:39:03.825 INIT LON E 0:46:36.277 ELEV MASK 10 deg *attempting to track INIT HGT +29.99 m (MSL) HEALTH MONITOR . [ OK ] Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK It will run overnight. Perhaps tomorrow it will sort itself out, but I'm not too hopeful. Dr. David Kirkby Ph.D CEng MIET Kirkby Microwave Ltd Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT, UK. Registered in England and Wales, company number 08914892. http://www.kirkbymicrowave.co.uk/ Tel: 07910 441670 / +44 7910 441670 (0900 to 2100 GMT only please) ___ 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] 1PPS users?
One thing I've never really understood is who actually uses the high-quality 1PPS output from a GPSDO. I have spent a lot of time, effort, and money on developing my GPSDO without a whole of thought to the user base. It was just a quest for the best result I could obtain with a particular technology. The frequency standard users was a no brainer. Everyone who wants a frequency standard eventually understands they need to get a GPSDO, or an Rb, or a Cs. And that's all I thought I had: a good frequency standard. And then Tom prodded me a bit and showed me the shortcomings of what I was doing, and I did something about it. So, if an NTP user can get his time fix directly from a noisy receiver, who actually needs a time-accurate, low jitter 1PPS pulse? Bob - AE6RV - AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info ___ 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] HP Z3801a piezo oscillator does work
I have a wonky Morian MV-89... probably the well know output cap failure. I wonder if one could pull the crystal out of that and stick in the HP10811? Something tells me Bob would know ;-) ___ 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] HP Z3801a piezo oscillator does work
OK the 10 MHz Piezo oscillator from a lucent RC/xtal pair does work and the 3801 is doing what it should. Some insights as mentioned. 3801 DAC being full scale is not an issue when a good signal within 2 HZ is used it will come out of limit. The DAC output was driving the piezo far to widely I added a 10:1 V antennuator to reduce the swing. The piezo requires a positive only EFC and its control is inverted as compared to the HP 10811. Used a single TL071 opamp to invert the signal and apply the offset. By calculations it should have been offset to 3.6V but the system seems to want 2.5V. Pretty sure an adjustment on the actual oscillator would fix that. I can now see that something like an RB could be plugged into the 3801 etc. But more important the proof is that the actual Z3801 is fully functional and the only bad thing is a the HP 10811 oscillator. Its been a great learning exercise. How to get rid of teh outer oven. How to use far simpler power supplies to run the 3801 instead of the 48 volt mess. Overall a lower power consumption solution can be built. Regards Paul WB8TSL ___ 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] Lady Heather for homebrew GPSDO
If you go digging in the Ladt Heather code, you will find references to a "luxor" device. This is a LED / power analyzer device that I built. It runs on a ATMEGA 2561 and uses the TSIP protocol. I've also implemented the same TSIP protocol code on a '328 with 32kB of program memory. It's not that hard to do. At the lowest level it doesn't take much more code than a NMEA processor. The code sends and receives properly formatted TSIP sentences. What gets really fiddly is all the details of trying to faithfully emulate an existing GPSDO. Binary or NMEA you need routines like send_msg_start, send item (like integer, float, double), send_msg_end. For received messages you need things like get_message, get_item_from_message, etc. The code to do that is not much more complicated for a binary protocol or an ASCII one like NMEA. Binary messages have the little complication of what byte ordering does the CPU and protocol use. Heather has a find_endian routine that determines the CPU ordering for getting values from the received messages and re-ordering the bytes to what the CPU expects and the output routines reformat CPU values into the byte order that the receiver wants. > Writing and *debugging* a binary protocol is a lot more involved than a > serial stream. You can argue that code it code and it’s all trivial. ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
On 12/18/2016 9:34 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: *12 -- ---MODE Survey: 0% complete If it's still showing that after being on for five hours, maybe it needs to be explicitly told to start a survey? dr ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
On 18 December 2016 at 14:31, Tim Shoppa wrote: > A common misconception, is that holdover is the opposite of GPS lock. > Sometimes we might even talk about the two as if we're in one or the other. > But really the power-on state, is that we're in neither holdover or GPS > lock. > > Holdover means the smartclock previously had GPS lock and had used it to > characterize the aging of the OCXO, and is maintaining the EFC > extrapolation, such that it believes it can still produce accurate time and > frequency through the GPS loss. > > The state of your clock at the moment, is that it has never had GPS lock > since regaining power, it does not know what time it is, and it has not > characterized or extrapolated the aging of the OCXO. So it is definitely > not in holdover. > > Tim N3QE > Cheers Tim, that makes sense. I'm a bit concerned it has not managed to track a single satellite, despite it has been on 5 hours or so. But perhaps things have improved, as its not attempting to track 6 (PRN=15, 2, 21, 25, 26 and 28), whereas before it was attempting to track just with a PRN of 32. I'm hoping its current status (see below), is looking more hopeful than what it was before. scpi > scpi > SYSTEM:STATUS? --- Receiver Status --- SYNCHRONIZATION ... [ Outputs Invalid ] SmartClock Mode ___ Reference Outputs ___ Locked TFOM 9 FFOM 3 Recovery 1PPS TI -- Holdover HOLD THR 1.000 us >> Power-up: GPS acquisition Holdover Uncertainty Predict -- ACQUISITION .. [ GPS 1PPS Invalid ] Tracking: 0 Not Tracking: 6 Time _ +1 leap second pending PRN El AzUTC 14:43:22 [?] 01 Jan 1998 *15 -- ---GPS 1PPS Invalid: not tracking *20 -- ---ANT DLY 0 ns *21 -- ---Position *25 -- ---MODE Survey: 0% complete *26 -- --- Suspended: track <4 sats *28 -- ---INIT LAT N 51:39:03.825 INIT LON E 0:46:36.278 ELEV MASK 10 deg *attempting to track INIT HGT -14.04 m (MSL) HEALTH MONITOR . [ OK ] Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK scpi > SYSTEM:STATUS? --- Receiver Status --- SYNCHRONIZATION ... [ Outputs Invalid ] SmartClock Mode ___ Reference Outputs ___ Locked TFOM 9 FFOM 3 Recovery 1PPS TI -- Holdover HOLD THR 1.000 us >> Power-up: GPS acquisition Holdover Uncertainty Predict -- ACQUISITION .. [ GPS 1PPS Invalid ] Tracking: 0 Not Tracking: 6 Time _ +1 leap second pending PRN El AzUTC 16:59:08 [?] 01 Jan 1998 * 8 -- ---GPS 1PPS Invalid: not tracking *10 -- ---ANT DLY 0 ns *11 -- ---Position *12 -- ---MODE Survey: 0% complete *13 -- --- Suspended: track <4 sats *30 -- ---INIT LAT N 51:39:03.825 INIT LON E 0:46:36.278 ELEV MASK 10 deg *attempting to track INIT HGT -14.04 m (MSL) HEALTH MONITOR . [ OK ] Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
On 18 December 2016 at 17:34, Dr. David Kirkby (Kirkby Microwave Ltd) < drkir...@kirkbymicrowave.co.uk> wrote: > But perhaps things have improved, as its not attempting to track 6 > (PRN=15, 2, 21, 25, 26 and 28), whereas before it was attempting to track > just with a PRN of 32. I'm hoping its current status (see below), is > looking more hopeful than what it was before. > I mean it is NOW attempting to track 6 !!! Almost the opposite of what I wrote. I'm guessing it gave up attempting to track the satellite with a PRN of 32. Dave ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
A common misconception, is that holdover is the opposite of GPS lock. Sometimes we might even talk about the two as if we're in one or the other. But really the power-on state, is that we're in neither holdover or GPS lock. Holdover means the smartclock previously had GPS lock and had used it to characterize the aging of the OCXO, and is maintaining the EFC extrapolation, such that it believes it can still produce accurate time and frequency through the GPS loss. The state of your clock at the moment, is that it has never had GPS lock since regaining power, it does not know what time it is, and it has not characterized or extrapolated the aging of the OCXO. So it is definitely not in holdover. Tim N3QE On Sun, Dec 18, 2016 at 8:01 AM, Dr. David Kirkby (Kirkby Microwave Ltd) < drkir...@kirkbymicrowave.co.uk> wrote: > My 58503 GPS time/frequency reference had its power disconnected a few > times yesterday as I moved things in the lab. At the modem the status of > the LEDs are > > * Power green > * GPS lock - not lit > * Holdover - not lit > * Alarm - not lit. > > That is what the manual says will happen when power is first applied, but > I'm puzzled why. > > The SYSTEM:STATUS? shows the information at the end of this email. What I > can't understand is why the holdover light is not lit, when clearly its not > tracking any satellites. It seems logical to me that holdover should be on, > when GPS lock is not, and visa versa. But that does not seem to be the > case. > > Looking at the data below, the date/time is obviously wrong (01 Jan 1998), > the height at -14.04 m (MSL) is wrong, but latitude and longitude look > about right, although they are certainly not exactly agreeing with Google > maps, which show 51°39'04.1"N+0°46'36.4"E. > > I must be misunderstanding the purpose of these lights. > > I'm also a bit puzzled it has been on about 1.5 hours, and can't seem to > find a single satellite. The antenna is fairly clear of anything else, and > it was certainly working yesterday, with the power and GPS lock LEDs both > lit. > > Any ideas what's going on? > > scpi > SYSTEM:STATUS? > --- Receiver Status > --- > > SYNCHRONIZATION ... [ Outputs > Invalid ] > SmartClock Mode ___ Reference Outputs > ___ >Locked TFOM 9 > FFOM 3 >Recovery 1PPS TI -- >Holdover HOLD THR 1.000 us > >> Power-up: GPS acquisition Holdover Uncertainty > > Predict -- > > ACQUISITION .. [ GPS 1PPS > Invalid ] > Tracking: 0 Not Tracking: 1 Time _ +1 leap second > pending >PRN El AzUTC 12:59:16 [?] 01 Jan > 1998 >*32 -- ---GPS 1PPS Invalid: not > tracking > ANT DLY 0 ns > Position > > MODE Survey: 0% > complete >Suspended: track <4 > sats > INIT LAT N 51:39:03.825 > INIT LON E 0:46:36.278 > ELEV MASK 10 deg *attempting to track INIT HGT -14.04 m > (MSL) > HEALTH MONITOR . [ > OK ] > Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: > OK > scpi > > > > > Dr. David Kirkby Ph.D CEng MIET > Kirkby Microwave Ltd > Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT, > UK. > Registered in England and Wales, company number 08914892. > http://www.kirkbymicrowave.co.uk/ > Tel: 07910 441670 / +44 7910 441670 (0900 to 2100 GMT only please) > ___ > 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
I believe the "Holdover" function only occurs when you you loose just the satellites Once locked disconnect the antenna for a minute and you will see the holdover LED light. IF the unit looses POWER it has no way of of powering the oscillator and its ovens ( to do a holdover) and has no way of knowing how long the unit has been off when re-powered until it goes through a complete acquisition/re-sync cycle. DAVE manu...@artekmanuals.com On 12/18/2016 8:01 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: My 58503 GPS time/frequency reference had its power disconnected a few times yesterday as I moved things in the lab. At the modem the status of the LEDs are * Power green * GPS lock - not lit * Holdover - not lit * Alarm - not lit. That is what the manual says will happen when power is first applied, but I'm puzzled why. The SYSTEM:STATUS? shows the information at the end of this email. What I can't understand is why the holdover light is not lit, when clearly its not tracking any satellites. It seems logical to me that holdover should be on, when GPS lock is not, and visa versa. But that does not seem to be the case. Looking at the data below, the date/time is obviously wrong (01 Jan 1998), the height at -14.04 m (MSL) is wrong, but latitude and longitude look about right, although they are certainly not exactly agreeing with Google maps, which show 51°39'04.1"N+0°46'36.4"E. I must be misunderstanding the purpose of these lights. I'm also a bit puzzled it has been on about 1.5 hours, and can't seem to find a single satellite. The antenna is fairly clear of anything else, and it was certainly working yesterday, with the power and GPS lock LEDs both lit. Any ideas what's going on? scpi > SYSTEM:STATUS? --- Receiver Status --- SYNCHRONIZATION ... [ Outputs Invalid ] SmartClock Mode ___ Reference Outputs ___ Locked TFOM 9 FFOM 3 Recovery 1PPS TI -- Holdover HOLD THR 1.000 us Power-up: GPS acquisition Holdover Uncertainty Predict -- ACQUISITION .. [ GPS 1PPS Invalid ] Tracking: 0 Not Tracking: 1 Time _ +1 leap second pending PRN El AzUTC 12:59:16 [?] 01 Jan 1998 *32 -- ---GPS 1PPS Invalid: not tracking ANT DLY 0 ns Position MODE Survey: 0% complete Suspended: track <4 sats INIT LAT N 51:39:03.825 INIT LON E 0:46:36.278 ELEV MASK 10 deg *attempting to track INIT HGT -14.04 m (MSL) HEALTH MONITOR . [ OK ] Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK scpi > Dr. David Kirkby Ph.D CEng MIET Kirkby Microwave Ltd Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT, UK. Registered in England and Wales, company number 08914892. http://www.kirkbymicrowave.co.uk/ Tel: 07910 441670 / +44 7910 441670 (0900 to 2100 GMT only please) ___ 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. -- Dave manu...@artekmanuals.com www.ArtekManuals.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] FPGA based TDC
Hi > On Dec 18, 2016, at 7:46 AM, Attila Kinali wrote: > > On Sat, 17 Dec 2016 10:48:35 -0500 > Bob Camp wrote: > >>> Sébastian told me that for the original TDC design (based on a Spartan3 >>> IIRC) >>> they didn't employ any method for increasing the resolution by compensating >>> for different bin sizes, as they got pretty close to the minimal bin size >>> anyways. But for the Cyclone4 I guess using something like Wu's Wave >>> Union[4] >>> approach might be a good idea. Unfortunately, we didn't have the time to >>> try it. >> >> If you do go to the Wave Union, it does work on Cyclone 5’s and Spartan 6’s. >> I suspect >> it will work on the newer stuff as well. The big issue you run into is >> “decoding” the patterns >> you get. The data is *not* a nice looking set of “all zeros before” and “all >> ones after” some >> point. Figuring out which bin came first with a random calibration approach >> requires a >> bit of a leap of faith (count the zeros / count the ones) to order them. >> Even with that you >> still get bins that appear to be equivalent (same number of zeros), but have >> them in a >> different order. > > Yes, the decoding of wave union is anything but trivial. The main issue > is that the ordering of the thermometer encoded bits is not the same as > the ordering of the delay line. This is due to the badly controlled delays > within the delay line and the clock tree causing unequal capture time for > the registers. This leads to "bubbles" in the encoding. The original TDC Core > code reordered the bits according to the timing simulation results. > For the Cyclone4 we encountered the problem, that the ordering is not stable. > i.e. the ordering changes over time and is dependent on the logic > surrounding the delay line. Thus we reverted to only count the zeros/ones as > an approximation. This of course does not work with wave union and an > other scheme as to be devised. One way to do it would probably be to make > the distance between the edges long enough such that the bubles can be > matched to a single edge. Then one could count the zeros/ones in the area > around the presumed edge position. But as I have not tried this, I do not > know how well it would work in reality. It does work, but it is a bit messy. The number of “indeterminate” states starts to get a bit alarming. Without a fancy system to actually figure out what is what ( = a generator that steps off at 1 ps resolution with jitter < 0.1 ps) there is a lot of “faith”involved. You also can do the same things with multiple delay lines. The assumption is that the odd stuff will not happen at the same places. At least with my limited skills, that turned out to be a poor assumption. The problems occurred to often and they pretty much *always* lined up. The scary part is that you can come up with issues like crosstalk that can turn the system into something a bit non-random. There have to be sensitivities like that on the die. It’s just a question of if they are large enough to matter in this case … Back to shopping the auction sites for that generator. I’ve got $20 as my max bid :) Bob > > Attila Kinali > > -- > Malek's Law: >Any simple idea will be worded in the most complicated way. > ___ > 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] Lady Heather for homebrew GPSDO
Hi If your GPSDO is based on an quad core 1.8 GHz with 4 GB of RAM, you can implement a lot of things. Effectively your GPSDO has more horsepower than a lot of the computers people are using to monitor GPSDO’s. Given the economics of silicon, that’s still not a crazy expensive CPU to use. If you are trying to cram your GPSDO into a PIC 16, coming up with complex structures for the i/o is likely to be a bit of a challenge. Most of the poor little beast is already tied up trying to keep up with the main work of the device. Writing and *debugging* a binary protocol is a lot more involved than a serial stream. You can argue that code it code and it’s all trivial. It’s also been argued that coming up with a fully working GPSDO is a 10 minute project. I don’t have a GPSDO project hidden somewhere under all this junk on the bench. I’m not planning to do one any time soon. I’m just a casual observer in all this. To me dumping stuff into an already existing NMEA message parser seems to be the more universal way to go. It’s not without it’s issues. Based on doing this from scratch on a few hundred times on various devices, it’s generally been the quicker and easier way to go. It’s certainly not the only way…. Bob > On Dec 18, 2016, at 12:02 AM, Mark Sims wrote: > >> 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 -- 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] FPGA based TDC
On Sat, 17 Dec 2016 10:48:35 -0500 Bob Camp wrote: > > Sébastian told me that for the original TDC design (based on a Spartan3 > > IIRC) > > they didn't employ any method for increasing the resolution by compensating > > for different bin sizes, as they got pretty close to the minimal bin size > > anyways. But for the Cyclone4 I guess using something like Wu's Wave > > Union[4] > > approach might be a good idea. Unfortunately, we didn't have the time to > > try it. > > If you do go to the Wave Union, it does work on Cyclone 5’s and Spartan 6’s. > I suspect > it will work on the newer stuff as well. The big issue you run into is > “decoding” the patterns > you get. The data is *not* a nice looking set of “all zeros before” and “all > ones after” some > point. Figuring out which bin came first with a random calibration approach > requires a > bit of a leap of faith (count the zeros / count the ones) to order them. Even > with that you > still get bins that appear to be equivalent (same number of zeros), but have > them in a > different order. Yes, the decoding of wave union is anything but trivial. The main issue is that the ordering of the thermometer encoded bits is not the same as the ordering of the delay line. This is due to the badly controlled delays within the delay line and the clock tree causing unequal capture time for the registers. This leads to "bubbles" in the encoding. The original TDC Core code reordered the bits according to the timing simulation results. For the Cyclone4 we encountered the problem, that the ordering is not stable. i.e. the ordering changes over time and is dependent on the logic surrounding the delay line. Thus we reverted to only count the zeros/ones as an approximation. This of course does not work with wave union and an other scheme as to be devised. One way to do it would probably be to make the distance between the edges long enough such that the bubles can be matched to a single edge. Then one could count the zeros/ones in the area around the presumed edge position. But as I have not tried this, I do not know how well it would work in reality. Attila Kinali -- Malek's Law: Any simple idea will be worded in the most complicated way. ___ 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] Why is holdover LED on HP 58503A not lit, when GPS lock is unlit too?
My 58503 GPS time/frequency reference had its power disconnected a few times yesterday as I moved things in the lab. At the modem the status of the LEDs are * Power green * GPS lock - not lit * Holdover - not lit * Alarm - not lit. That is what the manual says will happen when power is first applied, but I'm puzzled why. The SYSTEM:STATUS? shows the information at the end of this email. What I can't understand is why the holdover light is not lit, when clearly its not tracking any satellites. It seems logical to me that holdover should be on, when GPS lock is not, and visa versa. But that does not seem to be the case. Looking at the data below, the date/time is obviously wrong (01 Jan 1998), the height at -14.04 m (MSL) is wrong, but latitude and longitude look about right, although they are certainly not exactly agreeing with Google maps, which show 51°39'04.1"N+0°46'36.4"E. I must be misunderstanding the purpose of these lights. I'm also a bit puzzled it has been on about 1.5 hours, and can't seem to find a single satellite. The antenna is fairly clear of anything else, and it was certainly working yesterday, with the power and GPS lock LEDs both lit. Any ideas what's going on? scpi > SYSTEM:STATUS? --- Receiver Status --- SYNCHRONIZATION ... [ Outputs Invalid ] SmartClock Mode ___ Reference Outputs ___ Locked TFOM 9 FFOM 3 Recovery 1PPS TI -- Holdover HOLD THR 1.000 us >> Power-up: GPS acquisition Holdover Uncertainty Predict -- ACQUISITION .. [ GPS 1PPS Invalid ] Tracking: 0 Not Tracking: 1 Time _ +1 leap second pending PRN El AzUTC 12:59:16 [?] 01 Jan 1998 *32 -- ---GPS 1PPS Invalid: not tracking ANT DLY 0 ns Position MODE Survey: 0% complete Suspended: track <4 sats INIT LAT N 51:39:03.825 INIT LON E 0:46:36.278 ELEV MASK 10 deg *attempting to track INIT HGT -14.04 m (MSL) HEALTH MONITOR . [ OK ] Self Test: OKInt Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK scpi > Dr. David Kirkby Ph.D CEng MIET Kirkby Microwave Ltd Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT, UK. Registered in England and Wales, company number 08914892. http://www.kirkbymicrowave.co.uk/ Tel: 07910 441670 / +44 7910 441670 (0900 to 2100 GMT only please) ___ 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] Lady Heather for homebrew GPSDO
> 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 -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.