And the ones that don't seem to be dying off.

søndag den 30. december 2018 kl. 02.57.31 UTC+1 skrev Eric Jacobsen:
> On Sat, 29 Dec 2018 15:13:36 -0800 (PST),
> lasselangwadtchristensen@gmail.com wrote:
> 
> >l=C3=B8rdag den 29. december 2018 kl. 20.00.57 UTC+1 skrev Richard (Rick) L=
> >yons:
> >> Not all DSP engineers are godless heathens. I know several DSP engineers =
> >who celebrate Christmas.
> >
> >I'm not sure Christmas really qualifies as something religious anymore ;)
> 
> I'm not sure Christianity is about religion any more.   ;)

yeh it is just a cultural thing

we have (opt out) church tax of ~1%, around 80% of the population pay it even though a recent survey showed half of them are not religious 

On Saturday, December 29, 2018 at 5:57:31 PM UTC-8, Eric Jacobsen wrote:
> On Sat, 29 Dec 2018 15:13:36 -0800 (PST),

> ...
> I'm not sure Christianity is about religion any more.   ;)

I think Christianity is still about religion, it's Christians that aren't about religion. 

This isn't new:
Mahatma Gandhi — 'I like your Christ, I do not like your Christians. Your Christians are so unlike your Christ.'

On Sat, 29 Dec 2018 15:13:36 -0800 (PST),
lasselangwadtchristensen@gmail.com wrote:

>l=C3=B8rdag den 29. december 2018 kl. 20.00.57 UTC+1 skrev Richard (Rick) L=
>yons:
>> Not all DSP engineers are godless heathens. I know several DSP engineers =
>who celebrate Christmas.
>
>I'm not sure Christmas really qualifies as something religious anymore ;)

I'm not sure Christianity is about religion any more.   ;)

lørdag den 29. december 2018 kl. 20.00.57 UTC+1 skrev Richard (Rick) Lyons:
> Not all DSP engineers are godless heathens. I know several DSP engineers who celebrate Christmas.

I'm not sure Christmas really qualifies as something religious anymore ;)

Not all DSP engineers are godless heathens. I know several DSP engineers who celebrate Christmas.

On Wednesday, December 26, 2018 at 8:46:14 PM UTC-5, gyans...@gmail.com wrote:
> I realise DSP engineers don't celebrate Xmas so I feel warranted in asking a question at this time of year. A quad-detector connected  to say the shaft of a motor gives out pulses and senses direction. So it effectively gives out + or -1 which we count in the main loop which must execute at say within Ts seconds. Suppose there are thousands of pulses per revolution and my understanding is that the interrupt is used. So the processor stops what its doing and goes and grabs the sensor info every time it arrives. Surely if this happens too often then the loop cannot execute properly or incorrect information must be read. Therefore surely there is an aliasing problem associated with the number of pulses per rev and the speed of the shaft - also the sampling interval of the real-time loop doing say real-time control with this data.
> 
> 
> Thanks

This actually is an issue, so some Processors designed for use with motors actually have dedicated 'Quadrature' decoder hardware built-in, and then the main loop just reads the count from a register, at e.g. a few KHz.  

On 12/26/2018 20:46, gyansorova@gmail.com wrote:
> I realise DSP engineers don't celebrate Xmas so I feel warranted in asking a question at this time of year. A quad-detector connected  to say the shaft of a motor gives out pulses and senses direction. So it effectively gives out + or -1 which we count in the main loop which must execute at say within Ts seconds. Suppose there are thousands of pulses per revolution and my understanding is that the interrupt is used. So the processor stops what its doing and goes and grabs the sensor info every time it arrives. Surely if this happens too often then the loop cannot execute properly or incorrect information must be read. Therefore surely there is an aliasing problem associated with the number of pulses per rev and the speed of the shaft - also the sampling interval of the real-time loop doing say real-time control with this data.
> 
> 
> Thanks
> 
I don't really see a question.

Generally, a quad detector puts out two channels, referred to as A and 
B,  90 degrees out of phase. We can use the rising edge of channel A as 
the interrupt then read channel B.  If B is 0 we're rotating clockwise 
and increment the count.  If B is 1 we're rotating counterclockwise and 
decrement the count.

I suppose that enough interrupts could cause trouble, but the interrupt 
time is very short.  The main loop can simply read the current count and 
do whatever processing is needed (I'm assuming the increment, decrement 
and read operations are atomic). If the processor can't keep up, get a 
faster processor.

-- 
Best wishes,
--Phil
pomartel At Comcast(ignore_this) dot net

I realise DSP engineers don't celebrate Xmas so I feel warranted in asking a question at this time of year. A quad-detector connected  to say the shaft of a motor gives out pulses and senses direction. So it effectively gives out + or -1 which we count in the main loop which must execute at say within Ts seconds. Suppose there are thousands of pulses per revolution and my understanding is that the interrupt is used. So the processor stops what its doing and goes and grabs the sensor info every time it arrives. Surely if this happens too often then the loop cannot execute properly or incorrect information must be read. Therefore surely there is an aliasing problem associated with the number of pulses per rev and the speed of the shaft - also the sampling interval of the real-time loop doing say real-time control with this data.


Thanks