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 > > On Thu, Jun 18, 2015 at 12:51 PM Richard Bell <[email protected]> > wrote: > >> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: ------ [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
