In article <umtLa.7874$iM4.1091810@news20.bellglobal.com>, Matt Timmermans <mt0000@sympatico.nospam-remove.ca> wrote:> "Emil Tin" <eti@homebase.dk> wrote in message > news:280620032145247959%eti@homebase.dk... > > > > yes, that would surely work! > > > > however, i'm wondering if there's a way of doing it, that would not > > require time-of-next-pulse to be stored and manipulated for each pulse > > train? > > Why? > >saving procesor cycles. if i want to generate 100 or even 1000 sligtly detuned pulsetrains in real time it makes difference.
Calculating time intervals in multiple pulsetrains?
Started by ●June 27, 2003
Reply by ●June 29, 20032003-06-29
Reply by ●June 29, 20032003-06-29
Emil Tin wrote:> > i'm thinking about simple pulse trains of pulses with amplitude 1 > occuring at fixed intervals (the frequency of the pulse train). > they will not have any duty cycle (pulse width=0) - really its just the > start times of pulses i'm interested in calculating efficiently. > > by saying thay all start with phase=0 at time=0 i mean all pulse trains > emit a pulse at time 0. > > i would typically use less than 100 pulsetrains. > > so we have a series of pulses spaced in time, and im interested in the > time between an event and the next event (a delta time value). the > absolute start times would work as well, but my guess is it would be > easier to work with delta times values. > > as an example, look at two pulsetrains with freq 1.0 and 0.9. > pulses would occur at times: > 0.0 (two pulses at the same time) > 0.9 > 1.0 > 1.8 > 2.0 > 2.7 > 3.0 .... and so on > > So therefore, the delta time between pulses would be: > > 0.0 (the first two pulses occur at the same time) > 0.9 > 0.1 > 0.8 > 0.2 > 0.7 > 0.3 > 0.6 > 0.4 ... and so on... > > clearly there is a simple pattern that can be generated > algorithmically. however for more complex examples, i'm not sure how to > do it, but feel there should be a way? for example by cycling thru the > list of frequencies and using these to calculate the next delta time. > > i hope this makes it clearer. i wish a had a clear mathematical way of > expressing what i want to do, but i'm afraid i don't... > > thanks in advance, > emil > > In article <3EFC93F0.FD131757@ieee.org>, Jerry Avins <jya@ieee.org> > wrote: > > > Emil Tin wrote: > > > > > > Suppose we have several periodic pulsetrains, each with a different but > > > fixed frequency. Assume they all start with phase=0 at time=0. > > > > > > If we combine all pulse trains into a single signal, would there be an > > > efficient way to compute time interval between pulses, without keeping > > > track of phases of all individual pulsetrains? > > > The algorithm would not require the phase of each individual pusletrain > > > to be stored, but instead simply store frequencies, and produce a > > > series of intervals. (Perhaps using only a couple of counters.) > > > > > > Any ideas? > > > > > > Thanks, > > > Emil > > > > You need to define what you mean by phase in this context, and it would > > help if you provided a clearer description of what you expect to see. > > > > How many pulse trains do you contemplate? > > > > What are their duty cycles? > > > > At any instant, do you have the sum of the pulses, or does the amplitude > > saturate? > > > > JerryIs there a rule requiring the pulse trains to have commensurable periods? If one period is e; that is, exp(1), and another 3, with fine enough time resolution you can tell time from here to eternity. It's slightly easier if the amplitudes are somewhat different, but you don't need that for disambiguation if you can look at more than two pulses. More pulse trains complicate the issue, but not fatally. Of course, the real world imposes additional constraints, but you need to determine what resolution you can achieve and how well you can control the repetition rates before you can assess those. Is this question for real? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●June 30, 20032003-06-30
"Emil Tin" <eti@homebase.dk> wrote in message news:290620031406299363%eti@homebase.dk...> saving procesor cycles. > if i want to generate 100 or even 1000 sligtly detuned pulsetrains in > real time it makes difference.For N pulse trains, the priority queue method requires O(log N) work per pulse. That's fast.
