Re: [time-nuts] comparing two clocks
Hi Jimmy, Someone touched on the idea of using a scope. Go to the Agilent site and download a copy of the 10811 manual, 10811-90002.pdf. Section 3 describes how to adjust the 10811 and gives info on how to time the phase drift to calculate the frequency error. You can pull the time base out of the back of the counter and use it as one of the inputs to the scope for this measurement. For that matter, you should be able to send the time base back into the counter for a Time Interval measurement against your other oscillator. However, that won't give you much value unless you have a GPIB adapter and can capture the time interval value over some period and make pretty phase plots and do ADEV plots. You can get useful values a lot quicker using the method in the 10811 manual. Regardless of which method you use, you will quickly wonder which clock is being measured. Once you ask that question, a GPSDO is in your future. Been There, Done That. Still doing it. Bob - AE6RV From: Jimmy Burrell jimmydb...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, February 22, 2014 7:17 AM Subject: [time-nuts] comparing two clocks I need some help with a 'noob' question regarding some practical examples in some of the NIST literature. When attempting to compare two clocks, I'm a bit confused on the subject of exactly how to use my counter to compare a delayed clock relative to another. Or perhaps I should just say 'comparing two clocks'. Let's take some concrete examples. Let's say I want to characterize my Morion MV89 ocxo using my HP5335a. Obviously, I can tune the MV89's 10MHz by +/- 1Hz and feed it to the counter's input 'A'. Obviously, I can feed in a second, external reference clock at 10MHz into input 'B'. Suppose, however, I didn't have an external reference clock. Can I compare against the counter's internal time base by hooking a line from the rear jack time base output to channel 'B' input? Or am I making it too complicated? Do I simply plug into input 'A' and go? In a somewhat related question, in this article (http://www.wriley.com/Examples%20of%201%20PPS%20Clock%20Measuring%20Systems.pdf) where two clocks, both divided to 1PPS, were compared, W.Riley makes the following statement, The two 1 PPS outputs were connected to a Racal Dana 1992 time internal counter having 1 nanosecond resolution, and the start and stop signals were separated sufficiently in time for the counter to function properly. I wonder what exactly is meant by separated sufficiently in time for the counter to function properly and how one would go about doing this? For example, is inverting one of the signals sufficient separation? If not, how is this typically done? Delay line? Thank you, Jim... N5SPE ___ 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] Thermal Compensation: Digital vs Analog
I've been experimenting with digital thermal compensation on my GPSDO. The results have been favorable for a 14 bit dithered PWM-based DAC, but leaves a bit to be desired in the big picture. And it takes up a lot of program bytes on my PIC.. What's the general consensus on this? Should thermal compensation be completely analog? 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] Thermal Compensation: Digital vs Analog
Hi Atilla, The GPSDO is VE2ZAZ's circuit with new code. It detects phase crossings to change the DAC, so it has a phase crossing for every update. I'm working on a TIC design but haven't started on the hardware. In the interim, I hooked up an LM34 thermistor and have been playing with that. In the 8 hour plot below, there are no frequency updates, only temperature updates. I've tried a rolling average, but it doesn't smooth it enough, so I'll have to try hysteresis next. The orange/green/blue line is the DAC. The red line is the thermistor. The cyan smear is the phase plot of 1PPS from my Adafruit (MT3339) against the OCXO (Trimble 34310-T). The units on the right correspond to the temperature - 100 degrees at the EFC divider directly beneath the OCXO. Also, they correspond to the wrapped phase, where 0-20 is 0-360 degrees. The OCXO is limited to a swing of about +/- 1.1Hz at the moment. http://www.evoria.net/AE6RV/TempComp/GPSDO.png In the plot below is the ADEV. Hopefully it's self explanatory. The phase has varied a bit more than 180 degrees during the test. http://www.evoria.net/AE6RV/TempComp/ADEV.png The biggest influence on temperature seems to be the low quality divider resistors in the EFC divider chain. I have new low TempCo resistors but I couldn't resist playing with these first. Without temperature compensation, phase would vary through about one cycle every change to the red (thermistor) line. Bob - AE6RV From: Attila Kinali att...@kinali.ch To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, February 26, 2014 10:23 AM Subject: Re: [time-nuts] Thermal Compensation: Digital vs Analog On Wed, 26 Feb 2014 08:09:44 -0800 (PST) Bob Stewart b...@evoria.net wrote: I've been experimenting with digital thermal compensation on my GPSDO. The results have been favorable for a 14 bit dithered PWM-based DAC, but leaves a bit to be desired in the big picture. And it takes up a lot of program bytes on my PIC.. What's the general consensus on this? Should thermal compensation be completely analog? Out of pure interest. Could you elaborate what results you got? Ie. what does your GPSDO look like? How do you compensate for the temperature coefficient? How much did that improve performance compared to non-compensated operation? Did you try any other approaches? Why? Why not? Yes, i'm a curious mind :-) Thanks in advance Attila Kinali -- The trouble with you, Shev, is you don't say anything until you've saved up a whole truckload of damned heavy brick arguments and then you dump them all out and never look at the bleeding body mangled beneath the heap -- Tirin, The Dispossessed, U. Le Guin ___ 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 with all-digital phase/time measurement?
Hi Mark, I'm neither an engineer, nor an expert, but here are my comments. I think that the idea of 100ns/T is wrong. There are several variables that control accuracy, but the time between pulses from your OCXO (assuming no phase or frequency drift) isn't one of them. So, that gives 1/T. Here the problem is that T must get large before your accuracy can be good. You can achieve very good accuracy, but at the cost of waiting thousands of seconds between phase points; i.e. where your 1PPS coincides with the 10 millionth OCXO pulse. The theoretical maximum would be infinity, of course, but your oscillator won't be that stable. Another big problem is the accuracy of the 1PPS pulse. I'm using an Adafruit GPS receiver, and it's listed as accurate to within 10ns. And it is, but you have to be wary of exactly what that means. It doesn't mean +/- 5ns. So, as your 1PPS pulse bobs back and forth, you will often encounter an OCXO pulse up to 10ns early, or up to 10ns late. So, might you count 9,999,999 pulses from the OCXO immediately followed by 10,000,001 pulses. Neither of those, by itself is a signal to change the EFC voltage to your OCXO. In fact, it is normal for your count to alternate between the two for long periods, if you are very very close to exactly 10MHz, just from the quantization error on the 1PPS. It is also normal for 1/T to control the time between phase crossings. So you have to wait for two miscounts in a row in the same direction to make a change. And even then, you can't be 100% sure that it's not due to the quantization errors in your 1PPS signal. The better GPS receivers will output a quantization error value every second. But if you're using the 1/T method, there's nothing you can do with it, so you have to live with whatever quantization errors you get. Anyway, those are my experiences. Bob - AE6RV From: Mark Haun hau...@keteu.org To: time-nuts@febo.com Sent: Wednesday, February 26, 2014 3:51 PM Subject: [time-nuts] GPSDO with all-digital phase/time measurement? Hi everyone, I'm new to the list, and have been reading the recent threads on Arduino-based GPSDOs and the pros/cons of 10-kHz vs 1-Hz time pulses with interest. As I understand it, there are a couple of reasons why one needs a time-interval / phase measurement implemented outside the MCU: 1) Time resolution inside the MCU is limited by its clock period, which is much too coarse. The GPSDO would ping-pong within a huge dead zone. 2) Software tends to inject non-determinism into the timing. snip Thanks, Mark KJ6PC ___ 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 with all-digital phase/time measurement?
Tom, I took his 100ns figure to be simply the period of 10MHz. He mentioned using an interrupt driven system, so the counts should not necessarily be limited to 100ns accuracy. At least on the PIC I'm using, the CCP and timer interrupts don't seem to be synchronous with the PIC clock. I could be mistaken. Bob From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, February 26, 2014 11:22 PM Subject: Re: [time-nuts] GPSDO with all-digital phase/time measurement? At this point the time measurement is quite crude, with 100-ns resolution. But because we keep the counter running, the unknown residuals will keep accumulating, and we should be able to average out this quantization noise in the long run. That is, we can measure any T-second period to within 100 ns, so the resolution on a per-second basis becomes 100 ns / T. No. The timing resolution per second is always 100 ns. You're probably thinking about average frequency, in which case dividing by T is sometimes valid, and it looks better and better as time goes by, usually. What saves you here is that your counter noise (100 ns) is likely greater than the quantization noise. So you can pretty much ignore the receiver 1PPS quantization noise. For people with much lower measurement noise (e.g., 1 ns) the quantization noise becomes a more important piece of the error pie. Try not to say average out; that sounds like it goes away over time or gets smaller. You're doing a timing measurement so the 100 ns measurement granularity is always there, on every measurement. Is there any reason why this sort of processing cannot attain equivalent performance to the more conventional analog phase-detection approach? All other factors equal, a GPSDO based on 100 ns measurement resolution can never attain the equivalent of a GPSDO based on 10 ns or 1 ns measurement resolution. Waiting shorter or longer doesn't change the RMS timing accuracy. /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 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 with all-digital phase/time measurement?
Hi Hal, I've reviewed this a bit and I used the wrong terminology. Either Timer1 or Timer3 can use the T1CKI input as a clock. Along with that, the CCP1 or CCP2 pin can be used to trigger a capture of the timer in use into the CCPR1 or CCPR2 register pair. I had considered this as an interrupt function, but after looking at the manual, it's a matter of switchable dedicated hardware. Sorry for the bad info. Bob From: Hal Murray hmur...@megapathdsl.net To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Cc: hmur...@megapathdsl.net Sent: Thursday, February 27, 2014 1:13 AM Subject: Re: [time-nuts] GPSDO with all-digital phase/time measurement? b...@evoria.net said: At least on the PIC I'm using, the CCP and timer interrupts don't seem to be synchronous with the PIC clock. I could be mistaken. Unless you have a very strange architecture, it doesn't make sense for an interrupt to not be synchronous with the CPU clock. You are in the middle of an add instruction, and now you want to start an interrupt. What does that mean? I expect there is the standard 2 FF synchronizer on all the input pins. Things like the counter/timers run on the CPU clock, taking their input after the synchronizer. I don't remember seeing a data sheet that comes out and says that, but sometimes you can get some (strong?) hints with things like minimum pulse widths or max clock rate. -- 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] GPSDO with all-digital phase/time measurement?
Hi Alex, As these guys have told me, and as I have learned, Rb standards are very regular, but that doesn't mean they are very accurate. So, unless your Rb standard was being disciplined to the right frequency you'd probably have to do some sort of analysis to see the quantizing errors on your 1PPS pulse. Bob From: Alexander Pummer alex...@ieee.org To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, February 27, 2014 7:42 AM Subject: Re: [time-nuts] GPSDO with all-digital phase/time measurement? it would be interesting to see the accuracy of the 1pps pulses by comparing them with a second 1pps pulse, which is derived from a rubidium standard, which on his own does not have quantizing errors, 73 KJ6UHN Alex ___ 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 with all-digital phase/time measurement?
Hi Charles, The problem is that the only information available is the fact that a phase crossing occurred and whether there were more than 10M counts (or less) since the last PPS. The phase error value is not available to me, nor is the sawtooth value; which would of course be of no value. So, if I have a + phase crossing and then a - phase crossing, what do I know? If they are closely spaced, I can guess that the reason for the bouncing is the jitter on the PPS. If they are not closely spaced, then I can't really conclude anything other than that there is a phase offset in one direction or the other.. I could count the number of crossings over time and estimate the angle of the phase crossing, but I can't really be sure of the direction. Also, since this is not a timing receiver, it tends to wander around about 10-20 ns. So, that wander might be the only reason for a +/- count. In the case where there are two + crossings, or two - crossings in a row, it is a 1/T question. And with 1/T, it may be a long time until the next crossing, depending on how close you are in frequency, and how much the receiver wanders around. I'm aware of the limitations of the hardware. That's why I'm working on a TIC daughterboard. I could have used someone else's board, and a different GPS receiver, and on and on, but what fun would that have been? My goal is to do as much as possible with as little extra as possible using this particular board, learn as much as possible, and enjoy myself. I hope that helps. It's entirely possible that I've made some newbie mistake and that there's a good answer available. But, in that case, I would think that someone else would have already applied it to this board. Oh, and my granddaughter has been pestering me the whole time I've been writing this, so I hope I haven't been a bit short. =) Bob From: Charles Steinmetz csteinm...@yandex.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, February 28, 2014 12:29 PM Subject: Re: [time-nuts] GPSDO with all-digital phase/time measurement? Bob wrote: You can achieve very good accuracy, but at the cost of waiting thousands of seconds between phase points; i.e. where your 1PPS coincides with the 10 millionth OCXO pulse. So, as your 1PPS pulse bobs back and forth, you will often encounter an OCXO pulse up to 10ns early, or up to 10ns late. So, might you count 9,999,999 pulses from the OCXO immediately followed by 10,000,001 pulses. Neither of those, by itself is a signal to change the EFC voltage to your OCXO. In fact, it is normal for your count to alternate between the two for long periods, if you are very very close to exactly 10MHz, just from the quantization error on the 1PPS. It is also normal for 1/T to control the time between phase crossings. So you have to wait for two miscounts in a row in the same direction to make a change. I have been puzzled more than once by your comments about only changing the DAC count every several minutes or more. I am not familiar with the circuit you are using, but in a digital PLL the errors (assessed every second) typically feed a digital filter that drives the DAC. So, there is generally a very small correction every second according to the long running average of the individual errors, rather than a large correction after hundreds or thousands of seconds. If you only adjust the DAC every two miscounts in one direction, you are guaranteed to get slipped cycles (which appeared to be one of the problems you were having when comparing oscillators). This is a reasonable way to get an oscillator roughly on frequency if it is substantially off to start with, but it is not a good way to hold an oscillator within ppb of the desired frequency, and no way at all to hold it in phase lock with the reference. If that is really the way the circuit you are using works, perhaps it would be better to implement a proper all-digital PLL with digital filter than trying to get better results out of the circuit you are using than it is capable of delivering. Or, perhaps I'm not understanding what you are doing? Best regards, Charles ___ 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] Another atomic clock question
Tom, That's a pretty interesting idea. It makes me wonder if it would be worth it to switch perhaps a 1/2W heat source (random number) off and on over the XO in the UT+ say every minute or so. Bob From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, March 3, 2014 6:40 PM Subject: Re: [time-nuts] Another atomic clock question Sure. In fact you can loosely phase lock it to GPS that way. Your xtal doesn't need to have an EFC pin. You are using external temperature as a replacement for EFC. Call it TFC (temperature frequency control) instead. You can't get much simpler than that. Make sure to use a plain XO (not a TCXO or OCXO). I used a resistor heater to bust hanging-bridges: http://leapsecond.com/pages/vp/heater.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.
Re: [time-nuts] Another atomic clock question
I suggested yesterday to periodically heat and cool the oscillator, but my post may have been lost in the noise. Bob From: Didier Juges shali...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, March 4, 2014 11:00 AM Subject: Re: [time-nuts] Another atomic clock question What would be more interesting would be to adjust the temperature of the GPS receiver's oscillator to eliminate the hanging bridges altogether, kind of like Trimble does with the Thunderbolt, except that they do it directly instead of indirectly. That may require to characterize the crystal oscillator to find out if it has an appropriate control range over temperature. 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] Another atomic clock question
Hi Tom, You may have missed TVB's post yesterday, quoted below. A hanging bridge is an area on a timing receiver's plotted sawtooth correction value that stays on one side of phase zero for some period of time. As a result of this bias, a GPSDO that is not corrected for sawtooth will probably have at least a phase shift in its output frequency during a hanging bridge. It's not so bad on the newer 10ns receivers as it was on the older +/-52ns Oncores. If one could prevent these hanging bridges, an uncorrected GPSDO would likely track phase better. Tom suggested to detect when the bridge forms and give it a shot of heat. I suggested to vary the oscillator's frequency by periodically heating and cooling it. Tom's post: Sure. In fact you can loosely phase lock it to GPS that way. Your xtal doesn't need to have an EFC pin. You are using external temperature as a replacement for EFC. Call it TFC (temperature frequency control) instead. You can't get much simpler than that. Make sure to use a plain XO (not a TCXO or OCXO). I used a resistor heater to bust hanging-bridges: http://leapsecond.com/pages/vp/heater.htm /tvb From: Tom Holmes thol...@woh.rr.com To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Tuesday, March 4, 2014 12:07 PM Subject: Re: [time-nuts] Another atomic clock question Hanging bridge? What is it; where is it found; and how does it form? My guess is that a Google or Wikipedia search is going to come up with something named Golden Gate or maybe a musical term. Tom Holmes, N8ZM ___ 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] New TIC test run
I put my TIC to hardware, and have started testing it. Here is a sample run comparing it against the 5334B with an off frequency OCXO. I've scaled and rotated to tried to cancel out the length of the cables to the 5334B. Still early days with it, yet. http://www.evoria.net/AE6RV/TIC/TICvs5334B.png 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] New TIC test run
Hi Anders, I just put the schematic up at http://www.evoria.net/AE6RV/TIC/TIC2.bmp However, there are some caveats: I did not have to use the level shifter Q1/Q2. I am not yet using VR1. (Actually the one I bought failed for some reason.) R4 is actually 2.4K, and C1 is not being used. The capacitors in the 18F2220 PIC are sufficient without C1. I'm not sure what you mean by what is the range. The ADC is 10 bits wide. The output varies from about 150 to about 500 units over 360 degrees of phase error without the Voltage Ref. It should be twice that when I get that in and working; though I am worried that it might clip on the high side so... The red data, as it says on the plot, is the 53345B. The blue data is from the TIC. The transfer function is nonlinear, and I have made no effort to correct for this. I've had a day to play with it, and I'm amazed at the precision of this thing. It's like taking the 5334B and adjusting the focus knob. Of course it's not as accurate, due to the way it works, but it will fit my needs well in my GPSDO. Bob - AE6RV From: Anders Wallin anders.e.e.wal...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, March 9, 2014 3:19 AM Subject: Re: [time-nuts] New TIC test run Do you have the schematic for this online somewhere? what is the range of the interpolator? which TIC is the red/blue points? the blue data looks like it is aliased somehow, perhaps a number that is truncated/rounded badly? On Sat, Mar 8, 2014 at 9:46 PM, Bob Stewart b...@evoria.net wrote: I put my TIC to hardware, and have started testing it. Here is a sample run comparing it against the 5334B with an off frequency OCXO. I've scaled and rotated to tried to cancel out the length of the cables to the 5334B. Still early days with it, yet. http://www.evoria.net/AE6RV/TIC/TICvs5334B.png 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] New TIC test run
The link seems garbled for some reason with it inline so let me try again. http://www.evoria.net/AE6RV/TIC/TIC2.bmp From: Bob Stewart b...@evoria.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, March 9, 2014 10:40 AM Subject: Re: [time-nuts] New TIC test run Hi Anders, I just put the schematic up at http://www.evoria.net/AE6RV/TIC/TIC2.bmp However, there are some caveats: I did not have to use the level shifter Q1/Q2. I am not yet using VR1. (Actually the one I bought failed for some reason.) R4 is actually 2.4K, and C1 is not being used. The capacitors in the 18F2220 PIC are sufficient without C1. I'm not sure what you mean by what is the range. The ADC is 10 bits wide. The output varies from about 150 to about 500 units over 360 degrees of phase error without the Voltage Ref. It should be twice that when I get that in and working; though I am worried that it might clip on the high side so... The red data, as it says on the plot, is the 53345B. The blue data is from the TIC. The transfer function is nonlinear, and I have made no effort to correct for this. I've had a day to play with it, and I'm amazed at the precision of this thing. It's like taking the 5334B and adjusting the focus knob. Of course it's not as accurate, due to the way it works, but it will fit my needs well in my GPSDO. Bob - AE6RV From: Anders Wallin anders.e.e.wal...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, March 9, 2014 3:19 AM Subject: Re: [time-nuts] New TIC test run Do you have the schematic for this online somewhere? what is the range of the interpolator? which TIC is the red/blue points? the blue data looks like it is aliased somehow, perhaps a number that is truncated/rounded badly? On Sat, Mar 8, 2014 at 9:46 PM, Bob Stewart b...@evoria.net wrote: I put my TIC to hardware, and have started testing it. Here is a sample run comparing it against the 5334B with an off frequency OCXO. I've scaled and rotated to tried to cancel out the length of the cables to the 5334B. Still early days with it, yet. http://www.evoria.net/AE6RV/TIC/TICvs5334B.png 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. ___ 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] Modeling vs reality question re my TIC
Fellow Timenuts: I'm trying to square reality with the modeling that I did, and nothing makes sense. When I modeled the result of just my 2.4K resistor with the caps and resistor the PIC datasheet says it has in it, there's no relationship. The model says I'll get millivolts out. Here's how I calculate what I'm actually getting: ADC VRef is 2.5V 10-bit ADC = 1024 positions Max ADC from TIC = 975 975/1024*2.5 = 2.38V Max TIC value Min ADC from TIC = 293 293/1024*2.5 = 0.715V Min TIC value A range of 0.715V-2.38V is totally outside my expectations. The only way I can get close to these values is if the internal CHOLD in the PIC is only a fraction of the 120pf they say it has - say 20pf. Any thoughts would be appreciated. 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] Modeling vs reality question re my TIC
Hi Chris, I don't think it's a software issue, as the voltage doubled when I halved the VRef - which is what would be expected. Also, the voltages tracked the 5334B when I still had it connected, except that the TIC seems more precise and less noisy. Then again, the 5334B was being fed with 8 ft of RG-58U. What I'm seeing with the TIC is exactly what I would expect to see, only better, if that makes any sense. Maybe the LTSpiceIV models are where the problem lies. Let me clarify the caps. This is an 18F2220 PIC. The pin cap is 5pf. There is an internal CHOLD in the ADC which is listed as 120pf. Here is a screenshot of the relevant page. http://www.evoria.net/AE6RV/TIC/ADC.png Bob From: Chris Albertson albertson.ch...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, March 10, 2014 3:26 PM Subject: Re: [time-nuts] Modeling vs reality question re my TIC On Mon, Mar 10, 2014 at 12:12 PM, Bob Stewart b...@evoria.net wrote: A range of 0.715V-2.38V is totally outside my expectations. The only way I can get close to these values is if the internal CHOLD in the PIC is only a fraction of the 120pf they say it has - say 20pf. Any thoughts would be appreciated. Could it be a software issue? 20pf seems about right for a normal input pin in a typical chip. They all have diodes protecting from static and 20 pf seems like what I'd expect. You say there is an internal 120 pf cap inside the PIC? If so you'd need to connect that. It may be that you are not doing that correctly or at the time you think you are. I'm guessing and we'd need both the spec sheet and your code to know for sure. -- 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] Modeling vs reality question re my TIC
Wouldn't those types of problems tend to make the result worse in some obvious way, instead of better than expected? I'm getting an ADC swing from about .7V to about 2.4V; which corresponds to the usual diode sink at .7V and probably just blind luck with the 2.4V max being so close to the 2.5V VRef. In the plot below, I zapped the DAC on my system to get a picture of the charge ramp. The red dots are the TIC with the 10ns uncorrected jitter from a nav receiver. The purple is a 30 second rolling average. Am I right in thinking this is a typical RC charge ramp? Not trying to be argumentative, I'm just trying hard to understand. http://www.evoria.net/AE6RV/TIC/ChargeRamp.png Bob From: Bruce Griffiths bruce.griffi...@xtra.co.nz To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, March 10, 2014 3:53 PM Subject: Re: [time-nuts] Modeling vs reality question re my TIC Metastability in the Flipflops? Charge injection when tristating tristate buffers? Neither of which are included in your models. Bruce ___ 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] Modeling vs reality question re my TIC
Unfortunately, I don't have a DSO, and I don't see any way to capture waveforms with the equipment I have available to me. And then there's the insurmountable problem of not having access to the 120pf cap in the PIC. I may have to just accept it without understanding it. At least success is a good problem to have and not a bad one. I'm sending a board to a friend soon, and if the results repeat for him, it's not just a fluke. Bob From: Bruce Griffiths bruce.griffi...@xtra.co.nz To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, March 10, 2014 5:32 PM Subject: Re: [time-nuts] Modeling vs reality question re my TIC Charge injection could well account for the offset from the expected minimum. There are no forward biased diodes in your circuit. It would be helpful to capture the 125 buffer input signal waveforms (and if possible the timing capacitor waveform) rather than trying to infer whats going on from the ADC plots. Bruce ___ 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] PLL Math Question
Now that I've got the TIC going, I'm working on the PLL math for my GPSDO. My question is about moving averages. I've put in a moving average for the TIC. From that, I've calculated the slope, and have put a moving average on the slope to settle it down. I think this boils down to a moving average of a moving average. If both are 16 seconds long, is this essentially a 32 second moving average of the TIC, or is it some other function? I read briefly about averages of averages last night, but I'm not sure I understood the conclusion. This is all clean code so I may be over-complicating things, but I'm OK with that. NOTE: The reason I'm using 16 seconds is that I'm becoming memory limited. I'm switching to an 18F2320, but that only gets me more program memory. I'm constrained to this chip on an existing board. 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] PLL Math Question
Hi Magnus, Thanks very much for this response! It will be very easy to add the exponential averager to my code and do a comparison to the moving average. I have no experience with PI/PID. I'll have to look over the literature I have on them and relate that to what I'm controlling. It should be mentioned that I'm more interested in the adventure than in just copying someone else's code or formulae and pumping this out. I have an idea of how I want to do this and... Bob From: Magnus Danielson mag...@rubidium.dyndns.org To: time-nuts@febo.com Sent: Wednesday, March 12, 2014 12:51 PM Subject: Re: [time-nuts] PLL Math Question Bob, On 12/03/14 18:24, Bob Stewart wrote: Now that I've got the TIC going, I'm working on the PLL math for my GPSDO. My question is about moving averages. I've put in a moving average for the TIC. From that, I've calculated the slope, and have put a moving average on the slope to settle it down. I think this boils down to a moving average of a moving average. If both are 16 seconds long, is this essentially a 32 second moving average of the TIC, or is it some other function? I read briefly about averages of averages last night, but I'm not sure I understood the conclusion. This is all clean code so I may be over-complicating things, but I'm OK with that. When you serialize two averages you maintain the same time-constant of the average, but you get two 6 dB slopes on top of each other to form a 12 dB slope, while it is flat on the pass-band. You should be careful about use of averager inside the loop. A moving averager adds a zero in the loop, and you want to make sure you understand what that zero will do to the overall control-loop. Here you have two of them, as you run two average zeros in series. I prefer to use a PI or PID loop for such a control-loop, and potentially an exponential averager or two in there. If you make sure the exponential averager has a wide enough bandwidth, you can use standard PI dimensioning formulas, but achieve the tighter slope which the exponential averagers contribute to. NOTE: The reason I'm using 16 seconds is that I'm becoming memory limited. I'm switching to an 18F2320, but that only gets me more program memory. I'm constrained to this chip on an existing board. Exponential averger takes much less memory. Consider this code: x_avg = x_avg + (x - x_avg) * a_avg; Where a_avg is the time-constant control parameter. 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] PLL Math Question
Hi Hal, In the moving averages I'm doing, I'm saving the last bit to be shifted out and if it's a 1 (i.e. 0.5) I increase the result by 1. Bob From: Hal Murray hmur...@megapathdsl.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Cc: hmur...@megapathdsl.net Sent: Wednesday, March 12, 2014 2:25 PM Subject: Re: [time-nuts] PLL Math Question mag...@rubidium.dyndns.org said: Exponential averger takes much less memory. Consider this code: x_avg = x_avg + (x - x_avg) * a_avg; Where a_avg is the time-constant control parameter. Also note that if a_avg is a power of 2, you can do it all with shifts rather than multiplies. Note that the shift is to the right which drops bits. That suggests that you might want to work with x scaled relative to the raw data samples. Consider a_avg to be 1/8, or a shift right 3 bits. Suppose x_avg is 0 and you get a string of x samples of 2. The shift throws away the 2 so x_avg never changes. -- 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. ___ 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] PLL Math Question
x_avg = x_avg + (x - x_avg) * a_avg; Hi again Magnus, In fact, I just post-processed some data using that formula in perl. It looks great, and will indeed save me code and memory space. And, it can be a user variable, rather than hard-coded. Thanks for the heads up! Bob From: Magnus Danielson mag...@rubidium.dyndns.org To: time-nuts@febo.com Sent: Wednesday, March 12, 2014 12:51 PM Subject: Re: [time-nuts] PLL Math Question Bob, snip Exponential averger takes much less memory. Consider this code: x_avg = x_avg + (x - x_avg) * a_avg; Where a_avg is the time-constant control parameter. 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] PLL Math Question
Hal says: For exponential smoothing, a_avg will be a fraction. Let's pick a_avg to be 1/8. That's a right shift by 3 bits. I don't think there is anything magic about shifting, but that makes a particular case easy to spot and discuss. Hi Hal, Yeah, I've been sitting here manually running some sample data and I haven't been happy with my efforts so far. I think I'll just stay with what I know for now: moving averages. I've got a number of places I can reduce memory usage when I run a bit shorter, so I think it'll work out. And I suspect I'm being far too conservative; i.e. averaging way too long If not, maybe there will be a good gain value that will be convenient to code the exponential average. Thanks for the help, Bob From: Hal Murray hmur...@megapathdsl.net To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Cc: hmur...@megapathdsl.net Sent: Wednesday, March 12, 2014 10:08 PM Subject: Re: [time-nuts] PLL Math Question b...@evoria.net said: In the moving averages I'm doing, I'm saving the last bit to be shifted out and if it's a 1 (i.e. 0.5) I increase the result by 1. That's just rounding up at an important place. It's probably a good idea, but doesn't cover the area I was trying to point out. Let me try again... Suppose you are doing: x_avg = x_avg + (x - x_avg) * a_avg; For exponential smoothing, a_avg will be a fraction. Let's pick a_avg to be 1/8. That's a right shift by 3 bits. I don't think there is anything magic about shifting, but that makes a particular case easy to spot and discuss. Suppose x_avg is 0 and x has been 0 for a while. Everything is stable. Now change x to 2. (x - x_avg) is 2, the shift kicks it off the edge, so x_avg doesn't change. (It went 2 bits off, so your round up doesn't catch it.) The response to small steps is to ignore them. If you have noisy data, things probably work out OK. If you need to process low level (very) low frequency changes (which seems desirable for a GPSDO) you probably want some fractional bits. For me, the easy way to do that is to use y = x * k Let's use k = 16, a 4 bit left shift. For the same step of x=2, y= 32, (y - y_avg) is 32, shifted right by 3 that's 4, so y_avg is 4. I'm sure this is all business-as-usual for the people who write control loops in small CPUs using fixed point arithmethic. Of course, you have to worry about shifting too far left (overflow) and things like that. If you have enough cycles, you can use floating point. :) -- 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] PLL Math Question
Hi Daniel, re: FIR vs IIR I'm not a DSP professional, though I do have an old Smiths, and I've read some of it. So, could you give me some idea what the FIR vs IIR question means on a practical level for this application? I can see that the MA is effective and easy to code, but takes up memory space I eventually may not have. Likewise, I can see that the EA is hard to code for the general case, but takes up little memory. Any thoughts would be appreciated unless this is straying too far from time-nuts territory. Bob From: Daniel Mendes dmend...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, March 12, 2014 11:13 PM Subject: Re: [time-nuts] PLL Math Question This is a FIR x IIR question... moving average = FIR filter with all N coeficients equalling 1/N exponential average = using a simple rule to make an IIR filter Daniel ___ 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] PLL Math Question
Hi Jim, Thanks for your thoughts. Perhaps there are a few things that I know about my particular system that have been discounted. I have mentioned them in passing, but haven't collected them coherently for this thread. It's an 8-bit PIC, thus floating point calculations have to be improvised, and memory is limited to 4096 total instructions with 512 bytes of variable space. I'm using a nav receiver at the moment (no sawtooth correction), and the 1PPS is pretty noisy. The hardware is a fixed quantity, which includes a 10-bit PWM dithered to 14 bits. There is a voltage divider on the EFC to limit the range, and a thermistor for thermal correction. Think of it as a contest or a challenge. The only prize is success. The noisy 1PPS has been a big concern, and the reason for the moving average/low-pass filter. I have considered using a slotted-disk instead, or at least a smaller MA with a slotted-disk. The OCXO has shown itself to be extremely stable in both phase and frequency. Without eliminating the noise from the 1PPS, the OCXO would be needlessly moved around thus passing that noise through. Given the stability of the OCXO, I don't think that being 32 seconds behind (two 16 second moving averages at the moment) creates a problem. I do actually have a usable integrator designed for a PI system, but I'm trying to avoid using it. My preference is a state machine implementation. My approach to this is along the lines of 1. Warmup 2. Check and adjust the frequency close enough 3. If there is a frequency adjustment, decide when to (re)enable phase control 4. Compare the phase angle to the setpoint to discover which way to herd the phase 5. Use the smoothed slope and distance from setpoint to control the gain of any change applied to the DAC 6. Adjust for temperature change 7. Rinse and repeat from 2. Perhaps this is so close to PI that it makes no difference that I'm not using a transliteration of Wescott's code? I really do not relish the idea of implementing floating point operations in 8-bit unsigned characters on someone else's control code on this PIC if I can get it to work properly my way. Bob From: Jim Lux jim...@earthlink.net To: time-nuts@febo.com Sent: Thursday, March 13, 2014 7:57 AM Subject: Re: [time-nuts] PLL Math Question On 3/12/14 10:06 PM, Chris Albertson wrote: On Wed, Mar 12, 2014 at 9:13 PM, Daniel Mendes dmend...@gmail.com wrote: This is a FIR x IIR question... moving average = FIR filter with all N coeficients equalling 1/N exponential average = using a simple rule to make an IIR filter Isn't his moving average just a convolution of the data with a box car function? That treats the last N samples equally and is likely not optimal. I think why he wants is a low pass filter. A moving average (or rectangular impulse response) *is* a low pass filter. The frequency response is of the general sin(x)/x sort of shape, and it has deep nulls, which can be convenient (imagine a moving average covering 1/60th of a second, in the US.. it would have strong nulls at the line frequency and harmonics) This method is like the hockey player who skates to where to puck was about 5 seconds ago. It is not the best way to play the game. He will in fact NEVER get to the puck if the puck is moving he is domed to chase it forever.. Same here you will never get there. That distinction is different than the filter IIR vs FIR thing. Filters are causal, and the output always lags the input in time. if you want to predict where you're going to be you need a different kind of model or system design. Something like a predictor corrector, for instance. snip ___ 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] PLL Math Question
Dennis, I just realized that I could do the math in sixteenths. So, for 7/16ths multiply by 7 before shifting(i.e. dividing) and rounding. That would probably give enough granularity. I'll have to think about it. It does open new doors. thanks, Bob From: Dennis Ferguson dennis.c.fergu...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Cc: Hal Murray hmur...@megapathdsl.net Sent: Thursday, March 13, 2014 1:58 PM Subject: Re: [time-nuts] PLL Math Question Note that you can't do fixed-point computations exactly the same way you would do it in floating point, you often need to rearrange the equations a bit. You can usually find a rearrangement which provides equivalent results, however. Let's define an extra variable, x_sum, where x_avg = x_sum * a_avg; The equation above can then be rewritten in terms of x_sum, i.e. x_sum = x_sum * (1 - a_avg) + x; With an a_avg of 1/8 you'll instead be multiplying x_sum by 7, shifting it right 3 bits (you might want to round before the shift) and adding x. The new value of x_avg can be computed from the new value of x_sum with a shift (you might want to round that too), or you could pretend that x_sum is a fixed-point number with the decimal point 3 bits from the right. In either case x_sum carries enough bits that you don't lose precision. ___ 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] PLL Math Question
OK, gotcha. But, this is in assembler, and anything wider than 3 bytes becomes tedious. Also, anything larger than 3 bytes starts using a lot of space in a hurry. Three byte fields allow me to use 256ths for gain and take the result directly from the two high order bytes without any shifting. And as I mentioned to Hal in a separate post: when I hand-coded the exponential averager the results were actually good. I was forgetting to convert to decimal to compare values to the decimal run. For example: 0x60 doesn't look like 0.375 until you convert to decimal and divide by 256. This has been most informative and certainly gives me more options. Bob From: Chris Albertson albertson.ch...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, March 13, 2014 5:42 PM Subject: Re: [time-nuts] PLL Math Question You don't really shift so much as just change the way you think about it. The way to think about it is not that you have 16th but that you have the binary point force places over. It works just like a decimal point. If you multiply two numbers each that has four places to the right of the point you have now eight places to the right. You can shift it or not. If you use 64 bit longs you sand up not having to shift so much because those can cary up to about 32 binary places. On Thu, Mar 13, 2014 at 12:10 PM, Bob Stewart b...@evoria.net wrote: Dennis, I just realized that I could do the math in sixteenths. So, for 7/16ths multiply by 7 before shifting(i.e. dividing) and rounding. That would probably give enough granularity. I'll have to think about it. It does open new doors. thanks, Bob From: Dennis Ferguson dennis.c.fergu...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Cc: Hal Murray hmur...@megapathdsl.net Sent: Thursday, March 13, 2014 1:58 PM Subject: Re: [time-nuts] PLL Math Question Note that you can't do fixed-point computations exactly the same way you would do it in floating point, you often need to rearrange the equations a bit. You can usually find a rearrangement which provides equivalent results, however. Let's define an extra variable, x_sum, where x_avg = x_sum * a_avg; The equation above can then be rewritten in terms of x_sum, i.e. x_sum = x_sum * (1 - a_avg) + x; With an a_avg of 1/8 you'll instead be multiplying x_sum by 7, shifting it right 3 bits (you might want to round before the shift) and adding x. The new value of x_avg can be computed from the new value of x_sum with a shift (you might want to round that too), or you could pretend that x_sum is a fixed-point number with the decimal point 3 bits from the right. In either case x_sum carries enough bits that you don't lose precision. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Nav Receiver Sawtooth Correction?
I've gotten my PLL mostly working, but, since I'm using a nav receiver, it looks like I may want to see if I can do a poor-man's sawtooth correction based on GPS position changes. Has anyone done this or have a reference for a project that has? It would seem to me that only the East-West movements would be a factor, but I dunno. As a beginning, I was just going to plot lat and lon deltas from gpsd data to see what correlates to the phase error jumps I'm seeing, unless this path has already been tread. I don't expect the accuracy that would be afforded by a real timing receiver. 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] Nav Receiver Sawtooth Correction?
Hi Ignacio, Thanks for the response. I've got a UT+ in the parts box. But that's not the problem I'm trying to solve. I'm trying to make the best GPSDO that I can make using a nav receiver at the moment. Call it an obsession if you like. It's OK if I don't have corrections to the nanosecond for each PPS. But I can see the nav receiver wandering around; especially on cloudy days, (the antenna is in the attic, so that's about the best I can do for that) and it just seems to me that I should be able to do a general correction for nav position errors. Sorry if my naive posts are starting to get on people's nerves. Bob From: EB4APL eb4...@cembreros.jazztel.es To: time-nuts@febo.com Sent: Sunday, March 23, 2014 7:35 PM Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? Bob, The sawtooth is generated by the granularity of the GPS receiver clock not being synchronous with the recovered PPS. The receiver program can calculate the correction to be applied to the next PPS and outputs it in a message, bu only in timing receivers, this is not a useful thing in navigation receivers and I think that it cannot be calculated using the satellites' position, it is a receiver defect. Why don't you buy a timing receiver? An used Motorola Encore M12+ timing receiver can be bought by $35 or less (ebay items 290656401551 or 301131583613. The seller is a known Time Nuts supplier). An UT+ or GT+ even for quite less. Regards, Ignacio EB4APL ___ 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] Nav Receiver Sawtooth Correction?
Random noise or not, wouldn't a position error in a nav receiver cause a corresponding displacement of the 1PPS pulse? Also there's a bit more to it than just minor noise. It's probably multipath, or perhaps even jammers passing on the freeway about a mile away. Whatever the cause, take a look at this screen capture of foxtrotgps over about 40 minutes of elapsed time. The red is the GPS movement around my house that I periodically mention. I judge it to be about 15 ft on the diagonal. Sometimes it is much much worse. Likewise I would expect the 1PPS to move by that amount. http://www.evoria.net/AE6RV/Nav/NavWander.png Bob From: Chris Albertson albertson.ch...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, March 23, 2014 9:24 PM Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? What you are seeing in position error is a random noise. There is no pattern to it and it is not predictable. A sawtooth error is very nice and regular looking. It's not noisy and can be predicted in advance. Possition error is not at all like sawtooth. I think what you CAN do is look at the size of the error. Then you adjust the gain on the loop control based of the measured error sigma. On Sun, Mar 23, 2014 at 6:30 PM, Bob Stewart b...@evoria.net wrote: Hi Ignacio, Thanks for the response. I've got a UT+ in the parts box. But that's not the problem I'm trying to solve. I'm trying to make the best GPSDO that I can make using a nav receiver at the moment. Call it an obsession if you like. It's OK if I don't have corrections to the nanosecond for each PPS. But I can see the nav receiver wandering around; especially on cloudy days, (the antenna is in the attic, so that's about the best I can do for that) and it just seems to me that I should be able to do a general correction for nav position errors. Sorry if my naive posts are starting to get on people's nerves. Bob From: EB4APL eb4...@cembreros.jazztel.es To: time-nuts@febo.com Sent: Sunday, March 23, 2014 7:35 PM Subject: Re: [time-nuts] Nav Receiver Sawtooth Correction? Bob, The sawtooth is generated by the granularity of the GPS receiver clock not being synchronous with the recovered PPS. The receiver program can calculate the correction to be applied to the next PPS and outputs it in a message, bu only in timing receivers, this is not a useful thing in navigation receivers and I think that it cannot be calculated using the satellites' position, it is a receiver defect. Why don't you buy a timing receiver? An used Motorola Encore M12+ timing receiver can be bought by $35 or less (ebay items 290656401551 or 301131583613. The seller is a known Time Nuts supplier). An UT+ or GT+ even for quite less. Regards, Ignacio EB4APL ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] RC TIC linearity correction?
I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. Explanation: when I arrange things so that the phase point is near the top of my TIC's range, it requires a smaller movement than when the phase point is in the middle: Presumably the difference is even greater near the bottom. Can anyone give me a reference of some type for doing this? I looked around a few weeks ago, but my google-foo wasn't up to the challenge. The schematic is essentially this, except that C1 doesn't really exist. It was a place-holder on my board in case the caps in the PIC weren't up to it by themselves - which they were. And, not that it matters, but the level shifter (Q1,Q2) was also not needed. http://www.evoria.net/AE6RV/TIC/TIC2.bmp 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] RC TIC linearity correction?
Thanks Charles. That makes sense, but at the expense of adding unwanted complexity. As I've been moving the setpoint around this morning, I think I see a way to characterize what it's doing. Maybe I can come up with a small correction table or formula that's good enough for my purposes. Bob From: Charles Steinmetz csteinm...@yandex.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, March 26, 2014 12:27 AM Subject: Re: [time-nuts] RC TIC linearity correction? Bob wrote: I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. You are using a resistor to charge the integrating capacitance, so it charges with the classic exponential curve and you get a nonlinear time-to-voltage conversion. You need to charge the integrating capacitance with a constant current if you want a linear time-to-voltage function. The current source will probably need to be connected to a supply that is higher than 5v, because it needs some headroom. There may be secondary errors, as well, due to the leakage of the tri-state buffers in their hi-Z state and/or nonlinearity in the ADC's internal capacitors. Often you can improve things by using sufficient external capacitance to swamp the ADC's internal capacitance and increasing the charging current. Best regards, Charles ___ 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] RC TIC linearity correction?
If I were to try to do this automatically, I think I'd move the PLL set point in n steps from near the bottom to near the top and look at the width of the PPS signal at each step; perhaps using the bucket scheme that Stanley mentioned and using some count per bucket to decide how wide is wide. I don't have any sort of phase wrapping code, though, so I have to be careful how close to a phase point I get. Bob From: Chris Albertson albertson.ch...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, March 26, 2014 11:25 AM Subject: Re: [time-nuts] RC TIC linearity correction? On Wed, Mar 26, 2014 at 8:41 AM, Bob Stewart b...@evoria.net wrote: Thanks Charles. That makes sense, but at the expense of adding unwanted complexity. As I've been moving the setpoint around this morning, I think I see a way to characterize what it's doing. Maybe I can come up with a small correction table or formula that's good enough for my purposes. Yes a lookup table would be easy. But how to create the table? I've been thinking about a way to do self calibration. The controller purposely runs the DAC and of course the OCXO through some range and watches the phase. This gives you a rough DAC vs. Phase function. Re-running the calibration could make up for some component aging. It would take some time (hours) to wait for everything to warm up and then you'd have to move the EFV voltage slowly -- 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] RC TIC linearity correction?
I finally got my PLL running today, and I think I can manage with just a small table of 10 values to be used as the width of my PPS jitter corrector. That takes care of it for this project, but obviously not for the general case. Bob From: Chris Albertson albertson.ch...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, March 26, 2014 11:25 AM Subject: Re: [time-nuts] RC TIC linearity correction? Yes a lookup table would be easy. But how to create the table? I've been thinking about a way to do self calibration. The controller purposely runs the DAC and of course the OCXO through some range and watches the phase. This gives you a rough DAC vs. Phase function. Re-running the calibration could make up for some component aging. It would take some time (hours) to wait for everything to warm up and then you'd have to move the EFV voltage slowly ___ 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] FEI-5660 Rubidium Oscillator
What about the other side of audio-phoolery: audio FFT? I'm thinking more along the lines of an ARRL FMT. From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, March 27, 2014 6:10 PM Subject: Re: [time-nuts] FEI-5660 Rubidium Oscillator Recently I happened across an eBay listing for an Antelope Audio Isochrome, a device that apparently packages an SRI-PRS10 rubidium oscillator and distribution amplifier in a box and sells to audiophiles for a price in the Bruce, There have been threads about this on time-nuts every few years. The consensus is that audio companies that use atomic clocks are naive. It makes good marketing, though. Then again, speaking from experience, many of us make the same mistake: first thinking that precise time is the goal, then thinking that precise frequency is what counts, and later thinking that stability is what really matters, and only eventually realizing that all of these metrics are functions of tau, and that tau ranges from MHz/microseconds to years. Phase noise plots along with log-log ADEV plots start to tell the whole story. In the case of digital music, as far as I know, L(f) phase noise in the audio band and ADEV(tau) frequency stability from microseconds to seconds is far more important to the fidelity of digital recording and playback than absolute SI-accurate frequency or long-term timekeeping. Consequently, most atomic frequency standards are actually a poor choice as a sampling reference clock -- because their jitter (short-term noise) is no where near as good as a free-running, undisciplined, high-end OCXO. True, the PRS10 is a better choice than other cheap telecom rubidium's but none of these comes close to the performance of a premium OCXO. For the ultimate audio reference clock you want to avoid Rb, or GPSDO, or Cs for that matter. Instead pick a 1e-12 or 1e-13 stable OCXO, strap it to a 100 pound block of granite, and leave it alone. /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] First success with very simple, very low cost GPSDO, under $8
To further Brian's comment: you have to keep in mind that the interrupt routine interrupts the mainline code, and not the other way around. So, you set a semaphore in your mainline code and your interrupt routine checks to see if that's set when it starts, or at least before it uses any variables you have protected by the semaphore. In my code, I just set a bit immediately before changing two critical variables, and reset it immediately afterward. If the interrupt routine finds the semaphore set, it returns and does nothing till next time. This prevents any question about whether the interrupt routine can update or even use the variables in question. And not that it makes any difference, but I went down much the same path as Chris is going down with my non-TIC code. Maybe Chris will find something that I couldn't find. For me, there was always something just out of reach to prevent it from working properly. That something may just be that I was using a nav receiver instead of a timing receiver. I wound up with a very accurate counter; but it was still just a counter when all was said and done. Bob From: Brian Lloyd br...@lloyd.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, April 9, 2014 3:17 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8 On Wed, Apr 9, 2014 at 1:34 PM, Hal Murray hmur...@megapathdsl.net wrote: But I think you over looked one point that makes this project easier: We KNOW 100% for certain that the interrupts happen only once per second. So the foreground code knows for certain it has exclusive access to shared variables for a given period of time. There is zero chance of a problem in the next .999 seconds after an interrupt. Actually, you don't know that. You know that's the way it's supposed to work, but there are all sorts of ways that things can (and do) screw up and making that sort of assumption can lead to problems that are very hard to debug. So create a semaphore that says who owns the variable. Or, better still, us a message-passing executive. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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] First success with very simple, very low cost GPSDO, under $8
Have you considered reading the timer only at PPS? You don't need to keep track of the actual count. You just need to keep track of the difference between counts at each PPS. Resolution isn't a problem since the difference in the lower 16 bits is a fixed number for your purpose. IOW, 10,000,000 is 0x989680. You're only interested in the 0x9680. If there's a difference in two successive timer counts of 0x9680, then you know you counted 10,000,000, unless your oscillator is capable of running at one of the other values that gives 0x9680 as the lower two bytes. Bob From: Chris Albertson albertson.ch...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, April 9, 2014 6:35 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8 On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephi...@gmail.com wrote: Another point with the software is that your handler for the PPS just reads the counter. This gives an offset between the PPS edge and the value read, as your software takes time to respond to the interrupt and read the counter. In your code, it doesn't matter as you only have one interrupt. Actually there are two interrupts. One is for PPS and the other is for overflow of the 16-bit counter. This over flow happens about 76 times per seconds. However, if you have another interrupt enabled, this could run after the PPS pulse but before the handler runs, giving you a very rare jitter. A better way would be to use the input capture feature to read the timer into a capture register. Then the interrupt handler has until the next edge to read the capture register. Do you know how to do this. I don't see any way to capture the timer value other then reading it with software. The timer capture register is 16 bits and is set atomically after each timer increment but I don't see a way to make an external interrupt pin capture a timer. The two interrupts do bump into each other about roughly every 100 seconds but I can detect that. I think I'll just ignore that second. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Adafruit (MT3339) problems today
My Adafruit has gone walkabout again. This is a different unit than the one I spoke about some months ago. It's been about 150 ft from my actual location, which has, of course, made a mess of my GPSDO. Well, at least it verified my unlock code. I did a POR and it seemed to come home, but now it's off to the races again. Has anyone else seen this behavior with this device? The only particular anomaly I can see is that it uses satellites close to the horizon for position fixing.I'm getting a reported SNR of 39 at 5 degrees elevation and 37 at 3 degrees, though I notice the sat at 3 degrees is not being used to calculate position. I never got around to finishing the choke ring antenna with those pie pans. Maybe that needs to move higher on my priority list. 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] Adafruit (MT3339) problems today
Hi Jim, Could you give me a bit more information on using WAAS? I disabled gpsd and then ran the command (gpsctl -x PMTK301,2 /dev/ttyS1) which I thought would enable WAAS, but xgps shows that PRN51 is not in use. At least I think that PRN51 should show active with WAAS enabled. But I am totally clueless about this. In 2000 words or less, what am I missing? =) Sometimes I wonder if gpsd is meddling with things and causing me problems, in spite of their stated goal of non-interference. Bob From: Jim Harman j99har...@gmail.com To: Bob Stewart b...@evoria.net Sent: Thursday, April 10, 2014 5:25 PM Subject: Re: [time-nuts] Adafruit (MT3339) problems today Mine would do that when the antenna was indoors. It is much more stable since I put it outdoors on a windowsill. Do you have WAAS or equivalent available? Enabling that helped my stability as well. On Apr 10, 2014 5:51 PM, Bob Stewart b...@evoria.net wrote: My Adafruit has gone walkabout again. This is a different unit than the one I spoke about some months ago. It's been about 150 ft from my actual location, which has, of course, made a mess of my GPSDO. Well, at least it verified my unlock code. I did a POR and it seemed to come home, but now it's off to the races again. Has anyone else seen this behavior with this device? The only particular anomaly I can see is that it uses satellites close to the horizon for position fixing.I'm getting a reported SNR of 39 at 5 degrees elevation and 37 at 3 degrees, though I notice the sat at 3 degrees is not being used to calculate position. I never got around to finishing the choke ring antenna with those pie pans. Maybe that needs to move higher on my priority list. 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] First success with very simple, very low cost GPSDO
FWIW, I set the DAC to midpoint and use a binary search to get to frequency. On my system, I start off with a change of 0x80 and work my way down to 0x04 in powers of 2 (0x80, 0x40, 0x20, etc). Once I get to 256 seconds between DAC changes, I light the PLL fuse. I could probably get away with less than 256 seconds. Before I built the TIC, I worked down to 0x01 which resulted in pretty long times between changes. Bob From: Chris Albertson albertson.ch...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, April 10, 2014 6:05 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO On Thu, Apr 10, 2014 at 10:55 AM, Charles Steinmetz csteinm...@yandex.comwrote: Why even try to discipline an OCXO before it's warm? Just leave the control loop off for a predetermined time at startup. You can light up a bright red unlocked LED, and even inhibit the 10 MHz output until lock is achieved if you want. Even if you wait long enough you still need to set the DAC to something as a first try. What if your first guess is off by a large amount. The answer is not to guess better because you still need some way to determine if the guess is correct. Alternatively, you could figure out the EFC voltage needed to zero the cold oscillator How to do that? Can you write code to do this without counting overflows? You can be off by 256 cycles and never know it. Let's assume someone is building a GPSDO because they need a frequency reference and don't have one. A good assumption, I think. How could such a person figure out the EFC voltage needed with out either coining cycles? I'm thinking about turning the overflow counter off after lock. But without one I think we have a chicken and egg problem where you would need an accurate frequency reference to build a GPSDO. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] First success with very simple, very low cost GPSDO
The only thing I need to know, in fact the only thing available to me, is the fact that a phase crossing has occurred. Since 10MHz is 0x989680, then all I need to know is whether my timer delta is above, equal to, or below 0x9680, without regard to anything else. None of the other 0x9680 points are within the range of my oscillator. In fact, they are way out of range. There are two conditions that can happen with this type of counter which someone else spoke about. In the one case, you are sitting right on the phase point, and the timer will bounce back and forth, from 0x967F to 0x9681; i.e. you will have a limited amount of phase information. In the other, you are not near the phase point, and you will get just the frequency result. The problem with sitting right on the phase point is that it tricks you into thinking you are getting more out of the system than you actually are. But, you are only getting a few nanoseconds, i.e. a few degrees, worth of phase information. Once the system drifts out of that little phase band, then all you know is which way it drifted, not how quickly or how far. I spent far too many tens of hours thinking I could solve the problem. I couldn't. There's just not enough information available to you. You have to resort to guessing, based on what you know about your oscillator. But you can't be right enough in your guess to make a reliable phase control. So, at least for me, it sits on phase for quite awhile, then it drifts off, your PLL stops, and you wait till you drift back to the phase point. Rinse, repeat, fail. But, it's always possible that you can see something in the data that I didn't. Bob From: Chris Albertson albertson.ch...@gmail.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, April 10, 2014 11:33 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO On Thu, Apr 10, 2014 at 4:52 PM, Bob Stewart b...@evoria.net wrote: FWIW, I set the DAC to midpoint and use a binary search to get to frequency. On my system, I start off with a change of 0x80 and work my way down to 0x04 in powers of 2 (0x80, 0x40, 0x20, etc). Once I get to 256 seconds between DAC changes, I light the PLL fuse. I could probably get away with less than 256 seconds. Before I built the TIC, I worked down to 0x01 which resulted in pretty long times between changes. The point i not how to search but how to know if the current frequency is larger or smaller then the desired 10MHz WITHOUT counting all 10,000,000 cycles. The proposal was that could let the timer overflow many times, ignore those overflows and I need to look only at the last 5 or 6 bits of the timer after the PPS interrupt. I agree now that I can, under tightly limited conditions, but I claim in your case, while doing a binary search I must count all 10,000,000 cycles. So at each cycle in your binary search what data do you need to decide if the frequency is high or low? -- 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] First success with very simple, very low cost GPSDO
I did a poor job of explaining this. So, consider the phase point as where you are on the PPS coming in compared to your oscillator. That PPS is not corrected for sawtooth. So, when you have a regular sawtooth PPS, then at the phase point you will see the count bouncing back and forth. But, then a ramp or a hanging bridge comes along and you no longer know where the phase is WRT where where you are. You also don't know how long it's going to be there, or even whether you were at the actual phase center point and it's now on a hanging bridge, or that you were on a hanging bridge on one side and it's now gone to center, a bridge on the other side, or back to a sawtooth that averages to zero. That's probably still pretty poorly said, but it's way past my bedtime. Bob From: Bob Stewart b...@evoria.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, April 11, 2014 12:20 AM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO The only thing I need to know, in fact the only thing available to me, is the fact that a phase crossing has occurred. Since 10MHz is 0x989680, then all I need to know is whether my timer delta is above, equal to, or below 0x9680, without regard to anything else. None of the other 0x9680 points are within the range of my oscillator. In fact, they are way out of range. There are two conditions that can happen with this type of counter which someone else spoke about. In the one case, you are sitting right on the phase point, and the timer will bounce back and forth, from 0x967F to 0x9681; i.e. you will have a limited amount of phase information. In the other, you are not near the phase point, and you will get just the frequency result. The problem with sitting right on the phase point is that it tricks you into thinking you are getting more out of the system than you actually are. But, you are only getting a few nanoseconds, i.e. a few degrees, worth of phase information. Once the system drifts out of that little phase band, then all you know is which way it drifted, not how quickly or how far. I spent far too many tens of hours thinking I could solve the problem. I couldn't. There's just not enough information available to you. You have to resort to guessing, based on what you know about your oscillator. But you can't be right enough in your guess to make a reliable phase control. So, at least for me, it sits on phase for quite awhile, then it drifts off, your PLL stops, and you wait till you drift back to the phase point. Rinse, repeat, fail. But, it's always possible that you can see something in the data that I didn't. Bob ___ 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] Adafruit (MT3339) problems today
Hi Magnus, Yeah, there's no getting over the fact that it's a cheap $30 (or whatever it was) nav receiver. But I think the walkabout issue has been resolved. I think this thing is going to be OK for me, but I certainly wouldn't even give it a glance for professional use. Now that I've got the basic PLL code working with the new TIC, I'm starting to expand what I'm monitoring. There seems to be such a close connection between when it wanders around and when there are blips on the phase that I'm going to add position change monitoring shortly. Who knows? Maybe I can tune it out with the poor man's sawtooth that I've asked about. Yeah, I know. Just wrinkle your nose or look away in disgust if it bothers you. =) My goal is to see what I can get out of this; not what I can get for a few hundred dollars more. The project is more important to me than the result. I don't really have a concrete use for an accurate timebase. But, I have to say that after I've learned what I can with this, I'll probably look for something better; like maybe an LEA-4T or whatever I can get for cheap. I don't like the UT+ I have. Comms is overly finicky to get started. In fact, I don't even have a reliable way to do it after a cold start. And I don't like the +/- 52ns sawtooth. Bob From: Magnus Danielson mag...@rubidium.dyndns.org To: time-nuts@febo.com Sent: Friday, April 11, 2014 2:49 PM Subject: Re: [time-nuts] Adafruit (MT3339) problems today On 10/04/14 23:48, Bob Stewart wrote: My Adafruit has gone walkabout again. This is a different unit than the one I spoke about some months ago. It's been about 150 ft from my actual location, which has, of course, made a mess of my GPSDO. Well, at least it verified my unlock code. I did a POR and it seemed to come home, but now it's off to the races again. Has anyone else seen this behavior with this device? The only particular anomaly I can see is that it uses satellites close to the horizon for position fixing.I'm getting a reported SNR of 39 at 5 degrees elevation and 37 at 3 degrees, though I notice the sat at 3 degrees is not being used to calculate position. I never got around to finishing the choke ring antenna with those pie pans. Maybe that needs to move higher on my priority list. Can you raise the elevation limit? Low elevation causes many problems, multi-path is certainly one but massive tropospherical delay errors. Maybe we should look at a bare minimum requirement for GPSDO-use? 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.
[time-nuts] NTP and Oncore UT+
I've done as much as I can do with my little Adafruit, so I guess it's time to move to a timing receiver. I already have a UT+, so I might as well make use of it. My thought was to use the NTP refclock driver and probably take the sawtooth from SHMEM with a simple C program to pass to my GPSDO. The reference pages indicate that a PPS interface is required. Do I need to wire up the PPS just to get access to the sawtooth value, or can I just hook up serial access to the UT+ and use NTP as an interface to the UT+? I have no experience with setting up a refclock driver, so any help would be appreciated. Using NTP certainly looks a lot easier than figuring out why this UT+ doesn't always like to talk on the serial port and writing custom code to do the bits I want. The PPS from the UT+ will, of course, be connected to my GPSDO board. From the manual: The driver requires a standard PPS interface for the pulse-per-second output from the receiver. The serial data stream alone does not provide precision time stamps (0-50msec variance, according to the manual), whereas the PPS output is precise down to 50 nsec (1 sigma) for the VP/UT models and 25 nsec for the M12 Timing. If you do not have the PPS signal available, then you should probably be using the NMEA driver rather than the Oncore driver. 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] NTP and Oncore UT+
Hi Bob, There seems to be some issue with this UT+ that I haven't dealt with. After a cold boot it does not like to start up the comms. There is apparently some handshake procedure to get it all up properly, as the demo version of SynTac's software didn't have any problem with getting it going last summer. I just don't know what the proper sequence of probes is to boot it. Since it's been off of battery power for many months, I assume it's going to come up mute when I wire it in again. It always has before when the battery is disconnected. My assumption was that NTP would know the secret handshake. Writing the software to extract the sawtooth is no big deal. It has version 2.2 of the firmware. Bob From: Bob Camp li...@rtty.us To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, April 19, 2014 5:17 PM Subject: Re: [time-nuts] NTP and Oncore UT+ Hi If you have a serial “thing” hooked to the GPS, pulling the sawtooth data out of it is not very hard. They all have some sort of repeating message that contains time / date / sawtooth information. Bob ___ 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] NTP and Oncore UT+
Hi Bob, Somehow I missed that page in all the times I looked through the Oncore manuals I have. I see various commands to tell it to change this or change that, but no clear path on how to talk to a UT+ that is mute but not bricked. I'll go back through the PDFs I have. Maybe I just don't have the right document. Bob From: Bob Camp li...@rtty.us To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, April 19, 2014 7:03 PM Subject: Re: [time-nuts] NTP and Oncore UT+ Hi There are a series of init strings you send to any of these modules to get them into the “right” mode. There’s nothing secret about it. It’s all in the manuals for what ever board you have. You decide what you want it to send you and then tell it what to do. Bob On Apr 19, 2014, at 6:41 PM, Bob Stewart b...@evoria.net wrote: Hi Bob, There seems to be some issue with this UT+ that I haven't dealt with. After a cold boot it does not like to start up the comms. There is apparently some handshake procedure to get it all up properly, as the demo version of SynTac's software didn't have any problem with getting it going last summer. I just don't know what the proper sequence of probes is to boot it. Since it's been off of battery power for many months, I assume it's going to come up mute when I wire it in again. It always has before when the battery is disconnected. My assumption was that NTP would know the secret handshake. Writing the software to extract the sawtooth is no big deal. It has version 2.2 of the firmware. Bob From: Bob Camp li...@rtty.us To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, April 19, 2014 5:17 PM Subject: Re: [time-nuts] NTP and Oncore UT+ Hi If you have a serial “thing” hooked to the GPS, pulling the sawtooth data out of it is not very hard. They all have some sort of repeating message that contains time / date / sawtooth information. Bob ___ 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] NTP and Oncore UT+
Thanks Paul. As I mentioned to Bob, I'll look through that. I can still picture in my mind the code that does the startup. I just reached my aggravation saturation point with it last summer and put in the Adafruit. Bob From: Paul tic-...@bodosom.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, April 19, 2014 9:36 PM Subject: Re: [time-nuts] NTP and Oncore UT+ On Sat, Apr 19, 2014 at 9:18 PM, Bob Stewart b...@evoria.net wrote: Somehow I missed that page in all the times I looked through the Oncore manuals I have. I see various commands to tell it to change this or change that, but no clear path on how to talk to a UT+ that is mute but not bricked. You could just reference the NTP refclock driver. It determines the model and does appropriate initialization. It's a bit more flexible than some drivers since it uses a configuration file rather than just a mode selector. I suspect the sawtooth data is in the special status file. * Driver for some of the various the Motorola Oncore GPS receivers. * should work with Basic, PVT6, VP, UT, UT+, GT, GT+, SL, M12, M12+T * The receivers with TRAIM (VP, UT, UT+, M12+T), will be more accurate * than the others. * The receivers without position hold (GT, GT+) will be less accurate. ___ 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 and holdover
Hi Tom, Thanks for confirming that these lost PPS pulses are happening to someone else! I've looked through my interrupt code several times to see if I'm missing something. Please let me know if you find anything for sure. I've been thinking of saving the values for the satellites at each tick to see if it's related to AOS/LOS, but there's been too much else to do. I've already faced most of the points you make, and yeah, the decision on whether to have ideal time or ideal frequency has been a difficult one. But, there's only so much I can do with a nav receiver. I'll address it when a timing receiver goes in. I think I'll go ahead and loosen up my definition of what holdover is, as a strict interpretation seems to cause more damage than it prevents. Bob From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, April 22, 2014 8:57 PM Subject: Re: [time-nuts] GPSDO and holdover Hi Bob S, I have noticed skipped 1PPS on the Adafruit GPS also. Some days are clean, other days miss a few samples. I have not explained it yet. I plan to run two GPS boards and two counters to narrow down the cause. In any event, IMHO, a GPSDO should not go crazy if glitches like this occur. I don't think it should go into holdover for one missed sample, or even a few missed samples. But then you need to define what holdover is. I mean, by some definition a GPSDO is in holdover between every second. I do not think there is any standard. Just conventions: some documented, some not. It's attention to a dozen little details like this that separate a quick hack GPSDO from a quality one. You'll also face a number of design issues at startup, and coming out of holdover. Lastly, you get to choose between it being an ideal time standard vs. an ideal frequency standard. /tvb p.s. Please fix your address book. The correct email for the list is time-nuts@febo.com - Original Message - From: Bob Stewart To: time-nuts-ow...@febo.com Sent: Tuesday, April 22, 2014 6:03 PM Subject: GPSDO and holdover I hope I haven't asked this before, but is there a standard way of deciding to go into holdover mode? I'm still wrapping up code for this Adafruit, and as I've posted before: every now and then it skips a PPS. I'm trying to decide whether to allow a free pass (if not followed by another skip within some timeframe) or to immediately stop processing any further PPS pulses until I decide based on some criteria that they're reliable. 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 and holdover
I mentioned to Tom that I had seen the xgps program duplicate a lot of its satellites when I missed a PPS. I noticed my GPSDO go into holdover so I quickly brought up xgsp and noticed it happening again. This screen showed a few times intermixed with a normal screen. I have no idea whether it's a bug in xgps or due to something coming from the Adafruit, but it's interesting, nonetheless. http://www.evoria.net/Adafruit/Holdover.png Bob - AE6RV From: Paul tic-...@bodosom.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, April 25, 2014 1:20 PM Subject: Re: [time-nuts] GPSDO and holdover On Tue, Apr 22, 2014 at 9:57 PM, Tom Van Baak t...@leapsecond.com wrote: I have noticed skipped 1PPS on the Adafruit GPS also. I've always assumed this could happen but as a result of RF signal loss not a glitch in the gps. So I've started recording event timestamp deltas using the Linux kernel PPS interface. I read assert events (e.g. 1398449188.001000242#1741672) and compute timestamp and event deltas. If the t delta is .9 something horrible must have happened and if it's 1 some didn't happen assuming the event count delta is always 1. I wonder if this is a reasonable approach or if I'm being lazily optimistic. I just started (and I haven't added a join with the valid fix indicator yet) but I've had two missing pulses in the last 24 hours. ___ 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] New timing receivers?
Given the state of the GPS chip, would it really take that big an investment to just add in the firmware to do timing? Or have the manufacturers just made a marketing decision to keep that a high end market as long as they can? Bob From: Bob Camp li...@rtty.us To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, April 26, 2014 7:27 PM Subject: Re: [time-nuts] New timing receivers? Hi There are a number of timing receivers on the market. They still are a very small percentage of the total units sold. A lot of people play with the uBlox parts. Bob ___ 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] 3339 Interface for Linux? - was New timing receivers?
I was wondering if anyone has a decent interface to the Adafruit and related receivers for Linux? By that, i mean something like the Windows tools that Globaltop provides, or even just the ability to separate out the responses to the PMTK commands from the NMEA traffic. Bob - AE6RV From: Jim Harman j99har...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, April 28, 2014 2:45 PM Subject: Re: [time-nuts] New timing receivers? On Mon, Apr 28, 2014 at 1:08 AM, Mark Sims hol...@hotmail.com wrote: When I was playing with an Adafruit GPS, it appeared that if it thought you were not moving it would go into a pseudo-position-hold mode and the output coords would not change. It took it a while to start outputting new coords when you started moving again. This test was at walking speeds. I had to walk maybe 100 feet before it started sending new coords. The 3339 chip has a command PMTK386 to set its Nav Speed Threshold. This is intended to prevent the position from drifting if the unit is stationary. You can also query the current setting with the PMTK447 command, and it should respond with a PMTK527. ___ 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] New timing receivers?
Tom, Any progress on the Adafruit PPS study? (Hope this isn't a dupe. Yahoo's mail scripts have problems today.) Bob From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, April 28, 2014 1:56 PM Subject: Re: [time-nuts] New timing receivers? I don't see that behavior. Looking at ~24 hours of data I have 1,024 unique (x,y) coordinates (as reported by the GGA sentence). The standard deviation of the error relative to the median (x,y) position is 1.2 meters. Paul, I agree. I have 30 days of Adafruit data; the position is never quite static, bounces around over a couple of meters as one would expect for a receiver in 3D mode. Send me email off-list for details about lat/lon/alt RMS deviation and scatter plots. On the other hand, I have a second identical Adafruit receiver with distinctly different deviation patterns. I'm working through that mystery now. Nothing with this hobby ever ends up being a simple quick test. Thanks, /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] PIC Programmer for Piklab in Linux?
Can anyone suggest a PIC programmer that will work with Piklab on Linux? The replacement serial board I just bought won't drive my JDM Classic PIC programmer. It doesn't reliably drive my LIRC IR transmitter either, so I have to devote the serial port on my motherboard to LIRC. My GPSDO development is stalled until I can get something that works. 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] PIC Programmer for Piklab in Linux?
I neglected to mention that I'm pretty much limited to USB or ethernet (if such a programmer exists) at this point. Bob From: Bob Stewart b...@evoria.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, May 14, 2014 6:15 PM Subject: [time-nuts] PIC Programmer for Piklab in Linux? Can anyone suggest a PIC programmer that will work with Piklab on Linux? The replacement serial board I just bought won't drive my JDM Classic PIC programmer. It doesn't reliably drive my LIRC IR transmitter either, so I have to devote the serial port on my motherboard to LIRC. My GPSDO development is stalled until I can get something that works. 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] PIC Programmer for Piklab in Linux?
Hi Rudolf, The Pickit2 configuration choices were a bit confusing, so I decided to order a different serial board that contains actual 16550s. Now that I've had a chance to assimilate what I've learned, the problem is traced to the 3 Volt 3243 chips that are in today's serial boards. After doing more searching, I found a post by Roberto, EB4EQA on QSL.net where he made an booster to get around the problem. If the new serial board doesn't work out, Roberto's booster looks simple enough to hack together and I can continue to put off switching from my trusty old JDM. I may make 2 of them so I can get LIRC pulled off of the motherboard port, as well. http://www.qsl.net/eb4eqa/serial_booster/serial_booster.htm Bob From: Rudolf Bodocsi rud...@bodocsi.net To: time-nuts@febo.com Sent: Sunday, May 18, 2014 1:27 AM Subject: Re: [time-nuts] PIC Programmer for Piklab in Linux? Hi, You can use Pickit2 usb programmer. I used in ubuntu without any problem. Piklab can use with 1.x firmware version. If you want to use Pickit2 with latest firmware than you need to use microchip linux program. 73, Rudolf ___ 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] New tide gauge uses GPS signals to measure sea level change
Hal, you bring up an interesting point: Is the receiver in a Z3801 inherently more accurate in position reporting than the receiver in an Adafruit? Somehow I doubt it, if for no other reason than the improvements in technology. (Excluding any programming errors that may or may not exist in the MT3339.) What the Z3801 has that the 3339 doesn't have is code to accurately calculate the PPS timing error based on a fixed position. So, if my reasoning is correct, wouldn't you do better running the Adafruit X number of days and doing an average of the position over that period? Bob From: Hal Murray hmur...@megapathdsl.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Cc: hmur...@megapathdsl.net Sent: Wednesday, May 28, 2014 4:32 PM Subject: Re: [time-nuts] New tide gauge uses GPS signals to measure sea level change thol...@woh.rr.com said: I'm not sure my Z3801 or any of my navigation receivers have the necessary resolution to see even 10 mm. In normal operation (post survey), a Z3801A knows the location and uses that to work out a better time and/or the time with fewer satellites. So you won't be getting any new location data. It might be interesting to set one up in a loop to do a survey, grab the location, then repeat. After a day or week, you could average the locations and/or compute std dev and such. ___ 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] Audio DAC for GPSDO?
Now that my TIC is working with Bert's board, I'm considering taking the next step of designing a GPSDO from scratch. There are several projects I'd like to do with a dsPIC33, so that was a natural choice. But I now understand that it has an audio DAC and is not recommended for process control. Could someone explain to me how such an audio DAC differs from a non-audio DAC and why it's not suitable for this application? Is this just a disclaimer from microchip to avoid liability or is there some practical reason to go with a traditional DAC? On reading through the various datasheets, it appears to me that the concern might be that the input data to the DAC might be interrupted, thus causing it to go to some programmable safe output voltage. My initial thought was just to control the value of the safe voltage and not bother to feed the DAC, though I haven't really explored the idea. 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] Audio DAC for GPSDO?
Hi Poul, I've been reviewing microchips literature and the way I read it is that the DAC isn't sensitive to staying at a fixed value. If it's on, the FIFO is fed to the DAC. If the FIFO is drained, then the user-settable default value is fed to the DAC. When the output amp is turned off, it goes to a high impedance output. I also noticed that Finput can vary from 0-45 khz. I'm not certain what a 61db SNR would mean at DC values. I see that the specifications are for a 15 uA load. I assume that's not hard to meet with a typical op-amp. It's interesting that in one paragraph they call the DAC default register a safety feature for industrial control applications, and then a few inches later a black box warns that it's not recommended for control type applications. Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, June 2, 2014 4:08 PM Subject: Re: [time-nuts] Audio DAC for GPSDO? In message 1401742940.44103.yahoomail...@web142705.mail.bf1.yahoo.com, Bob Stewart writ es: Could someone explain to me how such an audio DAC differs from a non -audio DAC and why it's not suitable for this application?=A0 Is this just a disclaimer from microchip to avoid liability or is there some practical reason to go with a traditional DAC? A lot of them have DC protections, so you can't leave them at a particular input value for very long before they go into safety mode and clamp the output to zero. Your speakers love them for this, your OCXO not so much. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Audio DAC for GPSDO?
Hi Bob, I decided to look at Mouser for 16-bit DACs, and found the MAX541CCPA for $12.47. On the one hand, it's an extra $12.47 for the project. On the other, the dsPIC is a 3.3V device. I'll have to give some thought as to whether I want to lose that much output range between the DAC and the EFC divider which will be placed right at the OCXO. Given the flexibility of the dsPIC33 pin remapping, I may just add it to the board but jumper around it at first. Hmm, I could just place it right at the OCXO, since I need to communicate with it with SPI. TBH, I don't think I have the equipment needed to measure the noise unless it's really bad. I'm already way past my ability to measure with my TIC daughterboard added to the VE2ZAZ board. This is all new territory for me. Should be fun. =) Bob From: Bob Camp kb...@n1k.org To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, June 2, 2014 8:01 PM Subject: Re: [time-nuts] Audio DAC for GPSDO? Hi There are several reasons why they don’t recommend the typical MCU DAC for control applications: 1) They are noisy at low frequency (1/f noise corner). That impacts their hitting their INL and DNL specs. 2) They have constant current leakage at DC. That makes their “center” value wander around by more than the spec’s would suggest. 3) The major steps are trimmed for AC (high sample rate) compensation (the trim includes capacitance effects). At DC … no capacitance effects. Yes it’s all one big mess and the effects slop back and forth between the categories. Bottom line - they very much do not want you to measure their INL and DNL numbers on a continuous DC basis and then return the parts as being out of spec. MCU ADC’s can have some of the same issues. Even some pretty fancy outboard ADC’s only work well at DC if you put a chopper around them. Bob On Jun 2, 2014, at 7:22 PM, Bob Stewart b...@evoria.net wrote: Hi Poul, I've been reviewing microchips literature and the way I read it is that the DAC isn't sensitive to staying at a fixed value. If it's on, the FIFO is fed to the DAC. If the FIFO is drained, then the user-settable default value is fed to the DAC. When the output amp is turned off, it goes to a high impedance output. I also noticed that Finput can vary from 0-45 khz. I'm not certain what a 61db SNR would mean at DC values. I see that the specifications are for a 15 uA load. I assume that's not hard to meet with a typical op-amp. It's interesting that in one paragraph they call the DAC default register a safety feature for industrial control applications, and then a few inches later a black box warns that it's not recommended for control type applications. Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, June 2, 2014 4:08 PM Subject: Re: [time-nuts] Audio DAC for GPSDO? In message 1401742940.44103.yahoomail...@web142705.mail.bf1.yahoo.com, Bob Stewart writ es: Could someone explain to me how such an audio DAC differs from a non -audio DAC and why it's not suitable for this application?=A0 Is this just a disclaimer from microchip to avoid liability or is there some practical reason to go with a traditional DAC? A lot of them have DC protections, so you can't leave them at a particular input value for very long before they go into safety mode and clamp the output to zero. Your speakers love them for this, your OCXO not so much. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] CGSIC: Known Problem With Certain GPS Devices
There was a recent discussion with the above subject line about SVN-64. I've noticed that my Adafruit hasn't given me any holdovers for a few days, so I checked on the sat's status. The link below says it's been usable since May30. Hmmm. http://www.navcen.uscg.gov/?Do=gpsShowNanunum=2014047 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] dsPICs and GPSDOs
Once I got my TIC going, I suppose it was inevitable that I build a GPSDO with a dsPIC33. I have a few dsPIC specific questions for anyone who designs with them. 1. VCAP. The datasheet says that it should be a surface mount device. I had hoped to avoid those. Can I get away with a 10uf tantalum placed at .1 from the pin? I'm using a 28-pin DIP dsPIC, which will probably be socketed. 2. The datasheet suggests an inductor between AVDD and VDD. Given that I'll only be reading the ADC twice a second (PPS and temps), can I just use the straight wire that I have already penned in? I'm starting to run out of board space. As to why I'm using a dsPIC: the one I chose has a number of features that suit me, such as 2 UARTs, SPI, buffered ADC, (audio) DAC, and especially relocatable pins. To be honest, I don't know whether this will result in a general purpose GPSDO engine (with sawtooth correction) or a smoke machine, but I'm hoping for the best. I'll try to resist the temptation to make more posts until I have a completed project. 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?
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?
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?
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.
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?
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.
Re: [time-nuts] Loran, GPS, Lightning, Timing
You might be thinking of the file that David Byrne sent to the HP list last year on 9/7/13. It was an article by C. L. Stong and I think it was published in The Amateur Scientist in 1963. You should be able to find it in the HP list archives. Bob From: Max Robinson m...@maxsmusicplace.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, June 27, 2014 11:14 AM Subject: Re: [time-nuts] Loran, GPS, Lightning, Timing I think the QST article being referred to in this thread is one that I remember rather clearly. I kept the issue for a long time but it got away from me somewhere along the line. It was a lightening direction finder using a display much like a radar PPI. It used two crossed untuned loops and a vertical. All three signals were amplified using tubes and one of the loops was fed to the horizontal deflection plates of a CRT and the other loop's signal was fed to the vertical plates. The signal from the vertical was fed to the control grid of the CRT. The project was essentially an XY scope built from the ground up. He suggested figuring out the polarity of things by waiting for close lightening that was visible and correlating sightings with the display on the CRT. You wouldn't use a general purpose scope because the fair weather condition would burn a spot in the center of the screen. One more thing. He wound the loops in hula hoops he had cut open. I still have two hula hoops awaiting the project. The bandwidth of his amplifiers was low audio to about 100 kHz. I suspect that in today's radio environment some tuned traps would be necessary to notch out some of the strong signals in that frequency range. You now have all the information I have and I am sure I could build one if only I could find the time. Regards. Max. K 4 O DS. ___ 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] Magnetic Resonance Spectromater; was Re: Loran, GPS, Lightning, Timing
There's an interesting (and on topic) project in that book starting on page 335, discussing a home-made Magnetic Resonance Spectrometer. I wonder if any time-nuts have constructed such a device, and what potential accuracy it would have? Bob - AE6RV From: DaveH i...@blackmountainforge.com To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Saturday, June 28, 2014 1:09 PM Subject: Re: [time-nuts] Loran, GPS, Lightning, Timing A PDF of the 1960 book can be found here: http://www.sciencemadness.org/library/books/projects_for_the_amateur_scienti st.pdf 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] FASTRAX GPS
Jim, Are you trying to find out how to hook up a receiver in your office/radio room to an antenna that is some ways away? Or are you specifically trying to remotely hook up a receiver near your antenna? If the former, just use RG-6, like for cable TV, with adapters on each end. RG-6 has such low loss that the impedance change is not an issue. I've got a 30+ ft run up to the attic to a cheap GPS puck antenna for my setup. Others have much longer runs and it works OK. Bob From: jim s jwsm...@jwsss.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, July 1, 2014 4:56 PM Subject: Re: [time-nuts] FASTRAX GPS I went back thru this thread to look for the answer, and did not see it so am asking. The one of these I have has a threaded female connector on it. One of the ones in Tom's page has a smooth sided connector, FWIW. I wonder if this would work with one of the 5m SMA male active antenna units will work with it? http://www.ebay.com/itm/321295751672 This one happens to be 5 meters long and is active. I am guessing because the unit has antenna power this is the sort of item to use? I want a long run because where I plan to use it is some distance from clear line of site. thanks Jim On 6/20/2014 8:31 AM, Tom Van Baak wrote: Hi Ernie, Jason, (also Hal, Chris), I'm able to get NMEA and 1PPS out of the Fastrax/iTrax130 board now. Before I sink any more time into this project, have any of you made 1PPS measurements? Compared to ublox, using the same antenna, these units take tens of minutes or even hours to lock. And they have a bad habit of being close to UTC for a few hours but then gradually wandering off by tens or hundreds of microseconds. A power cycle puts them back on track (aligned with UTC), so it would seem to be a firmware issue rather than antenna or reception. A similar thing happens on three different boards I have evaluated over the past two weeks. Now, when they are working right, the 1PPS has an RMS deviation of around 20 ns, which I've come to expect as typical for cheap GPS/1PPS receivers these days. But the long lock times and unexplained 1PPS drift make them unreliable for GPSDO or serious timing work, even at $12 each. It might be me, so I'm asking if you've seen anything similar. The binary command set looks tempting, but I usually don't play with that until the unit can be trusted to give reliable NMEA and 1PPS output. Unfinished page: http://leapsecond.com/pages/itrax/ /tvb - Original Message - From: Ernie Peres erniepe...@aol.com To: time-nuts@febo.com Sent: Wednesday, June 11, 2014 4:11 AM Subject: Re: [time-nuts] FASTRAX GPS Hi Jason, I figured out a different pin assignments hold the PCB so that the SMA antenna connector is looking to right and under the PCB. open- 1 2- Ant power presently connected to pin nbr 4 TX- 3 4- Main power +3 volt RX- 5 6- 1PPS open- 7 8- Grnd power -3 Volt the unit takes about 60mA @ 3,0 volt and comes-up in NMEA mode.. 9600 Baud. I use the FASTRAX_WORKBENCH_522 software. I wonder if anybody has other pin arrangement/connection. The 2 open pins is UNK and also not sure if pin nbr 4 is the main power or perhaps the pin nbr 2..?? Rgds Ernie. ___ 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] FASTRAX GPS
Jim, I'm a rather junior member of the list, but I wouldn't try to move 1PPS over that kind of distance; especially when it's so easy to put the receiver right next to what needs the 1PPS. The pros are too small and the cons are too great. There are a couple of vendors on ebay who sell F to SMA adapters. But, a warning: from experience I have found that the RG6 is stiff and the SMA male adapter is fragile. While moving your unit around, it's all to easy to snap the adapter off your unit. It's a few more bucks, but consider getting a short F female to SMA male pigtail instead of just a machined adapter. I assume that it's not a problem on the antenna end, since you're not connecting to a bulkhead connector. In my house, I put the antenna in the attic, and snaked the RG6 through the same opening that the DirecTV cable came through. I changed the wall plate to add another F connector. From there is a short run of RG6 to my splitter, and then a few feet of RG316 to my receiver. Bob From: jim s jwsm...@jwsss.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, July 2, 2014 12:17 AM Subject: Re: [time-nuts] FASTRAX GPS Bob, I was being a bit lazy. The 15' distance gets from a couple of spots in the room with my systems and lab, and also is already terminated, and there is no issue with the power since it would be totally contained in the unit. But your suggestion and some work making the cables would work best. To you and Hal who suggested it, is this unit suitable for outputing a 1pps timing signal? Wouldn't the long serial option Hal suggestion mess that up, vs. using this method to put the Fastax as close as possible to a system which which would have the systems gpio and serial ports attached? Thanks to you both for answering. jim On 7/1/2014 9:30 PM, Bob Stewart wrote: Jim, Are you trying to find out how to hook up a receiver in your office/radio room to an antenna that is some ways away? Or are you specifically trying to remotely hook up a receiver near your antenna? If the former, just use RG-6, like for cable TV, with adapters on each end. RG-6 has such low loss that the impedance change is not an issue. I've got a 30+ ft run up to the attic to a cheap GPS puck antenna for my setup. Others have much longer runs and it works OK. Bob ___ 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] Magnetic Resonance Spectrometer - redux
First, an apology. When I changed the topic on my original post, I thought that would be OK. Apparently that's still a thread-jacking. Sorry. I'm still interested in this Magnetic Resonance Spectrometer thing, though. On page 335 of the pdf linked below by Dave, there's an experiment with an MRS using water and the magnet from a magnetron available back then. Apparently the resonant frequency of hydrogen nuclei in water is 6.131325 MHz in that magnetic field. Did anyone ever pursue this with the idea of creating a frequency standard, or was the technology just too primitive at the time? Perhaps it's a repeatability problem from the magnetic flux standpoint? I can guess that temperature changes would cause enough of a flux strength change to cause a problem, but that's just a guess. Bob - AE6RV From: DaveH i...@blackmountainforge.com To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Saturday, June 28, 2014 1:09 PM Subject: Re: [time-nuts] Loran, GPS, Lightning, Timing A PDF of the 1960 book can be found here: http://www.sciencemadness.org/library/books/projects_for_the_amateur_scientist.pdf 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] Magnetic Resonance Spectrometer - redux
Thanks Brooke. I'll look into it. It would be interesting to try to develop a frequency standard from a test tube of water. Bob From: Brooke Clarke bro...@pacific.net To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, July 6, 2014 12:20 AM Subject: Re: [time-nuts] Magnetic Resonance Spectrometer - redux Hi Bob: This is very similar to a proton precession magnetometer that measures the total magnetic field, not in vector components. There's a lot of amateur designs for these that you could use as the bases for a MRS. There is an article in the same publication for a tube type frequency standard that can be used to drive a line powered wall clock. The Magnatron magnets were probably Alinco, so if you upgraded to modern magnets it might be much more stable. http://en.wikipedia.org/wiki/Proton_magnetometer http://en.wikipedia.org/wiki/NMR Have Fun, Brooke Clarke http://www.PRC68.com http://www.end2partygovernment.com/2012Issues.html http://www.prc68.com/I/DietNutrition.html Bob Stewart wrote: First, an apology. When I changed the topic on my original post, I thought that would be OK. Apparently that's still a thread-jacking. Sorry. I'm still interested in this Magnetic Resonance Spectrometer thing, though. On page 335 of the pdf linked below by Dave, there's an experiment with an MRS using water and the magnet from a magnetron available back then. Apparently the resonant frequency of hydrogen nuclei in water is 6.131325 MHz in that magnetic field. Did anyone ever pursue this with the idea of creating a frequency standard, or was the technology just too primitive at the time? Perhaps it's a repeatability problem from the magnetic flux standpoint? I can guess that temperature changes would cause enough of a flux strength change to cause a problem, but that's just a guess. Bob - AE6RV From: DaveH i...@blackmountainforge.com To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Saturday, June 28, 2014 1:09 PM Subject: Re: [time-nuts] Loran, GPS, Lightning, Timing A PDF of the 1960 book can be found here: http://www.sciencemadness.org/library/books/projects_for_the_amateur_scientist.pdf 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. ___ 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] FASTTRAX GPS Antenna power
I'm a bit confused about what you're asking. You discuss antennas but you show pictures of a GPS receiver. They're not the same thing. I use a puck antenna. They cost about $6 on ebay, and take their power from the coax. Normally your GPS receiver supplies power to the coax, so you don't have to do anything special, other than don't short it out. Bob From: jim s jwsm...@jwsss.com To: time-nuts@febo.com Sent: Thursday, July 10, 2014 11:49 PM Subject: [time-nuts] FASTTRAX GPS Antenna power I disobeyed the group suggestions about antennas, and bought one of the one which needs power. I had asked whether I should apply 5 volts to the. tom posted on his fine info page a pinout, which I'm going to use. Pin 1 is 3-5.5VDC Antenna power input. Pin 2 is Prime Power input pin 4 is Backup Power input. Pin 8 is GND I am going to apply 3.3 to 1,2, and 4. Just wanted to get an opinion before trying it. I'm curious if somehow the suggested Primary and Backup power was all that was needed, or how you guys were getting your GPS signals in. Are your antennas not powered? thanks Jim http://leapsecond.com/pages/itrax/ ___ 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] Setting Windows XP clock.
Have you looked into NTP for Windows? Bob From: Max Robinson m...@maxsmusicplace.com To: Time Nuts time-nuts@febo.com Sent: Saturday, July 12, 2014 6:29 PM Subject: [time-nuts] Setting Windows XP clock. As some of you no doubt know microshaft has stopped supporting windows XP. As part of this they have ceased to correct windows XP clocks. This seams rather small of them as it can't possibly be any inconvenience to them to continue to provide this service. I have a program on my old 98 box which runs my weather station program. On boot-up it contacts some place and corrects the system clock. I put it on that machine so long ago I don't remember where I got it or who it contacts. Does anyone know of a program I can download that will do the same for my XP box. I have no intention of upgrading until this box becomes absolutely un-operational. Regards. Max. K 4 O DS. Email: m...@maxsmusicplace.com Transistor site http://www.funwithtransistors.net Vacuum tube site: http://www.funwithtubes.net Woodworking site http://www.angelfire.com/electronic/funwithtubes/Woodworking/wwindex.html Music site: http://www.maxsmusicplace.com To subscribe to the fun with transistors group send an email to. funwithtransistors-subscr...@yahoogroups.com To subscribe to the fun with tubes group send an email to, funwithtubes-subscr...@yahoogroups.com To subscribe to the fun with wood group send a blank email to funwithwood-subscr...@yahoogroups.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. ___ 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] Synergy-GPS SSR-6tru problems
I got one of these recently, along with the adapter board. This is the ublox only version, and I am using u-center version 8.11 software. I am unable to make it work properly. The NMEA section happily sends out messages, but I cannot get anything else to work. e.g. it ignores the commands to turn off antenna power. It ignores the command to put it in Survey-In mode. Nothing is displayed when monitoring the SVIN field. I sent the board back and received one that they have tested there at the site. Same story. When I plug my UT+ into the same connector in my GSPDO, it works just fine and responds properly to commands from WinOncore12. I have used both a serial port adapter and a USB-adapter to drive the TTL lines to the board. So, there is something wrong at my end, and it's probably something so trivial that no-one would think to mention it. Has anyone tried this board? Can you think of any setting that's inherently obvious to the most casual observer that a newbie could repeatedly overlook? For example, is there some first setting that you always do in u-center to shut down the NMEA and turn on the UBX, but the setting does not save on the board and the u-center software always overrides it? The configuration is this: The adapter does the 3V to 5V stuff, and plugs into the same connector as my UT+. The antenna lead is connected to a non-powered port on my GPS Source splitter. The splitter connects to a puck in the attic via RG-6. The SNR of the received signals is in the 20-50 range on the u-center display window. I have tried driving a different puck directly that is in my lab room. No change except for lower SNR values. 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] Synergy-GPS SSR-6tru problems
Art, I don't see that your response is relevant. This board uses the ublox command set. I mentioned the UT+ only in context of the hardware. It plugs into the same socket on my GPSDO. When the UT+ is in, I can control it with WinOncore 12 software with no problems. When the SSR-6tru is plugged in, I am trying to use ublox u-center 8.11 software to control it. It is deaf to all commands, and I do not see a reason. I have an expired version of your SynTac program and it complains of comms errors, though it then happily displays the satellite signal strength; probably from the NMEA broadcasts. I have brought up your SynTac software in a new Windows XP virtual box so that it is not expired. It is not able to control the SSR-6tru. I do not know what the problem is. The UT+ works (with the appropriate software). The SSR-6tru is deaf using all the software I have available to me. I am at my wits end, and I have nothing else that I can think of to try. I did not open this thread to start an argument with Synergy-GPS. I was hoping to get input from someone else who had installed this board with the adapter board and had it working or even who had experienced problems. Bob From: Art Sepin a...@synergy-gps.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, July 15, 2014 5:58 PM Subject: RE: [time-nuts] Synergy-GPS SSR-6tru problems Bob, One of the most obvious things is that the UT+ uses 8 channel Motorola binary commands with the @@Ea Position Status Data command producing the most useful data at start-up. The UT+ did not have a NMEA message capability. Another obvious thing is that the UT+ is an 8 channel device and the SSR-6T responds only to 12 channel Motorola binary commands. A firmware update including the 8 channel @@Ea message (like the UT+) will be available in the coming months. A 6 channel @@Ba command is also being added so that users of legacy HP timing products that used the old VP Oncore will have an up-grade path. Hope this helps. Art Sepin -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob Stewart Sent: Tuesday, July 15, 2014 2:37 PM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Synergy-GPS SSR-6tru problems I got one of these recently, along with the adapter board. This is the ublox only version, and I am using u-center version 8.11 software. I am unable to make it work properly. The NMEA section happily sends out messages, but I cannot get anything else to work. e.g. it ignores the commands to turn off antenna power. It ignores the command to put it in Survey-In mode. Nothing is displayed when monitoring the SVIN field. I sent the board back and received one that they have tested there at the site. Same story. When I plug my UT+ into the same connector in my GSPDO, it works just fine and responds properly to commands from WinOncore12. I have used both a serial port adapter and a USB-adapter to drive the TTL lines to the board. So, there is something wrong at my end, and it's probably something so trivial that no-one would think to mention it. Has anyone tried this board? Can you think of any setting that's inherently obvious to the most casual observer that a newbie could repeatedly overlook? For example, is there some first setting that you always do in u-center to shut down the NMEA and turn on the UBX, but the setting does not save on the board and the u-center software always overrides it? The configuration is this: The adapter does the 3V to 5V stuff, and plugs into the same connector as my UT+. The antenna lead is connected to a non-powered port on my GPS Source splitter. The splitter connects to a puck in the attic via RG-6. The SNR of the received signals is in the 20-50 range on the u-center display window. I have tried driving a different puck directly that is in my lab room. No change except for lower SNR values. 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] Synergy-GPS SSR-6tru problems
Hi Rex, Arts reply wasn't relevant because the board talks ublox rather than Motorola binary. The board has the same footprint as the UT+. You just plug it in. They sell 2 versions: one that talks ublox and one that talks Motorola binary. I got the ublox version so that I'd get some experience with that with the new GPSDO that I'm building. However, my GPSDO is not yet hooked up to the comms on the receiver. The comms is going directly to a PC. When the UT+ is in, I have no trouble controlling it with WinOncore12. When the SSR-6tru (which is an LEA-6T on an adapter board) is plugged in, I should be able to control it with ublox's u-center program. For whatever reason, I can't. They, Synergy, have tested this board on their test platform, using u-center software. It works. I have absolutely no doubt that it works. I've seen screen shots. I just don't understand why it's not working here. There has to be something, probably something quite trivial, that I'm missing. My comms signal is getting onto the board. I can see it with a scope. But, in spite of that, something is still not right. Bob From: Rex r...@sonic.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, July 16, 2014 3:45 AM Subject: Re: [time-nuts] Synergy-GPS SSR-6tru problems I think your story is rather incomplete. You never (to my deduction) told us what you are plugging this into. You mention a GPSDO so I guess that is where it is plugged while not doing what you want, but you never mention what that GPSDO might be. You blew off Art Sepin's reply as not relevant. Why? What is the communication path to the receiver from whatever you are using to send commands? Is it through the GPSDO? If so, it seems to me the communication may not be direct and may be filtered by the GPSDO so the commands you are sending aren't reaching the new board in the way you would like. I never used one of these new boards you are trying to use, but if you want good answers I think you need to tell us exactly what you are plugging it into and through what signal path you are issuing the commands. On 7/15/2014 2:36 PM, Bob Stewart wrote: I got one of these recently, along with the adapter board. This is the ublox only version, and I am using u-center version 8.11 software. I am unable to make it work properly. The NMEA section happily sends out messages, but I cannot get anything else to work. e.g. it ignores the commands to turn off antenna power. It ignores the command to put it in Survey-In mode. Nothing is displayed when monitoring the SVIN field. I sent the board back and received one that they have tested there at the site. Same story. When I plug my UT+ into the same connector in my GSPDO, it works just fine and responds properly to commands from WinOncore12. I have used both a serial port adapter and a USB-adapter to drive the TTL lines to the board. So, there is something wrong at my end, and it's probably something so trivial that no-one would think to mention it. Has anyone tried this board? Can you think of any setting that's inherently obvious to the most casual observer that a newbie could repeatedly overlook? For example, is there some first setting that you always do in u-center to shut down the NMEA and turn on the UBX, but the setting does not save on the board and the u-center software always overrides it? The configuration is this: The adapter does the 3V to 5V stuff, and plugs into the same connector as my UT+. The antenna lead is connected to a non-powered port on my GPS Source splitter. The splitter connects to a puck in the attic via RG-6. The SNR of the received signals is in the 20-50 range on the u-center display window. I have tried driving a different puck directly that is in my lab room. No change except for lower SNR values. 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. ___ 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] Synergy-GPS SSR-6tru problems
Dennis, I fooled around with PUBX 41, and can't get the board to respond. I think that with the original board, I *once* got some PUBX messages, but at this point I am only seeing NMEA broadcasts. That once may have been when I was using a serial port instead of the USB I'm using right now. This evening I will get in with the scope and do come comparisons on the 10-pin connector to see if there are differences between then the UT+ is plugged in and the SSR-6tru mounted on the adapter card. I have an ftdi adapter that I may put on as well if nothing else gives any results. I don't have the ability to deal with those .05 spaced pins on the GPS board's connector, or to supply the 3V power. But, if needs be, I can get a connector, put in a 3V regulator, and give that a try. Come to think of it: one of my little USB to TTL adapter boards can supply 3V. Maybe I can use some mini-clips to jumper directly to the .05 pins on the GPS board, let the USB adapter supply the 3V, and give that a try. I'm a bit leery of going that route, though. If I get pins mixed up and blow the board I've wasted all this time for nothing. Bob From: Dennis Ferguson dennis.c.fergu...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Cc: Bob Stewart b...@evoria.net Sent: Tuesday, July 15, 2014 11:46 PM Subject: Re: [time-nuts] Synergy-GPS SSR-6tru problems On 15 Jul, 2014, at 16:32 , Bob Stewart b...@evoria.net wrote: I do not know what the problem is. The UT+ works (with the appropriate software). The SSR-6tru is deaf using all the software I have available to me. I am at my wits end, and I have nothing else that I can think of to try. I've got several of these boards and they've worked okay for me without doing anything special. I have not tried the software you are using, however, nor do I use the adapter you mention (does that adapt the connector on the SSR-6tru to a connector that fits your UT+ board?). I made a connector to talk to mine directly from a 3 volt serial port in a BBB SOIC. Since you can see the NMEA sentences the transmit side of the serial port from the LEA-6T is clearly working and you have the baud rate right, but your symptoms suggest the module doesn't hear you. Have you tried looking at the basic connection, i.e. that the serial port receive pin on the module wiggles at the right voltage and polarity when the software tries to send stuff (maybe there are two ways to plug in the adapter, only one of which works)? If that looks okay then the only other guess I can think of is that the software is trying to talk to the board with u-Blox binary messages but that protocol has been turned off for input on the port (the PUBX,41 NMEA sentence can turn it on and off), but that seems unlikely since, no matter how I reconfigure mine, a power-on reset always sees the serial port come up willing to receive either protocol. Dennis Ferguson ___ 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] Synergy-GPS SSR-6tru problems
Hi Paul, No, it's the right configuration. The part number is as you say and it says SSR-6tru on a paper label. I'm certain it's something on my end, but I just don't see it. I think I'm going to go the mini-clips route, assuming a USB adapter will power the board. I'll have to look at the specs to see current draw. Bob From: Paul tic-...@bodosom.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, July 16, 2014 2:33 PM Subject: Re: [time-nuts] Synergy-GPS SSR-6tru problems On Wed, Jul 16, 2014 at 2:54 PM, Bob Stewart b...@evoria.net wrote: I fooled around with PUBX 41, and can't get the board to respond. I had some problems but that's because they sent the wrong configuration (a 16062133G). What's the part number? Assuming it hasn't changed a TRu is 16062152G. I don't have the ability to deal with those .05 spaced pins on the GPS board's connector, or to supply the 3V power. I was able to compress and heat shrink some .1 connectors on a .05 connector although I didn't try it on the SSR-6T. -- Paul ___ 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] Synergy-GPS SSR-6tru Problem Resolved
As a reminder, I received an SSR-6tru receiver from Synergy, along with their M12 adapter, which allows you to plug it into a slot for an Oncore GT+, UT+, or VP. I was unable to get the receiver to respond to any commands from the u-blox u-center software. After a lot of troubleshooting, I discovered that pin-5, the DGPS IN pin, must be brought to a logic level high in order for this assembly to work. If it's low, apparently anything going into the board on the Rx line is simply sent back out on the Tx line and not passed to the receiver. I've never owned a GT+ or a VP, so I wasn't aware that a logic high was needed on this pin. The UT+ works just fine with this pin not connected. Bob ___ 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] Synergy-GPS SSR-6tru Problem Resolved
Hi Tom, I think that an offline conversation with Dusty Morris may have pointed out the root cause. The SSR-6tru board uses 3V logic, but the Motorola Oncore boards use 5V. So the Synergy M12 adapter has to do the level shifting to protect the receiver. It does this for input signals by using a voltage divider composed of a 4.7K resistor on top (for the 5V input) and a 6.8K resistor on the bottom to ground. The center tap of these two resistors goes to the receiver. Normally we would expect an open TTL pin to be a logic high. But, in this case, an open pin to the 4.7K resistor on top leaves the 6.8K resistor to act as a pull-down on the receiver's input pin. At least that's my speculation. I'm no EE. Bob From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, July 24, 2014 12:02 AM Subject: Re: [time-nuts] Synergy-GPS SSR-6tru Problem Resolved Hi Bob, That's very good news. Thanks for following through on this issue. Newcomers to the list should know that unlike many of the large corporations in the TF business, Synergy has been hobbyist and time-nuts friendly since the beginning. I know a couple of us bought our first GPS receivers from Synergy in the mid-1990's. This was in the early days of GPS where we used Tom Clark's TAC h/w and SHOWTIME.EXE s/w, in the same way we use Trimble's Thunderbolt h/w and Mark/John's HEATHER.EXE s/w today. /tvb - Original Message - From: Bob Stewart b...@evoria.net To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, July 23, 2014 3:19 PM Subject: Re: [time-nuts] Synergy-GPS SSR-6tru Problem Resolved As a reminder, I received an SSR-6tru receiver from Synergy, along with their M12 adapter, which allows you to plug it into a slot for an Oncore GT+, UT+, or VP. I was unable to get the receiver to respond to any commands from the u-blox u-center software. After a lot of troubleshooting, I discovered that pin-5, the DGPS IN pin, must be brought to a logic level high in order for this assembly to work. If it's low, apparently anything going into the board on the Rx line is simply sent back out on the Tx line and not passed to the receiver. I've never owned a GT+ or a VP, so I wasn't aware that a logic high was needed on this pin. The UT+ works just fine with this pin not connected. Bob ___ 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] Synergy-GPS SSR-6tru Problem Resolved
And while this subject is still up, I want to let the group know that Synergy *really* went out of their way to help me with this. I was a bit surprised at their level of commitment to some ham radio operator who had bought a single unit from them and probably didn't know what the heck he was talking about. A real class act all around! Bob - AE6RV From: Art Sepin a...@synergy-gps.com To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Cc: Tom Van Baak t...@leapsecond.com; Dusty Morris doxielove...@cox.net Sent: Friday, July 25, 2014 5:17 PM Subject: RE: [time-nuts] Synergy-GPS SSR-6tru Problem Resolved Bob, Once in a while a mea culpa is required and we're posting it here so everyone understands our commitment to the users of Synergy's products. The Original Synergy Adaptor Board was designed to allow Motorola's newer 3 volt 12 channel M12+ to plug into an older 5 volt 8 channel UT+ slot. That product worked for hundreds of users over the years until (we found out through your personal aggravation and agony) the recent introduction of Synergy's SSR series of u-Blox based precision timing boards. To make sure that the Synergy UT+ Adaptor Board issue is put to bed properly we asked for an external, formal technical review of this product that was introduced fourteen years ago. The reviewing engineer's first comments were Ouch! This will not work. And, no, the SSR boards do not work the same as the M12 boards on the Synergy Adaptor Board. The M12+ and M12M receivers have separate serial ports for the two functions (Receiver command RxD and DGPS RxD input) so it does not matter what you do with the RTCM port, pin 5 on UT+ connector and pin 8 on the M12+/M12M connector, if not in use with an M12x receiver. The SSR boards, however, had to combine the two serial data streams expected by the M12x navigation receivers into one because the u-Blox receiver modules only use one serial input port for both receiver commands and DGPS correction data. The Synergy Adaptor Boards use a simple gate combiner circuit that worked well when using the M12+ or M12M but left Synergy open to this problem when using an SSR. Both serial lines on the SSR board, pins 2 (Receiver RxD) and 8 (DGPS RxD) are pulled high on the SSR board so open pins are OK but they must not be grounded. The solution is for Synergy to make a UT+ Adaptor Board part number available to users who only want to test the features of SSR timing receivers. That new SSR only Adaptor Board part number, which we'll have available in a few days, will remove R3 (4.7K) and R4 (6.8K) from the adapter board and the compatibility issue will be resolved. In the interim, other users can pull pin 5 of the UT+ connector high (+5V) as you did. We apologize for the confusion and frustration, Bob, and thank you for the valuable feedback! Art Sepin ___ 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] Effects of noise on EFC line?
I've run into a noise problem on the EFC line of my GPSDO engine at the frequency of the oscillator. I've traced the source down to the 74HCT365 I'm using to output the 1(or 5)MHz and 10MHz signals. When I pull it, the EFC quietens down a lot. I'm seeing about 50mv of 10MHz noise at the output of the op-amp that feeds the EFC voltage divider at the OCXO. The voltage divider is corrected by the VRef from the OCXO with a simple circuit using temp-co'ed resistors. On the 0.1uf cap at the OCXO's EFC pin, I'm seeing about 5mv of 10MHz signal. I've considered switching the HCT out for a 74LS365, assuming my drive levels are compatible. Unfortunately, I don't have one in stock, and I'm way out of my pay grade, as they say. I've also thought about putting a 100uh inductor in series with the EFC line. I wonder if I'll have to isolate the 74xx365 chip's VCC through an inductor? Any thoughts? I'm also wondering what the impact of this level of on-frequency noise will be? Is the impact somewhat mitigated, since it's at oscillator frequency? I don't have anything better than an HP 8558B to look at the output of the board. I'm not quite ready to generally share my schematic with the list, but I can make individual exceptions. 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] Effects of noise on EFC line? - Resolved
Thanks to everyone for their comments, and especially to Bill, WB6BNQ for cast a jaundiced eye on my schematic. The problem turned out to be in the design of my 5V rail on the PCB. There is a 2.5 inch run from the 5V regulator over to the hex driver (74HCT365) that outputs two signals of either 1MHz or 5MHz, as well as four 10MHz outputs. About .5 before the hex driver, I tapped off 5V to power both a thermistor and the output op-amp. I hadn't counted on the impedance of about 2.5 of trace at 10MHz, and the noise the hex driver would put on it. What I did was cut the tee at both ends, and put a jumper from the thermistor op-amp directly to the 5V regulator. The 10MHz noise is now gone. There is some noise from the DAC output that looks to be at the PIC's clock frequency, but that was filtered out by the voltage divider and .1uf cap at the EFC pin of the OCXO. I did learn something interesting, though. The Vref output of the OCXO (Trimble 34310-T) has about 4mv of 10MHz on it. That was also cleaned up by the voltage divider/corrector. So, I may throw another cap on it, but it seems to be clean down to what I can measure at the OCXO on my old Tek 455 with an X10 probe. Bob From: Bob Stewart b...@evoria.net To: Time Nuts time-nuts@febo.com Sent: Tuesday, August 5, 2014 1:36 PM Subject: [time-nuts] Effects of noise on EFC line? I've run into a noise problem on the EFC line of my GPSDO engine at the frequency of the oscillator. I've traced the source down to the 74HCT365 I'm using to output the 1(or 5)MHz and 10MHz signals. When I pull it, the EFC quietens down a lot. I'm seeing about 50mv of 10MHz noise at the output of the op-amp that feeds the EFC voltage divider at the OCXO. The voltage divider is corrected by the VRef from the OCXO with a simple circuit using temp-co'ed resistors. On the 0.1uf cap at the OCXO's EFC pin, I'm seeing about 5mv of 10MHz signal. I've considered switching the HCT out for a 74LS365, assuming my drive levels are compatible. Unfortunately, I don't have one in stock, and I'm way out of my pay grade, as they say. I've also thought about putting a 100uh inductor in series with the EFC line. I wonder if I'll have to isolate the 74xx365 chip's VCC through an inductor? Any thoughts? I'm also wondering what the impact of this level of on-frequency noise will be? Is the impact somewhat mitigated, since it's at oscillator frequency? I don't have anything better than an HP 8558B to look at the output of the board. I'm not quite ready to generally share my schematic with the list, but I can make individual exceptions. 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] Low noise powersupplies
What about a PC sound card? From: Alexander Pummer alex...@ieee.org To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 7, 2014 5:06 PM Subject: Re: [time-nuts] Low noise powersupplies to measure a power supply noise, better to say the noise spectrum, you would need a very large non polarized capacitor and spectrum analyzer, The input of the spectrum analyzer does not like DC, and has low impedance. Since spectrum analyzer's input impedance is usually 50 ohm, for to be able to see the noise at low frequency you need C = 1/( 2 x 3.14 x 50 ohm x f Hz ) capacitor, and you would need a DC level limiter to prevent blowing the input of the spectrum analyzer during the charge up of that capacitor. If you could get a hold of an old HP 1Meg to 50ohm buffer amplifier you would need much lover capacitance or if the buffer has AC input capability with low enough corner frequency like the Tektronix P6201 FET probe, you would not need any capacitor. And that would make your life much nicer since capacitors could generate noise to.. Charles Wenzel in his circuit collection files ha very nice good working noise reduction circuits. 73 Alex KJ6UHN ___ 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] Effects of noise on EFC line? - Resolved
Hi Bob, I hadn't even considered a filter in the OCXO. This isn't a 10811, but that's the OCXO I have a schematic of, so I'll assume that's the benchmark. Following the EFC in, it looks like it goes to a 100K resistor and then tees to the 100pf varicap and a 15pf to the xtal. Other caps are attached as well, but it doesn't look like it's bypassed to ground anywhere along the EFC line. I see that there's another 100K to a 6.4V reference with a 6.8uf cap. So, that means that the EFC line ranges from +6.4 to -6.4? I haven't worked out the time constant, but that wouldn't seem to apply for a 10MHz signal riding on the EFC voltage. Like I said, I don't have a 10811 on my GPSDO. It's my faithful Trimble 34310-T. Still, I would imagine that they at least looked at HP's design. As to Hal's comment about probe pickup. I was careful to specify the X10 position of the probe. In the X1 position there was a signal that wasn't visible in X10, but should have been. So, I assumed that was some sort of induced signal. I'm using a generic cheap Chinese probe available on ebay. Bob From: Bob Camp kb...@n1k.org To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 7, 2014 6:11 PM Subject: Re: [time-nuts] Effects of noise on EFC line? - Resolved Hi Your EFC line is probably bypassed internally to the OCXO. A 3db modulation bandwidth beyond 1 KHz is unlikely. A modulation bandwidth below 100 Hz is quite possible. Next thing to consider is that the EFC does FM on the OCXO. Phase noise is PM modulation. FM is 1/Fmod relative to PM. If I go up a decade in frequency with constant FM, my PM sideband will go down by 20 db. Yes that’s for small modulation indexes. That’s very likely the case if we are dealing with noise. You can calculate exactly what PM sideband in dbc you will get from a 1 Hz tone at 1 mV p-p on your EFC. From that you can pretty quickly work out what this or that number of microvolts will do at this or that frequency. The answer is normally that the noise you have from a reasonable regulator or op-amp isn’t a big deal. Bob ___ 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] EFC info on Trimble 34310-T OXCO
I've been using one for over a year. They take 12V to power, and they have a VRef output around +6.25V, which implies an EFC range of 0-6V. Unless you get one that's aged out, an EFC range of 0-5V should be fine. The VRef has a bit of 10MHz on it on mine. All in all, it seems to be a good OCXO, though I don't have the equipment to do a real careful test on it. However, I wonder if you'd really get anything from subbing in an Rb, other than the fun of doing it? Don't Rb standards usually just have a DDS output? If so, wouldn't that be a step backwards? Bob - AE6RV From: Dave M dgmin...@mediacombb.net To: FEBO Time Nuts time-nuts@febo.com Sent: Friday, August 22, 2014 1:39 PM Subject: [time-nuts] EFC info on Trimble 34310-T OXCO Does anyone have any info on the OXCO in the Nortel/Trimble NTBW50AA-17 GPSTM receiver? The OXCO is labeled as Trimble 34310-T. I see some Trimble 34310-T oscillators on Ebay with pinouts labeled, but no other info. Specifically, I'd like to know the EFC characteristics for it. I'm thinking of the possibility of pulling the OXCO out of the GPSTM and subbing in a 10 MHz Rubidium, and using the GPSTM to discipline the Rubidium. My Rubidium is a Symmetricom X72, recently purchased. It seems to be working well. Does anyone know the differences between the three OXCOs used in the GPSTM receivers (T, T2 and Oak)? Thanks for some insight, Dave M ___ 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] Practical Survey-In Accuracy?
I've had the LEA-6T sitting in survey-in mode for about 17 hours, and at this point, the u-center software says that the Mean 3D Std Dev is 0.109 meters. Given that my antenna is just a puck at the peak of the attic (never got around to adding the DIY choke-ring), has this reached the silly number phase, or should I let is simmer overnight before calling it done? 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] LEA-6T Software.
Hi Dan, I think you're looking for the u-center software. Finding software on that site can be difficult, so it's easier to resort to a websearch. There's a link to the latest software on this page. http://www.u-blox.com/en/evaluation-tools-a-software/u-center/u-center.html As to the antenna, google diy gps choke ring to get the fundamentals. Walmart sells a set of Wilton stackable aluminum pie pans that seem to be a pretty good fit for our needs. I've done a few experiments, but haven't set it up because I didn't find a suitable platform for the antenna puck to rest on and haven't wanted to spend the time to make something. Something made out of steel would be ideal for the magnetic mount of a puck antenna, if that's what you have. Bob From: Dan Kemppainen d...@irtelemetrics.com To: time-nuts@febo.com Sent: Monday, August 25, 2014 9:48 AM Subject: [time-nuts] LEA-6T Software. Hi All, Just purchased a LEA-6T based board to play with (It's a Synergy Systems SSR-6Tru). The Ublox web site has some documentation regarding the setup of these units. In the documentation are some screenshots of what appears to be a utility for configuration. I haven't seen it on the Ublox web site yet. Do any of you know what that software might be, and where one would get it? The unit is a few weeks out on delivery, so wanted to see what I could to to prepare for it's delivery. What other utilities and software are available what would pair with these units? FYI, I run windows based software. Also, I have a low cost antenna coming. It's one of the Synergy systems puck type amplified antennas. I remember some time back a bit of chatter about improving GPS antennas for timing, by providing some sort of guard ring or choke to prevent low angle reception. Are there any good links anyone could provide on what may be worth building or playing with. Keep in mind, I live in snow country (~300 inches/year) so a something that gathers a lot of snow could be undesirable! :) Thanks, Dan ___ 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] Practical Survey-In Accuracy?
Hi Bob, Thanks for the info. I'll have to run a long test to see what the difference is. Maybe I can capture the XYZ coordinates to the PC during the run. Bob From: Bob Camp kb...@n1k.org To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, August 25, 2014 4:54 PM Subject: Re: [time-nuts] Practical Survey-In Accuracy? Hi There are some periodic errors in GPS that only get averaged in after a = 48 hour survey. It’s not so much a specific error level in meters as much as averaging in all the “issues”. Bob On Aug 23, 2014, at 7:38 PM, Bob Stewart b...@evoria.net wrote: I've had the LEA-6T sitting in survey-in mode for about 17 hours, and at this point, the u-center software says that the Mean 3D Std Dev is 0.109 meters. Given that my antenna is just a puck at the peak of the attic (never got around to adding the DIY choke-ring), has this reached the silly number phase, or should I let is simmer overnight before calling it done? 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. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
I have my GPSDO developed well enough now that I'm correcting for the quantization error given by my LEA-6T. As I watch the phase difference plot, it seems a bit more noisy than it should be. I've also had to make the DAC pretty active to keep the phase noise on a short leash. So, I'm wondering what I have around here that I can use to measure the phase noise of my OCXO. For test equipment I have: My ex-telecom Rb that I turned on last night showed poor frequency stability over night, so I'm going to let it bake for a day or two to see if that improves. An HP 10811 standard in my 5335A, and the 5335A itself to measure time interval. I have GPIB and I can capture the TI from the 5335A. An ADR-291 Voltage Reference to lock the EFC of the OCXO to a known value. My thought was to begin by locking the DAC to a single value and plot an ADEV against the Rb. Is there anything else I can do with this somewhat primitive time lab? 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] OCXO Phase Noise Measurement in Primitive Conditions
Hi Poul, I'm not really sure what you mean by the term timeconstant WRT my GPSDO and not some other algorithm.. So, to avoid a discussion of that, let me just post links to some plots and note that there are very few and very small corrections for the position term by the PID controller. I'm using a sort of deadband filter for the p term damping set at 10 counts summed for direction. The first is to the last 2 hours on the GPSDO, and it has a lot of information on it. Blue is the DAC. It has a lot of bits, so it's scaled down to make it usable. True values are on the left in hex, though the resolution is multiplied by an additional 3.75 or so in hardware. The red is the phase in hundreds of ps measured by my TIC after correction for quantization errors. The green is raw ambient temperature which obviously doesn't have enough gain to be useful. The purple is the TI of the Rb to the GPSDO output in ns as a comparison for the final plot. http://evoria.net/AE6RV/TIC/GPSDOe.png The next plot is an ADEV of approximately the same timeframe for the corrected TIC from above. The green is the TIC the blue is the ADEV. http://evoria.net/AE6RV/TIC/TIC.png And finally is an ADEV of approximately the same timeframe of the Rb against the OCXO output as measured by my 5335A. Here the Rb phase is unwrapped. http://evoria.net/AE6RV/TIC/Rb.png Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, August 27, 2014 12:32 PM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409158879.13035.yahoomail...@web142706.mail.bf1.yahoo.com, Bob St ewart writes: So here is a pretty interesting way to optimize a GPSDO that I've been playing with for some years. I don't have a formal mathematical formulation of it. It is somewhat related to what Dave Mills calls the Allan intercept except this you can actually measure and not just estimate. You run several (long!) test-series with different timeconstants in your PLL, and you record the resultant EFC and phase offset as a function of time. If your timeconstant is too short, you will have a lot of high-frequency signal in the EFC, too long and you get too much high-frequency signal in the phase offset. The optimal timeconstant is where you have the least sum of spectral power where the two curves cross each other. My experience so far is that the curve around the optimum is very flat, getting the timeconstant wrong by a factor of two hardly changes the resultant performance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
Hi Poul, I accidentally replied to only you (and had to repost to the list), so I'm redirecting this thread back to the list. I have tried smaller gains, but I'll do it again. I'll post back later with a d gain of 1/9 of what it was for those plots. The difference will be obvious on the DAC plot. I did change the differential algorithm since I tried it with low gain, so maybe it'll help. Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net Sent: Wednesday, August 27, 2014 2:02 PM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409165381.1098.yahoomail...@web142702.mail.bf1.yahoo.com, Bob Ste wart writes: Your PLL (PID) has (far) to high gain: You are yanking the EFC around to every single little wiggle in the GPS signal. The curve relative to the Rb should be very, very straight, any wavyness should be on timescales of at least 20-30 minutes, not within single minutes as your first plot shows it. This is a very common beginners fault: I made it myself too :-) Lower the PID gain, until the DAC/EFC line only wiggles the minimum amount necessary to keep the OCXO from drifting away from the Rb... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
Thanks Paul! I had played around with gain a lot before adding that last bit to the differential algorithm. A word about that: I developed my code without a lot of reference to the PID work by Wescott. I had learned how to do the integral part a different way and hadn't realized it. So, it makes sense that things would go badly wrong without an iTerm. So, I cut the dTerm in half and divided the pTerm by about 3.5. I left my integral factor the same. This is only a 30 minute run, but the difference is remarkable. I'll play with the gains a bit more to see what happens. http://evoria.net/AE6RV/TIC/GSPDOe.2.png http://evoria.net/AE6RV/TIC/ADEV2.png I'd still like to know whether the tools I have at hand can measure the phase noise on my OCXO. Bob (And yes, I accidentally responded directly to you again so this is a repost to the list.) From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net Sent: Wednesday, August 27, 2014 2:02 PM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409165381.1098.yahoomail...@web142702.mail.bf1.yahoo.com, Bob Ste wart writes: Your PLL (PID) has (far) to high gain: You are yanking the EFC around to every single little wiggle in the GPS signal. The curve relative to the Rb should be very, very straight, any wavyness should be on timescales of at least 20-30 minutes, not within single minutes as your first plot shows it. This is a very common beginners fault: I made it myself too :-) Lower the PID gain, until the DAC/EFC line only wiggles the minimum amount necessary to keep the OCXO from drifting away from the Rb... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
I found also that I have a hardware problem. Bert posted recently that he keeps his OCXOs out in the open with at least one inch of free space on all six sides. My chassis badly ignores that, with the OCXO up against the edge of the case. I noticed that the EFC changed and then a bit later the thermistor reading changed and thought, hmmm, the OCXO on the edge of the case is seeing the temp changes first and causing unexpected changes to the loop condition. I've hooked up my thermistor to the PLL controls. Next is to reconfigure my GPSDO box to give the OCXO some room to breathe. I feel like I'm finally getting somewhere with this random noise from the OCXO. Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 28, 2014 1:04 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409175707.2080.yahoomail...@web142706.mail.bf1.yahoo.com, Bob Ste wart writes: This looks like a step in the right direction. The correct allan plot will have a clearly visible horizontal segment somewhere in the 100-1 second range (depending on OCXO quality). This is where the GPS long-term stability takes over from the OCXO's better short-term stability. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Practical Survey-In Accuracy?
Hi Attila, Is wood, nails, and asphalt shingle really that big of a problem at these frequencies? The antenna is within 2 ft of the highest point of the roof. Bob From: Attila Kinali att...@kinali.ch To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 28, 2014 8:15 AM Subject: Re: [time-nuts] Practical Survey-In Accuracy? On Sat, 23 Aug 2014 16:38:42 -0700 Bob Stewart b...@evoria.net wrote: Given that my antenna is just a puck at the peak of the attic (never got around to adding the DIY choke-ring) A choke ring will not help you much in the attic. You already have lots of reflecting and refracting surfaces/volumes above the antenna. Unless you get to the top of your roof, i wouldn't bother adding a choke ring. Attila Kinali ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
Hi Poul, I've made a few hardware changes and some software changes, and I was wondering if you (and/or others) would take a look at this plot. The green is phase over 70,000+ seconds with ~100ps resolution, while the blue is the ADEV. (The sharp departures in phase are from large temperature changes and not quite perfect temperature compensation software.) I don't see your horizontal line down at the bottom, but there are some worrying horizontal lines between about 3tau and 150tau. Should I take that to mean that I have some noise/oscillations from about 1/3Hz to 1/150Hz? Those up at about 150tau I think I can see by eye on another plot of different data. I've got a lot of data collected from this run (still running) including pTerm, iTerm, dTerm, and tTerm (temperature) updates to the DAC. I hope to try to tease something out of that later, though the pTerm and iTerm are mostly +1,0,-1 stuff. FWIW, in real terms, the dGain is at about 4.2. The phase starts to get ugly if I bring it much below that. iGain is .01 and pGain is .05. There are misc damping and limiting factors applied, as well. Just about ready to do a second board with updates from what I've learned, so any help is appreciated. The plan is to release the source code at some (not too) future date and make boards available, if there's interest. But I've still got a lot to do before that. http://evoria.net/AE6RV/TIC/ADEV3.png Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 28, 2014 1:04 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409175707.2080.yahoomail...@web142706.mail.bf1.yahoo.com, Bob Ste wart writes: This looks like a step in the right direction. The correct allan plot will have a clearly visible horizontal segment somewhere in the 100-1 second range (depending on OCXO quality). This is where the GPS long-term stability takes over from the OCXO's better short-term stability. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
Hi Bob, I take it that the 3 segment ADEV pretty much defines a GPSDO. So, is my plot an indication that I'm riding the OCXO too hard to get the results I think I should be getting? What I think I should be getting is a flat phase line. But is a GPS receiver, even after applying quantization error corrections, accurate enough to give that? I see three things at play here: hardware, software, and my expectations. I'm trying to figure out which one (or several) of these needs to be addressed. I suppose I could hook the Rb back up and see the effect on the ADEV of the Rb vs OCXO as I loosen the gain values. Bob From: Bob Camp kb...@n1k.org To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, September 2, 2014 6:38 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions Hi Your ADEV is (mostly) a plot of 1-2 ns resolution out over your sample range. It’s not a “typical” three segment ADEV. It’s more likely that any departure from a straight line is random rather than systematic. Yes I’ve spent a lot of time looking at random plots that I was *sure* had significant information in them….. Bob On Sep 1, 2014, at 9:31 PM, Bob Stewart b...@evoria.net wrote: Hi Poul, I've made a few hardware changes and some software changes, and I was wondering if you (and/or others) would take a look at this plot. The green is phase over 70,000+ seconds with ~100ps resolution, while the blue is the ADEV. (The sharp departures in phase are from large temperature changes and not quite perfect temperature compensation software.) I don't see your horizontal line down at the bottom, but there are some worrying horizontal lines between about 3tau and 150tau. Should I take that to mean that I have some noise/oscillations from about 1/3Hz to 1/150Hz? Those up at about 150tau I think I can see by eye on another plot of different data. I've got a lot of data collected from this run (still running) including pTerm, iTerm, dTerm, and tTerm (temperature) updates to the DAC. I hope to try to tease something out of that later, though the pTerm and iTerm are mostly +1,0,-1 stuff. FWIW, in real terms, the dGain is at about 4.2. The phase starts to get ugly if I bring it much below that. iGain is .01 and pGain is .05. There are misc damping and limiting factors applied, as well. Just about ready to do a second board with updates from what I've learned, so any help is appreciated. The plan is to release the source code at some (not too) future date and make boards available, if there's interest. But I've still got a lot to do before that. http://evoria.net/AE6RV/TIC/ADEV3.png Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 28, 2014 1:04 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409175707.2080.yahoomail...@web142706.mail.bf1.yahoo.com, Bob Ste wart writes: This looks like a step in the right direction. The correct allan plot will have a clearly visible horizontal segment somewhere in the 100-1 second range (depending on OCXO quality). This is where the GPS long-term stability takes over from the OCXO's better short-term stability. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
Hi Adrian, Actually no. This ADEV is a plot of the sawtooth-corrected 1PPS signal from the GPS receiver (LEA-6T) measured by the TIC in my GPSDO against the output of its OCXO. Bob From: Adrian rfn...@arcor.de To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, September 2, 2014 11:24 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions Bob, to me your ADEV plot looks pretty exactly like a measurement system noise floor plot with its typical 10/decade shape. I would assume that you connected the same signal to both counter inputs, or, both sources have been phase locked. Adrian Bob Stewart schrieb: Hi Bob, I take it that the 3 segment ADEV pretty much defines a GPSDO. So, is my plot an indication that I'm riding the OCXO too hard to get the results I think I should be getting? What I think I should be getting is a flat phase line. But is a GPS receiver, even after applying quantization error corrections, accurate enough to give that? I see three things at play here: hardware, software, and my expectations. I'm trying to figure out which one (or several) of these needs to be addressed. I suppose I could hook the Rb back up and see the effect on the ADEV of the Rb vs OCXO as I loosen the gain values. Bob From: Bob Camp kb...@n1k.org To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, September 2, 2014 6:38 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions Hi Your ADEV is (mostly) a plot of 1-2 ns resolution out over your sample range. It’s not a “typical” three segment ADEV. It’s more likely that any departure from a straight line is random rather than systematic. Yes I’ve spent a lot of time looking at random plots that I was *sure* had significant information in them….. Bob On Sep 1, 2014, at 9:31 PM, Bob Stewart b...@evoria.net wrote: Hi Poul, I've made a few hardware changes and some software changes, and I was wondering if you (and/or others) would take a look at this plot. The green is phase over 70,000+ seconds with ~100ps resolution, while the blue is the ADEV. (The sharp departures in phase are from large temperature changes and not quite perfect temperature compensation software.) I don't see your horizontal line down at the bottom, but there are some worrying horizontal lines between about 3tau and 150tau. Should I take that to mean that I have some noise/oscillations from about 1/3Hz to 1/150Hz? Those up at about 150tau I think I can see by eye on another plot of different data. I've got a lot of data collected from this run (still running) including pTerm, iTerm, dTerm, and tTerm (temperature) updates to the DAC. I hope to try to tease something out of that later, though the pTerm and iTerm are mostly +1,0,-1 stuff. FWIW, in real terms, the dGain is at about 4.2. The phase starts to get ugly if I bring it much below that. iGain is .01 and pGain is .05. There are misc damping and limiting factors applied, as well. Just about ready to do a second board with updates from what I've learned, so any help is appreciated. The plan is to release the source code at some (not too) future date and make boards available, if there's interest. But I've still got a lot to do before that. http://evoria.net/AE6RV/TIC/ADEV3.png Bob From: Poul-Henning Kamp p...@phk.freebsd.dk To: Bob Stewart b...@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, August 28, 2014 1:04 AM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions In message 1409175707.2080.yahoomail...@web142706.mail.bf1.yahoo.com, Bob Ste wart writes: This looks like a step in the right direction. The correct allan plot will have a clearly visible horizontal segment somewhere in the 100-1 second range (depending on OCXO quality). This is where the GPS long-term stability takes over from the OCXO's better short-term stability. ___ 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] OCXO Phase Noise Measurement in Primitive Conditions
Hi Magnus, I knew I was missing something! I'll warm up the Rb and test against that again. Thanks! Bob From: Magnus Danielson mag...@rubidium.dyndns.org To: time-nuts@febo.com Sent: Tuesday, September 2, 2014 3:27 PM Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions Well, in that case you do measure a form of noise-floor rather than measuring the OCXO performance, as OCXO performance is being corrected out in the PPS position (and sawtooth-correction). If you want to measure that OCXO performance, you need to do that against an independent PPS. 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.
