Re: [time-nuts] FE5682A inside pics
I reassembled the failed unit and booted it up. The internal working voltage is 15.3V, the unis seem similar to 5680A, and has even the footprints for a DB9 connector in the same position of the 5680A. I will try to spot if it carries the same signals than that unit. As I was expecting the failed FE-5682A wasnt working, but fortunately the problem was that it was unable to lock: the 10MHz output wasnt crossing the 10MHz boundary, but was low. I had read from John Beale that a FE5680 with the same problem was healed touching the C217 trimmer: https://plus.google.com/u/0/photos/109928236040342205185/albums/5680473650837554113/5680683008490223330 So i tried to spot something similar in the FE5682, and the right candidate was C245 here: http://www.flickr.com/photos/14336723@N08/8331581900/ http://www.flickr.com/photos/14336723@N08/8331582154/ After retouching it, the FE5682A passed again the 10MHz limit, and after few minutes locked on the right freq. It has c-field adjust both with a trimmer accessible from an hole on the side, and to the connector, and both work. My counter is busy logging, so I cannot measure the regulation range of the EFC, but if it follows the LPRO-101 probably it will have the same 0-5V range. After a night powered up, the unit seem stable against one of the 5680, I have it sitting on an thin (1mm) aluminium plate and it is using 820mA at 20V. The diagnostic voltages are: Pin 5 lamp voltage that reads 3.4V Pin 9 crystal Vmonitor 5.7V That's all for now. Fabio. Il 2012-12-31 16:45 Fabio Eboli ha scritto: Positive update, in the broken unit the pin 10 goes to power module input, while the pin 8 goes to power module ground, and there is grounded. I powered the good unit and it locked in few minutes, wothout driving the EFC, the frequency seem very near the FE5680 I set against the GPS. The output 10MHz phase is influenced badly by input voltage up to 18V, and is stable after that, so the unit seem to be a 19-32V one. Now that the failed unit is still opened, I will try to check the inner working voltageon this, if anibody has any question or curiosity about the units, I still have it opened up... Fabio. Il 2012-12-31 14:46 Fabio Eboli ha scritto: By the way, about the psu the unit contains this module: http://www.farnell.com/datasheets/14431.pdf so probably internally it works at 12V. Fabio. Il 2012-12-31 14:44 Fabio Eboli ha scritto: Hello, in the last day of this ugly year I received a pair of FE5682A. ... ___ time-nuts mailing 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] Is there anything wrong with DCF77?
I've got nothing running at the moment that decodes or locks to DCF77, and obviously can't comment on the possibility of localised interference, but here on the west coast of Scotland the signal certainly looks and sounds just as it always does. It's a nice clean signal peaking at approx -77dBm as opposed to MSF on 60KHz peaking at -50dBm, which is much as I would expectd given that MSF is very much closer. regards Nigel GM8PZR In a message dated 01/01/2013 12:40:47 GMT Standard Time, anth...@atkielski.com writes: For the past several days (now thirty hours straight), none of my radio-synchronized clocks has been able to synchronize with DCF77. Is there a problem with the transmitter, or maybe a geomagnetic storm or something that could explain it? I've been looked at the transmitter Web site and searching for news and information on any disturbances that would affect reception, but I haven't found anything. I'm about 500 km from the station. The only thing I have that will sync is my wristwatch, and it will only do it if I stand outside in an open area. -- Anthony ___ time-nuts mailing 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] Is there anything wrong with DCF77?
Here in north Italy (QTH locator JN45UJ) the DCF77 reception is regular. On Tue, Jan 1, 2013 at 1:40 PM, Anthony G. Atkielski anth...@atkielski.comwrote: For the past several days (now thirty hours straight), none of my radio-synchronized clocks has been able to synchronize with DCF77. Is there a problem with the transmitter, or maybe a geomagnetic storm or something that could explain it? I've been looked at the transmitter Web site and searching for news and information on any disturbances that would affect reception, but I haven't found anything. I'm about 500 km from the station. The only thing I have that will sync is my wristwatch, and it will only do it if I stand outside in an open area. -- Anthony ___ time-nuts mailing 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] Is there anything wrong with DCF77?
Hi Anthony, is there any possibility that you have a source of local interference that started up in your home or area? From time to time, I have had everything from power line arcing noise to a new computer power supply that was generating a high level of interference blocking signals on different frequencies. If you have a spectrum analyzer available that will cover the frequency range of DCF77, it may not hurt to look around and see what you can find. George -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Anthony G. Atkielski Sent: Tuesday, January 01, 2013 7:40 AM To: time-nuts@febo.com Subject: [time-nuts] Is there anything wrong with DCF77? For the past several days (now thirty hours straight), none of my radio-synchronized clocks has been able to synchronize with DCF77. Is there a problem with the transmitter, or maybe a geomagnetic storm or something that could explain it? I've been looked at the transmitter Web site and searching for news and information on any disturbances that would affect reception, but I haven't found anything. I'm about 500 km from the station. The only thing I have that will sync is my wristwatch, and it will only do it if I stand outside in an open area. -- Anthony ___ time-nuts mailing 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] Is there anything wrong with DCF77?
In message 01cde828$6a8e29d0$3faa7d70$@com, George Race writes: Hi Anthony, is there any possibility that you have a source of local interference that started up in your home or area? For DCF77 a very typical source of trouble is old CRT-based televisions or monitors, since 15625 Hz * 5 = 78125 Hz Reception looks good here in .dk -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] An embedded NTP server
Hi The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… Bob On Dec 31, 2012, at 10:56 PM, Michael Tharp g...@partiallystapled.com wrote: On 12/28/2012 12:34 PM, Chris Albertson wrote: One idea that I like is to first get a large FPGA. Then you load in a soft CPU and then you run an OS and NTP on the soft CPU. Inside the softCPU the counter is implemented like it is in a real CPU but you can add the ability for a PPS to latch it. Basicaly you move the interrupt handler to hardware. The trick is if you can get good enough performance out of the soft CPU?There is some intelectual property problems with some soft CPS but I'm pretty sure there are free SPARC CPS you can use and SPARC is ideal for this as it can run BSD Unix. Most microcontrollers that I have seen (PIC, ARM, presumably AVR as well) already have a peripheral called input capture that does exactly this, and that's what my project is using. Since it's part of the timer peripheral it usually runs at (up to) the same speed as the CPU which in my case is 72MHz, plenty for a decent lock. It simply grabs the current value of the counter when a pulse arrives and saves it until the CPU can get around to retrieving it. To get another order of magnitude the next step would be an analog TDC or a FPGA running a vernier TDC, but you can get quite satisfactory results with just an off-the-shelf microcontroller. Free CPU cores for FPGAs are not a problem, I have investigated a little and come up with a few candidates. Right now my favorite would be a microblaze clone called aemb, but there is also light8080 (tiny but 8-bit is a headache) and OpenRISC (fat but full-featured). There is a free vernier TDC core as well that is made available by CERN. They are using it in their White Rabbit system which does some rather neat things with custom Ethernet transceivers and switches that can distribute time across significant lengths of fiber to very good precision. I have not yet dedicated enough time to finish wiring the TDC to a CPU but I have made some progress; it synthesizes but is not yet operating correctly. I will be the first to admit I am not very experienced with FPGAs but given enough time and interest it can be made to work. -- m. tharp ___ time-nuts mailing 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] An embedded NTP server
On Tue, 1 Jan 2013 11:23:57 -0500 Bob Camp li...@rtty.us wrote: The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ time-nuts mailing 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] An embedded NTP server
On 01/01/13 17:34, Attila Kinali wrote: On Tue, 1 Jan 2013 11:23:57 -0500 Bob Campli...@rtty.us wrote: The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Many CMOS PLL solutions work like that. For instance, one chip I recall has a ~2.4 GHz oscillator, divides that down on the output side and then have input and feedback dividers as well. The benefit is that the tuning range of the core VCO can be fairly low, and you get decent jitter that way. For higher rates N-phase oscillators is used, typically 4-phase. Playing tricks which how those phases are used can keep divider noises down when doing fractional division rates. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] An embedded NTP server
Hi Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. Bob On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: On Tue, 1 Jan 2013 11:23:57 -0500 Bob Camp li...@rtty.us wrote: The only problem you may run into with an input capture is that the 72 MHz may be from an internal VCO that's locked to the external clock source or crystal. Often these micro's don't have VCO's that are as good a one might hope. You will indeed have less than 1 UI jitter, you may not have a whole lot less… What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ time-nuts mailing 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] Is there anything wrong with DCF77?
Hi Anthony, is there any possibility that you have a source of local interference that started up in your home or area? Maybe, but I'm not sure where it would come from. It's been like this for days, and today there is no reception by any of the clocks at all. If just one clock failed to receive, I'd look at the clock, but four at once means there's something wrong with reception. There are computers on my desk, but they've been there for years. But who knows what's happening in apartments around me. If you have a spectrum analyzer available that will cover the frequency range of DCF77, it may not hurt to look around and see what you can find. I wish! Santa didn't bring me one of those, unfortunately. There's one clock that often has trouble synchronizing, irrespective of its position. Two others usually synchronize okay, again irrespective of position, although they are usually near windows, anyway. The watch seems to synchronize very reliably as long as it's near the window. But right now nothing is synchronizing. Thank goodness I have NTP on the server or I wouldn't have exact time! -- Anthony ___ time-nuts mailing 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] Is there anything wrong with DCF77?
For DCF77 a very typical source of trouble is old CRT-based televisions or monitors, since 15625 Hz * 5 = 78125 Hz I suppose someone nearby could have received a collector's-item Trinitron for Christmas. What about Wi-Fi, cell phones, and such? They are way far away in frequency, but I'm not a radio engineer. Anything high-tech that could interfere? -- Anthony ___ time-nuts mailing 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] Is there anything wrong with DCF77?
On 01/01/2013 09:54 AM, Anthony G. Atkielski wrote: For DCF77 a very typical source of trouble is old CRT-based televisions or monitors, since 15625 Hz * 5 = 78125 Hz I suppose someone nearby could have received a collector's-item Trinitron for Christmas. What about Wi-Fi, cell phones, and such? They are way far away in frequency, but I'm not a radio engineer. Anything high-tech that could interfere? -- Anthony ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. It could be a newly installed CFL or one whose filtering has just failed. Or any switching power supply for that matter. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 ___ time-nuts mailing 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] An embedded NTP server
Hoi Bob, On Tue, 1 Jan 2013 12:03:49 -0500 Bob Camp li...@rtty.us wrote: On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. That's why i was specifically asking about those uC which use a higher frequency VCO for their clock generation. Ie not the tiny 8bit stuff, but those in the ARM7/Cortex-M3 class. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ time-nuts mailing 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] An embedded NTP server
Hi The little Arm7/ Cortex-M3 micro's don't pay as much attention to the clock chain as some of their bigger brothers (like a Sandy Bridge I7) do. At least the M3's and M4's I have seen are running the VCO at 50 to 150 MHz to generate a CPU clock at that frequency. The clock is divided by two for the RAM clock, and divided by two again for the flash clock. They may be doing a fake out on the VCO frequency. If they are, it's well hidden. Bob On Jan 1, 2013, at 1:14 PM, Attila Kinali att...@kinali.ch wrote: Hoi Bob, On Tue, 1 Jan 2013 12:03:49 -0500 Bob Camp li...@rtty.us wrote: On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. That's why i was specifically asking about those uC which use a higher frequency VCO for their clock generation. Ie not the tiny 8bit stuff, but those in the ARM7/Cortex-M3 class. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ time-nuts mailing 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] Is there anything wrong with DCF77?
Hi The first thing to think about is what did I get for Christmas?. If it runs 24 hours a day, it might be the source of the problem. Just about anything *could* have a switching power supply in it these days. It could be as silly as the plug in the wall charger for a cell phone. Bob On Jan 1, 2013, at 12:54 PM, Anthony G. Atkielski anth...@atkielski.com wrote: For DCF77 a very typical source of trouble is old CRT-based televisions or monitors, since 15625 Hz * 5 = 78125 Hz I suppose someone nearby could have received a collector's-item Trinitron for Christmas. What about Wi-Fi, cell phones, and such? They are way far away in frequency, but I'm not a radio engineer. Anything high-tech that could interfere? -- Anthony ___ time-nuts mailing 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] Is there anything wrong with DCF77?
In message 1991305643.20130101185...@atkielski.com, Anthony G. Atkielski wr ites: What about Wi-Fi, cell phones, and such? They are way far away in frequency, but I'm not a radio engineer. Anything high-tech that could interfere? Far more likely are switch-mode power-supplies, either in equipment or as black block to plug in the outlet. Many LED light devices, including some X-mas lights use a switchmode supply. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Is there anything wrong with DCF77?
Hi Could be that neighbor with the 1,000,000 light Christmas display …. Bob On Jan 1, 2013, at 2:14 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 1991305643.20130101185...@atkielski.com, Anthony G. Atkielski wr ites: What about Wi-Fi, cell phones, and such? They are way far away in frequency, but I'm not a radio engineer. Anything high-tech that could interfere? Far more likely are switch-mode power-supplies, either in equipment or as black block to plug in the outlet. Many LED light devices, including some X-mas lights use a switchmode supply. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] An embedded NTP server
Hi I'm not bashing the Arm parts, they are nice gizmos. They don't do the clock chains the way they do because they are lazy. They very much plan things out. Their main target audience is low power portable gear. Having a part that drops down to very low current when nothing much is going on is one of their goals. That drives them to keep the clocks / VCO's as slow as they possibly can. They worry about every uA of current drain… Bob On Jan 1, 2013, at 1:14 PM, Attila Kinali att...@kinali.ch wrote: Hoi Bob, On Tue, 1 Jan 2013 12:03:49 -0500 Bob Camp li...@rtty.us wrote: On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@kinali.ch wrote: What about those uC that use a VCO that runs up at several 100MHz (i've seen up to 800MHz) and devide it down to what they actually need. Shouldnt this improve jitter quite considerably? Most of the small micro's don't get very fancy on the clock chain. You are lucky if the VCO is running at twice the CPU clock. In some cases the input capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the CPU is running at half or a quarter of that. That's why i was specifically asking about those uC which use a higher frequency VCO for their clock generation. Ie not the tiny 8bit stuff, but those in the ARM7/Cortex-M3 class. Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ___ time-nuts mailing 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] Is there anything wrong with DCF77?
Could be that neighbor with the 1,000,000 light Christmas display . Hmm ... that sounds like a likely culprit. There are some Christmas lights nearby. We'll see if the problem disappears with the lights. Good ideas, thanks Bob and Poul. -- Anthony ___ time-nuts mailing 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] An embedded NTP server
In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@rtty.us, Bob Camp writes: I'm not bashing the Arm parts, [...] They worry about every uA of current drain True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] any unheated Vref better than LT1021-7 (at 7 ppm/khr typ.) ?
Take a close look at the photos of Malones nice little voltage reference boards (http://www.voltagestandard.com/Home_Page_JO2U.html). The voltage reference chip is mounted on an isolated peninsula of PC board material to help isolate it from stress due to environmental changes. If the humidity effect is strictly from mechanical stress on the die as the plastic encapsulant swells or shrinks, would a part in a metal can then be immune from this effect, even if it was non-hermetic? ___ time-nuts mailing 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] An embedded NTP server
I have had that problem more than once. Missing Vcc on a chip but the thing runs, just not necessarily well enough, or well enough to go through the next level of test. I have also used it when adding an inverter somewhere on a clock line, and a decoupling cap on the inverter's Vcc is enough to keep it running. Saves a jumper. Didier Sent from my Droid Razr 4G LTE wireless tracker. -Original Message- From: Poul-Henning Kamp p...@phk.freebsd.dk To: Discussion of precise time and frequency measurement time-nuts@febo.com, Bob Camp li...@rtty.us Sent: Tue, 01 Jan 2013 2:16 PM Subject: Re: [time-nuts] An embedded NTP server In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@rtty.us, Bob Camp writes: I'm not bashing the Arm parts, [...] They worry about every uA of current drain True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Is there anything wrong with DCF77?
If you can look at the output of a DCF77 demodulator you should see a nice clean set of 100ms/200ms pulses every second. All you need is a CRO, or you could just use a LED to indicate the state. On 2 January 2013 01:00, George Race geo...@mrrace.com wrote: Hi Anthony, is there any possibility that you have a source of local interference that started up in your home or area? From time to time, I have had everything from power line arcing noise to a new computer power supply that was generating a high level of interference blocking signals on different frequencies. If you have a spectrum analyzer available that will cover the frequency range of DCF77, it may not hurt to look around and see what you can find. George -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Anthony G. Atkielski Sent: Tuesday, January 01, 2013 7:40 AM To: time-nuts@febo.com Subject: [time-nuts] Is there anything wrong with DCF77? For the past several days (now thirty hours straight), none of my radio-synchronized clocks has been able to synchronize with DCF77. Is there a problem with the transmitter, or maybe a geomagnetic storm or something that could explain it? I've been looked at the transmitter Web site and searching for news and information on any disturbances that would affect reception, but I haven't found anything. I'm about 500 km from the station. The only thing I have that will sync is my wristwatch, and it will only do it if I stand outside in an open area. -- Anthony ___ time-nuts mailing 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. -- Tom Harris celephi...@gmail.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] An embedded NTP server
The NXP LPC111x series has a PLL that runs at 156 to 320 MHz. You then divide the clock down (internally by 2,4,8, or 16) to what you want. 50 MHz is the max. for the LPC111x series. Giving you capture ticks in 20nS increments. I have some experiments in the works with an LPC1114 chip and a 40 MHz DSA222MAB TCVCXO clock (divided by 2 for the LPC1114 input). But those experiments are just at the schematic stage. I do have the LPC1114s and the DSA222MABs in hand. Simon Engineering is the art of making what you want from what you can get at a profit. ___ time-nuts mailing 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] An embedded NTP server
In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] An embedded NTP server
On 1/1/13 12:16 PM, Poul-Henning Kamp wrote: In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@rtty.us, Bob Camp writes: I'm not bashing the Arm parts, [...] They worry about every uA of current drain True story: Many years ago when the very first ARM silicon arrived and they started testing it, it was generally execeeding expectations but a little bit flakey at high clock rates. After the bubbly had been drunk and hangovers subdued, the serious testing started and one of the first thing they found was that they had forgotten to hook up VCC: The chip ran entirely on leaked power from the I/O pins, most notably the #RESET pin. When they also connected the VCC pin, it was stable well above spec'ed speed. more than one person (including me) has found out that with boards powered from their I/O interfaces rather than the power supply that they forgot to turn on. It's a huge deal in the spacecraft world because of the desire to do cross strapped redundancy with cold spares. Is the interface truly dead faced? And if you have a pyro actuated cable cutter, what happens if power from one wire couples into an interface for an unpowered unit? ___ time-nuts mailing 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] An embedded NTP server
The design I'm working on brings out the UART pins to a header. I am designing adapter boards for RS-232 (using a MAX232 type equivalent) or USB using the FT232RL chip for the USB interface. There will also be an I2C interface for a display (16X2 to start with) or what have you. (more serial ports is one option) The code base is not going to be critical because I'm using Forth rather than C. I am no fan of C. And neither is my software guy who at one time managed 5,000 ATT programmers. The Forth is going to be pretty primitive to start with (assembler macros). But we may turn it into a full blown Forth as time goes on. When the first round is done and working we will publish a complete design (schematics and code - with bare boards available at a nominal cost). I like the LPC111x series because of its very low cost. I do have plans to move up to some of the higher series chips once this design is done - if I can figure out how to solder chips by hand that have pins on .5mm ctrs. Currently I can solder chips with .65 mm lead spacing without too much trouble. Simon Engineering is the art of making what you want from what you can get at a profit. From: Poul-Henning Kamp p...@phk.freebsd.dk To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, January 1, 2013 9:26 PM Subject: Re: [time-nuts] An embedded NTP server In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] An embedded NTP server
I should add that the first published design will probably be a frequency/period counter. It will have an input for an external 10 MHz reference. Simon Engineering is the art of making what you want from what you can get at a profit. From: Poul-Henning Kamp p...@phk.freebsd.dk To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, January 1, 2013 9:26 PM Subject: Re: [time-nuts] An embedded NTP server In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Is there anything wrong with DCF77?
On 1/1/2013 9:42 PM, Tom Harris wrote: If you can look at the output of a DCF77 demodulator you should see a nice clean set of 100ms/200ms pulses every second. All you need is a CRO, or you could just use a LED to indicate the state. This is how DCF77 looks, when received with an SDR capable of displaying spectrum and waterfall. Captured just minutes ago. [1]https://dl.dropbox.com/u/15089947/dcf77_a.gif 73 Alberto I2PHD References 1. https://dl.dropbox.com/u/15089947/dcf77_a.gif ___ time-nuts mailing 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] An embedded NTP server
Hi The VCO is part of the process, the PLL and it's loop are another part. There's no reason why they can't put a good loop in a micro, other than chip area for the passive parts. What ever they do, the loop will probably be a compromise, since the frequencies involved are not known at design time. A 4 MHz reference and a 40 MHz reference will need different loop components running a 100 MHz VCO …. Bob On Jan 1, 2013, at 3:45 PM, M. Simon msimon6...@yahoo.com wrote: The NXP LPC111x series has a PLL that runs at 156 to 320 MHz. You then divide the clock down (internally by 2,4,8, or 16) to what you want. 50 MHz is the max. for the LPC111x series. Giving you capture ticks in 20nS increments. I have some experiments in the works with an LPC1114 chip and a 40 MHz DSA222MAB TCVCXO clock (divided by 2 for the LPC1114 input). But those experiments are just at the schematic stage. I do have the LPC1114s and the DSA222MABs in hand. Simon Engineering is the art of making what you want from what you can get at a profit. ___ time-nuts mailing 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] clock-block any need ?
On 27 Dec, 2012, at 15:13 , Magnus Danielson mag...@rubidium.dyndns.org wrote: On GE, a full-length packet is about 12 us, so a single packets head-of-line blocking can be anything up to that amount, multiple packets... well, it keeps adding. Knowing how switches works doesn't really help as packets arrive in a myriad of rates, they interact and cross-modulate and create strange patterns and dance in interesting ways that is ever changing in unpredictable fashion. I wanted to address this bit because it seems like most people base their expectations for NTP on this complexity, as does the argument being made above, but the holiday intervened. While I suspect many people are thoroughly bored of this topic by now I can't resist completing the thought. Yes, the delay of a sample packet through an output queue will be proportional to the number of untransmitted bits in the queue ahead of it, yes, the magnitude of that delay can be very large and largely variable and, even, yes, the statistics governing that delay may often be unpredictable and non-gaussian, exhibiting dangerously heavy tails. The thing is, though, that this doesn't necessarily have to matter so much. A better approach might avoid relying on the things you can't know. To see how, consider a different question: what is the probability that any two samples sent through that queue will experience precisely the same delay (i.e. find precisely the same number of bits queued in front of it when it gets there)? I think it is fairly conservative to predict that the probability that two samples will arrive at a non-empty output queue with exactly the same number of bits in front of them will be fairly small; the number of bits in the queue will be continuously changing, so the delay through a non-empty queue should have a near-continuous (and unpredictable) probability distribution, as you point out, and if the sampling is uncorrelated with the competing traffic it is unlikely that any pair of samples will find exactly the same point on that distribution. The exception to this, of course, is a queue length of precisely 0 bits (which is precisely why the behaviour of a switch with no competing traffic is interesting). The vast majority of queues in the vast majority of network devices in real networks are no where near continuously occupied for long periods. The time-averaged fractional load on the circuit a queue is feeding is also the probability of finding the queue not-empty. If the average load on the output circuit is less than 100% then multiple samples are probably going to find that queue precisely empty; if the average load on the output circuit is 50% (and that would be an unusually high number in a LAN, though maybe less unusual in other contexts) then 50% of the samples that pass through that queue are going to find it empty. Since samples that found the queue empty will have experienced pretty much identical delays, the results (for some value of result) from those samples will cluster closely together. The results from samples which experienced a delay will differ from that cluster but, as discussed above, will also differ from each other and generally won't form a cluster somewhere else. The cluster marks the good spot independent of the precise (and precisely unknowable) nature of the statistics governing the distribution of samples outside the cluster. If we can find the cluster we have a result which does not depend on understanding the precise behaviour of samples outside the cluster. Given this it is also worth while to consider jitter, which intuition based on a normal distribution assumption might suggest should be predictive of the quality of the result derived from a collection of samples. In the situation above, however, the dominant contributors to jitter, however measured, are going to be the samples outside the cluster since they are the ones that are jittering (it is that property we are relying on to define the cluster). If jitter mostly measures information about the samples the estimate doesn't rely on then it tells you little about the samples the estimate does rely on, and hence can provide no prediction about the quality of an estimate derived from those samples alone. In fact, in a true perversion of normal intuition, high jitter and heavy-tailed probability distributions might even make it easier to get a good result by making it easier to identify the cluster. Saying I see a lot of jitter doesn't necessarily tell you anything about what is possible. While the argument gets a lot more complex in a hurry, and too much to attempt here (the above is too much already), I believe this general approach can scale to a whole large network of devices with queues (though even the single-switch case has real life relevance too). That is, I think it is possible to find a sample result for which there is a strong tendency for good samples to cluster together while bad samples are unlikely to do
Re: [time-nuts] clock-block any need ?
Hi The problem with your approach is that you can depart from normal for very long periods of time. Consider my home network, running NTP to external sources. Around 4 in the afternoon all the kids get home and start streaming video. At 7 I get home and start doing the same thing. We each keep this up for 5 hours. Past midnight, the bit torrent fires up and it runs through 5 AM. Mid day, there's a video conference that runs from home for an hour or two. Each of these things creates a non-zero load ahead of the NTP at some point. Given network congestion and re-transmission the load will really pile up at various times. Given the high level of transmit / receive asymmetry in my cable modem, it will be pretty hard for me to figure out what's going on. The net result will be that my NTP hops around a bit during the day. Bob On Jan 1, 2013, at 8:57 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 27 Dec, 2012, at 15:13 , Magnus Danielson mag...@rubidium.dyndns.org wrote: On GE, a full-length packet is about 12 us, so a single packets head-of-line blocking can be anything up to that amount, multiple packets... well, it keeps adding. Knowing how switches works doesn't really help as packets arrive in a myriad of rates, they interact and cross-modulate and create strange patterns and dance in interesting ways that is ever changing in unpredictable fashion. I wanted to address this bit because it seems like most people base their expectations for NTP on this complexity, as does the argument being made above, but the holiday intervened. While I suspect many people are thoroughly bored of this topic by now I can't resist completing the thought. Yes, the delay of a sample packet through an output queue will be proportional to the number of untransmitted bits in the queue ahead of it, yes, the magnitude of that delay can be very large and largely variable and, even, yes, the statistics governing that delay may often be unpredictable and non-gaussian, exhibiting dangerously heavy tails. The thing is, though, that this doesn't necessarily have to matter so much. A better approach might avoid relying on the things you can't know. To see how, consider a different question: what is the probability that any two samples sent through that queue will experience precisely the same delay (i.e. find precisely the same number of bits queued in front of it when it gets there)? I think it is fairly conservative to predict that the probability that two samples will arrive at a non-empty output queue with exactly the same number of bits in front of them will be fairly small; the number of bits in the queue will be continuously changing, so the delay through a non-empty queue should have a near-continuous (and unpredictable) probability distribution, as you point out, and if the sampling is uncorrelated with the competing traffic it is unlikely that any pair of samples will find exactly the same point on that distribution. The exception to this, of course, is a queue length of precisely 0 bits (which is precisely why the behaviour of a switch with no competing traffic is interesting). The vast majority of queues in the vast majority of network devices in real networks are no where near continuously occupied for long periods. The time-averaged fractional load on the circuit a queue is feeding is also the probability of finding the queue not-empty. If the average load on the output circuit is less than 100% then multiple samples are probably going to find that queue precisely empty; if the average load on the output circuit is 50% (and that would be an unusually high number in a LAN, though maybe less unusual in other contexts) then 50% of the samples that pass through that queue are going to find it empty. Since samples that found the queue empty will have experienced pretty much identical delays, the results (for some value of result) from those samples will cluster closely together. The results from samples which experienced a delay will differ from that cluster but, as discussed above, will also differ from each other and generally won't form a cluster somewhere else. The cluster marks the good spot independent of the precise (and precisely unknowable) nature of the statistics governing the distribution of samples outside the cluster. If we can find the cluster we have a result which does not depend on understanding the precise behaviour of samples outside the cluster. Given this it is also worth while to consider jitter, which intuition based on a normal distribution assumption might suggest should be predictive of the quality of the result derived from a collection of samples. In the situation above, however, the dominant contributors to jitter, however measured, are going to be the samples outside the cluster since they are the ones that are jittering (it is that property we are relying on to define the
Re: [time-nuts] Is there anything wrong with DCF77?
On 1/1/2013 9:42 PM, Tom Harris wrote: If you can look at the output of a DCF77 demodulator you should see a nice clean set of 100ms/200ms pulses every second. All you need is a CRO, or you could just use a LED to indicate the state. This is how DCF77 looks, when received with an SDR capable of displaying spectrum and waterfall. Captured just minutes ago. [1]https://dl.dropbox.com/u/15089947/dcf77_a.gif 73 Alberto I2PHD Unfortunately I don't have any tools or anything, just the clocks. Hopefully whoever is causing the interference will stop once the holidays are over (I don't think it's me, as nothing has changed inside the apartment). Even if I could find the source of the interference, I wouldn't necessarily be able to force my neighbors to stop whatever they are doing that causes it. -- Anthony ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] A New Years Resolution.
I hereby resolve to look at the subject line of every message I send and change it if necessary. Regards. Max. K 4 O DS. Email: m...@maxsmusicplace.com Transistor site http://www.funwithtransistors.net Vacuum tube site: http://www.funwithtubes.net Woodworking site http://www.angelfire.com/electronic/funwithtubes/Woodworking/wwindex.html Music site: http://www.maxsmusicplace.com To subscribe to the fun with transistors group send an email to. funwithtransistors-subscr...@yahoogroups.com To subscribe to the fun with tubes group send an email to, funwithtubes-subscr...@yahoogroups.com To subscribe to the fun with wood group send a blank email to funwithwood-subscr...@yahoogroups.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] An embedded NTP server
Yay for Forth! Don M. Simon The design I'm working on brings out the UART pins to a header. I am designing adapter boards for RS-232 (using a MAX232 type equivalent) or USB using the FT232RL chip for the USB interface. There will also be an I2C interface for a display (16X2 to start with) or what have you. (more serial ports is one option) The code base is not going to be critical because I'm using Forth rather than C. I am no fan of C. And neither is my software guy who at one time managed 5,000 ATT programmers. The Forth is going to be pretty primitive to start with (assembler macros). But we may turn it into a full blown Forth as time goes on. When the first round is done and working we will publish a complete design (schematics and code - with bare boards available at a nominal cost). I like the LPC111x series because of its very low cost. I do have plans to move up to some of the higher series chips once this design is done - if I can figure out how to solder chips by hand that have pins on .5mm ctrs. Currently I can solder chips with .65 mm lead spacing without too much trouble. Simon Engineering is the art of making what you want from what you can get at a profit. From: Poul-Henning Kamp p...@phk.freebsd.dk To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, January 1, 2013 9:26 PM Subject: Re: [time-nuts] An embedded NTP server In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si mon writes: The NXP LPC111x series [...] My personal preference is the LPC1343, because it has a USB port, and because there is a reltively nice codebase to start from: https://github.com/microbuilder/LPC1343CodeBase -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Neither the voice of authority nor the weight of reason and argument are as significant as experiment, for thence comes quiet to the mind. De Erroribus Medicorum, R. Bacon, 13th century. If you don't know what it is, don't poke it. Ghost in the Shell Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
