Alright thanks for the feedback. It sounds like I have some work to do. v/r, Rich
On Thu, Jun 18, 2015 at 1:01 PM, <[email protected]> wrote: > 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 > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
