Re: [time-nuts] A Request to the List
In message <59219f88-52bb-d127-29de-1ea0ccc2b...@febo.com>, John Ackermann N8UR writes: >It's much better to have one thoughtful post than a dozen written on the fly. See also: http://bikeshed.org -- 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] Sawtooth correction: next or previous PPS
In message <20180522011345.4db43406...@ip-64-139-1-69.sjc.megapath.net>, Hal Mu rray writes: > >hol...@hotmail.com said: >> One thing to look out for when messing with sawtooth messages is the >> question of does the message come out before or after the PPS pulse... good >> look finding the answer in the receiver documentation... > >Has anybody asked the manufacturers? It is trivial to measure with a HP5370: Capture a series where you measure the 1PPS against a good 10MHz and record the serial datastream. Then offline apply the negative sawtooth and plot the result. If you get ugly spikes at the turning points of the "hanging bridges" you're doing it wrong. For the UT Oncore etc. it is predictive of the next 1PPS flank. -- 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] Antenna cable delay compensation
A related question is: Do you use positive or negative numbers to set the antenna cable delay value? Again, most GPS receiver documentation does not say.I think that I've only seen it explicitly mentioned in the Trimble documentation and the Oscilloquartz Star-4 documentation. Also there is the question of does the receiver time message come out before or after the 1PPS and what is the message offset time from the 1PPS? Again, rarely documented by the receiver manufacturer. Lady Heather can measure those (if the operating system clock is accurately set) Heather uses the message time offset to adjust the displayed time or get the audible "tick clock" aligned to true time. Heather has a table of typical message offsets for the supported receivers, but measuring and setting the value for your receiver/computer/serial port can improve things. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
Having a linux box (Pi) dedicated as a time server should mean you have consistent delays? To offload time server requests so they don't affect disciplining response/timing, would it be worthwhile having one Pi dedicated to being disciplined by the GPS, then have that pi discipline a second Pi that handles time server requests? PPS-Client measures the delay of a Pi GPIO port and over time adjusts the PPS to compensate. I'd think PPS-Client could be modified to process the sawtooth. And possibly to adjust for the delays in writing to system time? The M8T's two EXTINT (External Interrupt) pins keep nagging me that the resulting timestamp (Timemark UBX-TIM-TM2 message) suggests that such a GNSS chip timestamp (not the iTOW value) should be able to be used to advantage, say to measure the net delays in getting a PPS to discipline system time. - Would the difference between a timestamp of Linux system time and a chip-internal timestamp provide a meaningful and worthwhile adjustment, to system time or to the incoming PPS? - Would successive pairs of timestamps provide the net delay in writing such a corrected system time, allowing for a further refined correction? - Should such a correction be an absolute adjustment based on the pair delta, or should a period of deltas be smoothed and applied over time? - Would/could such a correction (measuring and adjusting based on the end result of system time) provide a superior result in system time than a sawtooth corrected PPS triggering a write to system time? Michael On 21/05/2018 3:21 PM, Gary E. Miller wrote: Gregory! On Mon, 21 May 2018 19:06:17 + Gregory Maxwell wrote: My best guess is that the magnitude of sawtooth error is just not large enough to matter for typical applications of linux PPS. No need to guess. I recently posted that the RasPi 3B granularity is 52 nano Seconds and the PPS offset reported by UBX-TP is double that! So, clearly it matters. I'll do more data logging to get harder numbers. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin ___ 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] Sawtooth correction: next or previous PPS
Hi > On May 21, 2018, at 9:13 PM, Hal Murray wrote: > > > hol...@hotmail.com said: >> One thing to look out for when messing with sawtooth messages is the >> question of does the message come out before or after the PPS pulse... good >> look finding the answer in the receiver documentation... > > Has anybody asked the manufacturers? At least in the framework of Furuno and myself … yes. Not via email but face to face with their head of design engineering. > > This should be easy to see if you record the PPS offset referenced to a good > clock and compare that to the reported offset. The real simple answer is that you have four cases. Pulse before vs pulse after plus adds or subtracts. That’s not so may that you can’t just try it and see. It turns out to be very obvious when you get the right one. Bob > If the frequency is stable > and you are getting a sawtooth (rather than a bridge) then a point on a > corrected graph next to the jump in the sawtooth will look good if you have > it right or be off by a clock cycle if you have it wrong. > > > hol...@hotmail.com said: >> "After" seems to be the most common answer. That makes hardware/delay line >> compensation rather tricky. ... > > The slides from Tom Clark and Rick Hambly's VLBI talk (page 29) show a before > setup. > http://www.gpstime.com/files/TOW/tow-time2015.pdf > > You said "most common". That implies there are both types. (or > documentation errors) We should make a list of which GPS modules do it which > way. > > > -- > 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.
[time-nuts] Sawtooth correction: next or previous PPS
hol...@hotmail.com said: > One thing to look out for when messing with sawtooth messages is the > question of does the message come out before or after the PPS pulse... good > look finding the answer in the receiver documentation... Has anybody asked the manufacturers? This should be easy to see if you record the PPS offset referenced to a good clock and compare that to the reported offset. If the frequency is stable and you are getting a sawtooth (rather than a bridge) then a point on a corrected graph next to the jump in the sawtooth will look good if you have it right or be off by a clock cycle if you have it wrong. hol...@hotmail.com said: > "After" seems to be the most common answer. That makes hardware/delay line > compensation rather tricky. ... The slides from Tom Clark and Rick Hambly's VLBI talk (page 29) show a before setup. http://www.gpstime.com/files/TOW/tow-time2015.pdf You said "most common". That implies there are both types. (or documentation errors) We should make a list of which GPS modules do it which way. -- 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] A Request to the List
TVB is traveling and not on-line as much as usual, so in his absence I'm going to ask everyone to please consider his request a couple of weeks ago to think before you post. Please keep in mind that time-nuts isn't a chat room, and that every message doesn't require an individual response. It's much better to have one thoughtful post than a dozen written on the fly. Remember that 1800 "new message" flags go up each time you post. Thanks, John ___ 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] NEO-M8N vs. NEO-M8T
On May 21, 2018, at 11:19, Gary E. Miller wrote: > Now, how to I tell the Linux kernel to apply that correction? I honestly don’t understand how this would be used in a meaningful way via the Linux kernel. The nanoseconds of correction for the PPS signal seems a small nit compared with the microseconds of error introduced by the kernel’s interrupt handling. ___ 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] ✘NEO-M8N vs. NEO-M8T
Gary E. Miller writes: > Which I always thought was pointless, that only works for a fixed > antenna. Any GPS in a fixed position lab will have a good rooftop > antenna with clear skyview. Except when it doesn't and then the ability to survive on fewer visible/good satellites without going into holdover is most welcome. > Except that requires a post process step, so not useful for real time. No, you can very much use it to inform a consumer of the PPS in realtime about the sub-quantization phase shift and have the PLL take this error refinement into account. > I just looked at the 'U-blox 8 Receiver Description' and it makes no > mention of sawtooh anything. Is that in a different doc? No, it's in there, look for the UBX-TIM series of messages, specifically TOS and TP. However, it talks about offsets of the time pulse, not a sawtooth. But there's a more specific description for series 6 timing receivers, most if not all of which will be applicable to your series 8 module as well: https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_(GPS.G6-X-11007).pdf > I'll also test Surevey-In mode to see how much that helps. _Any_ error in the surveyed position will show up as timing error that also depends on the GPS constellation. I think Lady Heather provides a special plot to map these deviations to the GPS sky tracks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ 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] NEO-M8N vs. NEO-M8T
Hi Simple answer on any GPSDO is always “that depends”. The sawtooth correction improves the PPS into the device by at least an order of magnitude on most GPS modules. Less noise in pretty much always equates to less noise out. It also takes care of hanging bridges ( sawtooth stuck to one side) that will pass through just about any control loop. The Furuno GT-87 parts are a bit of an exception to the rule. They only improve by about 3 to 5X when sawtooth correction is applied. Yes that’s looking at a 1 second measure. As you get out to 100,000 seconds things get a bit muddier. You also are down in the parts in 10^-13 ( or lower) range so it may or may not be that big a deal. With most designs, the emphasis is on “how fast can I cross over to GPS?”. Once you get crossed over, the oscillator (or other flywheel) in your GPSDO really does not matter. Getting that done at 100 seconds vs 1,000 *is* a big deal. Bob > On May 21, 2018, at 5:11 PM, Chris Caudle wrote: > > On Mon, May 21, 2018 2:23 pm, Gary E. Miller wrote: >> I look forward to your patch! > > My GPSDO doesn't have sawtooth error, so limited interest for me. > > How much does one of those u-blox modules cost? > > How would you tell if it made the gpsd performance better? I think that > question came up a couple of weeks ago, most of the ways to check time > stability involve hardware test equipment logging electrical signals, and > there isn't a good way to get an electrical signal generated cleanly from > the gpsd software clock. > > Is there a way to have a timestamp log from another instance of a PPS > driver (another meaning the first instance is the one in use by ntpd)? So > you could have a PPS driver log timestamps from a really high quality > input signal, such that any variation in the timestamps was due to the > clock variation and not from the input signal, and then see if the > variation in timestamps was less after adding sawtooth correction to gpsd. > That's the only idea I can up up with off the top of my head to check > whether such a patch would actually improve the clock estimate noticeably. > In essence this is like trying to build a GPSDO without being able to see > the output of the oscillator directly, so the normal approach to measuring > stability with TICC, counters, phase noise analyzers, etc. doesn't really > work. > > -- > Chris Caudle > > > ___ > 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] NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 2:23 pm, Gary E. Miller wrote: > I look forward to your patch! My GPSDO doesn't have sawtooth error, so limited interest for me. How much does one of those u-blox modules cost? How would you tell if it made the gpsd performance better? I think that question came up a couple of weeks ago, most of the ways to check time stability involve hardware test equipment logging electrical signals, and there isn't a good way to get an electrical signal generated cleanly from the gpsd software clock. Is there a way to have a timestamp log from another instance of a PPS driver (another meaning the first instance is the one in use by ntpd)? So you could have a PPS driver log timestamps from a really high quality input signal, such that any variation in the timestamps was due to the clock variation and not from the input signal, and then see if the variation in timestamps was less after adding sawtooth correction to gpsd. That's the only idea I can up up with off the top of my head to check whether such a patch would actually improve the clock estimate noticeably. In essence this is like trying to build a GPSDO without being able to see the output of the oscillator directly, so the normal approach to measuring stability with TICC, counters, phase noise analyzers, etc. doesn't really work. -- Chris Caudle ___ 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] NEO-M8N vs. NEO-M8T
On 21 May 2018 at 21:24, Mark Sims wrote: > > One thing to look out for when messing with sawtooth messages is the question of does the message come > out before or after the PPS pulse... good look finding the answer in the receiver documentation... > > "After" seems to be the most common answer. That makes hardware/delay line compensation rather tricky. > Sometimes you can use the antenna cable delay / pps offset commands to shift the pulse before the true > position (assuming that they support negative offsets) and use a longer delay line to add the tweak back in. In the protocol specification for the Furuno GT-87 ( from, for example: https://www.marutsu.co.jp/contents/shop/marutsu/ds/GT-87ProtocolSpecifications.pdf ) the sawtooth correction figure is given in the CRX message, at the top of page 30 of that document says the figure given refers to the second before last (t-1) ! Peter ___ 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] NEO-M8N vs. NEO-M8T
See Marks recent message about whether the offset applies to the next or previous PPS. For the rest of this, I'll assume next since it's simpler to describe. We can discuss the other/harder case if you agree that the rest of this makes sense. g...@rellim.com said: > Your concept of 'real time' does not match mine. The correction message arrives before the PPS. What's not real-time about that? You don't need any data from the future. > Also, how does that get me to the gola of a good PPS to feed into the Linux > PPS kernel module? I doubt Linux would accept a patch to put gpsd, and > more, into the kernel to read GPS and adjust the PPS. You don't fix the PPS, you fix the software processing the PPS to use the offset. Assuming you are using gpsd, you fix the serial side of gpsd to save the offset and the PPS side uses that offset to correct the PPS offset and then pass the corrected value to ntpd rather than the raw value. Linux/ntpd actually has two modes of PPS processing. The normal mode is that ntpd tells the kernel how to adjust the drift and offset. In that case, the gpsd processing described above would work. There is another mode where the PLL is done in the kernal and ntpd sits off to the side and watches, mostly doing a sanity check. This option, NTP_PPS, is not included in most kernels since it conflicts with NO_HZ_COMMON which saves power. I haven't checked the code. ntpd has a refclock config option for the offset. If that works for the kernel PLL, then the latest sawtooth correction could be passed in each second. If that doesn't work yet, it would be a small kernel mod to fix. Another option would build some hardware to apply the correction. See Mark's recent message and/or the archives. There are chips that do the adjustable delays. -- 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] NEO-M8N vs. NEO-M8T
One thing to look out for when messing with sawtooth messages is the question of does the message come out before or after the PPS pulse... good look finding the answer in the receiver documentation... "After" seems to be the most common answer. That makes hardware/delay line compensation rather tricky. Sometimes you can use the antenna cable delay / pps offset commands to shift the pulse before the true position (assuming that they support negative offsets) and use a longer delay line to add the tweak back in. ___ 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] Improving ocxo temp control
First, be sure not to measure your HP52132A stability with the OCXO. What is your reference source? On Mon, May 21, 2018 at 7:12 PM, Bob kb8tq wrote: > Hi > > There are a lot of reasons an OCXO drifts. Temperature control is rarely the > issue. > More likely you are looking at the drift / wander characteristics of the > crystal ( and > components) in the OCXO. The simple answer is to leave it on for a while ( > like weeks) > to allow things to settle out a bit. > > The paper that Rick tossed up last week is a pretty good one in terms of > temperature > control issues in an OCXO and what the issues are. > > This all assumes you are in a fairly benign environment. If you have lots of > drafts, put a > cardboard box over the unit to shield it. If you room temperature is all over > the place, then > there are a lot of ways to get to ~ 1 or 2C sort of stability in a lab. What > you do depends > a *lot* on what your situation is. > > = > > So, assuming you *do* want to improve the temperature control: > > First you need to take out what’s in there now. If it’s wandering around get > rid of it. This > involves tearing apart the OCXO. > > Now take a look at Rick’s paper and redesign the thermal enclosure. Get the > heater placement > and sensor placement right and feed that into a simple controller. > > Run some tests over temperature and check out the data. It’s likely your > first guess at things > is not going to be correct. > > Try to optimize the heat sources and sensors and re-test the result. > Everything interacts so > this is not a quick process. > > Once you are reasonably happy with where things are, start looking at a more > fancy controller. > A simple approach would be feeding thermistor voltage into some 24 bit ADC’s > and then > processing the result with an MCU. > > Ok so that’s all a bit much. > > = > > What happens if you mess with the OCXO from the outside of the package? > > You change the heat loss out of the package. This increases the thermal gain. > ( less power > to increase the oven temperature by 1 C ). Assuming the original circuit was > balanced > out, you have made things worse rather than better. > > Ok so you do an enclosure with a fan it it so the heat loss doesn’t get less. > > You now have more heat loss and the same issue applies. In addition the fan > and it’s > nonsense probably haven’t done the poor little OCXO any good. > > When one designs a double oven, the inner oven is optimized for performance > *with* > the outer oven present. Equally, the outer oven is optimized for performance > with the > heat load (and dynamics) of the inner oven. > > = > > Assuming you still want to head down this road, temperature controllers are > no different > than any control loop. The first place to start is a textbook on control > loops and control > theory. The basics of what a loop does and the terminology are what you are > after. Anything > advanced will assume you understand this part first. > > Next up are temperature sensors. Simple answer here is that a glass bead > thermistor is > the way to go. For heat, transistors are the normal go-to device. The > controls loop takes > in the thermistor output and spits out a voltage to change the current > through the transistor. > > If you have the money for software licenses, the next stop is some good > mechanical CAD > that will feed into thermal modeling. From that you can work out a proper > heat flow and > gradient design. Assuming that is a bit to expensive, you are back to trial > and error. There > are no “just duplicate this” designs that I know of. > > Once you have the structure, sensors, heaters, and control you toss it into a > temperature > test chamber. That may be something fancy or something you put together. You > run the > gizmo over temperature and observe what it does. You then optimize the P,I,D > coefficients > in your control loop. Indeed you may not have all of them or you may have an > extra one. > > === > > Of course one could simply shop for a $20 OCXO on eBay. Even if you have to > buy a > dozen before you find a good one, it’s still cheaper / faster / easier / more > likely to succeed > than all the nonsense above. If this is a commercial design for a product you > are going > to sell, that does not work very well. The same fundamental answer applies. > If you need > better performance, shop for a better oscillator. > > > Lots of fun > > > >> On May 21, 2018, at 12:23 PM, Club-Internet Clemgill >> wrote: >> >> Thanks for your interesting replies. >> What I am actually trying to do is the following: >> I bough a small ocxo (size of half a ping-pong ball) that performs well >> (Abracon / AOCJY3_B 10Mhz) >> Reaching about 5*10E-11 kind of MDEV at low point ("kind of"… because a I >> use an HP52132a as input to Timelab) >> But it’s frequency is slowly drifting with time, with a quasi linear slope. >> I wondered if placing it in a third ovenized enclosur
Re: [time-nuts] time-nuts Digest, Vol 166, Issue 44
Mark, Ditto this. On 6T's and M8T's both. The 6T's do have an odd issue once in a while, right at the roll over limit from +10.whatever nS to -10.whatever nS, sometimes the sawtooth value comes in with the wrong sign. We were playing with the 6T's in a GPSDO, against a good crystal it stuck out really well in the graph. A software check in the GPSDO looks for this and fixes it. Seemed like it happened about once a week to once a month type timeframe. Have you noticed this in your hardware? Dan On 5/21/2018 3:21 PM, time-nuts-requ...@febo.com wrote: Message: 10 Date: Mon, 21 May 2018 19:21:25 + From: Mark Sims To:"time-nuts@febo.com" Subject: [time-nuts] NEO-M8N vs. NEO-M8T Message-ID: Content-Type: text/plain; charset="iso-8859-1" It looks like you have slipped a decimal point somewhere (also that "ps" label is wrong). I have an M8N running here and the report sawtooth errors are all within a ± 10 ns span. (and LEA-5T is ± 5ns). ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi Backing up a bit …. If this is all about a system that can quantize to 52 ns at best … your ADEV plot shows everything *well* below that at all offsets you display. If you assume a +/- 1 LSB sort of quantization, you are out to 104 ns. That’s 10X anything on the plot. You would very much need to dig into just how the i/o structure on the device actually handles asynchronous inputs to be sure of what it really is doing. There are a lot of “debounce / re-synch” sort of structures that get pasted into devices these days. Bob > On May 21, 2018, at 3:21 PM, Gary E. Miller wrote: > > Gregory! > > On Mon, 21 May 2018 19:06:17 + > Gregory Maxwell wrote: > >> My best guess is that the magnitude of sawtooth error is just not >> large enough to matter for typical applications of linux PPS. > > No need to guess. I recently posted that the RasPi 3B granularity is > 52 nano Seconds and the PPS offset reported by UBX-TP is double that! > > So, clearly it matters. > > I'll do more data logging to get harder numbers. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? >"If you can’t measure it, you can’t improve it." - Lord Kelvin > ___ > 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] Motorola GPS Antenna?
I grew up downstate — NE of Quincy, IL and the Motorola TV mfg. operations at Quincy closed before the Franklin Park (North) plant. While there were assurances that Panasonic would continue operations at Quincy, local officials were caught “off guard” with decision to close a Motorola plant that was less than 15 years old. My high school electronics instructor (former Motorola) came to new vocational wing of high school (1970) as a result of those layoffs and closings. greg == Since timing is everything to TimeNuts ….. :) The Motorola TV plant ( known as the Franklin Park North plant, not to be confused with Franklin Park South where they made …. errr ….. oscillators ) to Panasonic in 1974. The whole transaction came as quite a shock to the people involved. The guy running the division was very much caught off guard….. He happened to be presenting to a group of us the day after the announcement …. The Panasonic cell tower timing antenna shows up under a *lot* of different labels. They do indeed sell it under the Panasonic brand name as well. It is regarded as reasonably bullet proof in terms of blocking cell tower RFI. 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] NEO-M8N vs. NEO-M8T
Yes, the Ublox sends ps... whatever software that is processing the message is scaling it wrong. And labeling it wrong... qErr:-0.00105210 ps... that aint' right... no way... no how.. ___ 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] NEO-M8N vs. NEO-M8T
Richard McCorkle on his own GPSDO design had a separate PIC keep track of the saw tooth information from a M12 ad and subtract during the filter time constant and transferd the sum to the filter for processing. Bert Kehren In a message dated 5/21/2018 2:55:44 PM Eastern Standard Time, ch...@chriscaudle.org writes: On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote: > On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: >> Now, how to I tell the Linux kernel to apply that correction? > > Have the PPS driver accept the correction before logging the PPS > timestamp. Or just have the PPS driver log the raw timestamp, then have the PLL engine in ntpd incorporate the corrections into the math of the control loop. Presumably ntpd will be getting the information passed in from gpsd, so the clock control daemon should have the correction information in plenty of time before the next PPS pulse gets logged. -- Chris Caudle ___ 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] NEO-M8N vs. NEO-M8T
Yo Mark! On Mon, 21 May 2018 19:21:25 + Mark Sims wrote: > It looks like you have slipped a decimal point somewhere (also that > "ps" label is wrong). Yes, seemed 10x too high to me too. But the doc for UBX-TIM-TP clearly says 'ps'. UBX-TIM-TP: qErr ps Quantization error of time pulse (not supported for the FTS product variant). Here is another data point, with the raw data so you can check the decode: Class: TIM(0xd) ID: TP(0x1), len: 0x10 payload: f0fb5509e7d6d2070a00 tow:1566300.0 qErr:-0.00105210 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available Sure looks like 105 nano seconds to me. If I'm wrong I'd love to know where. > I have an M8N running here and the report > sawtooth errors are all within a +/- 10 ns span. (and LEA-5T is +/- > 5ns). Many things could explain the difference. We seem to only differ by 5x or 10x. Also, my ADEV plot clearly showed the NEO-M8N adev was better than the NEO-M8T adev at tau=0, so your observations match mine. Right now I'm doing a survey-in. Then I'll grab a days worth of TICC data. After that I'll go back and get long term standard deviations for qErr in Stationary and Survey-in modes. That, of course, will take days. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpy6EpQTaJpb.pgp Description: OpenPGP digital signature ___ 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] NEO-M8N vs. NEO-M8T
Yo Chris! On Mon, 21 May 2018 13:55:23 -0500 "Chris Caudle" wrote: > On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote: > > On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: > >> Now, how to I tell the Linux kernel to apply that correction? > > > > Have the PPS driver accept the correction before logging the PPS > > timestamp. > > Or just have the PPS driver log the raw timestamp, then have the PLL > engine in ntpd incorporate the corrections into the math of the > control loop. Presumably ntpd will be getting the information passed > in from gpsd, so the clock control daemon should have the correction > information in plenty of time before the next PPS pulse gets logged. I look forward to your patch! RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpiFYVgSKpnB.pgp Description: OpenPGP digital signature ___ 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] NEO-M8N vs. NEO-M8T
It looks like you have slipped a decimal point somewhere (also that "ps" label is wrong). I have an M8N running here and the report sawtooth errors are all within a +/- 10 ns span. (and LEA-5T is +/- 5ns). --- > Class: TIM(0xd) ID: TP(0x1), len: 0x10 tow:1519310.0 qErr:-0.00048400 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available Which says the next PPS is going to be -48.4 nano seconds out. Similar to the 52 nano seconds quantization error of a RasPi 3B.___ 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] ✘NEO-M8N vs. NEO-M8T
Gregory! On Mon, 21 May 2018 19:06:17 + Gregory Maxwell wrote: > My best guess is that the magnitude of sawtooth error is just not > large enough to matter for typical applications of linux PPS. No need to guess. I recently posted that the RasPi 3B granularity is 52 nano Seconds and the PPS offset reported by UBX-TP is double that! So, clearly it matters. I'll do more data logging to get harder numbers. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpRzSV8XavdG.pgp Description: OpenPGP digital signature ___ 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] Motorola GPS Antenna?
Hi Since timing is everything to TimeNuts ….. :) The Motorola TV plant ( known as the Franklin Park North plant, not to be confused with Franklin Park South where they made …. errr ….. oscillators ) to Panasonic in 1974. The whole transaction came as quite a shock to the people involved. The guy running the division was very much caught off guard….. He happened to be presenting to a group of us the day after the announcement …. The Panasonic cell tower timing antenna shows up under a *lot* of different labels. They do indeed sell it under the Panasonic brand name as well. It is regarded as reasonably bullet proof in terms of blocking cell tower RFI. Bob > On May 21, 2018, at 2:56 PM, Gregory Beat wrote: > > Motorola has worked with Matsushita Electric Industrial Co., Ltd (now known > as Panasonic Corporation) since 1960s. Motorola sold their television > division to Matsushita in 1970. > — > I believe that Motorola and Panasonic jointly developed this GPS antenna. > While Motorola exited the GPS receiver business over a decade ago, Panasonic > continued to OEM the VIC-100 antenna. > > Synergy has a product page and data sheet for the Panasonic VIC-100 antenna. > http://www.synergy-gps.com/index.php?option=com_content&task=view&id=139&Itemid=114 > > greg, w9gb > > Sent from iPhone 6s > ___ > 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] ✘NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 at 5:54 PM, Gary E. Miller wrote: > Also, how does that get me to the gola of a good PPS to feed into the > Linux PPS kernel module? I doubt Linux would accept a patch to put > gpsd, and more, into the kernel to read GPS and adjust the PPS. Considering that sawtooth error is something found in virtually every GPS receiver I've previously been somewhat surprised that the linux PPS stuff did not have support for it. My best guess is that the magnitude of sawtooth error is just not large enough to matter for typical applications of linux PPS. ___ 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] Motorola GPS Antenna?
Motorola has worked with Matsushita Electric Industrial Co., Ltd (now known as Panasonic Corporation) since 1960s. Motorola sold their television division to Matsushita in 1970. — I believe that Motorola and Panasonic jointly developed this GPS antenna. While Motorola exited the GPS receiver business over a decade ago, Panasonic continued to OEM the VIC-100 antenna. Synergy has a product page and data sheet for the Panasonic VIC-100 antenna. http://www.synergy-gps.com/index.php?option=com_content&task=view&id=139&Itemid=114 greg, w9gb Sent from iPhone 6s ___ 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] NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 1:52 pm, Chris Caudle wrote: > On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: >> Now, how to I tell the Linux kernel to apply that correction? > > Have the PPS driver accept the correction before logging the PPS > timestamp. Or just have the PPS driver log the raw timestamp, then have the PLL engine in ntpd incorporate the corrections into the math of the control loop. Presumably ntpd will be getting the information passed in from gpsd, so the clock control daemon should have the correction information in plenty of time before the next PPS pulse gets logged. -- Chris Caudle ___ 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] NEO-M8N vs. NEO-M8T
On Mon, May 21, 2018 1:19 pm, Gary E. Miller wrote: > Now, how to I tell the Linux kernel to apply that correction? Have the PPS driver accept the correction before logging the PPS timestamp. -- Chris Caudle ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi > On May 21, 2018, at 2:08 PM, Gary E. Miller wrote: > > Yo Bob! > > On Mon, 21 May 2018 14:00:41 -0400 > Bob kb8tq wrote: > Ok, are you trying to hold close to UTC or simply have a second that is as close to 1 second as possible? >>> >>> Yes. One follows the other. >> >> Not really, you can have a source of seconds that are all within 0.1 >> ns of the right length but are offset from UTC by 200 ns. ( stable >> but not accurate) >> >> You can have a series of seconds that are all within 10 ns of UTC, >> but one may be 20 ns to short and the next is 20 ns to long. >> ( accurate but not stable ) >> >> So, which of the two is more important? > > UTC is most important (to me), but if one has perfect UTC, then one also > has perfect seconds. Except that you are doing a design. That involves tradeoffs. Pre-processing a thing message that comes in 800 ms before a pulse does not sound like a big deal to me. In your design it apparently *is* a big deal. If you indeed want very tight UTC, that involves very similar sorts of things. There are a *lot* of delays to be worked out. The offsets between GPS time and UTC need to be downloaded and summed into the servo as well. A GPSDO ( or anything that works like one) will have accurate second to second timing. In a very general sense, it does not care about a time offset. A fixed delay of 100 ns is no different than a fixed delay of 200 ns as far as it’s output or it’s function. So, no, it’s not a drop dead simple choice. Bob > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? >"If you can’t measure it, you can’t improve it." - Lord Kelvin > ___ > 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] NEO-M8N vs. NEO-M8T
Yo Scott! On Mon, 21 May 2018 13:08:06 -0500 Scott Newell wrote: > >The NEO-M8T is an FTS product. > > Are you sure about that? I thought the M8T was timing, and the M8F > was FTS. Please check your firmware version string against the table > on page 8. I stand corrected. I do see UBX-TIM-TP: Class: TIM(0xd) ID: TP(0x1), len: 0x10 tow:1519310.0 qErr:-0.00048400 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available Which says the next PPS is going to be -48.4 nano seconds out. Similar to the 52 nano seconds quantization error of a RasPi 3B. Here is another one, -101 nano seconds out: Class: TIM(0xd) ID: TP(0x1), len: 0x10 tow:1522360.0 qErr:-0.00101900 ps, week:2002 flags:0xa refInfo:0x0 is GPS, UTC available That is more than double my quantizaation error! Now, how to I tell the Linux kernel to apply that correction? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpKCL0vRvDzZ.pgp Description: OpenPGP digital signature ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi Gary, It sounds like you need some special hardware that corrects the pulse timing before feeding it out. Richard Hambley's CNS-II did exactly that, using a programmable delay-line - see: https://www.cnssys.com/cnssys.php I seem to remember discussion about that in the Time-Nuts archives. I have one, and it is excellent (and Richard was very helpful), but was "only" accurate to a nanosecond or two - excellent then, but you can now get that natively from the Furuno. But if you were willing to build some hardware and use that principle on the Furuno, with (a lot of!) care you should be able to get a very stable and accurate output signal. Peter ___ 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] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Mon, 21 May 2018 14:00:41 -0400 Bob kb8tq wrote: > >> Ok, are you trying to hold close to UTC or simply have a second > >> that is as close to 1 second as possible? > > > > Yes. One follows the other. > > Not really, you can have a source of seconds that are all within 0.1 > ns of the right length but are offset from UTC by 200 ns. ( stable > but not accurate) > > You can have a series of seconds that are all within 10 ns of UTC, > but one may be 20 ns to short and the next is 20 ns to long. > ( accurate but not stable ) > > So, which of the two is more important? UTC is most important (to me), but if one has perfect UTC, then one also has perfect seconds. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp8XPhkHfA2F.pgp Description: OpenPGP digital signature ___ 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] NEO-M8N vs. NEO-M8T
At 12:57 PM 5/21/2018, Gary E. Miller wrote: As the manual says: "Quantization error of time pulse (not supported for the FTS product variant)." The NEO-M8T is an FTS product. Are you sure about that? I thought the M8T was timing, and the M8F was FTS. Please check your firmware version string against the table on page 8. I'm sorry, but I don't have any ublox 8 variants handy to test with. (Just a 6T and 7N. I'm nearly certain I've seen the quant error message from the 6T, maybe the 7N as well.) -- newell N5TNL ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi > On May 21, 2018, at 1:44 PM, Gary E. Miller wrote: > > Yo Bob! > > On Mon, 21 May 2018 13:41:08 -0400 > Bob kb8tq wrote: > >> Ok, are you trying to hold close to UTC or simply have a second that >> is as close to 1 second as possible? > > Yes. One follows the other. Not really, you can have a source of seconds that are all within 0.1 ns of the right length but are offset from UTC by 200 ns. ( stable but not accurate) You can have a series of seconds that are all within 10 ns of UTC, but one may be 20 ns to short and the next is 20 ns to long. ( accurate but not stable ) So, which of the two is more important? Bob > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? >"If you can’t measure it, you can’t improve it." - Lord Kelvin > ___ > 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] NEO-M8N vs. NEO-M8T
Yo Scott! On Sun, 20 May 2018 22:03:49 -0500 Scott Newell wrote: > At 09:23 PM 5/20/2018, Gary E. Miller wrote: > > >I do not see the keyword 'sawtooth' in the u-blox 8 doc. Can I buy > >a clue? > > UBX-TIM-TP, "Time Pulse Timedata". Look for "Quantization error of > time pulse". I'm seeing this on page 359 of the ublox 8 receiver > description/protocol spec book. As the manual says: "Quantization error of time pulse (not supported for the FTS product variant)." The NEO-M8T is an FTS product. So not on the NEO-M8T. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpGk1JeWvazK.pgp Description: OpenPGP digital signature ___ 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] ✘NEO-M8N vs. NEO-M8T
Yo Hal! On Sun, 20 May 2018 20:22:46 -0700 Hal Murray wrote: > g...@rellim.com said: > > Yeah, which does me zero good real time. I'm putting the PPS into > > a TICC. My TICC has not way to accept real time corrections. So > > that does me no good, except as a post processing step. > > Yes, but that post processing step can be done in real time. > Assuming you are writing the TICC data to a log file: > Read the TICC data. > Read the sawtooth info. > Apply the sawtooth correction. > Write out the updated TICC data. Your concept of 'real time' does not match mine. Also, how does that get me to the gola of a good PPS to feed into the Linux PPS kernel module? I doubt Linux would accept a patch to put gpsd, and more, into the kernel to read GPS and adjust the PPS. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpYPohJ7hec_.pgp Description: OpenPGP digital signature ___ 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] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Mon, 21 May 2018 13:41:08 -0400 Bob kb8tq wrote: > Ok, are you trying to hold close to UTC or simply have a second that > is as close to 1 second as possible? Yes. One follows the other. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpczGhZvqeLC.pgp Description: OpenPGP digital signature ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi Ok, are you trying to hold close to UTC or simply have a second that is as close to 1 second as possible? Bob > On May 21, 2018, at 1:33 PM, Gary E. Miller wrote: > > Yo Bob! > > On Mon, 21 May 2018 10:39:33 -0400 > Bob kb8tq wrote: > >>> Yeah, which does me zero good real time. I'm putting the PPS into a >>> TICC. My TICC has not way to accept real time corrections. So that >>> does me no good, except as a post processing step. >>> >> >> You have a *something* to read the TICC output it does not just do it >> all on it’s own. > > Yes, but by then it is not real time. My real goal is to improve > Linux time. I'm not holding my breath for a kernel module that > takes the corrections. Someday. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? >"If you can’t measure it, you can’t improve it." - Lord Kelvin > ___ > 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] ✘NEO-M8N vs. NEO-M8T
Yo Bob! On Mon, 21 May 2018 10:39:33 -0400 Bob kb8tq wrote: > > Yeah, which does me zero good real time. I'm putting the PPS into a > > TICC. My TICC has not way to accept real time corrections. So that > > does me no good, except as a post processing step. > > > > You have a *something* to read the TICC output it does not just do it > all on it’s own. Yes, but by then it is not real time. My real goal is to improve Linux time. I'm not holding my breath for a kernel module that takes the corrections. Someday. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgplB8NWTwgfN.pgp Description: OpenPGP digital signature ___ 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] ✘NEO-M8N vs. NEO-M8T
Yo Oleg! On Mon, 21 May 2018 18:05:08 +0300 Oleg Skydan wrote: > You can use uBlox u-center software to enable and disable messages > you need, the configuration can be saved. I have not done Windows since the year 2000. Not restarting now. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpSX7YICfJKI.pgp Description: OpenPGP digital signature ___ 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] â NEO-M8N vs. NEO-M8T
Yo Chris! On Mon, 21 May 2018 08:23:27 -0500 "Chris Caudle" wrote: > The UBX-TIM-TP message is described in: > 32.21.8.1 Time Pulse Timedata > byte offset 8, name: qErr unit: ps > Quantization error of time pulse (not supported for the FTS product > variant). Notice the: not supported for the FTS product So, not on the NEO-M8T RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpVdk9FAD2pc.pgp Description: OpenPGP digital signature ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi Ok so they changed that from the earlier parts. Time marches on. Bob > On May 21, 2018, at 1:08 PM, Oleg Skydan wrote: > > > From: "Bob kb8tq" >> You have always been able to poll the time offset message on any of the uBlox >> modules. Getting that message to auto repeat was the traditional issue on >> there >> earlier products. A serial dump would tell you if u-center is getting the >> information >> by polling or not. > > Thanks for the information. I have checked the console dump (of the NEO-6M > module), it does not poll for TIM-TP, the message is sent automatically > (after enabling in u-center). > > Oleg > ___ > 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] Improving ocxo temp control
Hi There are a lot of reasons an OCXO drifts. Temperature control is rarely the issue. More likely you are looking at the drift / wander characteristics of the crystal ( and components) in the OCXO. The simple answer is to leave it on for a while ( like weeks) to allow things to settle out a bit. The paper that Rick tossed up last week is a pretty good one in terms of temperature control issues in an OCXO and what the issues are. This all assumes you are in a fairly benign environment. If you have lots of drafts, put a cardboard box over the unit to shield it. If you room temperature is all over the place, then there are a lot of ways to get to ~ 1 or 2C sort of stability in a lab. What you do depends a *lot* on what your situation is. = So, assuming you *do* want to improve the temperature control: First you need to take out what’s in there now. If it’s wandering around get rid of it. This involves tearing apart the OCXO. Now take a look at Rick’s paper and redesign the thermal enclosure. Get the heater placement and sensor placement right and feed that into a simple controller. Run some tests over temperature and check out the data. It’s likely your first guess at things is not going to be correct. Try to optimize the heat sources and sensors and re-test the result. Everything interacts so this is not a quick process. Once you are reasonably happy with where things are, start looking at a more fancy controller. A simple approach would be feeding thermistor voltage into some 24 bit ADC’s and then processing the result with an MCU. Ok so that’s all a bit much. = What happens if you mess with the OCXO from the outside of the package? You change the heat loss out of the package. This increases the thermal gain. ( less power to increase the oven temperature by 1 C ). Assuming the original circuit was balanced out, you have made things worse rather than better. Ok so you do an enclosure with a fan it it so the heat loss doesn’t get less. You now have more heat loss and the same issue applies. In addition the fan and it’s nonsense probably haven’t done the poor little OCXO any good. When one designs a double oven, the inner oven is optimized for performance *with* the outer oven present. Equally, the outer oven is optimized for performance with the heat load (and dynamics) of the inner oven. = Assuming you still want to head down this road, temperature controllers are no different than any control loop. The first place to start is a textbook on control loops and control theory. The basics of what a loop does and the terminology are what you are after. Anything advanced will assume you understand this part first. Next up are temperature sensors. Simple answer here is that a glass bead thermistor is the way to go. For heat, transistors are the normal go-to device. The controls loop takes in the thermistor output and spits out a voltage to change the current through the transistor. If you have the money for software licenses, the next stop is some good mechanical CAD that will feed into thermal modeling. From that you can work out a proper heat flow and gradient design. Assuming that is a bit to expensive, you are back to trial and error. There are no “just duplicate this” designs that I know of. Once you have the structure, sensors, heaters, and control you toss it into a temperature test chamber. That may be something fancy or something you put together. You run the gizmo over temperature and observe what it does. You then optimize the P,I,D coefficients in your control loop. Indeed you may not have all of them or you may have an extra one. === Of course one could simply shop for a $20 OCXO on eBay. Even if you have to buy a dozen before you find a good one, it’s still cheaper / faster / easier / more likely to succeed than all the nonsense above. If this is a commercial design for a product you are going to sell, that does not work very well. The same fundamental answer applies. If you need better performance, shop for a better oscillator. Lots of fun > On May 21, 2018, at 12:23 PM, Club-Internet Clemgill > wrote: > > Thanks for your interesting replies. > What I am actually trying to do is the following: > I bough a small ocxo (size of half a ping-pong ball) that performs well > (Abracon / AOCJY3_B 10Mhz) > Reaching about 5*10E-11 kind of MDEV at low point ("kind of"… because a I use > an HP52132a as input to Timelab) > But it’s frequency is slowly drifting with time, with a quasi linear slope. > I wondered if placing it in a third ovenized enclosure could improve things. > I tried a few experiments but seems that the temp needs to be very accurately > controlled. > Any similar experience ? > Could you suggest papers describing high performance analog or digital > controllers ? > Thx, > Gilles. > > >> Le 19 mai 2018 à 16:09, Bob kb8tq a écrit : >> >> Hi >> >> One key point about t
Re: [time-nuts] ✘NEO-M8N vs. NEO-M8T
From: "Bob kb8tq" You have always been able to poll the time offset message on any of the uBlox modules. Getting that message to auto repeat was the traditional issue on there earlier products. A serial dump would tell you if u-center is getting the information by polling or not. Thanks for the information. I have checked the console dump (of the NEO-6M module), it does not poll for TIM-TP, the message is sent automatically (after enabling in u-center). Oleg ___ 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] Improving ocxo temp control
Thanks for your interesting replies. What I am actually trying to do is the following: I bough a small ocxo (size of half a ping-pong ball) that performs well (Abracon / AOCJY3_B 10Mhz) Reaching about 5*10E-11 kind of MDEV at low point ("kind of"… because a I use an HP52132a as input to Timelab) But it’s frequency is slowly drifting with time, with a quasi linear slope. I wondered if placing it in a third ovenized enclosure could improve things. I tried a few experiments but seems that the temp needs to be very accurately controlled. Any similar experience ? Could you suggest papers describing high performance analog or digital controllers ? Thx, Gilles. > Le 19 mai 2018 à 16:09, Bob kb8tq a écrit : > > Hi > > One key point about the need for “zero gradient”: > > Crystals and many other components are quite sensitive to thermal gradients. > Very small > fractions of a degree (as a gradient ) can have significant impact on the > frequency of an > oscillator. > > One of many “interesting things” about fiddling about OCXO’s. > > The equally frustrating thing about this is that unless you can tease kind > paper authors > into posting things ( thanks Rick !!) the papers are behind pay walls. I > pretty much despise > that practice. Referencing papers that send people off to spend money ….not > so much. > > Bob > >> On May 19, 2018, at 12:03 AM, Richard (Rick) Karlquist >> wrote: >> >> In my experience, the oven temperature controller is rarely >> the determining factor for static oven performance. This article >> explains what the real determining factors are: >> >> http://www.karlquist.com/oven.pdf >> >> An analog oven temperature controller will be limited in >> its dynamics by how much capacitance you are able to >> design with. Digital controllers get around this as well >> as having the capability of double integration for much >> better transient response. >> >> Rick >> >> On 5/18/2018 11:03 AM, Gilles Clement wrote: >>> Hi, >>> I am trying to improve performance of an OCXO. >>> Could you point me at a good design of a high resolution oven temperature >>> controler please ? Preferably analog. >>> Thx much, >>> Gilles. >>> ___ >>> 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] Motorola GPS Antenna?
Is it worth buying for that money if it is? On Mon, 21 May 2018 5:13 pm Dan Rae, wrote: > On 5/21/2018 8:24 AM, Clint Jay wrote: > > Found on eBay with no further information, can anyone identify? > > > > > https://www.ebay.co.uk/itm/EX-MOD-Motorola-Antenna/323177970249?hash=item4b3ee87a49:g:tHIAAOSwUCZavUAe > > > It looks like the standard "Marine" antenna, probably 5v, loads of gain > (30 dB?), like the one I have up on my roof. There should be a part > number under the rubber gasket if you want to ask the seller to have a > look. > > 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] Motorola GPS Antenna?
On 5/21/2018 8:24 AM, Clint Jay wrote: Found on eBay with no further information, can anyone identify? https://www.ebay.co.uk/itm/EX-MOD-Motorola-Antenna/323177970249?hash=item4b3ee87a49:g:tHIAAOSwUCZavUAe It looks like the standard "Marine" antenna, probably 5v, loads of gain (30 dB?), like the one I have up on my roof. There should be a part number under the rubber gasket if you want to ask the seller to have a look. 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] ✘NEO-M8N vs. NEO-M8T
Lady Heather can configure the various time pulse / PPS outputs on the Ublox receivers. (P keyboard menu) If the receiver supports sawtooth data, the current sawtooth value will be shown at the top of the screen (second column). It can also be shown in the plot area (GD will toggle the sawtooth graph... it is off by default since it tends to be noisy looking mess). Ublox receivers may power up speaking NMEA. If you start Heather up with the /rxu command, it will put it into Ublox binary mode. The Thunderbolt has no sawtooth error since the GPS RF chain is locked to the OCXO. If the OCXO is too far off freq the Thunderbolt will not be able to track satellites. ___ 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] Motorola GPS Antenna?
Found on eBay with no further information, can anyone identify? https://www.ebay.co.uk/itm/EX-MOD-Motorola-Antenna/323177970249?hash=item4b3ee87a49:g:tHIAAOSwUCZavUAe -- Clint. M0UAW IO83 *No trees were harmed in the sending of this mail. However, a large number of electrons were greatly inconvenienced.* ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi You have always been able to poll the time offset message on any of the uBlox modules. Getting that message to auto repeat was the traditional issue on there earlier products. A serial dump would tell you if u-center is getting the information by polling or not. Bob > On May 21, 2018, at 11:05 AM, Oleg Skydan wrote: > > Hi! > > From: "Bob kb8tq" >> Not by default You go through the 390 pages of their manual and eventually >> find the bits to turn this and that on. When you do, those magic bits will >> enable >> the data on a T version and will not enable it on a non-T version. At least >> that’s >> the way it’s worked since the LEA-4T … > > You can use uBlox u-center software to enable and disable messages you need, > the configuration can be saved. > > It looks like the NEO-M8N (non timing one) module should provide sawtooth > correction data (at least the manual does not say that TIM-TP message is > available on timing modules only). I was able to enable TIM-TP message on the > older NEO-6M. You can test if it works with the help of u-center. > > Best! > Oleg > ___ > 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] ✘NEO-M8N vs. NEO-M8T
Hi! From: "Bob kb8tq" Not by default You go through the 390 pages of their manual and eventually find the bits to turn this and that on. When you do, those magic bits will enable the data on a T version and will not enable it on a non-T version. At least that’s the way it’s worked since the LEA-4T … You can use uBlox u-center software to enable and disable messages you need, the configuration can be saved. It looks like the NEO-M8N (non timing one) module should provide sawtooth correction data (at least the manual does not say that TIM-TP message is available on timing modules only). I was able to enable TIM-TP message on the older NEO-6M. You can test if it works with the help of u-center. Best! Oleg ___ 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] ✘NEO-M8N vs. NEO-M8T
Hi > On May 20, 2018, at 11:49 PM, Mark Sims wrote: > > I think what Gary really wants is a GPS receiver with the most stable PPS > output available. Unfortunately that’s not how any of these devices are designed to be used. They all ( including the Furuno ) have a sawtooth issue. It’s just how the fundamental process inside them works. > That is probably the Furuno GT-8736... 1.7 nsec sawtooth error. Typical PPS > span is +/- 4 nsec. Also, the Trimble Thunderbolt has 0 sawtooth error. The TBolt is a GPSDO, which is a very different beast. It takes the “sawtooth" error it measures and shoves it into the control loop for the OCXO. The net result is a zero average error vs GPS. That’s how all phase lock based GPSDO’s do things. The tradeoff is the magic word “average” that snuck in there. Depending on the control loop parameters ( and a few other things ) the time out of the GPSDO may be off from GPS time by quite a bit. If “time right now” is what you are after ( this is TimeNuts after all ), a GPSDO may not be the ideal answer …. If “time right now” is the goal, the real time clock corrections you can grab on the internet may well be part of the total solution. 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] ✘NEO-M8N vs. NEO-M8T
Hi > On May 20, 2018, at 10:58 PM, Gary E. Miller wrote: > > Yo Bob! > > On Sun, 20 May 2018 22:53:37 -0400 > Bob kb8tq wrote: > >> If you look at the section under “timing (page 79)” in the uBlox >> manual you will find all the fun stuff that makes the T different. >> One of the timing messages includes the time offset between the pps >> output and the real GPS time solution. Page 351 and after are the >> time related commands. The stuff back around page 358 looks like it’s >> got the sawtooth data in it. > > Yeah, which does me zero good real time. I'm putting the PPS into a > TICC. My TICC has not way to accept real time corrections. So that > does me no good, except as a post processing step. > You have a *something* to read the TICC output it does not just do it all on it’s own. The same something at the same time gets the same data on the same pulse to correct it. That’s real time. That device does the math for the correction and presents it instantaneously. That is very much real time. >> Bottom line is that with the sawtooth correction applied, you can get >> down to below 1x10^-9 at one second on your plot. > > Yeah, which does me no good real time. > >> The T version will >> automatically output the magic message with the data in it. > > Not seeing it by default. Not by default You go through the 390 pages of their manual and eventually find the bits to turn this and that on. When you do, those magic bits will enable the data on a T version and will not enable it on a non-T version. At least that’s the way it’s worked since the LEA-4T … Bob > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? >"If you can’t measure it, you can’t improve it." - Lord Kelvin > ___ > 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] â NEO-M8N vs. NEO-M8T
On Sun, May 20, 2018 9:23 pm, Gary E. Miller wrote: > I do not see the keyword 'sawtooth' in the u-blox 8 doc. Can I buy a > clue? Sawtooth is what it looks like when you plot the quantization error of the PPS output, the documentation will just refer to it as quantization error. Referencing this doc (not sure it is the exact match for your model) https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_%28UBX-13003221%29_Public.pdf 18.1 Introduction u-blox receivers include a time pulse function providing clock pulses with configurable duration and frequency. The time pulse function can be configured using the UBX-CFG-TP5 message. The UBX-TIM-TP message provides time information for the next pulse, time source and the quantization error of the output pin The UBX-TIM-TP message is described in: 32.21.8.1 Time Pulse Timedata byte offset 8, name: qErr unit: ps Quantization error of time pulse (not supported for the FTS product variant). I believe that means you ready byte offset 8 of that message, and it tells you how many picoseconds the next PPS output is expected to be early or late compared to the nominally correct location of the PPS pulse. Inject that offset into the math for your software implemented PLL and you can cancel out that noise caused by the GPS clock used to generate the PPS being asynchronous to the GPS satellite clocks. This document has some nice graphs of sawtooth shaped quantization errors, just search for sawtooth: https://ivscc.gsfc.nasa.gov/meetings/tow2011/Hambly.Sem.pdf -- Chris Caudle ___ 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] ✘NEO-M8N vs. NEO-M8T
Should say 1.7 nsec we also plan to use the GCLK output for what I call a GPS PLL we have done it successfully with low cost u-blox with E-11 frequency results. Bert Kehren In a message dated 5/21/2018 7:49:20 AM Eastern Standard Time, time-nuts@febo.com writes: Our answer was real time correction, see attached, just received boards for Furuno BT-87, with a specification of 1.7 msec. saw tooth, we do not plan on any additional processing.We have experience with Ublox up to 7 but have spend no time on 8, waited on availability of the 87. Digi Key wants $ 100 but found them half that price in Germany. Has any body found a lower price in the US? Bert Kehren In a message dated 5/20/2018 11:12:05 PM Eastern Standard Time, g...@rellim.com writes: Yo Mark! On Mon, 21 May 2018 03:04:23 + Mark Sims wrote: > The sawtooth value is in the 0x0D-0x01 (TIM-TP) message. Third > value, called qErr. 32-bit dword. In picoseconds. How do I feed that into my TICC in real time? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin ___ 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.