Re: [time-nuts] 10 MHz to 32.768 kHz converter
Years ago I needed to lock a 16.777216 MHz oscillator to a 10 MHz reference for a "Williams" DDS synthesizer. Because 32768 is a subharmonic of 2^24 Hz, this same sort of scheme should be adaptable. I will quote my own posting to this group from Feb 2, 2012: Clint wrote: > Years ago (in the 80's) I needed to lock a homebrew DDS to an accurate, > stable 10 MHz reference (a good TCXO in this case) that was set to WWV/H. > Considering that the DDS was clocked at 2^24 Hz (16.777216 MHz) this was > slightly awkward, but I did it using standard HC and 4000 logic. > > The convoluted path was: > > 10 MHz / 625 = 16 kHz (HC40103 as a div-by-125 and an HC4017 as a div-by-5 > would work...) > > 16 kHz * 32 = 512 kHz (using a 4046 and 4040) > > 512 kHz /125 = 4096 Hz (using 40103 or similar) > > From there, it was a no-brainer to compare this with the 16.777216 MHz / > 4096 with another 4046/integrator - but the same 'HC4040 that did this also > had a tap with 32768 kHz on it. > > With a fairly slow loop and a low-noise 2^24 Hz VCXO, the DDS's clock was > both clean and stable - and tuned in 1 Hz steps! A cheap and more-common > 4.194304 MHz crystal would work and I suppose that a similar scheme could > be used to lock a 32768 Hz VCXO but I've never tried to 'VCXO a tuning-fork > crystal before:-) 73, Clint KA7OEI ___ time-nuts mailing 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] wtd: WWVB info
Hi Bob, The use of the PIC for WWVB carrier/data detection was only ever intended for use with a visual clock, thus uncertainty (e.g. lag, delay or whatever you want to call it) was par for the course in the implementation that I described. On 8/7/2015 3:51 AM, time-nuts-requ...@febo.com wrote: Hi The gotcha with under sampling is the need for tight bandpass filters in front of the sampler. Narrow bandwidth always equates to long delay. If the filters are analog (rather than digital) that delay will have drift and temperature sensitivity. Both of those things are to be avoided (if possible) in a receiver intended for high accuracy use. Bob Neil, as for the link below, unfortunately that's not it. The project in question used the PIC's A/D converter to directly process the signal. This would rule out the PIC16F84 used in the link, below, as that has no A/D capability. I've looked some more and have still been unable to find it: I'm sure that it's on the Wayback Machine somewhere, but things can be tricky to find if you don't already have a URL! Clint, Is this the design you are looking for? http://webpages.charter.net/ekyle/WWVB.html -Neil I did see a mention of a Tayloe detector (or QSD - Quadrature Sampling Detector) that might also be used to advantage in a project like this. As with A/D converters, they, too may be undersampled with reasonable effect - Some of the readily-available SDR receiver kits do this - so it should be very practical to do something like the following: - Produce an audio/sine wave DDS in software using the PWM hardware in the processor (PIC, Arduino) at 4x the desired frequency using outboard low-pass filtering. - Slice it using the processor's onboard comparator or an outboard: Many PICs have comparators with outputs that may be made external. - Apply this sliced signal to a divide-by-four system or counter to produce the quadrature signal, or use the interrupt from the comparator have the processor produce a count on a pair of pins for a multi-channel analog switch. - Use a QSD (a.k.a. Tayloe) to yield baseband at/around DC. - Apply said baseband quadrature output to a pair of A/D inputs. If the A/D's are sampled in quick succession compared to the detection bandwidth, reasonable balance could be maintained. Again, the QSD could be operated at a fraction of the desired frequency using undersampling techniques provided that the input was adequately bandpass-filtered - but this would seem like overkill since undersampling using the A/D converter could accomplish practically the same thing and the quadrature channels (or Costas) be done in software. * * * Taking a different approach, one could feed the sine output (at audio frequencies) to a plain-old 4046 VCO/PLL and multiply the audio frequency to 4x the receive frequency (240 kHz for WWVB, 310 kHz for DCF77, etc.) and then produce the quadrature clocks for a direct conversion at-frequency, the advantage being that there would need not be any particular bandpass filtering in front of the QSD - just standard low-pass filtering - to produce the baseband/quadrature outputs. The phase/jitter incurred by the squaring/frequency multiplication would be largely irrelevant in the long-term detection windows involved. An audio-frequency DDS synthesizer with 32 bit accumulator resolution is very easy to produce in software and with microHertz tuning resolution, very fine phase control may be achieved in the long term: I've used PIC-based audio DDS generators referenced from stabilized oscillators to produce references to synthesize VHF frequencies as well as discipline VHF/UHF oscillators with excellent results - with special steps taken to mitigate phase modulation issues - so such should be practical at 60 kHz with trivial hardware. (See links below for information on using audio DDS techniques with respect to VHF oscillators.) What would produce delay/uncertainty would be the necessary lowpass filtering on the output of the QSD needed to limit the detection bandwidth, but some of this could be mitigated with multiple windowed detectors (in software), stable analog components and appropriate characterization of the circuits involved. It is probably fair to say that given the limited detection bandwidth and, more importantly, the rather limited processing resources of a low-end processor one will never quite achieve the same timing accuracy that one might get with long-term correlation techniques to determine the phase reversal of the original carrier down to the half-cycle - minus propagational uncertainties, of course! (One would have to be nuts to want to do all of this, but that's half of the name of this group!) 73, Clint KA7OEI References for using PIC-generated DDS audio signals as references for VHF oscillators: - http://www.ka7oei.com/wxsat.html - http://utaharc.org/rptr/synchronous_62.html - using the same DDS techniques to
Re: [time-nuts] wtd: WWVB info
Years ago I ran across a project in which the WWVB signal, after being siphoned from a cheap TRF clock module with a Hi-Z follower, IIRC, was shoved directly into the A/D input (10 bits) of a rather low-end PIC running at a fairly low sample rate - something in the 4-8 kHz range. IIRC, from this point on the carrier was coherently recovered in software and the IRIG time code extracted: I've tried to find this reference more recently, but it resists my attempts to locate it. What I do remember was that it relied on undersampling techniques - the fact that one could sample at a much lower rate and via Nyquist, see the desired signal translated. While one loses a bit of dynamic range, etc. in doing this, such was largely irrelevant in this case as between the narrowband techniques involved for internally the carrier and then analyzing the amplitude thereof, 10 bits (minus noise, etc.) plus AGC of the TRF module seemed to be good enough. I seem to recall that the sample rate offset yielded an internal carrier frequency in the low kHz or hundred Hz range at most and then further-decimated. What I do recall was that the carrier was detected separately using a long time constant and the amplitude was then determined by using coherent demodulation to extract the DC component and then simple rectangular-window sample-and-hold integration (done in software) in something like 0.05 or 0.1 second chunks. I believe that pulse-swallowing/insertion was used to keep the carrier recovery in phase. What struck me at the time was that this method could have, with a bit of extra work, been used to obtain the precise carrier frequency - albeit with a bit of short-term jitter. Even though this was well before the current BPSK modulation was implemented I thought that it could have also been used to detect the then-45 degree phase shift ID that was used. Nowadays, I'd bet that a similar technique could be used to recover carrier with a simple Costas loop implemented in software, all at just a few hundred Hz - just as long as it was comfortably above the detection bandwidth. (Severely limiting the input bandwidth of the original signal also relaxes the filtering requirements involved in decimation as well!) (A similar scheme - sans undersampling - was implemented by Mark, WB7CAK, using an 8-bit A/D in the 1980's for experimental 10 baud BPSK reception on the LowFER bands using a Hitachi 64180 - a processor similar to the Z80: The similarities of the article to his implementation was one of the reasons why it stuck in my brain.) As for having the PIC just 10 bits, with a narrowband input filter and AGC and comparatively long time constants it should be practical to keep the A/D at mid-high scale, well out of quantization noise territory. If something more than a simple-minded sub-sampling of bit timing is used for detection (simultaneous, parallel detection of 0, 1, marker bits on that amplitude stream along with long-term integration of the beginning-of-second marker detection using even shorter detection windows, for example). While I've not done an all in one detection for a WWVB receiver, I've done most of the above pieces at one time or another (oversampling to down-convert, carrier recovery, sample/hold/integration) in separate projects on low-end PICs (e.g. 16F88, 18F series, etc.) and even some decent DSP using the PIC16F1847 for removal of mains harmonics in audio sampling at 32 kHz, so I believe that it *is* possible - and such should also be possible on an Arduino-type platform as well provided that one can obtain the needed control of the hardware layer. 73, Clint KA7OEI ___ time-nuts mailing 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] Connections for FE-5680A rubidium sources
Hello, I've mounted both my LPRO-101 and FE-5680 in Hammond 1590-type cast aluminum boxes, bolting the rubidium unit to the lid of said box, and found the heat sinking of the entire arrangement to be entirely adequate. In each case there is a (well filtered!) switching regulator present that contributes little to the overall thermal load as well as allowing them to run directly from a standard 12 volt equipment bus. If you run the units at their minimum allowed voltage (19 volts for the LPRO-101, 15 volts for the FE-5680, IIRC) they will dissipate much less power as the regulators contained therein are linear type. It struck me that at the lower limit voltages that they take slightly longer to warm up and come online, but still somewhere around the 3 minute mark for a Physics Lock. Details may be found at: http://www.ka7oei.com/10meg_rubidium1.html - For the LPRO http://www.ka7oei.com/10_MHz_Rubidium_FE-5680A.html - For the '5680, of course! 73, Clint KA7OEI On 16 December 2014 at 12:16, Bob Campkb...@n1k.org wrote: Hi One fairly important issue - the unit needs to be on a heat sink. If you run it without cooling of some sort, it will not run for very many years. Bob I do realize that, but how big? Normally the bigger the better is not an unreasonable rule on heatsinks, but I have heard that cooling these too much is bad. I have here a heatsink about 600 x 300 x 150 mm, although I think that is a bit OTT !! Dave ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] temperature sensor
One cheap device that has a fairly predictable tempco over a fairly good range of temperatures is the lowly ceramic resonator - especially the low frequency variety (e.g. 400-500 kHz) having a reasonably straight line temperature versus frequency curve. If one already has a decent frequency reference on hand, it might be interesting to characterize it for both linearity and retrace. Depending on the needed accuracy, I would suspect that it would be easily beat by a calibrated and dithered DS18B20 or a thermocouple - not to mention an LC or even a Y (a.k.a. parallel) cut quartz crystal-based oscillator, to name but two. 73, Clint KA7OEI ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] New WWVB modulation format receivers
Hi Paul, Without digging through the archives, I'll rely on your memory of that past thread! The scheme of using the doubler relied on the 100 kHz carrier recovery relied on the fact that the 200 kHz bandpass filters, being based on quartz crystals, was extremely narrow - on the order of fractions of Hz. This effectively made them frequency-selective integrators (not the right word, but you get the idea...) and they were effectively immune to noise pulses as they simply could not react quickly. IIRC - and I'll have to review my old notes - I used the first 200 kHz crystal as a series element and then passed it to a source-follower and then a bipolar amplifier with ridiculous gain (e.g. grounded emitter, high collector resistance) to form a limiter - and then ran it through another 200 kHz crystal and JFET/limiter. It took a couple of seconds for the outputs of the two limiters to saturate due to the narrow bandwidth and it was extremely tolerant of amplitude variations. There was a phase shift with different amplitude levels, but since, on an FM microwave link the amplitude wasn't going to change much, that - and the phase shift related to temperature - was inconsequential. On this simple recover scheme you could remove the input carrier for nearly a second (or blot it out with noise) and there would be almost no measurable effect on the output, aside from a phase shift of a few 10's of degrees which quickly rectified itself once the signal was returned. Had added some better tuning of the resonators I could have likely minimized this. (I happened to have these 200 kHz HC-6 style units in my semi-large collection of 40-80's vintage crystals.) The trick to replicating such a filter would be to find a suitable bandpass filter for the doubled frequency - in this case, a 120.005 kHz crystal (or thereabouts) - but it should be practical to convert the previously-filtered 60 kHz signal to a frequency for which a suitable crystal could be located. The 60.003 kHz crystal to which I referred was a bandpass filter rather than an oscillator: The TRF units found in WWVB clocks use these since most standard 60.000 kHz units end up being low in frequency when used in this sort of mode and they are a bit tricky to pull this far. Rather than try to find such a crystal I would probably throw together a Tayloe commutating mixer with RC lowpass filtering with a time constant of a hundred milliseconds or so - this, filter/mixer being clocked at the nominal 60 kHz receive signal. I would then follow it with another commutating mixer to translate the quadrature signal to any convenient frequency (say, audio - no doubt available from the 4060 or 4040 counter I'd be using!) where I would then do my frequency doubling and then follow it by yet another extremely narrow filter - this time, using an 8-capacitor SCF where I could set the detection bandwidth to a tiny fraction of 1 Hz just using a bunch of electrolytics! It should be easy to set the carrier detection bandwidth to be a fraction of the information bandwidth so that reliable carrier recovery can be maintained under any conditions under which the BPSK data could be recovered. (An example of an 8-capacitor Roanoake type SCF may be seen here: http://ka7oei.com/emm2a_scf.html ) This recovered (and slightly filtered) signal, divided-by-two, could then be used to synchronously demodulate the original frequency-converted signal, at which point one should have a reasonable representation of the phase (and amplitude) of the transmitted signal - albeit, delayed by a fairly consistent amount. Of course, all of this could be done by throwing a 16 bit A/D and DSP chip at it, but sometimes there's a simple pleasure in doing it with a bunch of 4000 CMOS and a few op-amps, handing the recovered baseband off to a PIC or Arduino only at the very end! * * * Many years ago I built a WWVB carrier recovery circuit using just a single-stage LC bandpass filter (to get rid of the VLF powerhouses) and an NE565 phase detector along with a 6 MHz VCXO divided down to 60 kHz as the comparison. What amazed me was that even with the practically nonexistant filtering in front of the '565 (you really couldn't see the 60 kHz carrier with the oscilloscope) that '565 would always find its way into lock over time - and then it would stay firmly there owing to that effect that occurs in which the effective loop bandwidth seems to decrease once lock has been achieved. (WWVB's 45 degree phase shift ID would always throw it for a loop, though - pun intended!) 73, Clint KA7OEI Date: Thu, 20 Feb 2014 22:10:26 -0500 From: paul swedpaulsw...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] New WWVB modulation format receivers Message-ID: cad2jfahzvjsz1vzihbh05bwnc+dhd2glqstv1cajc40ue1-...@mail.gmail.com Content-Type: text/plain;
Re: [time-nuts] Looking for WWVB digital wall clock with digital 24 hour UTC display
Other than WWVB-based frequency references/clocks that lock onto the 60 kHz carrier itself, I'm not aware of any WWVB-based clocks that were the slightest-bit affected by format change (e.g. the addition of the low-rate BPSK): Please point me to any references to the contrary if you find them. Co-incident with the WWVB format change there were a number of WWVB clocks that quit working - namely, a few of the older SkyScan models, but this had nothing at all to do with the format change, but rather an error in the silicon that caused them to fail to automatically set themselves (after initially doing so when first powered-up). For WWVB, the timing of the manifestation of this bug was most unfortunate and there is/was quite a bit of information on the net that continues to propel this myth. Being a bit of a nerd and Time Nut I went out of my way to determine the actual cause of this problem. There is this: http://ka7oei.blogspot.com/2013/02/did-nist-break-bunch-of-radio.html In this, I determined that at least with this receiver, its detection bandwidth was far too wide to be adversely affected by the phase reversal which - in theory - could skew the timing of the recovered amplitude waveform of the time code modulation. From this I concluded that the TRF receivers used by these inexpensive clocks weren't likely to be affected in the least by the BPSK. And secondly, there is this: http://ka7oei.blogspot.com/2013/03/yes-nist-did-break-bunch-of-radio.html In short, I created my own, local WWVB signal and demonstrated to my satisfaction that the real problem with these particular clocks was that they couldn't tolerate dates beyond a certain range. A shame, too, since these same clocks will happily display UTC with no DST - although they would sync at Midnight and early morning for their set time zone which means that they would sync during daylight hours: Not a problem here in Utah where we have mV/m signal levels, but it could be disastrous for stations farther east where usable signals are available only in the wee hours of the morning! (These clocks also had a bug that would cause them to delay a day during the spring change onto DST - disconcerting on the morning of the time change if it was set to local time with DST!) 73, Clint KA7OEI Wouldn't that be nice! They implement a new format which destroys much of the installed infrastructure, then don't actually produce the 'better replacement'. How very LORAN! -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] New WWVB modulation format receivers
Several years ago I spotted a clever PIC-based software (DSP-ish) approach to WWVB modulation - but it has thusfar defied my attempts to find it via Google. It was from the late 90's, early 2000's - and I may have it in an archive somewhere. The exact details escape me, but I believe that it sampled at 8 kHz and was fed a crystal-filtered WWVB signal at 60 kHz, putting this bandwidth-limited, AGC-leveled signal directly into the PIC's A/D. If I've done my math correctly, that would yield a frequency-inverted alias at 4 kHz. The A/D was then mixed and/or decimated significantly and a simple software-based carrier recovery scheme (a Costas loop, maybe?) was implemented in this rather low-end PIC. Because the TRF bandwidth was on the order of just a few Hertz, it took a fairly trivial amount of horsepower to implement. Presumably, at just one baud it should be practical to do this on more modern PICs and AVRs using the same scheme. The trick to homebrewing this is to find a 60.003 kHz crystal - but one of these could be swiped from a WWVB receiver module, or, perhaps, a source-follower could be used to recover the phase component of the received carrier, tapping off the signal from the BPF itself and making it available to the processor. * * * Another scheme - one that I believe was poo-poohed a while back on this list - is to simply take a bandpass filtered sample of around 60 kHz and throw it into a four-quadrant multiplier to yield a 120 kHz signal sans phase shift. I believe that the initial critique of this was that this was not a particularly good way to recover a weak signal, but I found it to be quite useful on a project some (15) years ago. On this project, I had a 100 kHz pilot carrier modulated with NRZ BPSK telemetry data and this same carrier was used to convey the reference frequency to multiple, simulcast transmitters via a 33cm microwave link. At 100 kHz, I simply had an L/C bandpass filter that was roughly 3-5 kHz wide on the transmit (to control the occupied bandwidth when XOR-gate modulated) and a similar filter on the receive end. Listening to this 100 kHz center frequency, 3-5 kHz bandwidth was a 1496 configured as a multiplier, the output of which was passed through a simple filter constructed using 200 kHz crystals. The 200 kHz from the doubler output was then divided-by-two and used to synchronously demodulate the BPSK data (after being filtered with either a Bessel or Gaussian LPF) and this same recovered 100 kHz signal was then made available to the master 10 MHz frequency reference for locking. What impressed me was the fact that my input signal S/N could go about 40 dB below the detection bandwidth of the BPSK signal and still maintain perfect lock on the 100 kHz carrier, despite the fact that the 1496 - which really doesn't make all that great of a doubler compared with other available (but more expensive!) devices was being pelted with 3-5 kHz of garbage when the S/N was purposely compromised. IIRC, the detection bandwidth of the crystal-based carrier recover filter was on the order of a few 10ths of Hz. Yes, the phase did vary with temperature, but the rate-of-change was fairly slow and this fact was inconsequential in our application. * * * The upshot of this is that it should be quite easy to do a simple doubler-based carrier recovery system at 120 kHz (or something else, if it's frequency-converted) and, since it may be a bit tricky to find a cheap 120.006 kHz crystal, use an SCF clocked from a VCXO (or a simple fractional divider/DDS implemented in software) to provide a very narrow detection bandwidth that would satisfy the dynamics associated with the usable signal range over which the WWVB carrier could be reconstructed and the phase data could likely be recovered. The AM output of a standard WWVB clock module could then be used to aid in the windowing of a synchronous demodulator integrate-and-dump filter to recover the phase information and make these two pieces available to something like a PIC or an AVR/Arduino for crunching. In the (likely!) event of a signal that was too weak to recover the amplitude information from the broader-bandwidth WWVB receiver module it should be practical to oversample (say, by 8x) the output of the synchronous demodulator and then infer the timing of the phase change over a period of time since the minimum period of this is well known (1 second!) and such timing could be (initially) autonomously applied with very good stability until the timing of the phase change resolved itself - something that could be correlated with a statistical analysis of the output of the amplitude detector, as well. To a large degree, this sounds like a candidate for a front end consisting of good old 4000 CMOS logic and a few op amps with the output handed off to a fairly low-end, cheap processor module! 73, Clint KA7OEI
[time-nuts] WWVB repeater (was: WWV Simulator Programs)
Sometime in the late 1990s, a friend of mine who works for a local city government asked me if there was something that I could do about some WWVB clocks located in a conference room, downtown, on a middle floor of an office building amongst computers and fluorescent lights that never managed to get the correct time. Together, we built this: http://ka7oei.blogspot.com/2013/03/getting-atomic-wwvb-clocks-to-work.html It's been in operation since it was installed, except for two occasions: - After a few weeks it quit working so my friend opened the cover of the outdoor unit to take a look. Once the water drained out, it started operating again. (He then drilled a drain hole and sealed everything else a bit better.) - Last year - after somewhat more than a decade of operation - it quit working when the electrolytics in the transformer-type wall wart that powered it dried out and there was several volts of AC riding atop the DC output. A new wall wart was procured and I added a large capacitor in the indoor amplifier's box as well. The original plan was to drop the receiver coupling loop down, through the stud space in the wall behind the clocks, but it turned out that just laying them atop the drop ceiling provided more than enough signal and that's where things have been. When getting it back in service after the more recent work I did some testing and found that I had to get the outdoor antenna and the indoor coupling loops within 15-20 feet of each other (and oriented properly) in order for the system to oscillate, but this close distance - and optimal loop orientation for mutual coupling - should be easy to avoid. I would thing that the outdoor amplifier/loop coupling could be optimized somewhat, but it provided many 10's of dB of margin when checked on a receiver. (The several millivolts/meter field strength around here doesn't hurt, either!) 73, Clint KA7OEI Chuck Forsberg WA7KGX wrote: I'd like to see a WWVB generator that could output the 60 KHz WWVB signal through a sound card for the benefit of hard of hearing atomic clocks by Oregon Scientific and others. ___ time-nuts mailing 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] wwvb d-psk-r updated general purpose reciever
When I was messing with my SkyScan WWVB clocks to determine if something that WWVB's signal had done broke them, preventing them from setting properly and so-doing, I wanted to see what the receiver module was seeing. (Spoiler: They didn't - they just break if the date is something later than approx. August, 2012 - I mentioned this some months ago on this list, providing a link to a blog entry where this was discussed in detail.) What I did to see what the clock chip was seeing via a 'scope was to hang a JFET source follower on the narrow (downstream) side of the 60.003 kHz bandpass filter crystal coupled with a small value cap and a with a 10 meg resistor from the gate to ground: That didn't seem to adversely affect performance, and I could see the phase flopping back and forth. (The signal was pretty low - but usable.) At that point the AM was still present, so the key up portions of the waveform were expectedly weaker - but it seemed to me at the time that I could have used it for something more complicated down the line. What I was thinking at the time, were I to proceed farther, would have been to take that buffered signal off-board, amplify it a bunch and then run it through a limiter. In theory, this - along with the demodulated time code - would have provided both the amplitude and phase components. Clint KA7OEI On Fri, 1 NOV 2013 saul swed said: Hello to the group. It has been a while since I have sent anything. The last was the wwvb regenerator for time clocks. However I have been working on a general purpose wwvb receiver. One that is inexpensive, uses parts available today, is inexpensive, single supply, low power, and uses parts I don't need a microscope for. There are lots of older designs out there and at least one quite nice design is by one of our fellow time-nuts that started me thinking. But many of the designs use inductors that have become difficult to obtain. As much as I would have loved to hack one of the one chip wwvb clock chip wonders they simply did not work out. They are hot receivers actually because there was no way to pull the amplified wwvb signal out. Tried a number of schemes like 2 chips in parallel. One detecting the AM signal and providing AGC control to chip 2 that had no AGC or demod caps. snip ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Good (cheap) PIC chip choice for project?
Having used PICs since 1990, I've designed them into projects rather than getting a board like a Parallax or Arduino (either of which are far more expensive than the chip and the few components required to make it work) and then shoehorning someone else's board into my project. Since the late 90's, I've used the PICC compiler (by CCS) which - once you know it - can produce reasonably tight code that is can also be fast: I've done a number of audio DSP projects on 16F platforms - mostly in C - and had plenty of horsepower. A bit expensive, but I updated only every 4-7 years and with as many projects that I've done (I have used rails of the things with personal/amateur/work projects as well as some commercial prototypes) the time/power is worth the cost. The PICs that I use the most are the 12F683 - an 8-pin device with 10 bits of A/D and a 10 bit PWM: With a 20 MHz xtal, I've done audio DSP with this. As it turns out, a great many projects require =6 pins (the PIC using an internal R/C clock - 1 of the pins is input-only) and this will do the trick. The other one that I use is the 16F88 - It has the A/D, PWM as well as I2C/SCL and USARTs and internal clocks - an 18 pin device, 16 of which can be used for I/O (1 of those only does I). With more RAM/Program memory, one can do more DSP than with the '683... For more horsepower I'll often use the 18F2620/18F4620's - 28/40 pin devices (respectively) and these have more I/O and peripherals. There's are close cousins of this that also has hardware-based USB (I don't recall the number of an example, however...) I've yet to do anything with the 24F and dsPICs, but maybe, the next time I update the compiler... 73, Clint KA7OEI ___ time-nuts mailing 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] WWVB sync
Not to beat the topic to death, I did have an occasion to repeat the WWVB signal. Although the signals here in Utah are very strong (3-5 millivolts/meter, maybe) they weren't strong enough to find their way into a noisy office building, so about a decade ago I built a system for a friend of mine that works there http://ka7oei.blogspot.com/2012/08/receiving-wwvb-indoors-so-that-your.html Apparently, its been duplicated elsewhere for DCF77, etc. It may be possible to carefully null the MSF signal without also taking WWVB out too much, but Murphy says that anywhere it's needed, MSF and WWVB will be exactly 180 degrees apart! * * * There are also some passive booster systems, such as this: http://newdwf.com/viewtopic.php?f=59t=4736 This is just a large-ish resonant ferrite antenna circuit into which one places the watch (or whatever). This passive device may not help with QRM from MSF or something local like a switching supply, but it ought to work in cases of weak signal. 73, Clint KA7OEI David McGaw, N1HAC wrote: Guys this is just silly build a 10' square loop and preamp. Driver amp and place it 400 ft from the house. Now run coax to your wrist and use link coupling next to the watch. Open a six pac and wait. ___ time-nuts mailing 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] WWVB Clocks don't sync anymore (revisited)
I found a note on the SkyScan web site itself that attempts to offer an explanation/excuse as to why some of their clocks no longer synchronize: http://skyscanatomicclocks.com/site/help-my-86715-86730-87315-is-not-catching-the-signal/ This, however, is a BIG red herring. The ONLY change that was made of any significance was the addition of a BPSK component to the carrier. Fortunately, this occurs at the instant that the UTC second begins - when the carrier drops in amplitude - which, in the unlikely event that the ringing of the filtering in these clocks TRF receivers were enough be at all sensitive to BPSK, this phase shift would only go toward assisting them in their immediate detection of the amplitude reduction of the ASK signal transmitted by WWVB. Certainly, by the minimum time at which the carrier amplitude might increase (0.2 seconds for sending a binary 0) the filter has pretty much recovered from the effects of the phase reversal. In programming the WWVB simulation, I also found that the clock's timing was very forgiving - seeming not to care if the timing of these bits was over 100ms out of spec in either direction! (The fact that the clock reliably locked once, after replacing the battery, indicated that it had no trouble with the different modulation.) On these clocks I was able to locate the circuit board trace that connects one epoxy-covered blob (the TRF chip) to the other (the clock itself) and find the demoduated time code which was present after a power-cycle. Even with a fairly poor S/N and the added BPSK, the bandwidth of the TRF is wide enough that time code very nicely matched what WWVB was sending - albeit that it was offset very slightly in time (group delay, etc.) This was easily determined with a dual-trace scope with one channel coming from a strong audio beat note from an LF receiver on a good antenna, and the other channel looking at this logic line. As far as any of these consumer-grade clocks are concerned, there is no modulation present other than the ASK signal and I tend to believe the assertion by the NIST that the addition of the BPSK would be transparent to these receivers. While I don't have an answer for those clocks that flat out refuse to acquire a time signal in the first place (again, even my clocks would lock exactly once after replacing the battery) it would seem clear that these particular units have a problem with their programming in that they don't know what to do with the now-current dates. I've been experimenting on the WWVB simulator with different years to try to more accurately determine the window during which they work, but the initial indications are that the period for which the programming works ranges from somewhere in the late '90s to mid-late '12. As I note on the web page, the 60 kHz WWVB frequency is, unfortunately, fairly close to that on which many switching converters operate - or near its 2nd harmonic and I've found that having an operating CFL or switching wall wart in somewhat close proximity can prevent one of these clocks from acquiring lock - and this is in an area in which the signal's field strength is quite strong, somewhere in the 5 millivolts/meter range! In at least one occasion, I've found that a non-locking clock could be explained by the recent addition of one of these unintentional radiators. 73, Clint KA7OEI ___ time-nuts mailing 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] WWVB Clocks don't sync anymore (revisited)
A few weeks ago I posted a question/comment about some of my WWVB-based Atomic clocks no longer setting themselves properly. These two clocks, SkyScan #86716, would show the symbol indicating that they had set themselves, but their time was drifting away from UTC. Interestingly, they *would* set themselves exactly once upon installation of the battery, but never again. Since that time, I've done a bit of digging around. The first suspicion was that, perhaps, the NIST had fudged a bit in the WWVB timecode recently, so I manually decoded a few frames and analyzed them: Nothing suspicious there. The next question was if the addition of the BPSK somehow skewed the timing of the TRF's AGC/threshold - but logically, this didn't make sense since the clock *did* set itself exactly ONCE - and it wouldn't have been able to do this at all were this the case. Out of curiosity I poked around on the board and found the trace containing the time code and found that despite the BPSK, its timing was exactly as it should have been: No surprise there. This left the clock itself, so I did what any other Time Nut would do: I built a WWVB simulator. Initially, I set it to a 2010 date - a time that I knew that the clock worked properly. I had two clocks: One that I'd just reset by pulling and replacing the battery while the other had been stuck for a few weeks, not resetting itself nightly as it should. I put both of these in the coupling loops from my WWVB simulator and over the next few days, the recently re-set clock happily synchronized itself while the other one with the 2013 date was still stuck. I then reset that clock and it, too, behaved itself from then on. I then reset the clock on the simulator to a February 2013 date and time. Initially, both clocks reset themselves to the current time and date at their next midnight, but after that, they got stuck, never resetting themselves at night again. So, it appears to be a problem with Broken Sand (e.g. a silicon problem). For the morbidly curious, I have documented my efforts here: http://ka7oei.blogspot.com/2013/02/did-nist-break-bunch-of-radio.html - The initial testing http://ka7oei.blogspot.com/2013/03/yes-nist-did-break-bunch-of-radio.html - The testing with the WWVB simulator 73, Clint KA7OEI ___ time-nuts mailing 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] WWVB Clocks don't sync anymore (revisited)
Someone pointed out a typo: I wrote model number 86716 where I meant to write 86715 for the SkyScan clock in question. In the linked web pages it is correct, however. 73, Clint KA7OEI Clint Turner wrote: A few weeks ago I posted a question/comment about some of my WWVB-based Atomic clocks no longer setting themselves properly. These two clocks, SkyScan #86716, would show the symbol indicating that they had set themselves, but their time was drifting away from UTC. Interestingly, they *would* set themselves exactly once upon installation of the battery, but never again. Since that time, I've done a bit of digging around. The first suspicion was that, perhaps, the NIST had fudged a bit in the WWVB timecode recently, so I manually decoded a few frames and analyzed them: Nothing suspicious there. The next question was if the addition of the BPSK somehow skewed the timing of the TRF's AGC/threshold - but logically, this didn't make sense since the clock *did* set itself exactly ONCE - and it wouldn't have been able to do this at all were this the case. Out of curiosity I poked around on the board and found the trace containing the time code and found that despite the BPSK, its timing was exactly as it should have been: No surprise there. This left the clock itself, so I did what any other Time Nut would do: I built a WWVB simulator. Initially, I set it to a 2010 date - a time that I knew that the clock worked properly. I had two clocks: One that I'd just reset by pulling and replacing the battery while the other had been stuck for a few weeks, not resetting itself nightly as it should. I put both of these in the coupling loops from my WWVB simulator and over the next few days, the recently re-set clock happily synchronized itself while the other one with the 2013 date was still stuck. I then reset that clock and it, too, behaved itself from then on. I then reset the clock on the simulator to a February 2013 date and time. Initially, both clocks reset themselves to the current time and date at their next midnight, but after that, they got stuck, never resetting themselves at night again. So, it appears to be a problem with Broken Sand (e.g. a silicon problem). For the morbidly curious, I have documented my efforts here: http://ka7oei.blogspot.com/2013/02/did-nist-break-bunch-of-radio.html - The initial testing http://ka7oei.blogspot.com/2013/03/yes-nist-did-break-bunch-of-radio.html - The testing with the WWVB simulator 73, Clint KA7OEI ___ time-nuts mailing 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] WWVB clocks no longer lock (Was: Used Spectracom)
At about the time WWVB announced switching the format, two of my clocks - identical SkyScan units bought at about the same time 10 or so years ago suddenly stopped synchronizing, too. If just one of these clocks had a problem, I would chalk it up to a random failure - but two of them? One of these clocks is in my ham shack, next to a different model clock (one displays UTC, the other local) and this other clock hasn't missed a beat while the other is on the wall, well away from any noisemaker like a switcher or a CFL. I've actually swapped these clocks and neither one is happy. I've also put a different brand clock in its place and it maintains synchronization just fine. I've checked for noisemakers (switching supplies) and found a noisy one - and then quieted it down with added filtering, but even before I did this it hadn't affected a clock only a few feet away from it! The *only* time that these clocks lock up is when I first install the battery, but from then on they claim to be locked, but are drifting away from proper time. For one of these, I popped the cover and found the trace with the WWVB time code from the die-mounted receiver chip and it looks pretty clean: No stuttering is apparent, but I didn't make any attempt to time every type of mark or space to verify its timing. The fact that it synchronizes just once is puzzling - as is the fact that just this particular model is now unhappy: Was even a minor change made to the AM portion of the code? I could imagine that a too-narrow bandpass filter could slightly affect the timing of the pulses as the phase flipped, but even if this were the case, why does it always synchronize just the one time and then never again? 'Tis a puzzlement... 73, Clint KA7OEI J.L. Trantham wrote: I have two 'cheap' WWVB 'Atomic Clocks', both of which say they are 'locked' and are about 2 minutes apart. Joe ___ time-nuts mailing 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] WWVB Response
While there could have been a few things to make the WWVB transmissions easier to recover with low S/N, keeping them compatible with the legacy time-only receivers was somewhat of a hindrance. Unlike the DCF77 signal - which has a digital phase modulation that does NOT really lend itself to improved SN (it's at a much higher rate, but since a WWVB-ish signal is much stronger in Germany owing to its small-ness) and was really intended for use with strong signals, anyway - the vast majority of users ignore the BPSK, anyway and rely on the AM. As for how the new WWVB format allows improved recovery of frequency reference and time signals: - I really don't see how this new scheme makes it worse - just different. A very narrow bandwidth loop on the carrier recovery such as a Costas (e.g. as slow as you want!) allows the carrier to be recovered at very low S/N. At least in part, it depends on how long you want to wait! - With typical antennas and receivers, the fairly narrow bandpass is still wide enough to allow reasonable recovery of the signal. Note that, at worst, the phase changes at a rate of 0.5 Hz and to have recovered the 1-second time signalling at all with any degree of accuracy, it would be wider than that 0.5 Hz! - The phase change occurs in a pre-determined manner. Once you recover the carrier, you *know* that you can window the filtering on 1 second blocks and that there are only two possibilities of what the phase could be within that block. On a computer, you can use past data and slide back and forth until good correlation is received: This would then get one close to 1-second timing in that same operation! (A bit harder to do this on very low-power receivers, but easy on a PC.) - The use of the same preamble (to indicate time or message) can allow one to review many minutes of past-stored data to achieve a correlation of the minute frame. Using multiple blocks of past data can greatly improve the effective S/N of that particular aspect - the degree depending on how long you are planning to wait! (Again, tougher on a low-power receiver, but fine on a PC.) - Once you have minute frame correlation (and second-timing as well) you can then use several techniques to further-recover the time data: - You *know* that the DST/Leap Second information isn't going to change much so that can be used for further correlation. - The time data is incrementing at a known rate. In the event that the data is consistently ratty (e.g. you don't get the full time frame without errors) you could further-correlate those bits that are NOT changing very quickly over several minute frames. - Furthermore, if you have an approximate time (which can be known from the user if not from long-term correlation of that time data that changes very slowly over several frames) you can then go back in old data and apply assumptions based on best guesses of time and see if that data fits as well. - Don't forget that the use of the Hamming code (the ability to correct one bit of data and to detect if two bits are in error) also provides a degree of recoverability - particularly if applied over a number of minute frames. With a low-bandwidth antenna (assuming that it's not too narrow - that is, it has 2-3 Hz bandwidth or more) the difficulty will be determining when, exactly, the 1-second intervals are occurring to within a few 10's of milliseconds - even knowing the amount of (fixed) delay in the filter/detection scheme, but this uncertainty is almost guaranteed with varying noise and signal level conditions and the vagaries associated with a very narrow filter. If, however, the filter within the receive system is extremely narrow (1-2 Hz) then the BPSK does make things more difficult. 73, Clint KA7OEI The AM just makes the situation in low S/N areas worse. The BPSK wipes out the possibility of any very narrow band prefiltering, because of filter time response. I suspect, although have not tested, that active antennas with either mechanical or crystal filters in their preamps will be rendered useless. -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] WWVB Now a Monopoly
In reviewing the NIST document, I don't see anything particularly difficult about the new format - either in terms of extracting the time or phase/frequency information from the transmissions. With undersampling, carrier recovery (to determine phase and amplitude information) should be do-able even with a fairly low-end microprocessor. It occurred to me that, as was the case with the old format, this new one could *still* be implemented entirely in glue-logic LSI hardware (think 7400 or 4000 series): True, it would take several dozen chips to do this, but it would be perfectly do-able - even the implementation of parity. The tricky part would be the conversion of the seconds to usable time/date with glue logic - but then again, a bit of clever use with lookup ROMs (violating the glue logic premise a bit!) could clear that up. About the only part that is unknown is the message format - which is not essential to the operation of any receiver in terms of determining time/frequency - which would be interesting to know more about. Clint KA7OEI ___ time-nuts mailing 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] ANFSCD - Synchronizing time in home video recorders
Years ago (in the 80's) I needed to lock a homebrew DDS to an accurate, stable 10 MHz reference (a good TCXO in this case) that was set to WWV/H. Considering that the DDS was clocked at 2^24 Hz (16.777216 MHz) this was slightly awkward, but I did it using standard HC and 4000 logic. The convoluted path was: 10 MHz / 625 = 16 kHz (HC40103 as a div-by-125 and an HC4017 as a div-by-5 would work...) 16 kHz * 32 = 512 kHz (using a 4046 and 4040) 512 kHz /125 = 4096 Hz (using 40103 or similar) From there, it was a no-brainer to compare this with the 16.777216 MHz / 4096 with another 4046/integrator - but the same 'HC4040 that did this also had a tap with 32768 kHz on it. With a fairly slow loop and a low-noise 2^24 Hz VCXO, the DDS's clock was both clean and stable - and tuned in 1 Hz steps! A cheap and more-common 4.194304 MHz crystal would work and I suppose that a similar scheme could be used to lock a 32768 Hz VCXO but I've never tried to 'VCXO a tuning-fork crystal before:-) * * * I, too, have an older (Philips) DVR that has lost its time sync since the analogs went dark. For a while, I used the XDS time code that happened to be in the vertical interval of one of its standard definition DTV PBS station's sub-channels (received on a set-top box and modulated onto a TV channel to which the DVR would look for its time code) but this has code since been dropped. Before I discovered this, I dug up the line 21 (IIRC) code specifications and noted that even a PIC could probably generate the proper code, synchronized either from a GPS or a WWVB receiver. I'd thought about putting it on multiple lines and then RF modulating it for the DVR to see, but lost enthusiasm after I discovered the time code on the sub-channel. Since that went away (about a year ago) I've just remembered to set the clock once a month, not being able to quickly find the specs for the time code again online... 73, Clint KA7OEI ___ time-nuts mailing 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] Internal 5 volt switching regulator on some non-programmable FE-5680A's
Hello, After posting a few days ago about one of my '5680A's having the voltage converter installed - but not connected - I've done a bit of reverse-engineering and sleuthing around and (probably) have a fairly complete picture of what it would take to populate that section of the board. That information may be found here: http://ka7oei.com/10_MHz_Rubidium_FE-5680A.html This page is a work in progress, using my LPRO-101 page as a template and unashamedly stealing a good chunk of its content - most of which is directly applicable, anyway! Note that I haven't done the board population myself and there *may* be additional jumpers that need to be added/removed - or, as I suggest, one could avoid that problem and simply connect to known V+ and +5 volt points instead. If you happen to have one of those boards with the installed (but not connected) regulator, information is also included on which two jumpers I needed to add to enable it: Again, YMMV, DNTHFB, etc... If anyone populates their own board, please let me know how it worked out. I add this mostly out of interest expressed by a few others that emailed me. It's no doubt far easier/cheaper to simply add an outboard 7805 (or switching converter) than populate the board, but hey, why not? 73, Clint KA7OEI ___ time-nuts mailing 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] Internal 5 volt switching regulator on some non-programmable FE-5680A's
Hi, Are you sure about those resistor values? They look like 5.11K and 5.62K (standard 1% values) to me. Whoops - you are right: In squinting at the board I'd thought about turning the thing 180 degrees since the numbers look believable either way! These two 5k-ish values are more in line with the values called out in the data sheet for the '1376 (4.99k/5.36k). I look forward to hearing from someone who might take on populating these components on the board and what they find. 73, Clint KA7OEI ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
