<!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="#000066">
Andrea Montefusco wrote:
<blockquote cite="mid:4A8FFEE3.2020808@montefusco.com" type="cite">
  <pre wrap="">One question for Alberto I2PHD: when you wrote the WindRad DLL for Perseus,
did you got the same problem ?
The problem seems to me very similar, because you are getting data at the FPGA rate
and send them to audio card.
  </pre>
</blockquote>
Ciao Andrea,<br>
<br>
  the DLL for Perseus wasn't written by me, but rather by Nico. But the
problem is a false one, as clearly<br>
explained by Kirk a few messages ago, at least when sending again back
the demodulated data to the<br>
FPGA.  I was puzzled by the fact the uneven arrival of the USB
interrupts (and they are uneven, as a <br>
matter of fact...) did not cause problems in the decoding of phase
sensitive data modes. <br>
And speaking on the phone with Nico, he confirmed that also when using
the Perseus hardware, <br>
with his FPGA code, that USB interrupts rate is uneven.<br>
<br>
But Kirk gave a clear insight on the issue, which I am now trying to
exemplify.<br>
Suppose you have to unload a truck, process the packs that are unloaded
(may stamping them..) then<br>
reload those packs on a different truck.<br>
<br>
The man that unloads the packs does that a very precise and constant
rate, and the packs are queued <br>
on the floor waiting for a clerk to stamp them. The clerk is an
unreliable guy, a bit lazy, that works in bursts,<br>
taking sometimes an moment of rest to drink a coffee. The packs, when
stamped, are again queued on<br>
the floor on the side of the truck that is being loaded. The man
loading that truck is again a very precise<br>
and accurate person, and loads the packs at a very constant and precise
rate.<br>
<br>
So, if the <u>average</u> speed of the stamping clerk is equal to that
of the two loading/unloading men, the two <br>
queues, that before and after the stamping, do not overflow nor
underflow, despite the jerkiness of the<br>
speed at which the clerk works.<br>
<br>
Hence, the most important thing, i.e. that the departing truck is
loaded at a constant rate, is fulfilled. <br>
<br>
Of course, in the above similitude, the stamping clerk is the
combination of the operating system (Windows <br>
or Linux), and the processing software (PowerSDR, Winrad, Linrad,
whatever). <br>
The rate of the USB interrupts is the rate at which the clerk takes the
packs from the incoming queue to<br>
stamp them. Any irregularity in this rate is of no consequences, as
long as the clerk is able to cope<br>
which the <u>average</u> speed of the two men on the trucks.<br>
<br>
Of course, all the above is true if the demodulated data are sent again
to the FPGA, which uses the same<br>
exact clock for input and for output.<br>
<br>
If instead the output goes to a sound card, which has its own sampling
clock, things become a little more<br>
complicated. A difference in the clocks is <u>unavoidable</u> and must
be taken into account. Some do drop<br>
samples or insert empty samples, but this causes clicks or bops.<br>
This is how I solved the problem in Winrad.<br>
<br>
The demodulated data are resampled to a constant rate (depending on the
mode), using a fractional resampler,<br>
based on sinc interpolation on a great enough number of points, so to
have resampling artifacts at a very low level.<br>
<br>
The outgoing data are queued in a FIFO queue, whose filling status is
continuously monitored by a routine that<br>
adjusts consequently the ratio of the fractional resampler, so to keep
the number of the 512-sample buffers queued<br>
at a set point of 6. That routine implements a simple form of a PID
controller, that reach stability after a short time.<br>
<br>
If you are interested, I released the source code of Winrad a few
months ago. Go to <a class="moz-txt-link-freetext" href="http://www.weaksignals.com">http://www.weaksignals.com</a><br>
<br>
BTW, I have the Winrad WinUSB DLL for HPSDR working, and I will release
it in a short time, after adding some <br>
final missing things.<br>
<br>
73  Alberto  I2PHD<br>
 <br>
</body>
</html>

 1250953560.0