Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
On 5/16/09 10:00 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20090517031525.292e7b...@ip-64-139-1-69.sjc.megapath.net, Hal Murr ay writes: This is one of the reasons why I was looking for a low-cost FPGA on PCI board with some way to get a couple of external inputs. Things get interesting if your hardware splits a 64 bit read into 2 32 bit transfers. Many years ago, all Intel chips did that. I don't know about today. You don't need a 64bit counter in the first place. You might want a 64 bit counter, if you want to keep time across processor resets. In which case, if you're saddled with 32 bit (or 8 bit!) reads, you have to do multiple reads, so that by the end of the process, you can assure yourself it's consistent. E.g read high, read low, read high, read low So you can check low #1 against low #2, and figure out if you had a roll over. ___ 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] FreeBSD, NetBSD, or Minix-III?
In which case, if you're saddled with 32 bit (or 8 bit!) reads, you have to do multiple reads, so that by the end of the process, you can assure yourself it's consistent. E.g read high, read low, read high, read low So you can check low #1 against low #2, and figure out if you had a roll over. Why read the low twice? I though the normal recipe was to read high, low, high. If the two highs are the same you know a carry didn't happen so a high/low pair is a valid reading. -- These are my opinions, not necessarily my employer's. 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] FreeBSD, NetBSD, or Minix-III?
On 5/17/09 9:24 AM, Hal Murray hmur...@megapathdsl.net wrote: In which case, if you're saddled with 32 bit (or 8 bit!) reads, you have to do multiple reads, so that by the end of the process, you can assure yourself it's consistent. E.g read high, read low, read high, read low So you can check low #1 against low #2, and figure out if you had a roll over. Why read the low twice? I though the normal recipe was to read high, low, high. If the two highs are the same you know a carry didn't happen so a high/low pair is a valid reading. Yes, but then, if it did happen, then you need to read low again. If you do the 4 reads as a block (say, with interrupts disabled), then you get a nice deterministic timing for the code. In practice, it's just a design decision which way one does it. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
Lux, James P skrev: On 5/17/09 9:24 AM, Hal Murray hmur...@megapathdsl.net wrote: In which case, if you're saddled with 32 bit (or 8 bit!) reads, you have to do multiple reads, so that by the end of the process, you can assure yourself it's consistent. E.g read high, read low, read high, read low So you can check low #1 against low #2, and figure out if you had a roll over. Why read the low twice? I though the normal recipe was to read high, low, high. If the two highs are the same you know a carry didn't happen so a high/low pair is a valid reading. Yes, but then, if it did happen, then you need to read low again. If you do the 4 reads as a block (say, with interrupts disabled), then you get a nice deterministic timing for the code. In practice, it's just a design decision which way one does it. No, if the high parts differs, then the MSB of the lower part indicates which of the higher parts to go with it, MSB low is the late high read and MSB high is the early high read. Infact, by always look at the MSB then it will always be correct. With a second lower read will the low read point in time be modulated and hence jitter is added. 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] FreeBSD, NetBSD, or Minix-III?
Why not add a hardware latch with a fixed delay to read. That is the delay controls the latch function after the counter is static as well as the interrupt. Then reset the latch buffer on the last read. We have a fixed hardware delay plus a software delay to allow for but eliminate some of the variability. And reduce the failed read due to software delay. Now a second interrupt / read will indicate delays greater than the tick rate if our OS has interrupts that are off greater than the tick rate minus the delay of the latch. Our choice would be to slow the tick rate or reduce the interrupts off blind time if we have many failed reads where the tick is more than one. The idea would be to reduce the error to a rare event. This problem is like the meta stable problem discussed here before so perhaps the fixes are the same. Stanley - Original Message From: Lux, James P james.p@jpl.nasa.gov To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, May 17, 2009 9:19:50 AM Subject: Re: [time-nuts] FreeBSD, NetBSD, or Minix-III? On 5/16/09 10:00 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20090517031525.292e7b...@ip-64-139-1-69.sjc.megapath.net, Hal Murr ay writes: This is one of the reasons why I was looking for a low-cost FPGA on PCI board with some way to get a couple of external inputs. Things get interesting if your hardware splits a 64 bit read into 2 32 bit transfers. Many years ago, all Intel chips did that. I don't know about today. You don't need a 64bit counter in the first place. You might want a 64 bit counter, if you want to keep time across processor resets. In which case, if you're saddled with 32 bit (or 8 bit!) reads, you have to do multiple reads, so that by the end of the process, you can assure yourself it's consistent. E.g read high, read low, read high, read low So you can check low #1 against low #2, and figure out if you had a roll over. ___ 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] Help ID 5 MHz Distribution Box
After numerous diversions, I got back to the box and got it working. Just as an experiment I stuck 10 MHz in the Reference Input, nada. So, I need to find a divider to get 5 MHz. I got lots of 10 MHz signals, even a 15 MHz but no 5 MHz. I really don't want another project just to build a divider. I'll look around. As she stands, it is pretty stable. But it would be nice to lock it to a GPDSO. Thanks again for the help, 73, Dick, W1KSZ -Original Message- From: Ed Palmer ed_pal...@sasktel.net Sent: May 14, 2009 8:49 PM To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] Help ID 5 MHz Distribution Box Pinout is as follows - I think - remember that this is a work in progress 1 - no connection 2 - alarm output - High = alarm, low = normal (TTL) 3 - probably 'reference fail' - High = fail, low = normal (TTL) 4 - EFC okay - High if 4V8 EFC 7V5 else low (TTL) 5 - no connection 6 - buffered EFC voltage for oscillator 7 - no connection 8 - +10V reference output from oscillator - doesn't seem to be used for anything 9 - +5V supply (input) 10 - External EFC input - only used when reference fails 11 - ground 12 - 13 - 14 - +24V supply (input) for oscillator 15 - +15V supply (input) You talked about BNC. Did you mean TNC? My unit has TNC and SMA connectors. The SMA connectors are all outputs from the oscillator. J3 (TNC) is the input from an external 5 MHz reference. J4 (TNC) is another output from the oscillator. Approximate output levels are as follows: J2 - +7 dbm J4 - 0 dbm J5 - 0 dbm J6 - +7 dbm The purpose of the box is to discipline the internal oscillator to an external reference and then distribute the oscillator's signal to four outputs. The level of the external reference can vary over an unknown range because there's an internal AGC circuit. I haven't figured out the parameters of the low pass filter used on the output of the phase detector. Just for laughs I took the 10 MHz output of a Navsync CW-12 GPS board, divided it by 2, and fed it into the reference input. The result wasn't pretty. Obviously, the circuit wants a smoother source. On mine, the oscillator was defective. I had to hack into it to fix a broken wire on the output transformer. I started a message thread a few months back about how to hack into an oscillator - check the archive if you need to. Remember Engineering Rule #1 - Tune for minimum smoke! Ed Richard W. Solomon wrote: Was it that good a deal ?? I'll share my secret, I use Gixen to snipe on e-Pay. Sometimes it works, sometimes not. Do you know the connections for the DB-15 connector ? Then I can do the smoke test !! Also what are the BNC and SMA connectors for ? Basically, I know nothing but would appreciate any help. I will likewise share my findings. 73, Dick, W1KSZ -Original Message- From: Ed Palmer [1]ed_pal...@sasktel.net Sent: May 14, 2009 1:10 PM To: Discussion of precise time and frequency measurement [2]time-nuts@febo.com Subject: Re: [time-nuts] Help ID 5 MHz Distribution Box Since you beat me by *THREE SECONDS* I shouldn't help you, but I have one of these boxes and have partially figured it out. What do you want to know? Ed Richard W. Solomon wrote: I picked up a box from over there that says ...5 MH REF DISTRIB... , which I assume stands for 5 MHz Reference Distribution. It was made by Satellite Transmission Systems of Hauppagge, NY. 2 BNC connectors on one end, 3 SMA's a Red LED Alarm light and a DB-15 connector. A real long shot, I know, but on the off-chance, does anyone know anything about this ? Anyone know if the company still exists ? Thanks, Dick, W1KSZ ___ time-nuts mailing list -- [3]time-n...@febo.com To unsubscribe, go to [4]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- [5]time-n...@febo.com To unsubscribe, go to [6]https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. References 1. mailto:ed_pal...@sasktel.net 2. mailto:time-nuts@febo.com 3. mailto:time-nuts@febo.com 4. https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts 5. mailto:time-nuts@febo.com 6. https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts ___ 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] FreeBSD, NetBSD, or Minix-III?
Yes, but then, if it did happen, then you need to read low again. If you do the 4 reads as a block (say, with interrupts disabled), then you get a nice deterministic timing for the code. In practice, it's just a design decision which way one does it. Let's see if I understand your idea... If the two highs are the same, you know a carry didn't happen between reading the highs so the answer is high, first-low. That gives you an answer that corresponds to some time when you read the first low. If the two highs differ, you know a carry did happen but you don't know if the first low was before or after the carry. You know the second low was after the carry. So use the second high, second low. That gives you a time between the carry and reading the second low. I think that works without disabling interrupts. If we are doing this with a FPGA and have interrupts disabled or a kernel lock or only one user or .., it would be easy to latch the other half on the first read so you always got a coordinated pair with just two reads. No, if the high parts differs, then the MSB of the lower part indicates which of the higher parts to go with it, MSB low is the late high read and MSB high is the early high read. Infact, by always look at the MSB then it will always be correct. With a second lower read will the low read point in time be modulated and hence jitter is added. My head hurts, but I think I have convinced myself that will work. Thanks. If there is no carry, you get the time of reading the low half. If there is a carry... If the MSB of the low half is high, you get a time that is someplace between reading the first high half and reading the low. If the MSB of the low half is low, you get a time that is someplace between the carry and reading the second high. -- These are my opinions, not necessarily my employer's. 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] Help ID 5 MHz Distribution Box
So, the output levels looked good? Then you were luckier than me. I think I tried a fast and dirty divider off of a 10 MHz signal and it worked very nicely. I wasn't trying for 'time-nuts' quality, just confirming basic functionality. I used a 'scope in X-Y mode to view both signals. It's nice to see a Lissajous figure that doesn't make you dizzy. :-) Do you have a mixer kicking around? Mix a 10 MHz and 15 MHz signal and dump the results into the ref input. I don't know if the output will be at a high enough level, but it can't hurt! Ed Richard W. Solomon wrote: After numerous diversions, I got back to the box and got it working. Just as an experiment I stuck 10 MHz in the Reference Input, nada. So, I need to find a divider to get 5 MHz. I got lots of 10 MHz signals, even a 15 MHz but no 5 MHz. I really don't want another project just to build a divider. I'll look around. As she stands, it is pretty stable. But it would be nice to lock it to a GPDSO. Thanks again for the help, 73, Dick, W1KSZ -Original Message- From: Ed Palmer [1]ed_pal...@sasktel.net Sent: May 14, 2009 8:49 PM To: Discussion of precise time and frequency measurement [2]time-nuts@febo.com Subject: Re: [time-nuts] Help ID 5 MHz Distribution Box Pinout is as follows - I think - remember that this is a work in progress 1 - no connection 2 - alarm output - High = alarm, low = normal (TTL) 3 - probably 'reference fail' - High = fail, low = normal (TTL) 4 - EFC okay - High if 4V8 EFC 7V5 else low (TTL) 5 - no connection 6 - buffered EFC voltage for oscillator 7 - no connection 8 - +10V reference output from oscillator - doesn't seem to be used for anything 9 - +5V supply (input) 10 - External EFC input - only used when reference fails 11 - ground 12 - 13 - 14 - +24V supply (input) for oscillator 15 - +15V supply (input) You talked about BNC. Did you mean TNC? My unit has TNC and SMA connectors. The SMA connectors are all outputs from the oscillator. J3 (TNC) is the input from an external 5 MHz reference. J4 (TNC) is another output from the oscillator. Approximate output levels are as follows: J2 - +7 dbm J4 - 0 dbm J5 - 0 dbm J6 - +7 dbm The purpose of the box is to discipline the internal oscillator to an external reference and then distribute the oscillator's signal to four outputs. The level of the external reference can vary over an unknown range because there's an internal AGC circuit. I haven't figured out the parameters of the low pass filter used on the output of the phase detector. Just for laughs I took the 10 MHz output of a Navsync CW-12 GPS board, divided it by 2, and fed it into the reference input. The result wasn't pretty. Obviously, the circuit wants a smoother source. On mine, the oscillator was defective. I had to hack into it to fix a broken wire on the output transformer. I started a message thread a few months back about how to hack into an oscillator - check the archive if you need to. Remember Engineering Rule #1 - Tune for minimum smoke! Ed Richard W. Solomon wrote: Was it that good a deal ?? I'll share my secret, I use Gixen to snipe on e-Pay. Sometimes it works, sometimes not. Do you know the connections for the DB-15 connector ? Then I can do the smoke test !! Also what are the BNC and SMA connectors for ? Basically, I know nothing but would appreciate any help. I will likewise share my findings. 73, Dick, W1KSZ -Original Message- From: Ed Palmer [1][3]ed_pal...@sasktel.net Sent: May 14, 2009 1:10 PM To: Discussion of precise time and frequency measurement [2][4]time-n...@febo.c om Subject: Re: [time-nuts] Help ID 5 MHz Distribution Box Since you beat me by *THREE SECONDS* I shouldn't help you, but I have one of these boxes and have partially figured it out. What do you want to know? Ed Richard W. Solomon wrote: I picked up a box from over there that says ...5 MH REF DISTRIB... , which I assume stands for 5 MHz Reference Distribution. It was made by Satellite Transmission Systems of Hauppagge, NY. 2 BNC connectors on one end, 3 SMA's a Red LED Alarm light and a DB-15 connector. A real long shot, I know, but on the off-chance, does anyone know anything about this ? Anyone know if the company still exists ? Thanks, Dick, W1KSZ ___ time-nuts mailing list -- [[5]3]time-n...@febo.com To unsubscribe, go to [4][6]https://www.febo.com/cgi-bin/mailman/listinfo/time-n uts and follow the instructions there. ___ time-nuts mailing list -- [[7]5]time-n...@febo.com To unsubscribe, go to [6][8]https://www.febo.com/cgi-bin/mailman/listinfo/time-n uts and follow the instructions there. References 1. [9]mailto:ed_pal...@sasktel.net 2. [10]mailto:time-nuts@febo.com 3. [11]mailto:time-nuts@febo.com 4.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
Hal Murray skrev: Yes, but then, if it did happen, then you need to read low again. If you do the 4 reads as a block (say, with interrupts disabled), then you get a nice deterministic timing for the code. In practice, it's just a design decision which way one does it. Let's see if I understand your idea... If the two highs are the same, you know a carry didn't happen between reading the highs so the answer is high, first-low. That gives you an answer that corresponds to some time when you read the first low. If the two highs differ, you know a carry did happen but you don't know if the first low was before or after the carry. You know the second low was after the carry. So use the second high, second low. That gives you a time between the carry and reading the second low. I think that works without disabling interrupts. If we are doing this with a FPGA and have interrupts disabled or a kernel lock or only one user or .., it would be easy to latch the other half on the first read so you always got a coordinated pair with just two reads. No, if the high parts differs, then the MSB of the lower part indicates which of the higher parts to go with it, MSB low is the late high read and MSB high is the early high read. Infact, by always look at the MSB then it will always be correct. With a second lower read will the low read point in time be modulated and hence jitter is added. My head hurts, but I think I have convinced myself that will work. Thanks. It can be a bit hard to visualize this... yes. Hopefully it is worth it. If there is no carry, you get the time of reading the low half. If there is a carry... If the MSB of the low half is high, you get a time that is someplace between reading the first high half and reading the low. If the MSB of the low half is low, you get a time that is someplace between the carry and reading the second high. You also need to understand the basic most common case that no carry occur between the two high readings, in that case those will be the same so we can use either of them to form the result. If a carry occurs between the two high readings, then we can expect the low reading to be close to 0 on either side of the wrapping. Which side determines which holds the right value. If the wrapping of counter happend before reading the low part, then the low part will be just above 0 where as if it happends just after the low read but before the high read, the low read will be just below the maximum counter value. Thus, the MSB of the low value will disclose which of the two cases we have. We can now identify that the first high read would match the case where the wrapping occurs after the low read, they both are taken on the same side of the wrapping. The second high read would match the case where the wrapping occurs before the low read, they both are taken on the same side of the wrapping. If we have a continous counter of high speed, taking a second low value would actually polute the result, as it was taken at a later time. Such a 4 read solution would add a delay for the low value whenever the carry occurs between the high reads. Using the 3 read solution avoids that as the low count is samples once and at the same time for all instances. 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] FreeBSD, NetBSD, or Minix-III?
If a carry occurs between the two high readings, then we can expect the low reading to be close to 0 on either side of the wrapping. Which side determines which holds the right value. If the wrapping of counter happend before reading the low part, then the low part will be just above 0 where as if it happends just after the low read but before the high read, the low read will be just below the maximum counter value. I'm interested in the case where interrupts and scheduling are enabled so there may be arbitrary gaps inserted into the simple code. My rule-of-thumb for works right is that the final answer has to correspond to a time between the first read and the last read. (Anywhere in there is OK.) I though I had convinced myself the above scheme would work, but now that I try again I'm not so sure. I think this case doesn't work right: read high overflow long gap read low read high Suppose the low half overflows once a second so I can use handy numbers. If the long gap is 0.6 second, the MSB of the low half will be on so we use the first high sample. That corresponds to a time 0.4 seconds before the overflow. That's outside the first-last window. (I'm assuming all the reads and checking take negligible time which seems reasonable if we are talking about 0.6 seconds of gap.) I think there is a mirror image case: read high read low long gap overflow read high Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB will be off so we use the second high sample. That will produce an answer 0.4 seconds into the future. -- These are my opinions, not necessarily my employer's. 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] FreeBSD, NetBSD, or Minix-III?
In message: 20090517233218.01d11b...@ip-64-139-1-69.sjc.megapath.net Hal Murray hmur...@megapathdsl.net writes: : : If a carry occurs between the two high readings, then we can expect : the low reading to be close to 0 on either side of the wrapping. : Which side determines which holds the right value. If the wrapping of : counter happend before reading the low part, then the low part will : be just above 0 where as if it happends just after the low read but : before the high read, the low read will be just below the maximum : counter value. : : I'm interested in the case where interrupts and scheduling are enabled so : there may be arbitrary gaps inserted into the simple code. Interrupts enabled means that you can't make it reliable. : I think this case doesn't work right: : read high : overflow : long gap : read low : read high : : Suppose the low half overflows once a second so I can use handy numbers. : : If the long gap is 0.6 second, the MSB of the low half will be on so we use : the first high sample. That corresponds to a time 0.4 seconds before the : overflow. That's outside the first-last window. (I'm assuming all the reads : and checking take negligible time which seems reasonable if we are talking : about 0.6 seconds of gap.) : : I think there is a mirror image case: : read high : read low : long gap : overflow : read high : : Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB : will be off so we use the second high sample. That will produce an answer : 0.4 seconds into the future. Yes, this is why you must disable interrupts. You aren't racing other parts of software, but rather you are racing the wrapping of the counter in hardware. To reliably cope, you have to make sure that a third-party can't interrupt you producing the cases you describe... Warner ___ 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] Help ID 5 MHz Distribution Box
Ed A simple 3 transistor (2N3904) injection locked divider could be used to produce +20dBm @ 5MHz in a 50 ohm load. The 3 transistors combine the VCO, phase detector and filter functions. With high level injection the loop bandwidth is very high and the 5MHz output phase noise will closely track the input signal phase noise albeit a few dB below the input source phase noise. An emitter coupled differential pair oscillator with 10MHz modulation of the tail current source should work well. This technique can be used effectively at frequencies for which no digital divider is available. It is important to choose an appropriate oscillator topology. The above oscillator topology works well for frequency division by an even integer. Dividing by an odd integer requires a different oscillator topology Bruce Ed Palmer wrote: So, the output levels looked good? Then you were luckier than me. I think I tried a fast and dirty divider off of a 10 MHz signal and it worked very nicely. I wasn't trying for 'time-nuts' quality, just confirming basic functionality. I used a 'scope in X-Y mode to view both signals. It's nice to see a Lissajous figure that doesn't make you dizzy. :-) Do you have a mixer kicking around? Mix a 10 MHz and 15 MHz signal and dump the results into the ref input. I don't know if the output will be at a high enough level, but it can't hurt! Ed Richard W. Solomon wrote: After numerous diversions, I got back to the box and got it working. Just as an experiment I stuck 10 MHz in the Reference Input, nada. So, I need to find a divider to get 5 MHz. I got lots of 10 MHz signals, even a 15 MHz but no 5 MHz. I really don't want another project just to build a divider. I'll look around. As she stands, it is pretty stable. But it would be nice to lock it to a GPDSO. Thanks again for the help, 73, Dick, W1KSZ -Original Message- From: Ed Palmer [1]ed_pal...@sasktel.net Sent: May 14, 2009 8:49 PM To: Discussion of precise time and frequency measurement [2]time-nuts@febo.com Subject: Re: [time-nuts] Help ID 5 MHz Distribution Box Pinout is as follows - I think - remember that this is a work in progress 1 - no connection 2 - alarm output - High = alarm, low = normal (TTL) 3 - probably 'reference fail' - High = fail, low = normal (TTL) 4 - EFC okay - High if 4V8 EFC 7V5 else low (TTL) 5 - no connection 6 - buffered EFC voltage for oscillator 7 - no connection 8 - +10V reference output from oscillator - doesn't seem to be used for anything 9 - +5V supply (input) 10 - External EFC input - only used when reference fails 11 - ground 12 - 13 - 14 - +24V supply (input) for oscillator 15 - +15V supply (input) You talked about BNC. Did you mean TNC? My unit has TNC and SMA connectors. The SMA connectors are all outputs from the oscillator. J3 (TNC) is the input from an external 5 MHz reference. J4 (TNC) is another output from the oscillator. Approximate output levels are as follows: J2 - +7 dbm J4 - 0 dbm J5 - 0 dbm J6 - +7 dbm The purpose of the box is to discipline the internal oscillator to an external reference and then distribute the oscillator's signal to four outputs. The level of the external reference can vary over an unknown range because there's an internal AGC circuit. I haven't figured out the parameters of the low pass filter used on the output of the phase detector. Just for laughs I took the 10 MHz output of a Navsync CW-12 GPS board, divided it by 2, and fed it into the reference input. The result wasn't pretty. Obviously, the circuit wants a smoother source. On mine, the oscillator was defective. I had to hack into it to fix a broken wire on the output transformer. I started a message thread a few months back about how to hack into an oscillator - check the archive if you need to. Remember Engineering Rule #1 - Tune for minimum smoke! Ed Richard W. Solomon wrote: Was it that good a deal ?? I'll share my secret, I use Gixen to snipe on e-Pay. Sometimes it works, sometimes not. Do you know the connections for the DB-15 connector ? Then I can do the smoke test !! Also what are the BNC and SMA connectors for ? Basically, I know nothing but would appreciate any help. I will likewise share my findings. 73, Dick, W1KSZ -Original Message- From: Ed Palmer [1][3]ed_pal...@sasktel.net Sent: May 14, 2009 1:10 PM To: Discussion of precise time and frequency measurement [2][4]time-n...@febo.c om Subject: Re: [time-nuts] Help ID 5 MHz Distribution Box Since you beat me by *THREE SECONDS* I shouldn't help you, but I have one of these boxes and have partially figured it out. What do you want to know? Ed Richard W. Solomon wrote: I picked up a box from over there that says ...5 MH REF DISTRIB... , which I assume stands for 5 MHz Reference
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
I'm interested in the case where interrupts and scheduling are enabled so there may be arbitrary gaps inserted into the simple code. Interrupts enabled means that you can't make it reliable. Sure you can. Just compare the two high samples and try again if they are different. This disadvantage is that you get more jitter on how long it takes to get the answer. That may be better than taking the overhead of a system call to get into the kernel. -- These are my opinions, not necessarily my employer's. 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] Msg to N.Z. time nuts
I am assuming my GPS clocks I have are correct (too early here to get WWVH reception). Hoping the one second delta is not me! I have seen consumer grade GPS receivers be off by a second while claiming to be OK. One case was a gross software bug. I think it was triggered by a pending leap second. http://www.megapathdsl.net/~hmurray/ntp/leap-gps.gif One was off by a second for 13 seconds just before the leap second kicked in. I assume they inserted it on GPS midnight rather than UTC midnight. The interesting cases are just off-by-a-second quirks. I think they happen when the receiver is recovering from a too-weak signal. http://www.megapathdsl.net/~hmurray/ntp/GPS18LVC-glitch1-off.gif http://www.megapathdsl.net/~hmurray/ntp/GPS18LVC-glitch2-off.gif -- These are my opinions, not necessarily my employer's. 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] FreeBSD, NetBSD, or Minix-III?
do {
t32a = read.high
t32b = read.low
t32c = read.high
} while (t32a != t32c)
time64 = (t32a 32) | t32b
/tvb
___
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] FreeBSD, NetBSD, or Minix-III?
Why not add a hardware latch with a fixed delay to read. That is the delay controls the latch function after the counter is static as well as the interrupt. Then reset the latch buffer on the last read. We have a fixed hardware delay plus a software delay to allow for but eliminate some of the variability. And reduce the failed read due to software delay. Now a second interrupt / read will indicate delays greater than the tick rate if our OS has interrupts that are off greater than the tick rate minus the delay of the latch. Our choice would be to slow the tick rate or reduce the interrupts off blind time if we have many failed reads where the tick is more than one. The idea would be to reduce the error to a rare event. This problem is like the meta stable problem discussed here before so perhaps the fixes are the same. I don't understand what you are trying to describe. There are two separate problems. One is reading 64 bits. The other is metastability. Metastability is simple. Lets assume we have 2 clocks. The PCI clock is 33 MHz. The external good-timing clock is 10 MHz. Since 10 is slower than 33, the simple way to do things is to toggle a FF with the 10 MHz clock and send that through a synchronizer to the 33 MHz domain. Each time that FF changes, we know a tick has happened so we bump the counter by 1 clock tick at 10 MHz. That's just a clock enable on the register adding 100 (ns) to itself. (assuming the register counts ns) This is simple and clean. The disadvantage is that the clock has slightly lower resolution than what might be posible. The other way is do the counting with the 10 MHz clock, perhaps after PLLing it up to 100 MHz. Now, to read the clock, you send a signal from the PCI domain through a synchronizer to the external clock domain. That copies the counter to a holding register, sends a ready signal back through a synchronizer to the PCI domain so the PCI logic which has been stalled can read the stable copy. This is classic 4-way handshake. You can speed things up by knowing (by design) that X will happen within Y clock cycles, so you only have to count to Y rather than wait for the ACK to get ack. Another approach is to use a small FIFO. In this context, FIFO means magic that solves metastability, and small means as small as you can get away with to minimize latency. Again, lets assume the PCI clock is 33 MHz and the external clock is 10 MHz PLLed up to 100 MHz. The PCI would read samples from the FIFO and add them to its counter. The external side would write samples into the FIFO. Each sample would represent the number of ns to add to the counter. Since 100 is bigger than 33, the FIFO will normally be full. So the send side can't write a constant 10 each cycle. It has to collect those 10s in a register. When the FIFO has room, it writes that register into the FIFO and resets it to the 10 for this cycle. With 33 MHz and 100 MHz, the FIFO would contain samples of 30 and 40. I think there is a simple/sneaky way to build that FIFO. It needs 2 or 4 registers. I don't remember the trick. I might be able to work it out. The other problem is how to read a 64 bit register when the hardware only supports reading 32 bit chunks. I think you either have to: fFx the hardware (or get new hardware) so it can do 64 bit atomic reads. Read the halves separately and put things together with the tricks we have been discussing. That only works if you know something about the data, for example that the whole register is a counter and the high bits only change slowly. Read one half and put the other half into a holding register where you can read it later. If you only have 1 holding register, then you have to restrict things to only 1 context is doing the reads at a time. Otherwise somebody else will come along during an interrupt or reschedule and read things. Then when you get to run again you read their copy of the holding register rather than yours. You can have multiple holding registers, but then you have to allocate 1 to each context that needs it. I don't see how a hardware latch with a fixed delay is going to help and/or what you have in mind. Perhaps you wanted to have the right value of other half ready when the second read happened? The problem with that is that the timing on PCI isn't predictable so a fixed delay won't work. So you need a holding register triggered by logic rather than a fixed delay. -- These are my opinions, not necessarily my employer's. 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.
