|
It's not unique to modern DSP systems, either.
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 Foster wrote:
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.
--n
Hi all,
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.
v/r,
Rich
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|