multiple PWM capture

[sturgessb]

Hi, and happy new year to all!

As a side project to the quadcopter, im working on some flight aids for conventional rc heli. With the zxquad im capturing a muxed PPM signal from the receiver using inputcapture. This works great and uses very little processor time (although obviously ties up a timer). However for the other apps I am going to need to capture each of the separate PWM lines from the receiver (4 in total) rather than capturing the PPM as a whole.

In the past I have tried the AWC PAKVII IC (http://www.awce.com/pak7.htm) but had a terrible time getting it to comunicate with the ZX. Thanks to Tom Becker We eventually managed to get them talking, but the performance was terrible (only able to capture the pins at about 7hz!).

So the question to the group is.... does anyone know of an IC that could capture 4 (or more) 50hz PWM pulse trains and that can be easily interfaced to the zx?

I say another IC as I presume this is not possible onboard the zx-24n or zx-128ne.

Cheers

Ben

[dkinzer]

I am going to need to capture each of the separate PWM lines from the receiver (4 in total) rather than capturing the PPM as a whole.

Are the 4 channels synchronized at all or are they totally asynchronous? If they have a constant phase relationship and only one channel is active at any moment, you could logically OR them together and feed the result to the ICP input. Then, with a special input capture ISR you could measure the pulse width of each channel using a native mode ZX and only 1 timer.

[sturgessb]

Not sure, they would be coming from the same receiver so i presume they would be all being output at the same time as each other, and all channels would be operational at once.

However maybe that method could still be used?

Ben

[spamiam]

I think that complexity of the answer is going to depend, in part, on what you are going to DO with the data once you have obtained it.

1) So how are you going to process this data once you get it? The way you use the data may dictate the best native format for the data. The best native format may influence the method of ovtaining the data.

2) You say that 7Hz is not fast enough. How fast is JUST fast enough? How fast is MORE than fast enough? How fast are you realistically able to process that data?

I would bet that the leading edges of the PWM outputs are synchronized (a job for Mike Perk's inexpensive logic analyzer!), but I don't understand how that will help you much. Sure you will only need one timer (starts at the leading edge of the synched PWM pulses), but you still need to time each one of them individually, probably by using an external interrupt for each channel. When the interrupt fires you grab the current timer value.

The range of PWM values is 1-2mS. You probably need no more than 10 bits of resolution (1024 steps) within that 1mS span. Therefore you would need about 1uS (1MHz) precision. This may not be possible on a 14MHz machine especially when multiple interrupt sources will cause variable durations of latency.

I am thinking that much faster hardware will be necessary. Maybe some external glue logic will help process the signals for you.

-Tony

-Tony

[sturgessb]

I need to capture at around 30-50hz for smooth control.

The data will then be processed and output at 270hz (digital servos).

maybe a dsPIC would have the grunt, I see the dsPIC30 and 33 range have up to 5 16bit timers, although the spec sheets only indicate 4x input capture is possible (http://www.microchip.com/ParamChartSear ... &pageId=75), so not sure if this is the answer.

to be honest i would rather have a seperate IC doing this job which i can hook up to the zx via i2c, will make it more flexible in the future.

anyone have experience with the dsPIC range?

[mikep]

I need to capture at around 30-50hz for smooth control.

The data will then be processed and output at 270hz (digital servos).

I think it is definitely doable with an AVR using either an interrupt driven or polling approach. See this thread for some discussion on the matter.

On a mega128 there are 8 external interrupts available. INT0 and INT1 are shared with the I2C bus but that still leaves 6 interrupts. Alternatively you could use the pin change interrupts on the mega644 or mega644p.

The polling approach samples the I/O pins at a frequency of 32KHz which gives 7-bit resolution. With some tight assembly code it might be possible to achieve 64 or even 128KHz.

In all cases you need to use a 16-bit timer (with overflow) to measure the length of a pulse.

As I understand RC control the 1-2ms pulse only happens every 30-50Hz which means that there is a dead time of 18ms or more between pulses which can be used for any post-processing of pulses and I2C communication with the controller.

I just pulled out my ATTiny25/45/85 datasheet. This device is very small (PDIP8, SOIC-8 ) but includes a 16-bit timer, I2C, and 4 pins that could have pin change interrupts. I wouldn't be surprised if this device could be used - you just need a little bit of AVR code

[mikep]

I say another IC as I presume this is not possible onboard the zx-24n or zx-128ne.

I think it depends on how much free processing time is available on each device. As I understand your setup the zx-128ne is doing all of the main processing and is very time sensitive. The zx-24n is the auxiliary I/O processor and may be more available. You will definitely need a 16-bit timer and the ability to process the pin change interrupts for 4 I/O lines on a single port.

[sturgessb]

Hey Mike. Just checked the Tiny25 sheet, cant see any mention of a 16bit timer?

[mikep]

Hey Mike. Just checked the Tiny25 sheet, cant see any mention of a 16bit timer?

I'm sorry you are correct. I was also looking at the 14-pin mega24/44/84 that does have a 16-bit timer.

Thinking some more I believe you may be able to do it with an 8-bit timer. The processor probably needs to run at 8 MHz (i.e. no CKDIV8 fuse) to make sure you can quickly execute the ISR code.

You will need to intercept the timer1 overflow interrupt and increment a 8 or 16-bit overflow count. For example a 2ms pulse would be 16777 timer ticks without any timer prescalers. You could also choose to reset the timer during an idle period (i.e. no outstanding pulse timing).

[sturgessb]

"You will need to intercept the timer1 overflow interrupt and increment a 8 or 16-bit overflow count"

I'm afraid thats gone right over my head!

Maybe I need to sub this out to someone else, any offers?

Ben

[sturgessb]

silly question, but how do i grab one of the 16bit timer values, when im doing the Interrupt method?

is it a register value? and do i need to start the timer at all?

edit: am i right in thinking they are Register.TCNT1 and Register.TCNT3?
both are showing 0 though, how do i start the timer?

[dkinzer]

am i right in thinking they are Register.TCNT1 and Register.TCNT3?

Yes, those are the timer values. There are other registers that control the operational mode, clocking frequency, etc.

how do i start the timer?

There is a good tutorial about AVR timers on the AVR Freaks site. N.B.: the AVR Freaks site currently has some Russian hacker scripts on it so don't visit it unless you have a good script blocker installed. I'm using the NoScript plug-in for FireFox and the scripts are blocked for me.

[dkinzer]

I was also looking at the 14-pin mega24/44/84 that does have a 16-bit timer.

Another option is the 28-pin ZX-328n, soon to be announced. It is currently available in limited quantities but we expect to have ample stock within a week or so.

[sturgessb]

interesting! nice product.

Could that be set up to be an I2C slave?

[sturgessb]

Sorry I really dont follow the code in that link (avr freaks)

TCCR1B |= (1 << CS10); // Set up timer

If I want to just start the timer at a 1:1 ratio with the AVR clock speed how would I do that? And presumably I need to set it to a rate that is much slower than that in order to capture these high periods before the timer overflows. trying to work out what rate would be the best.