Real Time Interpolation/Resampling
in [DSP]
|
Prev: phase of FFT
Next: relationship between losslessness of an allpass and the l1 norm of the impulse response of the allpass
From: FatScouser on 20 Jan 2010 07:27 Hi, I have a motion control system comprising a realtime component and a non-realtime component. Simple 2D data (position/time) is being streamed from the non-realtime area into a FIFO queue in the realtime area. I have a few things that I'm hoping someone could help me with: The realtime component needs to keep running at all cost. Thus, when data is delayed, my buffer is in danger of running dry. There may be several options, and I'm unsure which one is best: 1. Ensure the buffer is N elements deep before I allow the realtime component to start popping off the queue. N is determined by trial-and-error testing and will be the number of cycles in an assumed maximum delay. E.g. by assuming the non-realtime component will never delay beyond 5 cycles, I can start the realtime component when the buffer reaches 5: it will then never run dry. 2. Add a second 'backup' buffer that holds predicted data (of fixed arbitrary size M) beyond the end of what's available in the first buffer. The realtime component will then switch to this backup if the first buffer runs dry; it will switch back as data becomes available. The backup buffer needs to dynamically update every cycle, e.g. as new real data comes in. 3. An alternative method? Is there a standard way for transferring data from non-realtime to realtime, ensuring realtime always has something to work on? Thanks in advance!
From: John on 20 Jan 2010 07:57 On Jan 20, 7:27 am, "FatScouser" <john.ha...(a)truebit.co.uk> wrote: > Hi, > > I have a motion control system comprising a realtime component and a > non-realtime component. Simple 2D data (position/time) is being streamed > from the non-realtime area into a FIFO queue in the realtime area. I have a > few things that I'm hoping someone could help me with: > > The realtime component needs to keep running at all cost. Thus, when data > is delayed, my buffer is in danger of running dry. > > There may be several options, and I'm unsure which one is best: > > 1. Ensure the buffer is N elements deep before I allow the realtime > component to start popping off the queue. N is determined by > trial-and-error testing and will be the number of cycles in an assumed > maximum delay. E.g. by assuming the non-realtime component will never delay > beyond 5 cycles, I can start the realtime component when the buffer reaches > 5: it will then never run dry. > > 2. Add a second 'backup' buffer that holds predicted data (of fixed > arbitrary size M) beyond the end of what's available in the first buffer. > The realtime component will then switch to this backup if the first buffer > runs dry; it will switch back as data becomes available. The backup buffer > needs to dynamically update every cycle, e.g. as new real data comes in. > > 3. An alternative method? > > Is there a standard way for transferring data from non-realtime to > realtime, ensuring realtime always has something to work on? > > Thanks in advance! To make sure the FIFO stays around the half-full mark, you could consider varying the rate at which it is filled as a function of how full it is. If it starts to get empty, fill it faster. If it starts to get full, fill it slower. This would be a crude phase locked loop. Search terms include "elastic store", "jitter buffer", "rate locked loop". John
From: FatScouser on 20 Jan 2010 08:54 >On Jan 20, 7:27=A0am, "FatScouser" <john.ha...(a)truebit.co.uk> wrote: >> Hi, >> >> I have a motion control system comprising a realtime component and a >> non-realtime component. Simple 2D data (position/time) is being streamed >> from the non-realtime area into a FIFO queue in the realtime area. I have= > a >> few things that I'm hoping someone could help me with: >> >> The realtime component needs to keep running at all cost. Thus, when data >> is delayed, my buffer is in danger of running dry. >> >> There may be several options, and I'm unsure which one is best: >> >> 1. Ensure the buffer is N elements deep before I allow the realtime >> component to start popping off the queue. N is determined by >> trial-and-error testing and will be the number of cycles in an assumed >> maximum delay. E.g. by assuming the non-realtime component will never del= >ay >> beyond 5 cycles, I can start the realtime component when the buffer reach= >es >> 5: it will then never run dry. >> >> 2. Add a second 'backup' buffer that holds predicted data (of fixed >> arbitrary size M) beyond the end of what's available in the first buffer. >> The realtime component will then switch to this backup if the first buffe= >r >> runs dry; it will switch back as data becomes available. The backup buffe= >r >> needs to dynamically update every cycle, e.g. as new real data comes in. >> >> 3. An alternative method? >> >> Is there a standard way for transferring data from non-realtime to >> realtime, ensuring realtime always has something to work on? >> >> Thanks in advance! > >To make sure the FIFO stays around the half-full mark, you could >consider varying the rate at which it is filled as a function of how >full it is. If it starts to get empty, fill it faster. If it starts to >get full, fill it slower. This would be a crude phase locked loop. >Search terms include "elastic store", "jitter buffer", "rate locked >loop". > >John > I see - thanks John.
From: Tim Wescott on 20 Jan 2010 11:40 On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote: > Hi, > > I have a motion control system comprising a realtime component and a > non-realtime component. Simple 2D data (position/time) is being streamed > from the non-realtime area into a FIFO queue in the realtime area. I > have a few things that I'm hoping someone could help me with: > > The realtime component needs to keep running at all cost. Thus, when > data is delayed, my buffer is in danger of running dry. > > There may be several options, and I'm unsure which one is best: > > 1. Ensure the buffer is N elements deep before I allow the realtime > component to start popping off the queue. N is determined by > trial-and-error testing and will be the number of cycles in an assumed > maximum delay. E.g. by assuming the non-realtime component will never > delay beyond 5 cycles, I can start the realtime component when the > buffer reaches 5: it will then never run dry. > > 2. Add a second 'backup' buffer that holds predicted data (of fixed > arbitrary size M) beyond the end of what's available in the first > buffer. The realtime component will then switch to this backup if the > first buffer runs dry; it will switch back as data becomes available. > The backup buffer needs to dynamically update every cycle, e.g. as new > real data comes in. > > 3. An alternative method? > > Is there a standard way for transferring data from non-realtime to > realtime, ensuring realtime always has something to work on? > > Thanks in advance! If a part of the system has a hard deadline (i.e. "so much data in so much time") then it is hard real time, whether or not you're calling it that. So solution 1 is out. Only you know if 2 will work. I have a suggestion that may do, depending on your problem. If your 2D trajectories can be broken down into segments that allows the mechanism to stop when they are done, then you can terminate each segment with a delimiter that basically says "it's OK to stop here". Then make sure that your buffer is big enough for the longest such segment, and never start such a segment until you've received the delimiter. Or go down path '1' and just keep making the buffer deeper and deeper, chasing a solution that never gets fully implemented but rather just makes the problem less and less likely to happen but always leaves it latent. -- www.wescottdesign.com
From: FatScouser on 20 Jan 2010 12:36
>On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote: > >> Hi, >> >> I have a motion control system comprising a realtime component and a >> non-realtime component. Simple 2D data (position/time) is being streamed >> from the non-realtime area into a FIFO queue in the realtime area. I >> have a few things that I'm hoping someone could help me with: >> >> The realtime component needs to keep running at all cost. Thus, when >> data is delayed, my buffer is in danger of running dry. >> >> There may be several options, and I'm unsure which one is best: >> >> 1. Ensure the buffer is N elements deep before I allow the realtime >> component to start popping off the queue. N is determined by >> trial-and-error testing and will be the number of cycles in an assumed >> maximum delay. E.g. by assuming the non-realtime component will never >> delay beyond 5 cycles, I can start the realtime component when the >> buffer reaches 5: it will then never run dry. >> >> 2. Add a second 'backup' buffer that holds predicted data (of fixed >> arbitrary size M) beyond the end of what's available in the first >> buffer. The realtime component will then switch to this backup if the >> first buffer runs dry; it will switch back as data becomes available. >> The backup buffer needs to dynamically update every cycle, e.g. as new >> real data comes in. >> >> 3. An alternative method? >> >> Is there a standard way for transferring data from non-realtime to >> realtime, ensuring realtime always has something to work on? >> >> Thanks in advance! > >If a part of the system has a hard deadline (i.e. "so much data in so >much time") then it is hard real time, whether or not you're calling it >that. > >So solution 1 is out. > >Only you know if 2 will work. > >I have a suggestion that may do, depending on your problem. If your 2D >trajectories can be broken down into segments that allows the mechanism >to stop when they are done, then you can terminate each segment with a >delimiter that basically says "it's OK to stop here". > >Then make sure that your buffer is big enough for the longest such >segment, and never start such a segment until you've received the >delimiter. > >Or go down path '1' and just keep making the buffer deeper and deeper, >chasing a solution that never gets fully implemented but rather just >makes the problem less and less likely to happen but always leaves it >latent. > >-- >www.wescottdesign.com > Thanks Tim - that all sounds good. Unfortunately I can't demand the thing to stop. I really need the crystal-ball type of extrapolator that no-one has invented yet! I wonder whether inserting a dynamic resampler is the way to go - that upsamples the input as the buffer dries up, and downsamples as it fills? |