Discrete-time systems

Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.removethis.de> wrote:
> On 2012-11-02 21:48, gyansorova@gmail.com wrote:

>> suppose we have a digital control system, can the model of 
>> the system respond instantaneously? A computer surely must 
>> have a delay of one step as I pass data from input to output 
>> (unlike analogue). So you have a digital filter
>> which is say b0+b1z^-1+b2z^-2+... but when you IMPLEMENT 
>> it an extra delay must be there surely to get from input 
>> to output? No this doesn't matter for digital filters, 
>> who cares, but for controllers an extra delay is important - 
 
> What makes you think analogue system do not have delay?

I remember learning this a long time before I knew so much
else about filter circuits. My dad bought a color TV when
I was about 10, and bought me a book about how they work.

One that I remember not understanding is that there is
a delay line in the video circuit. Not so long, but long
enough. 

If you believe that analog filters don't have delay, then you
would not find an explanation for this. 

There are two important filters in the video circuitry
of an NTSC TV receiver. One in the luminance path, to
filter the bandwidth to about 4MHz, and another in the
crominance (color) signal to about 1MHz, maybe a little
less. The difference means that the chrominance signal
is delayed relative to the luminance signal. That is
fundamental to the analog filters involved, just as
delay is fundamental to digital filters. If you ignore
it, the color doesn't match up with the luminance
(intensity) signal, visible in the picture.
 
> First of all, there is an upper limit, which is the speed
> of "electrons" in circuit (far below the speed of light).
> Second, you can always have a combination of analogue
> components (LRC) causing a delay.

And you can't do much about that.
 
> In the end, analogue delay lines do exist.

In an undergrad physics lab, we were measuring the
properties of coax cables. The experiment was a little
to teach about the physics, and more to teach about data
analysis, but it is applicable here.

We had some spools of cable, with both ends available 
to determine the impedance, attenuation, and propagation
velocity. To do that, you send pulses down the cable with
a series resistor, such that you can see the reflection
coming back. Then adjust a resistor at the far end to match
the impedance. Measure the ampliude at both ends, to get the
attenuation, and the time between the pulse in and the reflection
(when not impedance matched) for the delay. The length was
given.

It isn't so hard to show that the velocity for a signal
down a coax cable depends on the capacitance and inductance
per unit length, and to show that for an ordinary coax that
the velocity is c divided by the square root of the dielectric
constant, the latter being better known as the index of
refraction. (Assuming non-magnetic wire.)

We had one cable, though, that is designed for delay lines.
The center conductor is helical instead of just a wire,
which increases its inductance (per unit length). The 
increased inductance results in a slower propagation speed.

However, if instead of computing the inductance you just 
figure out how much longer the wire is, due to its
helical shape, you get about the same delay!

-- glen

On 2012-11-03 20:14, glen herrmannsfeldt wrote:
[...]
> In an undergrad physics lab, we were measuring the
> properties of coax cables. The experiment was a little
> to teach about the physics, and more to teach about data
> analysis, but it is applicable here.
[...]

Actually, this reminds me something.

If I correctly recall, during World War II, someone was
designing FIR filters, using cables of a certain length
as delay elements and capacitors as "coefficients".

It was a fully analogue FIR filter, not switched capacitors,
just delayed capacitors... :-)

bye,

-- 

piergiorgio

On 2012-11-03 17:13, mnentwig wrote:
[...]
> Implement a single filter, then cascade 100 of them.
> If I write the Verilog code, the resulting _system_ will have a latency of
> _one sample_ (because I use one single register at the output to
> synchronize the otherwise combinatorial path to the output clock.).
[...]

And if you use asynchronous logic, you'll not have
even that one! :-)

> Now if anybody insists that implementing _the filter_ needs a delay (that
> is, each of them!), you'd come out with a delay of 100 samples.

Probably it does not *need* a delay, but if we define
"delay" as the time a change at the input shows up at
the output, then you'll have always a delay...

bye,

-- 

piergiorgio

On Sunday, November 4, 2012 9:46:48 AM UTC+13, Piergiorgio Sartor wrote:
> On 2012-11-03 17:13, mnentwig wrote:
> 
> [...]
> 
> > Implement a single filter, then cascade 100 of them.
> 
> > If I write the Verilog code, the resulting _system_ will have a latency of
> 
> > _one sample_ (because I use one single register at the output to
> 
> > synchronize the otherwise combinatorial path to the output clock.).
> 
> [...]
> 
> 
> 
> And if you use asynchronous logic, you'll not have
> 
> even that one! :-)
> 
> 
> 
> > Now if anybody insists that implementing _the filter_ needs a delay (that
> 
> > is, each of them!), you'd come out with a delay of 100 samples.
> 
> 
> 
> Probably it does not *need* a delay, but if we define
> 
> "delay" as the time a change at the input shows up at
> 
> the output, then you'll have always a delay...
> 
> 
That makes sense. For a controller a time-delay in a feedback loop
even of one step is important since it reduces phase margin. Yes you can increase sampling frequency I suppose and that's why we sample 10 times the bandwidth.

On 11/2/12 5:30 PM, Vladimir Vassilevsky wrote:
> <gyansorova@gmail.com>  wrote:
>
>> Yes I know you'll find it in textbooks, but you know about them they are
>> all either elementary, irrelevant or wrong.
>
> Can't read books. Too many letters.

oh c'mon Vlad.  how many *real* college textbooks on DSP get into this 
kind of detail of the practice.  i dunno even if Rick does and his book 
*is* pretty damn focused on the practical.  it's often so implementation 
specific and not very elegant mathematically.  and if the textbook 
*does* get into it with specific devices, it's outa date in a couple years.

>
>> suppose we have a digital control system, can the model of the system
>> respond instantaneously? A computer surely must have a>delay of one step
>> as I pass data from input to output (unlike analogue). So you have a
>> digital filter
>> which is say b0+b1z^-1+b2z^-2+... but when you IMPLEMENT it an extra delay
>> must be there surely to get from input to output?>  No this doesn't matter
>> for digital filters, who cares, but for controllers an extra delay is
>> important -
>
> Sample the input, do some calculation and output the result in femtosecond
> from input. No relevance to sample rate here.

this is implementation specific.

i'm not a hardware guy (but i used to dabble in it), but i am familiar 
with the so-called "3-wire standard" (serial data, bit clock, word 
clock).  i am also familiar with interrupt service routines, DMA, and 
*synchronous* vs. asynchronous sample I/O.

now, what Vlad says is true (well, almost; the femtosecond response time 
is an exaggeration) for a dedicated embedded system where you have an 
extremely fast ADC (like a flash), an extremely fast DAC (like R-2R), 
and totally separate input and output code.

suppose your algorithm is a simple wire:

    y[n]  =  x[n]

generic C code for a wire might look like this (with memory-mapped I/O):

int* dac_ptr = DAC_ADDRESS, adc_ptr = ADC_ADDRESS;
int sample_period = SOME_NUMBER;
...

    while(TRUE)
       {
       for (int i=0; i<sample_period; i++)
           ;                                // this is a timing loop

       *dac_ptr  =  *adc_ptr;
       }



note there is no call to an I/O routine, nor is there any interrupt 
service routine (ISR) for the I/O.  for this code, and for the kind of 
devices i assumed, there will be very little delay (like microseconds) 
to your wire.

but sometimes, either the hardware (an integrated ADC/DAC codec) latches 
the input voltage and output voltage simultaneously.  from the same 
clock.  this is so that delays, while not minimal, are *known*.  then, 
with a single word clock interrupting the DSP (or embedded CPU, there is 
not much difference nowadays), a single I/O routine outputs the output 
sample and inputs the next input sample to/from the codec.


int y=0, x=0;
int n=0;
...

    while(TRUE)
       {
       x  =  do_input_output(y);
       y  =  x;                         // this alg is a wire.
       }


then, even neglecting the finite conversion time required by the DAC and 
ADC, you can see that there is a single-sample delay because the output 
y comes from the previous input sample.

now, there are other situations like direct memory access (DMA) and 
sample buffering (something i very recently gave a sorta crappy 
presentation about and i think i'm gonna have to return to it next AES 
convention to plug the holes).  those also affect delay.

Vlad, i don't think it's a STUPIDENT question.  these are exactly the 
kind of questions that should be asked.  and in fact, i think the 
"one-instruction delay" depicted by the first code example is quite 
uncommon.  but i may be wrong.



-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

"robert bristow-johnson" <rbj@audioimagination.com> wrote:
> On 11/2/12 5:30 PM, Vladimir Vassilevsky wrote:
>> <gyansorova@gmail.com>  wrote:
>>
>> Sample the input, do some calculation and output the result in 
>> femtosecond
>> from input. No relevance to sample rate here.
>
> this is implementation specific.

There are minor technical problems and serious conceptual problems.
Leave minor technical problems to stupidents and matlabi.

> now, what Vlad says is true (well, almost; the femtosecond response time 
> is an exaggeration) for a dedicated embedded system where you have an 
> extremely fast ADC (like a flash), an extremely fast DAC (like R-2R), and 
> totally separate input and output code.

Okay. How about sample rate of once per hour and processing time of 0.1 
second?
Nothing extremely fast. Realistic system, say, bio fermentation tank 
temperature control.
Here is my point:  the conceptual delay in a sampled system is because you 
can't get signal before input is sampled.

> i'm not a hardware guy (but i used to dabble in it), but i am familiar 
> with the so-called "3-wire standard" (serial data, bit clock, word clock). 
> i am also familiar with interrupt service routines, DMA, and *synchronous* 
> vs. asynchronous sample I/O.

That sounds just like resume of stupident matlabi looking for internship; I 
receive tonns of theese.  "I am not a hardware guy but I heard something 
about DMA and such". Do not cry the blues,  many people know what you are 
really worth.

> then, even neglecting the finite conversion time required by the DAC and 
> ADC, you can see that there is a single-sample delay because the output y 
> comes from the previous input sample.
> now, there are other situations like direct memory access (DMA) and sample 
> buffering (something i very recently gave a sorta crappy presentation 
> about and i think i'm gonna have to return to it next AES convention to 
> plug the holes).  those also affect delay. Vlad, i don't think it's a 
> STUPIDENT question.  these are exactly the kind of questions that should 
> be asked.

Fie, boring and trivial shit. Let's talk something more interesting. Like, 
in PWM systems, the delay in feedback loop is variable due to the nature of 
PWM. This makes optimal control a non-trivial problem.

VLV

robert bristow-johnson <rbj@audioimagination.com> wrote:

(snip)
> this is implementation specific.
 
> i'm not a hardware guy (but i used to dabble in it), but i am familiar 
> with the so-called "3-wire standard" (serial data, bit clock, word 
> clock).  i am also familiar with interrupt service routines, DMA, and 
> *synchronous* vs. asynchronous sample I/O.

I presume also Vcc and GND. In that case, three wires more than needed.

http://en.wikipedia.org/wiki/1-Wire

(2 wires if you include ground.)

-- glen

On 11/3/12 9:29 PM, Vladimir Vassilevsky wrote:
> "robert bristow-johnson"<rbj@audioimagination.com>  wrote:
>> On 11/2/12 5:30 PM, Vladimir Vassilevsky wrote:
>>>
>>> Sample the input, do some calculation and output the result in
>>> femtosecond from input. No relevance to sample rate here.
>>
>> this is implementation specific.
>
> There are minor technical problems and serious conceptual problems.

and both are welcome at comp.dsp .  and everything in between.

> Leave minor technical problems to stupidents and matlabi.
...
> Here is my point:  the conceptual delay in a sampled system is because you
> can't get signal before input is sampled.
>
>> i'm not a hardware guy (but i used to dabble in it), but i am familiar
>> with the so-called "3-wire standard" (serial data, bit clock, word clock).
>> i am also familiar with interrupt service routines, DMA, and *synchronous*
>> vs. asynchronous sample I/O.
>
> That sounds just like resume of stupident matlabi looking for internship; I
> receive tonns of theese.  "I am not a hardware guy but I heard something
> about DMA and such". Do not cry the blues,  many people know what you are
> really worth.

not crying the blues.  but i have (a little more than 2 decades ago) 
hooked up codecs to DSP56K.  the 3-wire glueless hookup to these 
UART-like ports ("SSI" in 56K, "SPORT" in SHArC) are pretty easy.  i 
have also set up and used the DMA capability in both 56K3 and SHArC. 
but there are delay issues to be concerned with.  including regarding 
the serial port (like it might be buffered, too).  for audio &sum;&#8710;, it 
seems that the delay issues due to conversion are roughly a millisecond 
in and out in addition to whatever buffering and I/O delay there is.

>> then, even neglecting the finite conversion time required by the DAC and
>> ADC, you can see that there is a single-sample delay because the output y
>> comes from the previous input sample.
>> now, there are other situations like direct memory access (DMA) and sample
>> buffering (something i very recently gave a sorta crappy presentation
>> about and i think i'm gonna have to return to it next AES convention to
>> plug the holes).  those also affect delay. Vlad, i don't think it's a
>> STUPIDENT question.  these are exactly the kind of questions that should
>> be asked.
>
> Fie, boring and trivial shit.

and necessary shit.  if one doesn't understand it, unhappy consequences 
might result.

> Let's talk something more interesting. Like,
> in PWM systems, the delay in feedback loop is variable due to the nature of
> PWM.

that (this particular nature of PWM) is also implementation specific. 
you can do PWM where you advance the upward edge by half of the pulse 
width, so that the center of the pulse is always at the same relative time.

> This makes optimal control a non-trivial problem.

trivial is a subjective and relative thing.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On 11/3/12 9:33 PM, glen herrmannsfeldt wrote:
> robert bristow-johnson<rbj@audioimagination.com>  wrote:
>
> (snip)
>> this is implementation specific.
>
>> i'm not a hardware guy (but i used to dabble in it), but i am familiar
>> with the so-called "3-wire standard" (serial data, bit clock, word
>> clock).  i am also familiar with interrupt service routines, DMA, and
>> *synchronous* vs. asynchronous sample I/O.
>
> I presume also Vcc and GND. In that case, three wires more than needed.
>
> http://en.wikipedia.org/wiki/1-Wire
>
> (2 wires if you include ground.)

i looked at the .pdf from the first-mentioned external link:

    http://www.maximintegrated.com/products/1-wire/index.cfm?CMP=WP-7

and it appears to be the "1-Wire", GND, and some "internal Vdd".  so 
what i have understood to be the ostensible "3-wire interface" really 
has at least 5 wires to include +5v or +3.3v and GND.  but, like other 
digital circuits or with op-amps, i think the power supply is sorta 
understood to be there, even when not indicated in the circuit.

that 1-wire wiki-thing referred to Dallas Semiconductor.  about a decade 
ago, when or just before intel was supposedly putting serial numbers 
into their pentiums, Dallas sold these little 3-wire thingies (that 
looked like a transistor) where 2 of the wires were Vcc and GND.  the 
3rd wire was the I/O line, and must have been tri-state (low-impedance 
0, 1, and high impedance) which i presume the serial interface (or a 
single bit from a parallel interface) had to be also.

this common "3-wire interface" is not even s'pose to be that.  just 
serial bit data, bit clock, and word clock.  to the point of the 
original question, it seems to me that *any* serial interface to a DAC 
or ADC will have a delay of 1 sample (each) just to accommodate the 
serial bit bottleneck.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Saturday, November 3, 2012 7:30:29 AM UTC-7, Piergiorgio Sartor wrote:
> On 2012-11-02 21:48, gyansorova@gmail.com wrote:
> 
> [...]
...
> What makes you think analogue system do not have delay?
>
> First of all, there is an upper limit, which is the speed
> of "electrons" in circuit (far below the speed of light).
> Second, you can always have a combination of analogue
> components (LRC) causing a delay.
> 
> 
> 
> In the end, analogue delay lines do exist.
> ...
> piergiorgio

The delay in analog circuits is the time until the electrons start moving according to the signal, not 'how long does it take electrons to get there'. This is the propagation time of the electric field not the electrons. Speed of light in a vacuum, less in matter, as glen measured.

Dale B. Dalrymple