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.
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
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
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,
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
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.
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...
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
