<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Alberto I2PHD wrote:
<blockquote cite="mid:4A8A83EC.6050802@weaksignals.com" type="cite">Hi
Phil and Dave,<br>
<br>
thanks for the answers. But there is still something that puzzles me.<br>
I am quite familiar with FIFO and Ring buffers, I use them extensively
both in Winrad<br>
and in the new code to interface the HPSDR HW.<br>
<br>
But you need a timing to start a new signal processing cycle on the
PC... when data are coming <br>
from a sound card, that timing is given by the card interrupts, that
happen at a regular<br>
rate, given by the sampling frequency.<br>
<br>
In the case of HPSDR, the only timing available is given by the arrival
of a new USB buffer,<br>
FIFO and Ring buffers can compensate for delays in obtaining CPU cycles
from the <br>
Windows scheduler, but cannot correct the timing.<br>
</blockquote>
<font color="#990000">The key is the PC has to check for new data ready
from the USB chip on Ozy faster than I send it into the USB chip on Ozy
from the FPGA. As long as this occurs, it doesn't matter. The timing
in the FPGA is precise and each sample the PC gets was obtain with an
exact timing. Similarly, as long as the PC supplies data to the USB
chip faster than I remove it, then all is well too as I send it to the
sound chip with exact timing. The 63 or N sample thing is irrelevant
since its just a transfer size.</font><br>
<blockquote cite="mid:4A8A83EC.6050802@weaksignals.com" type="cite"><br>
And the inherent timing of the HPSDR HW is that of providing 63
samples. Suppose you want<br>
to start a processing cycle that process a 512-sample buffer. How can
you obtain the right<br>
trigger to start it from the HPSDR timing ? 63 has no powers of two in
its prime decomposition,<br>
being it 3 * 3 * 7. So to have a timing without jitter you would need
to fill a buffer of 63 * 512 samples,<br>
and only when it is full you could start a processing cycle being
certain of having no jitter.<br>
</blockquote>
<font color="#990000">Data sampling in the FPGA is continuous and the
timing exact. Since each data sample is obtain precisely, the PC knows
that each data sample, whether it all be in the same packet or
different packets is precisely a given amount of time apart. Assume
each data sample in the FPGA is T seconds apart. So the last data in
the "63" samples is precisely T seconds from the 1st data in the next
packet even though they may be taken from the USB chip on Ozy with some
other timing. So as long as the PC keeps the FIFOs happy, it can take
data from N packets and process them knowing there is no time
difference between each sample.</font><br>
<blockquote cite="mid:4A8A83EC.6050802@weaksignals.com" type="cite"><br>
But that size is way too large, it would introduce unacceptable latency.<br>
If you do a close inspection at the process, you see that initially, to
fill a 512 sample buffer, you need<br>
9 buffers of 63 samples, and you remain with (63 - 8) = 55 samples as
'reservoir'.<br>
So for the second 512 sample buffer you need now only 8 buffers of 63
samples, using 8 samples<br>
taken from the 'reservoir'. And so on for some cycles. But then, when
the 'reservoir' is empty,<br>
you need again 9 buffers of 63 samples....<br>
<br>
So the rate of preparation of the 512 sample buffers, which ultimately
is the rate that determines <br>
the timing of the signal processing cycle on the PC, is slightly
uneven, with some jitter. It alternates<br>
between 9 and 8 USB-interrupts (not the right word, but you understand
what I mean).<br>
And frankly I cannot understand how this jitter can be eliminated with
the use of FIFO and/or Ring buffers...<br>
<br>
</blockquote>
<font color="#990000">Yes, all processing on the PC has a lot of
"jitter" as far as how it gets the data processed, but that doesn't
matter. The amount of time (assuming its faster than the data needs of
the USB chip/FPGAs on Ozy) and method (5 interrupts or 50 interrupts)
on the PC doesnt matter, just as long as you keep the bucket with the
hole in the bottom filled so it doesn't empty or overflow. Its how the
data was obtained in the FPGA that matters so that things like FFT's,
etc. can be done with precision on the PC. The PC's job is "merely"
(I say this with utmost respect since it does a ton of processing), is
to get the data at any speed/sample size it likes, process it, and send
data back at the rate required to keep the FPGA FIFOs happy. Hopefully
I've made this as clear as mud....<span class="moz-smiley-s1"><span>
:-) </span></span>OK..fire at me at random...<br>
<br>
Kirk KD7IRS<br>
</font>
<blockquote cite="mid:4A8A83EC.6050802@weaksignals.com" type="cite">As
said in my previous message, there are absolutely no consequences on
voice/music or CW<br>
signals. My fear is that those few data modes that require phase
coherence can be affected...<br>
<br>
Sorry if I make you spending some time reading this...<br>
<br>
73 Alberto I2PHD<br>
<br>
</blockquote>
</body>
</html>
1250609251.0