Re: [time-nuts] distirbuted sync
You can prototype a system with off the shelf parts get a few computers, old notebook computers, Raspburry pI' or repurposed routers, what ever you have. Connect a Trimble Thunderbolt GPS to each one. Each one runs NTP. Connect them all to a isolated network. It could be wired, WiFi or whatever. Let's say you have three systems. When all three can se the sky they have good timing.Now cover lone, two or all three GPS antenna and you are stil doing OK for a while. With all thre antennacovered you ar will still have the system time sync'd even it it drifes from real UTC by a few tens of milliseconds. But if just one of the three can see the sky for a little while the time gets corected in all systems You can't use Eithernet in the real system but you can rig some other media. Blue Toth works over a short distance but you have radar. It seems like you should be able to use the radar for data communications. Radars if they ca hear the echo at all would be senitive for very long range lateral communications. You say you don't want more radios on the devices so just use the radar signal for low data rate local communications. Put TCP/IP stack on it On Tue, Jul 23, 2013 at 8:19 PM, Jim Lux jim...@earthlink.net wrote: On 7/23/13 9:15 AM, Chris Albertson wrote: I don't think those requirements are hard. You can build a system that works in three cases 1) GPS is available full time 2) GPS is available intermittently. 3) there is not GPS system, world war III has destroyed it. or you're in an urban canyon or you're underground or you're working in a GPS-denied environment (battlefield scenario) I think what you want is a system that is failure tolerant and can make use of the best available source of timing and degrade performance gracefully. And you need this is be automatic with the only control maybe being a status LED that shows free/yellow/red I'm not sure failure tolerance is actually the right approach: more like selecting the appropriate mode. There's probably no need to smoothly change between GPS available and not available, for instance, so one doesn't need some sort of optimal estimator that combines all available sources. You can just jump There is a desire to leverage other assets that are available (there's already too many radios.. we don't need to add more). Each system has a GPS receiver that disciplines a crystal oscillator. This oscillator is used for timing. I think it's clear that this handles cases #1 and #2. Then use you Blue Tooth or whatever other short distance communications system you have to support an IP network. TCP/IP over zBlueTooth works well and is a standard now. Using this you can configure a NTP based network of peers. Each of the above systems, when they are close enough will share timing with the other peers. Time is probably not the hard part. There's tons of ways to sync to 1 millisecond, and for the ranges of interest, light/propagation time isn't an issue. The challenge is finding something that gives me the 1 millisecond without having to add some sort of hardware. For instance, the system *is* a 3 GHz radar, and the challenge is to synchronize transmitters and receivers, but hey, the transmitter can transmit at a known time, the receiver can detect when it sees the transmitted signal. I could even modulate the transmitter. The system runs on a consensus time. If one or more systems has access to GPS those system will supply timing to any other system in range of the blue tooth. If there is no GPS at all the systems will form what they call an orphan network and will remain synced to each other untill some outside source of time connects and puts them all back on GPS time. NTP is pretty good at handing the case where timing sources come on and off line and where network connects connect and then go away. It is very failure tolerant. Or an NTP-like algorithm that handles the communications dynamics of the system. NTP is tuned/designed for networks in terms of adaptation rates and the filters. What you'd have is a kind os graceful degradation. When GPS is visible to all units they are all dead-on and running well above you specs. If GPS is hidden (perhaps in an urban canyon or you happen to be inside a tunnel) the systems ail remain in spec for many hours or even days depending on how much money you spent on the crystal (or Rubidium) oscillators Power mass is more an issue than cost, although $1000 oscillators are probably out of the question. Imagine you have to carry one or more of these things for 12 hours across a disaster site along with your other gear. Power turns into mass, too. Finally if there is no GPS at all but several systems are within blue tooth range that can sync to each other at the few millisecond level. but because you did spend $$ on a god crystal will stay sync'd for hours even when out of bluetooth range with no GPS.
Re: [time-nuts] distirbuted sync
albertson.ch...@gmail.com said: Then use you Blue Tooth or whatever other short distance communications system you have to support an IP network. TCP/IP over zBlueTooth works well and is a standard now. Using this you can configure a NTP based network of peers. .., I'm a big NTP fan, but I wouldn't use NTP for this. (I assume we are talking about the standard NTP reference package from ntp.org.) It's too big and complicated and will be hard to debug if something goes wrong. The real problem is that it will do the best it can rather than scream and shout when something unexpected happens. On the other hand, I like playing with low level things like packets and clocks, and I'm not good at paying attention to the big picture when resources (manpower, time) are limited. It might work fine. It's probably easy to try it. If I was doing something like this (and I could be way off by what this is), I'd try roughly: Measure the clock drift rate on a sample of typical systems. These systems need a clock good to 1E-10. If that can be used by the OS time keeping code the drift should be hard to measure. If not, measure whatever the system will be using. Most likely, it will be way off, as in 10s to 100s of PPM. (The 100s covers software bugs in the OS and design errors in the hardware.) Linux (on a PC) measures the CPU crystal at boot time. There is lots of noise in that. You can bypass that noise if you build your own kernel and find that chunk of code and patch in a constant. (I'm thinking of one kernel build per set of boxes rather than one per box.) Now you have a good thermometer. Ballpark is 1 PPM per C. If you measure the drift on each system and save it in ROM/Flash/file-system, you can add some code to the startup area to tell the system how to tweak its clock. (I'll fish out the API details if anybody wants it.) Is that good enough? Do you even need to do the drift measurement and correction on each box? ... That's some combination of the requirements, how much drift is left and how well the boxes in the field track each other (temperature, manufacturing batch) and if you need the correct time or just closely tracked time. Are some boxes in the sun and others in the shadow? ... Another quirk to consider is that happens if you reboot a box half way through the battery lifetime. Does it get the time from its brothers or from the master PC? Does the PC drift track the others or track GPS or...? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] distirbuted sync
On 7/23/13 11:03 PM, Chris Albertson wrote: You can prototype a system with off the shelf parts get a few computers, old notebook computers, Raspburry pI' or repurposed routers, what ever you have. Connect a Trimble Thunderbolt GPS to each one. Each one runs NTP. Connect them all to a isolated network. It could be wired, WiFi or whatever. This is at work. No junker old laptops.. there isn't enough time in the world to try and figure out their idiosyncracies. Let's say you have three systems. When all three can se the sky they have good timing.Now cover lone, two or all three GPS antenna and you are stil doing OK for a while. With all thre antennacovered you ar will still have the system time sync'd even it it drifes from real UTC by a few tens of milliseconds. But if just one of the three can see the sky for a little while the time gets corected in all systems I think that's overkill for this system. 1 millisecond relative timing is an easy bar to meet with almost any comm link; that's more of an integration challenge: what off the shelf widget comes with the ability to do the sync. The challenge is in the frequency control, without resorting to OCXOs or atomic standards. You can't use Eithernet in the real system but you can rig some other media. Blue Toth works over a short distance but you have radar. It seems like you should be able to use the radar for data communications. Radars if they ca hear the echo at all would be senitive for very long range lateral communications. It's not a pulsed radar. CW, at a milliwatt or ten. the bandwidth of the communications channel, if it can be called that, is on the order of 10-50 Hz. The way the system works is to look at the received signal reflected from the rubble and victim. That signal has a very strong fixed component (the rubble isn't moving) and a very weak component (heartbeats cause a phase shift of around 10 degrees). With a sufficiently large dynamic range receiver one could just digitize, calculate the baseline, subtract it, and look for the changes. However, this is impractical for a variety of reasons. So we coherently subtract a sample of the transmitted signal from the received signal to reduce the overall dynamic range requirement. Then we digitize and process. It's sort of like an nulling interference canceller in the RF comm world, or a flavor of Wheatstone bridge. If the transmitter and receiver are separated (say on opposite sides of a collapsed building, with no direct path), the problem becomes how do I get that copy of the transmitted signal to subtract. We also use the transmitted signal as a coherent LO for the demodulation. (Called homodyne detection in the radar world, and widely used in familiar applications like radar speed guns) You say you don't want more radios on the devices so just use the radar signal for low data rate local communications. Put TCP/IP stack on it Hmm.. TCP/IP at 10 bits/second? I think we can go simpler. We already have to have some sort of data link to send the sampled data for processing, but it's in the 1-10kbps range. Whatever that winds up being, I think that 1 millisecond sync won't be a problem. The challenge is the frequency control (or perhaps frequency knowledge. One additional challenge with the separated Tx and Rx is that we now have two phase noise sources, and we can't leverage the inherent cancellation with homodyne detection. ___ time-nuts mailing 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] distirbuted sync
On Wed, Jul 24, 2013 at 12:45 AM, Hal Murray hmur...@megapathdsl.net wrote: albertson.ch...@gmail.com said: .. It's too big and complicated and will be hard to debug if something goes wrong. The real problem is that it will do the best it can rather than scream and shout when something unexpected happens.x can be used by the OS time keeping code the drift should be hard to measure. If not, measure whatever the system will be using. Most likely, it will be way off, as in 10s to 100s of PPM. (The 100s covers software bugs in the OS and design errors in the hardware.) Hard to debug? It runs of every router and (non MS Windows) computer on Earth every day 24x7 How often do people have to debug it? I'd guess that 99.99% of the people who use it don't know it even exists. (for example NTP runs on Android phones, along with NITZ for cell signals) It is pretty easy to keep track of how well it is doing You run ntpq and have it output some numbers, then look at the numbers and do what's needed. But then, intersystem communications between two or more radar should be EASY. You can put some data bits on the radar pulses. Same for timing if the PRF (pulse repetition frequency) is well timed then the radar is broadcasting a timing reference The infamous radar range equation pretty much ensures that every radar can hear all the pulses from the other radars. The receivers need to be very sensitive relative to the transmit power MUCH more so then in a communications system. There is also a good reason to modulate a radar pulse with psudorandom-like bits, The receiver knows what was sent and looks for it with an autocorellation function. This allows good noise and jamming resistance. Good plan if you have multiple radars in the same general area. Sounds like a lot of processing but I think this gets done inside a FPGA -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] HP 10811 update
Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing 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] Time and Frequency book from NBS
I was able to find a copy of this in like new condition for about what it originally sold for - what a treasure! I may never need most of the info in it, but just the deep dives into subjects like quartz crystals makes this book worth every penny - even though some info is dated. Tip of the hat to Tom for listing on the web site. Russ K0WFS ___ time-nuts mailing 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] HP 10811 update
Thanks Charles. I suspect all said the regulated output delivers 1 ma. It doesn't feed much. I have the 2n3904s so cheap test to see if that picks up the 45 Hz On Wed, Jul 24, 2013 at 3:20 PM, Charles P. Steinmetz charles_steinm...@lavabit.com wrote: Paul wrote: Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. A BC549C or BC550C should work fine, and they are readily available and cheap. A 2N3904 should be fine, too, but the current regulator diode on the zener is only a 1mA part, so the 2N3904's increased base current will leave a wee bit less for the already-starved zener. Shouldn't be a problem, though. Noise of the transistor is not a factor (within reason) -- the zener will dominate that. Best regards, Charles __**_ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/** mailman/listinfo/time-nutshttps://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] HP 10811 update
2N6429... $1 each: http://www.talonix.com/shop/item.aspx?itemid=3522 ___ time-nuts mailing 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] HP 10811 update
Hi The regulator should be fixed, and the OCXO will work better with it repaired. That said, shifting the regulated voltage from 5.7 to 5.27 volts should not shift that oscillator 45 Hz. Bob On Jul 24, 2013, at 9:00 AM, paul swed paulsw...@gmail.com wrote: Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing 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] HP 10811 update
I can hope I will embed a k thermocouple also. On Wed, Jul 24, 2013 at 7:45 PM, Bob Camp li...@rtty.us wrote: Hi The regulator should be fixed, and the OCXO will work better with it repaired. That said, shifting the regulated voltage from 5.7 to 5.27 volts should not shift that oscillator 45 Hz. Bob On Jul 24, 2013, at 9:00 AM, paul swed paulsw...@gmail.com wrote: Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing 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] HP 10811 update
Well learned quite a bit Q4 does have an issue. Further there is a reason it has such high Beta. Its must deliver 30 ma to the oscillator and buffer. I was quite surprised by this current level. I was guessing the oscillator was a few mils and the buffer maybe 8. The 2n3904 simply does not cut it. Need to do some digging in the ole transistors. Regards Paul. On Wed, Jul 24, 2013 at 8:06 PM, paul swed paulsw...@gmail.com wrote: I can hope I will embed a k thermocouple also. On Wed, Jul 24, 2013 at 7:45 PM, Bob Camp li...@rtty.us wrote: Hi The regulator should be fixed, and the OCXO will work better with it repaired. That said, shifting the regulated voltage from 5.7 to 5.27 volts should not shift that oscillator 45 Hz. Bob On Jul 24, 2013, at 9:00 AM, paul swed paulsw...@gmail.com wrote: Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing 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] HP 10811 update
Sorry mate, this isn't much help, I haven't heave of any of these, must be before my time?! Mat Struct Pc Ucb Uce Ueb Ic Tj Ft Cc, pF Hfe Caps 1. 2N6429http://alltransistors.com/transistor.php?transistor=5816 Si NPN 0.625 55 45 6 0.2 175 100 3 400 TO92 2. NTE2341http://alltransistors.com/transistor.php?transistor=44370 Si NPN 1 100 80 7 1 2000 TO92 3. NTE46http://alltransistors.com/transistor.php?transistor=44457 Si NPN 0.625 100 100 12 0.5 1 TO92 4. NTE48http://alltransistors.com/transistor.php?transistor=44458 Si NPN 1 60 50 12 1 25000 TO92 5. SM2285http://alltransistors.com/transistor.php?transistor=45948 Si NPN 1 0 100 0 0.2 200 150 600 TO92 6. STL73Dhttp://alltransistors.com/transistor.php?transistor=50901 Si NPN 0 700 400 0 1.5 0 TO92 7. STX112http://alltransistors.com/transistor.php?transistor=50927 Si NPN 0 100 100 0 2 1000 TO92 8. STX616http://alltransistors.com/transistor.php?transistor=50930 Si NPN 0 980 500 0 1.5 0 TO92 -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of paul swed Sent: Thursday, 25 July 2013 11:29 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] HP 10811 update Well learned quite a bit Q4 does have an issue. Further there is a reason it has such high Beta. Its must deliver 30 ma to the oscillator and buffer. I was quite surprised by this current level. I was guessing the oscillator was a few mils and the buffer maybe 8. The 2n3904 simply does not cut it. Need to do some digging in the ole transistors. Regards Paul. On Wed, Jul 24, 2013 at 8:06 PM, paul swed paulsw...@gmail.commailto:paulsw...@gmail.com wrote: I can hope I will embed a k thermocouple also. On Wed, Jul 24, 2013 at 7:45 PM, Bob Camp li...@rtty.usmailto:li...@rtty.us wrote: Hi The regulator should be fixed, and the OCXO will work better with it repaired. That said, shifting the regulated voltage from 5.7 to 5.27 volts should not shift that oscillator 45 Hz. Bob On Jul 24, 2013, at 9:00 AM, paul swed paulsw...@gmail.commailto:paulsw...@gmail.com wrote: Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing list -- time-nuts@febo.commailto: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.commailto: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.commailto:time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] NTP to discipline Raspberry Pi
I was hoping to measure the ppm error of a Raspberry Pi's crystal using an NTP client running on the Pi itself. The NTP client reports a ppm correction that I find to be consistently (measurements performed over several days) off by about 10 ppm compared to what I measure using my GPS calibrated frequency counter (HP5328). Specifically, the Pi reports a required ppm correction of -33 ppm whereas I consistently measure a required correction of -43 ppm on my frequency counter. Any ideas on where I can look to track down the discrepancy? Perhaps the timers on the RPi are configured incorrectly in the kernel? Or is this the best I can expect from NTP? I would understand the situation if the NTP reported correction drifted above and below -43ppm, but it seldom departs from -33ppm by more than 1 or 2 ppm... Thanks, James P.S. I apologize if this isn't time-nutty enough :) I only need about 1ppm accuracy in my corrections :) -- *Integrity is a binary state - either you have it or you don’t.* - John Doerr ___ time-nuts mailing 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] HP 10811 update
The 2N6429 crosses to an NTE123AP, in stock at Allied for $0.80. http://www.alliedelec.com/search/productdetail.aspx?SKU=70214870mkwid=szEc5 jMBIpcrid=23468365337pkw=nte123appmt=epdv=cgclid=CKyzu9_cybgCFWYV7AodJA sAWQ Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of paul swed Sent: Wednesday, July 24, 2013 8:29 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] HP 10811 update Well learned quite a bit Q4 does have an issue. Further there is a reason it has such high Beta. Its must deliver 30 ma to the oscillator and buffer. I was quite surprised by this current level. I was guessing the oscillator was a few mils and the buffer maybe 8. The 2n3904 simply does not cut it. Need to do some digging in the ole transistors. Regards Paul. On Wed, Jul 24, 2013 at 8:06 PM, paul swed paulsw...@gmail.com wrote: I can hope I will embed a k thermocouple also. On Wed, Jul 24, 2013 at 7:45 PM, Bob Camp li...@rtty.us wrote: Hi The regulator should be fixed, and the OCXO will work better with it repaired. That said, shifting the regulated voltage from 5.7 to 5.27 volts should not shift that oscillator 45 Hz. Bob On Jul 24, 2013, at 9:00 AM, paul swed paulsw...@gmail.com wrote: Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NTP to discipline Raspberry Pi
ja...@peroulas.com said: Any ideas on where I can look to track down the discrepancy? Dig out the kernel sources. There are 2 sources of error. One is the calibration routine. It's comparing the CPU cycle counter with another counter that runs at a specified frequency. I think recent kernels have cleaned up this area but it used to generate a lot of noise. Boot a system several times and you will get several different answers, off by up to 100 ppm. Grep your log file looking for things like: Detected 430.931 MHz processor. See if you get the same answer each time you boot. The other possible error is just the main timekeeping routines. Maybe some constant is off a bit. Unless somebody does your type of measurement, nobody would notice as long as it was close enough that NTP could fix it. (Who but a time-nut would care if the crystal was off by 33 ppm or 43 ppm?) but it seldom departs from -33ppm by more than 1 or 2 ppm... What do you expect? Ballpark is 1 ppm/C. How stable is your temperature? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] HP 10811 update
I find it hard to believe that NTE spec the 123AP to replace a transistor with min beta of 500... This is quite entertaining: http://www.vetco.net/catalog/product_info.php?products_id=1856 Look at the parts it's supposed to replace. (Nothing against Vetco - they are a great source of NTE components and are local to me. They are just quoting what NTE claim.) Orin. On Wed, Jul 24, 2013 at 8:42 PM, J. L. Trantham jlt...@att.net wrote: The 2N6429 crosses to an NTE123AP, in stock at Allied for $0.80. http://www.alliedelec.com/search/productdetail.aspx?SKU=70214870mkwid=szEc5 jMBIpcrid=23468365337pkw=nte123appmt=epdv=cgclid=CKyzu9_cybgCFWYV7AodJA sAWQ Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of paul swed Sent: Wednesday, July 24, 2013 8:29 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] HP 10811 update Well learned quite a bit Q4 does have an issue. Further there is a reason it has such high Beta. Its must deliver 30 ma to the oscillator and buffer. I was quite surprised by this current level. I was guessing the oscillator was a few mils and the buffer maybe 8. The 2n3904 simply does not cut it. Need to do some digging in the ole transistors. Regards Paul. On Wed, Jul 24, 2013 at 8:06 PM, paul swed paulsw...@gmail.com wrote: I can hope I will embed a k thermocouple also. On Wed, Jul 24, 2013 at 7:45 PM, Bob Camp li...@rtty.us wrote: Hi The regulator should be fixed, and the OCXO will work better with it repaired. That said, shifting the regulated voltage from 5.7 to 5.27 volts should not shift that oscillator 45 Hz. Bob On Jul 24, 2013, at 9:00 AM, paul swed paulsw...@gmail.com wrote: Hello to the group. Numbers of threads running on the HP 10811. Mine is 45 Hz low. The oven is most likely ok. I did get the can open per the various other threads and the web pix. Started testing the circuits and have found that the regulator for the oscillator isn't. Its supposed to produce 5.7V and is at 5.27V thats pretty significant. The transistor looks like a shorted collector base junction. Though I do not have it out of circuit yet. Its Q4 a 2n6429. What interesting about this transistor is its beta at 1 ma is 500 min and max is 1300. Its not a darlington. Thats pretty amazing. I am looking through my xsistors to find something close. May just through a 2n3904 in for a quick test. Its beta is nothing like the 6429. But it would help to prove/disprove the point that the low V may be offsetting the oscillator I hope. Will also embed a K thermal couple to verify the oven really is in the 80-84C region. Regards Paul. WB8TSL ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing 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.
