I’m working on a system that has hardware defining an input rate and
hardware defining an output rate. This is a data based system, so I
can’t
afford to lose any bits, which implies sample rate changes have to be
exact.
For example, if data is being input at 2.4 ksps and the USRP outputs
data
at 468.168 ksps, unless my intermediate sample rate changes produce a
perfect mapping between the two rates, I can expect a buffer under or
overflow eventually, which would produce problems.
One solution to this problem, would be to use an arbitrary resampler
before
the USRP, that consists of a PLL dynamically changing the sample rate of
the arbitrary resampler based on how full it’s output buffer is. If the
buffer is above half full, decrease your sample rate, if the buffer is
below half full, increase your sample rate.
Now the question. I assume I’m not the first person that has needed to
do
something like this, is there a built in mechanism to handle this
problem
already or do I have to create the feedback loop structure myself? I’d
rather not re-invent the wheel.
We call this the “two clock problem”. This is something people
(including
myself) have been talking about implementing for ages. There’s nothing
available in GNURadio right now to do this.
When we put together a bit-regenerating repeater for 56kbit packet “back
in the day”, we had to design an elastic hardware buffer to “soak up”
slight differences in RX and TX clocks–the RX bit clock was from the
remote station, and TX bit-clock was ours. The elastic buffer worked OK
over the modest frame sizes we were using, but couldn’t soak up skew
indefinitely…
On 2015-06-18 15:53, Nick F. wrote:
For example, if data is being input at 2.4 ksps and the USRP outputs data at
468.168 ksps, unless my intermediate sample rate changes produce a perfect mapping
between the two rates, I can expect a buffer under or overflow eventually, which
would produce problems.