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] Furuno GT-8031 breakout board
Hi Bob, If you do a group buy of GT-8736 I'm game for 10. On Thu, Feb 15, 2018 at 6:55 PM, Bob Darlington wrote: > I bought some of the Furuno GT-8736 boards for $35 a pop, qty 1 (or 2 as > was the case). And was quoted at $26.91 a pop if I buy 100. If there's > interest, I'm happy to coordinate a group buy at cost. Just paid off that > credit card yesterday so why not? If there are more desirable boards from > Furuno, let me know and I'll see what I can do. > > -Bob > > On Thu, Feb 15, 2018 at 3:59 AM, ew via time-nuts > wrote: > >> Talking about Furuno has any one looked at the GT-87. I have known about >> it for years but found no way to buy some now DigiKey has them for $ 100, >> Buerklin in Germany for half that price. Saw tooth is +- 1.7 nsec we are >> not going to bother with correction. We are in the process to lay out a >> board any recommendations are appreciated >> Bert Kehren >> >> In a message dated 2/15/2018 12:39:48 AM Eastern Standard Time, >> hol...@hotmail.com writes: >> >> >> I just did a small adapter board that converts the 2x5 pin 2mm header on >> the Furuno GT-8031 to a 1x9 pin 0.1" connector with the pinouts of the >> Adafruit Ultimate GPS. There a couple of minor pin differences... the >> Adafruit FIX pin is not used and the Adafriuit 3.3VREG output pin is used >> as the Furuno antenna power connection. The Furuno can be soldered to the >> board or a female connector could be installed. >> >> I'm getting ready to order a few boards. If interested, contact me off >> list.___ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> 1 Attached Images >> >> ___ >> time-nuts mailing 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] Why discipline Rubidium oscillator?
On Mon, Nov 20, 2017 at 8:28 PM, Jerry Hancock wrote: > Bob, I was referring to the rubidium standard of 6834682610.904 Hz. For some > reason I thought it was closer to 9Ghz. > > I assume then rubidium standards oscillate (if that is the correct term) > somewhere around that number but not exact or is it in the detection where > things fall down? I think you are confused by the difference between primary and secondary standards. A typical rb gas cell is a secondary standard. Its exact frequency is distorted by a number of factors like gas pressure, interaction with the cell walls, and ambient magnetic fields which cannot be canceled by the design of the standard. This is why it is useful to discipline a telecom rb against GPS, disciplining can be accomplished through control of a biasing magnetic field. Something like a cesium beam standard is able to internally cancel most of these biases "under standard conditions". A drift free frequency source can also be constructed using rubidium, such as rubidium fountains just as a secondary standard could be constructed using cs-- like cs gas cell standards (such as the sa.45 CSAC). [Hopefully I haven't mangled 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.
[time-nuts] Novatel Dual frequency GNSS receivers on ebay
There is an ebay listing for "Novatel GPS-702-GG with SPAN-CPT Single Enclosure GNSS/INS Receiver + Cable" with a fairly large number available. This is a Novatel OEM628 dual frequency receiver (supports GPS, Glonass, SBAS, apparently including L1C and L2C), plus a three fiber ring gyros (with bias performance that blows away any mems gyro I've ever used) and an 3-axis mems acceletrometer in an aluminum case, plus a decent dual frequency antenna. This is a generation-ish old kit. The industrial casing conspires to make it look somewhat less modern than it actually is. The receivers have external clock input (though not plumbed to the outside of the case) which appears to work though I didn't try much with it yet. Mine came with 2013-ish firmware but easily upgraded to current (2016) firmware. There is a windows based firmware update tool which talks to it over serial and is very straight forward (The firmware update OEM6631.zip can be found via google). You can communicate with them over serial in ascii, there is extensive firmware documentation that goes over every command https://www.novatel.com/assets/Documents/Manuals/om-2129.pdf some of which are specific to other modules. There is also a separate manual for the inertial navigation specific features (NovAtel SPAN-CPT Users manual.pdf) The external clock should allow you to hang it off a more stable oscillator which will improve the stability of the GNSS results, and _I presume_ improve the quality of the PPS output-- the firmware manual and operating manual are thin on details, and mostly just go into telling you how to adjust the kalman filter constants for different clock types. These also appear to support the novatel 'align' mode where you serial connect two receivers separated by a short baseline and get really accurate absolute headings; I'm planning on trying that that but haven't set it up yet. Looks like uber (last position was ubers offices in denver) had a fleet of these things. The couple I got run great, including the IMU, the antennas obviously spent a long time outside, but work fine. The cable they come with is weird, but I had no problem chopping one end off and figuring out the pinout (see bottom). The novatel OEM6 is well supported by rtklib and I was able to get post-processed positions very easily. Seller takes best offers a fair amount below the $649 asking price. Looks like they may have another 30 or so of them. May be useful for doing time transfer especially with the clock input. Just using it to get nice dual band observations to precisely survey an antenna location for a traditional GPSDO may improve GPSDO performance by a fair amount. Here is the signals and wire colors on the cables mine came with. YMMV, I'd suggest not blindly trusting that colors match on other units.These cables don't plumb out many of the signals from the module (in particular, they don't carrying COM2, which is why I haven't tried multi-receiver headings yet, since I'd need to figure out how to talk to it over USB if com1 is in use for that), I'm unsure if they're wired through the to external connector. 01 white power return (-) 02 brown 9-18 VDC power input (+) 03 yellowCOM1 RS232 TX 05 pink COM1 RS232 RX 09 green COM1 GND 10 black USB D+ 11 purple USB D- 12 yellow brnstp USB GND 15 redODO SIGA 16 blue ODO SIGA-inv 29 grey pinkstp PPS (high resistance? 80 ohm) 30 whitw grnstp Event1 31 red blustp signal ground ___ time-nuts mailing 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] The Witching Hour; short fiction that will likely amuse time-nuts
Found on the web: http://slatestarcodex.com/2013/11/03/the-witching-hour/ ___ time-nuts mailing 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] Optical Cesium or maybe Cesium "light"!
On Sat, Mar 18, 2017 at 2:48 AM, wrote: > Looks like Oscilloquartz is getting ready to sell this commercially! http://www.chronos.co.uk/files/pdfs/itsf/2015/day2/1410_High_performance_optically-pumped_cesium_beam_clock-PBerthoud-Oscilloquartz.pdf Two year old deck with a fair amount of overlap, though a few more engineering diagrams. Heres to hoping they fit it with an unreliable LCD backlight so they'll be available as cosmetically defective cheap surplus in the future. :) ___ time-nuts mailing 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] hm H Maser
On Wed, Jan 11, 2017 at 12:25 AM, Bob kb8tq wrote: > I have a pile of stuff. You have a pile of stuff. Others each have their pile > of stuff. Doing > a design that works only with my pile is possible. Doing a design that works > with my pile [...] > You have to do it with a fairly standardized > design. That means buying (at the very least) kits of parts. Like it or not, > the parts kit for a > Rb will be cheaper than the parts kit for any of the other devices….. I read the occasional posts by PHK on his efforts to upgrade the electronics in his 5065a and Corby's SUPER physics package upgrade with great interest. I have wondered if the end result may be that incremental upgrades to someone elses classic design, adding on modern synthesizers and digital control, etc. Might eventually result in a 'Ship of Theseus' oscillator, which in its final form is buildable from relatively easily sourced parts (plus perhaps a rubidium cell that could be group bought at non-absurd prices). Presumably taking an already established design and improving it incrementally has lower risk and costs than a new design. In particular, it can start off with 5065a as "my pile" inputs, but by the end it doesn't have them anymore... and not just lest risky but also a more natural way to divide the effort up into less professionally-sized chunks. ___ time-nuts mailing 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] Line Voltage - USA
On Mon, Jan 2, 2017 at 4:49 AM, Bill Byrom wrote: > Most US homes and small businesses are powered by what is commonly > called a "split-phase" 240 V feed. The final distribution system > transformer has a 240 V center-tapped secondary. The center tap is > grounded, and three wires are fed to the building (actually it might be > up to around 6 houses): > (1) Leg L1 or phase A (red wire) -- This wire will measure 120 V to the > neutral or 240 V to Leg L2. > (2) Neutral (white wire) -- This wire is grounded at the distribution > system and at the service entrance to the building. > (3) Leg L2 phase B (black wire) -- This wire will measure 120 V to the > neutral or 240 V to Leg L1. When someone here previously mentioned observing high voltage, one possible cause for this in this common "split-phase" configuration is that if the neutral wire is overloaded, damaged, poorly connected, or otherwise has high resistance, the voltage on the two legs will swing wildly and in opposite directions depending on load. So, e.g. if you put a 1kw load on L1 while L2 is nearly unloaded then perhaps L1s voltage drops to 108v while L2 rises to 132v. The reason for this is that, e.g. imagine that the neutral were removed completely you would effectively be connecting your appliances in a parallel-series circuit (all on L1 in parallel, all on L2 in parallel, the both in series) across the 240v feed. I've had issues with neutrals several times in the past, and in one instance, temporarily dealt with it by moving as much of the load to 240v as I could, manually balancing the remaining loads, and then using a digital multi-meter to dynamically control some additional load to keep the voltage sane on each side. I think the fact that you can end up with a much higher voltages at the outlet if the neutral has problems is one of the more unfortunate properties of the split-phase approach. ___ time-nuts mailing 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] Google public NTP service
On Wed, Nov 30, 2016 at 2:21 PM, Michael Rothwell wrote: > ... was just announced. > https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1 Obvious outcome is obvious. Leap smear prevented faults between google systems but then created the problem that other things don't agree with google's timestamps-- and the leapseconds still cause problems for many other parties. ___ time-nuts mailing 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] Sapphire whispering gallery mode masers?
The recent mention of WGM sapphire oscillators and recent threads about time-nut constructable secondary frequency standards reminded me of a paper I ran into a while back about a WGM maser. The mechanical of the device were similar to an ordinary WGM oscillator: cryocooled sapphire crystal in a vacuum. But electronically it was pretty different, a dopant in the crystal could be RF pumped at some frequency far away from one of the normal high-Q modes of the oscillator and formed a three-stage laser whos emission bandwidth included the normal (~10GHz) high-Q WGM, which it would then happily lase at. They reported that the signal power was significantly higher than a AHM. The advantage of the construction is that the maser level is controlled by saturation, and so it was not very sensitive to the intensity stability of the pump. It seemed to me that it might be a possible candidate for a difficult but achievable 'home' experiment for an oscillator with exceptional short to medium term stability in a way that something like a hydrogen maser isn't. (Then again, I've never worked with anything cooler than LN2). Unfortunately I can't find the paper, but I doubt I dreamed it. ___ time-nuts mailing 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] Tbolt issues
On Fri, Sep 2, 2016 at 12:51 AM, Charles Steinmetz wrote: > Now shorten the observation time to 20nS. We see 1/5 of a complete cycle > (72 degrees, 0.4 pi radians) of the wave. No matter which particular 72 > degrees we see, we simply don't have enough information to reliably deduce I do not see why you argue that. For the purpose of discussion, lets assume you have a noiseless signal which is stationary in frequency and amplitude over 20nS starting at the zero crossing. Given these strong priors (single tone, constant frequency which is not higher than one half cycle in our 20nS window, constant amplitude, noiseless) there is exactly one frequency consistent with any of those two observations. If the starting phase is unknown, I believe you need one additional observation to end up over-determined and have an unambiguous solution again. This kind of strong prior assumption is why sinusoidal estimators and PLLs are able to extract tones with precision far beyond what you would expect from taking a DFT from equivalent amount of data. In reality, there is phase noise, non-linearities, harmonics, tidal variations, and whatnot that make these assumptions untrue... but how far they corrupt these assumptions depends on how useless the results are. ___ time-nuts mailing 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] Ashtech Z-12 firmware?
I recently picked up a couple non-functional Ashtech Z-12 receivers with the external frequency input (these appear to PLL an internal TCXO; I understand there are other models where they replace the TCXO completely). I was hoping to use them both better data sources for common view time transfer with better performance than the GPS L1/CA that I've been using; as well as using them for ground truth data for a SDR semi-codeless CRPA receiver I'm slowly building. These units were hanging at startup at "Downloading channel". I determined that they would work a single time if the memory were cleared (by holding an arrow, right for external up for internal, during start). Because the internal 3.6v primary cell batteries were reading about 40mv I took a guess that the low battery was causing memory corruption across restarts. New batteries and a bit of soldering later, and they are working reliably across restarts, locking sats on L1/L2, talking on RS232, etc. (hurrah). Hopefully this message in the archives is useful if someone else encounters similar symptoms. Before I go further I was wondering if anyone knew of a source for firmware for these old units? One of mine is marked "Z-12 700751-6 (b)", unfortunately it seems ashtech has been sold many times, and the old web/ftp sites have been scattered to the wind. The nearest I was able to find was this page http://kb.unavco.org/kb/article/astech-micro-z---firmware,-firmware-release-notes,-firmware-upload-programs-and-how-to-use-them-368.html with micro-Z firmware. [If there is a relevant GNSS nuts list, I'd be glad to hear about it-- my interest is in CVTT but perhaps somewhere else there is a den of people obsessed with old survey hardware that would prefer these questions.] ___ time-nuts mailing 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] NUT4NT: Four-channel All-frequency GNSS RF-to-Bits
On Sat, Aug 13, 2016 at 11:53 PM, Bob Camp wrote: > Hi > > It’s not real clear what the second chip on the board does. If it is just a > bit to Ethernet converter > then you are dealing with 2 bit data out of each of the four channels. You > aren’t just doing tracking > in that case ….4 channels at 2 bits -> 8 bits per clock. Clock at 38 to 100 > MHz. That could turn out > to be a very crowded Ethernet connection. I assume it's like the GNSS firehose ( http://pmonta.com/blog/2012/06/04/gnss-firehose/ ) or the other existing GNSS SDR receivers: The device samples some bandpass around the relevant GNSS frequency(/ies), sends a digitized signal for you to despread and track. 2bits * 4ch * 20MHz * 2 (nyquist) = 320Mbit/sec, no big deal for gigabit ethernet or USB3 (or even USB2 for that matter, at least ignoring overheads). >From there you can have arbitrarily complex processing on the host-- but from that setup you can't easily produce a PPS signal-- the host will operate asynchronously with the signal, with lots of delay and jitter. I've long though a better design for a GPSDO is instead of having the GPS produce a PPS, you have the GPS contain a TIC and feed it a PPS, and capture those timestamps along with the gps observations. The GPS solution would then also include the observed offset. Beyond eliminating the extra complexity of sawtooth correction, this could produce better results under some signal conditions because averaging error signal produced from single fixes will not always produce the same result as running a larger model over more observations (because the errors can be multimodal). (besides-- for precise timing against an local atomic standard... you probably don't want to perturb the local clock, but instead track corrections to some reference time.) In either case (PPS out or PPS in) I believe some actual hardware support is needed to tie the PPS pulses to the GPS sampling clock, in any of these SDR GPS approaches... though I think not much. ___ time-nuts mailing 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] NUT4NT: Four-channel All-frequency GNSS RF-to-Bits
On Thu, Aug 4, 2016 at 11:08 PM, Daniel Mendes wrote: > > A new interesting toy soon to be crowdsourced: > > https://www.crowdsupply.com/amungo-navigation/nut4nt A shame, it looks like it can be externally clocked, but I don't see a way to get in and measure a PPS signal. Considering the increasingly frequent jamming I see doing a multiband CRPA timing receiver sounds like a fun project; but I'm not quite seeing how to do really overkill timing with this device. :) I guess on the NT1065 you'd want use the clk with a counter to capture the position of a PPS or external reference with respect the the sample clock?... and hopefully the signal processing chain from clock to the ADC has a constant delay? ___ time-nuts mailing 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] Leap second to be introduced at midnight UTC December 31 this year
On Thu, Jul 21, 2016 at 5:27 PM, Tom Van Baak wrote: > Time to mention this again... > > If we adopted the LSEM (Leap Second Every Month) model then none of this > would be a problem. The idea is not to decide *if* there will be leap second, > but to force every month to have a leap second. The IERS decision is then > what the *sign* of the leap second should be this month. I think dithered leapsecond would be a massive improvement over what we have now, I'd even pay for travel to send someone to advocate it at whatever relevant standards meeting was needed. But I still think it is inferior to no leapseconds at all (and adjusting timezones after the several thousand years required to make that needed). The reason I hold this is three fold: (1) The complexity to deal with leapseconds remains in LSEM. It won't be as much of a constant source of failure but correct handling is a real cost that goes into the engineering millions of products/projects. Some of the current practical methods of handling leap seconds (like shutting off/rebooting critical systems or discarding data) would also be less reasonable with LSEM. They might be less needed with LSEM but I cannot say that they would be completely unneeded*. (2) I'm not aware of any application that cares greatly about the precise alignment with the _mean_ solar day that doesn't need to go on and apply location specific corrections. Those applications could easily apply the UTC to mean solar adjustment along with their location specific adjustment. (3) Obtaining the leap second sign requires a trusted data source. When UTC has leap seconds a happily ticking atomic clock cannot keep second level alignment with UTC without some trusted source of data. Existing mechanisms for distributing leap second information have communicated false information in several well known events in the past, and these were accidents not malicious cases. LSEM would improve this somewhat, since there would always be an update you just need to learn the sign, so communications failures could be detected and alarmed. But the need for this trusted input still creates a security vulnerability window that could be avoided. Systems where their security/integrity depend on time sync, could be pushed 24 seconds out of sync in one year by an attacker that can control their leap observations-- creating error greater than their free running oscillators might have absent any sync at all. This is especially acute in that in a decade or two we might have 1PPB solid state optical clock chips which are inexpensive and allow for "set once and run forever without sync" operation for a great many applications -- getting potentially 0.5 ppm of error added on top from the lack of leap seconds would basically limit the civil time performance of unsynchronized clocks what you can get from a TCXO bought off mouser for a couple bucks today. So: It's my experience that the current handling of leap seconds is a slow motion disaster. LSEM would be a big improvement-- reducing the costs to the "intended costs" by eliminating many of the extra costs created by inadequate testing. But it would not eliminate the base cost of continuing to have our civil time perturbed by leap seconds to begin with-- costs that are only increasing as atomic oscillators come down in price and applications with tight synchronization requirements become more common. (*) once a month is not adequate testing to ensure freeness of fringe race conditions. Meaning that at a minimum large scale life or large value handling systems that might be impacted would still get the reboot treatment in LSEM, but now with disruption every month. ___ time-nuts mailing 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-M8T
On Fri, Apr 8, 2016 at 12:06 AM, Tom Van Baak wrote: > Meanwhile it would not surprise me if each GNSS system gives a slightly > different position and a slightly different time than GPS does. One could easily imagine a system that when signals from both constellations were strong it fit a model matching a secondary system to a primary. Then when the primary was degraded/unavailable used the secondary data with the model-- which would hopefully fix any bias between the systems-- assuming that it's fairly stable. But that would be a fairly specialized mode of operation. If the solutions were pooled with weighing and knowledge of their process errors adding more shouldn't make it worse... but might not add anything: the ideal weight might be zero. I wonder how much of these negative experience with glonass are due to non-calibrated antenna: Glonass does frequency division multiplexing, and so the antenna's angle/frequency dependent phase can harm performance... many GPS antenna greatly attenuate the glonass signal too. For time-nuts operation where the GPS is conditioning one (or more) nice OCXO or atomic clocks in a world where tens of gigaflops of CPU are among the least expensive toys we can buy, I imagine that fairly different signal processing approaches would be ideal: e.g. instead of just computing second by second solutions and putting the error into a PLL, one could collect hours of observation data and produce after the fact correction data that uses prior assumptions about the stability of the local oscillator. Such a processing mode could be more robust against disturbance from multipath and SV failure, as that data could be excluded as hopelessly inconsistent compared to modes that didn't assume a stable local clock and didn't use potentially hours of observation that watched the SV move across the whole sky. It's somewhat annoying that this kind of experimentation first would require something like getting a software GPS implementation working well; when you just want to try changing around secondary processing after all the coorelators 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] Springer textbooks >10 years old now available for download as PDF at no cost
The Quantum Beat http://link.springer.com/book/10.1007/978-1-4757-2923-8 Frequency Standards and Metrology http://link.springer.com/book/10.1007/978-3-642-74501-0 Frequency Measurement and Control http://link.springer.com/book/10.1007/3-540-44991-4 (and, many many other books on control theory, and other time-nuts relevant works.) ___ time-nuts mailing 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] GPS Disciplined TCXO
On Fri, Oct 23, 2015 at 11:08 PM, Nick Sayer via time-nuts wrote: > >> On Oct 23, 2015, at 2:09 PM, Gregory Maxwell wrote: >> >> On Tue, Oct 20, 2015 at 8:53 PM, Bryan _ wrote: >>> Saw this on the Hackaday site if anyone is interested. >>> https://hackaday.io/project/6872-gps-disciplined-tcxo >> >> Will this design that uses the output of the DAC directly not run into >> problems with non-monotonicity and/or dead-zones in the DAC output? I >> would expect a PLL to behave very poorly if there is any >> non-monotonicity in the least significant bit of the DAC. > > The datasheet claims the DAC is inherently monotonic. It’s a $7 part, so I > don’t have much reason to look sideways at that claim. Indeed! However, the spec sheet shows (e.g. figure 10) a differential non-linearity of 0.2 .. -0.2 LSB, meaning that when the PLL makes a single step the result may be 20% greater or lower than expected, which probably isn't good for stability though not the PLL breaking-ness of a non-monotone response. > That strikes me as familiar - a little like how Arduino fakes analog output > by running PWM into an LPF. It's a common technique, (it and ones like it) also used internally in high bit depth DACs. > If you look at the AD5061 datasheet, there is unfortunately a relatively > significant (to my eyes, at least) update glitch. I suppose it’s quick enough > that the RC filter would get rid of most of it, but it is an extra noise > source if you do it frequently, like you’re suggesting. Ouch, that is a fairly substantial spike compared to 1lsb... it's short at least, but if you are only updating once a second I'd wonder if that would not have a measurable impact on stability. A potential advantage of running at a constant high rate is that rather than taking the impact of that glitch once per second, the glitch happens constantly and so its effect can just be averaged out by the PLL. (e.g. it becomes equivalent to just scaling the output voltage by its average effects). ___ time-nuts mailing 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] GPS Disciplined TCXO
On Tue, Oct 20, 2015 at 8:53 PM, Bryan _ wrote: > Saw this on the Hackaday site if anyone is interested. > https://hackaday.io/project/6872-gps-disciplined-tcxo Will this design that uses the output of the DAC directly not run into problems with non-monotonicity and/or dead-zones in the DAC output? I would expect a PLL to behave very poorly if there is any non-monotonicity in the least significant bit of the DAC. My intuition would be to use TPDF dither against a higher resolution internal value (perhaps 32 bits) with noise shaping so that the dither has no power at DC (and not much near it), followed by a RC low-pass filter. With this approach the fact that available DAC parts run at speeds far faster than needed for this control helps overcome the fact that highly monotone parts are less common (last I looked). This would also help give much finer control without compromising tuning range. [Disclaimer: I've never built a GPSDO] ___ time-nuts mailing 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] KS-24361 REF-0 standalone
On Fri, Aug 7, 2015 at 6:06 PM, paul swed wrote: > Looking forward to the notes. > Yes it could be fairly simple if what ref 0 wants is a string that > essentially says the system is fixed with 3 d accuracy. Perhaps after that > the ref 0 makes no checks other then the string keeps coming with the > correct quality. Not to push a particular proc but any of the low end ones > will do that stunt very easily. > That would be pretty sweet. Does it also take and apply sawtooth correction data? It would be pretty great to e.g. be able to use the sawtooth data that comes out of the modern ublox recievers (even the non-timing models). ___ time-nuts mailing 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] End Of The World
On Wed, Jul 1, 2015 at 1:03 AM, Bob Camp wrote: > Hi > > So are we all still here? Any portion of the group blasted into non-existance > by the leap second please speak up :) > > === > > Any observations of anomalous behavior yet? I was eagerly connecting to various things to watch for problems when everything stopped responding precisely at the end of the leapsecond. Turned out my cell phone-- an old android 2.3 device on the sprint network-- dropped off the network (looked like it was up but couldn't make or receive calls and no data was getting through). I waited 15 minutes to see if it would recover on its own, but it did not during that time. OTOH if it went out for 15 minutes otherwise I might not have thought to much of it-- so no proof that it was due to the leapsecond; very coincidental timing if not. :) ___ time-nuts mailing 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] Using CPLD/FPGA or similar for frequency
On Tue, Jun 9, 2015 at 11:40 AM, Alan Ambrose wrote: > How about a 1pS resolution TIC? :) > > Or a >12 digit frequency counter? :) :) > > It's not a proper time-nut project unless there's a nutty element... Well, how complex? Front end with a fast ADC and make a DSP DMTD device? In terms of simpler things that (AFAIK) one can't go out and buy: a TIC with 4 or 8 inputs would be an interesting piece of time nut gear.even if it was 'just' 1ns resolution Surplus lab TICs are easily had but become quite a pile of equipment when you want to concurrently measure a half dozen oscillators. ___ time-nuts mailing 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] Current state of optical clocks and the definition of the second
On Tue, Jan 13, 2015 at 5:46 PM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > I had a brief read. Equation 1 made me wonder what could be achieved > with a cheap HeNe laser. It should be fairly easy to mix a couple of See Sams Laser Faq section on stabalized HeNe Lasers: http://www.repairfaq.org/sam/laserchn.htm#chnsshnl1 This uses zeeman splitting to get two different polarization modes lasing at slightly different wavelengths. (this is described in more detail elsewhere in the FAQ about some commercial lasers that use this effect.) There are do it yourself at home grade (/ easily available surplus parts) things you can do to get the short term linewidth down to about 4MHz or so, sadly 4MHz out of 470THz is only 1e-8 or so, so not super competitive with some off the shelf OCXO. You're also then stuck with an optical standard, and the down conversion to microwave is decidedly more complex. It would probably be a fun time-nuts project, even given the not amazing performance, if not for the difficulty in down-converting to something that could feed a counter. ___ time-nuts mailing 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] Current state of optical clocks and the definition of the second
On Mon, Jan 12, 2015 at 12:34 PM, Attila Kinali wrote: > I just stumbled over this [1] nice article by Fritz Riehle that might be > of interest to others as well. I've seen less discussion of non-atomic stable optical oscillators. Most (all?) of these optical atomic standards are passive atomic clocks and need a free running oscillator. Seems that the state of the art in stabilized lasers has improved a lot lately, e.g. there are commercial available 1550nm devices which have a <=3Hz line-width: http://stablelasers.com/products.html (well on a short term basis, the medium term performance is not so impressive) Considering the rarity and extreme cost of H-masers, or just really exceptional quarts oscillators; might it be the case that optical LOs start looking interesting for applications which just need stability (or being steered by other sources; e.g. GPSDL)? (They can be down-converted to microwave frequencies using an optical comb; a mode-locked laser whos pulses are phase locked to an incoming beam.) Certainly just the local oscillator is _closer_ to something a time-nut might experiment with than a complete optical atomic standard (if still not quite in reach). ___ time-nuts mailing 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] June 30 2015 leap second
On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki wrote: > Systems which are simply time clients can receive the leap second warning > via the usual protocols like NTP or PTP/IEEE1588. Indeed, they can. Even when there hasn't been a leap-second. Practically all internet (and otherwise?) time distribution is unauthenticated, the leap second itself is unauthenticated. It's fragile enough that there have been accidental false leap-second events. ... one of many reasons I'd prefer leap seconds went away though I've personally had great fun observing them in the past. (and, I suspect, they may have been one of the first reasons I became interested in precise time keeping). ___ time-nuts mailing 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] Fwd: CGSIC: FW: New NANU 2014090
On Wed, Dec 17, 2014 at 12:01 AM, Jim Lux wrote: > On 12/16/14, 3:36 PM, Magnus Danielson wrote: > what about one of the software receivers? I would think that making L2 and > L5 filters isn't that tough, so all you need is the back end. I'm pretty sure GNSS-SDRLIB supports L2C, you can see it working with a ~$400 bladerf http://www.rtl-sdr.com/real-time-gps-positioning-bladerf/ Though getting dual band, in phase, requires something like a $1100 USRP B210... and that that point you're getting in to the price-points where you can find surplus survey receivers and such. >From a timenuts perspective, it may be more interesting to go the SDR route, since the survey receiver is not likely to have a lot of affordances for timing applications and there is a lot of interesting things you could do in software. There have been some people talking about GNSS targeted SDRs, e.g. things with 4x in phase down mixers and backing ADCs that could simultaneously capture every current/known GNSS signal and send them down to the computer, at a reasonably low price... but I think none have moved past the prototyping phase. The nearest I'm aware that seems actually available is http://www.onetalent-gnss.com/ideas/software-defined-radio/sdrnav40 but I don't really know anything about it. (e.g. if it's real, what the software support story is, etc.) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] 58503a and Yixunhk
On Sun, Dec 14, 2014 at 1:38 AM, Adrian wrote: > Same here. I have a Z3805A from this vendor that works flawlessly, and I > know of other people that purchased from him without any problems. > > To call it a cam when a HP unit comes with a remanufactured box is quite > a harsh statement, IMHO. > > I'm glad they are putting those ugly units into a neat and practical box > that is made with attention to every detail. Almost $800 for a box that arrived full of rust (and faulty to boot) is a bit crazy though. I bought a z3805a (in an ugly old rackmount case) from this seller for $180 a while back and it works great. I expected it to be beaten up old surplus stuff, and it was but still quite functional. I wouldn't be shocked if thats whats getting remade here. I did so after researching the seller somewhat (he's been mentioned on time-nuts a few times before) and knowing what I was getting into... e.g. that it would be some surplus with some amount crap-shoot potential, but that he was also experienced in selling these things. Opened it up and checked for rust, because water damage had been specifically cited in some other post. Indeed, when I got it, I first tossed it on a somewhat inadequate power supply and had it not come up... he responded quickly and competently to my message and offered a replacement if it was bad. All that said, I'd think I'd be pretty torqued if I'd bought the $800 box and got a box of rust. There is something unethical about making somethings external condition not match the internal condition and selling it for a high price... unless it's clearly marked as a re-manufacturing of surplus hardware. ___ time-nuts mailing 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] gravity, space and time
On Fri, Dec 12, 2014 at 8:42 PM, folkert wrote: > Hi, > > If I understood it well, we should occasionally encounter gravitational > waves going through, well, the whole galaxy. As time and space are > intertwined, those ripples may be measured somehow I guess. > Isn't this that "we as time nuts community" can help the scientific > world with? E.g. create some kind of grassroots effort where our very > accurate clocks can detect this? I can imagine all kinds of reasons > that existing infra for this may not always be able to detect this on > its own. > What do you think? The waves fall of with distance just as other undirected radiations do. As a result they should be incredibly weak when we observe them (if not, we have worse concerns!). There are observatories working on detecting these with incredibly sensitive equipment. Search for LIGO for an example. Even assuming we all had H-masers at home (I wish... anyone know what a VCH-1008 costs? is it too much to dream that it has a small price to match its small size?), I'm not aware of any way we could usefully measure gravitational waves, even ignoring their weakness, just due to a lack of precise time transfer with enough time resolution. ___ time-nuts mailing 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] Beaglebone NTP server
On Wed, Dec 10, 2014 at 9:58 PM, Brian Lloyd wrote: > Well, I am hoping to get to the point where the path to using the BBB as an > NTP server using the PRU for more precise timing, and using the LTE-lite to > provide the 1pps and time data. Of course, the LTE-lite can also provide > 1pps and 10MHz to my workbench. (It's all going to go in a 1U box in the > rack next to my workbench.) > > Yes, I know that all the information is out there and much if it can be > gleaned from this list by following several threads back through several > months. But that brings to mind playing Adventure. Has anyone compiled a > how-to for turning a BBB into an NTP server using the PRU for timing? Seems > like a straight-forward and useful turn-key kind of thing. Getting a BBB to take 10MHz refclk input (in the fashion of http://www.febo.com/pages/soekris/) and being able to timestamp _multiple_ PPS signals via the PRUs would make for a pretty awesome time-nuts toy. ___ time-nuts mailing 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] Did a member of time-nuts buy this?
On Sun, Dec 7, 2014 at 7:03 PM, Bob Camp wrote: > Of the $20K to $30K that a new tube costs, I doubt the material and basic > assembly adds up to over $5K. The rest of the cost is the final assembly / > test / yield / re-test / tooling / labor. That’s doing them in as high a > volume as anybody does them. You will need either a couple of H-Masers or a > set of Cs’s running and in good condition simply to make sure you got them > put together right …. I'm sure that assembly/test/yield/re-test/tooling/labor are all killers, but why the comment on h-masers? CS beam standards are largely self-calibrating, thats why they can be primary references. For checking against systemic error you might want a CS ensemble, but everyone has access to one of those for long term measurement via GPS. ___ time-nuts mailing 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] Did a member of time-nuts buy this?
Bob Camp wrote: > Unless you are making a GPS receiver from scratch (which you might be), there > is a certain “trust factor” that comes into using a GPS for timing. Since you > can’t play with the firmware, you trust that the guy who wrote it did a good > job. As compared to internet facing software embedded systems seem to be unusually fragile, consider this paper on GPS receivers with adversarial signals: http://www.andrew.cmu.edu/user/tnighswa/GPS_CCS.pdf And the trust with using GPS goes beyond the quality of the construction of the receiver: You're trusting the the GPS constellation is working and correct (see the recent GLONASS failure) and you're trusting that there aren't random jammers going by, you're trusting that there isn't someone in physical proximity manipulating the signal intentionally (see the paper above), or even just random truckers going by with jammers (there have been past threads on time-nuts) about this. IIRC the stated US policy with respect to GPS signal integrity is that it may be intentionally degraded (and can be degraded in a geographically targeted manner) for e.g. political/military objectives, so you trust that you won't be the target or collateral damage of any such degradation or that it won't be severe enough to effect you. GPS driven timing works amazing well under most conditions most of the time and at a very low cost. The trade-off is that you're taking more fringe risk and greater trust. I sometimes worry that we're building too much public infrastructure which is depends on a single system (or on space based timing in general, since Kessler syndrome, while unlikely, is a risk that exists) now that loran is gone in the US. Of course, the attractiveness of GPS makes this self-fulfilling: Solid, long living, CS primary frequency sources would probably be much less expensive of GPS didn't cover so much of the commercial demand for them. There are newer receivers (e.g. ublox m8) that are concurrent mult-gnss which might help, or maybe not: who knows what the receiver will do if one system starts emitting crap? I am not especially confident that the software in these systems is well baked under exceptional conditions. If you're working on things with no availability requirements, no real-time requirements (e.g. able to go download after-the-fact GPS reliability and precise ephemeris from NGS), and aren't doing anything where your timing is likely to be intentionally attacked, say for test-lab purposes... then these issues may be less of a consideration. In the context of time-nuts though many people are interested in the art and science of precise time/frequency for pretty much its own sake... and the driving need for the lowest phase noise or best adev at some window might just be because it's possible. In that light, the extremes of autonomy, reliability, avoidance of systemic risk, and surviving attacks are also interesting parameters that I find to be interesting to explore, and they're ones which perhaps have inadequate commercial attention on them these days since it seems people are often (a little too) willing to trust and then point fingers when things fail. [Or at least this is an area I personally find interesting ... I wrote this back in 2011 not so long after I started reading time-nuts: https://people.xiph.org/~greg/decentralized-time.txt before I knew common-view time-transfer was already a thing, and when I knew a little less nothing than the nothing I know now about time/frequency standards.] In terms of the 5061A at least some of the old surplus units floating around out there are "non-working" for silly reasons, e.g. left sitting for a long time, and they'll actually lock up fine if left with the ion pump running for a few days, or the OCXO put back on frequency, or the gain adjusted though I wouldn't spend $1k just to find out. I picked up a 5061B for basically shipping costs a while back and it was up and running reliably after some minor repairs... though the beam current is low and it likely doesn't have much life left in the tube. It's hard to deny how interesting and finely built these devices are, objects of techno-lust in their own right, even in surplus-and-maybe-not-reliable and impossibly-expensive-to-refurbish condition. As an actual lab tool-- rather than a science project, sadly, I do have to agree that you're better off with a GPSDO than a surplus CS unless you happen to get really lucky in the surplus gear lottery. Of course, none of this is mutually exclusive. It's possible and reasonable to have both. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
