MultiWii

Hi All,

I have an FRSKY futaba compatible receiver which has a PWM RSSI output.
I tried to add PWM RSSI reading:

in config.h added:


in def.h added:


in void setup() added:


in Multiwii.ino added:


in Multiwii.ino taskOrder added:


Of course this line must be modified from this:

to this:


I'm sure this is not the most elegant way and also maybe NOT MATCH the Multiwii coding rules, but I'm not familiar with port handling.

Could someone help making PWM RSSI reading compatible with Multiwii coding?

BR
Adrian

What is the problem with the existing rssi code in _shared ?

Alexinparis wrote:What is the problem with the existing rssi code in _shared ?

For me it was unusable without an R-C filter (100nF + 10kOhm) applied. (the value was far too glitchy when measured by analog input)
With R-C filter I still had to apply 32 for moving average...

But instead of applying R-C filter to average the PWM signal phisically it would better to measure the signal length since it is a PWM input.

With the modified code part I apply only 16 for moving average and the RSSI value is rock solid!

Unfortunatelly pulseIn is slow mneasuring method. That's why it would be better to have something faster, like RC channel handling for example.

BR
Adrian

ps.: this problem only occures when the RSSI signal is PWM and analog reading is not working very well.

Adrian, your filter has 160Hz cut off frequency, and that won't filter 50 Hz pwm or even the third armonic so the signal passes as a square wave:)

Abut RC filter, i use 4.7uF smd capacitor with 100K smd rezistor. It works perfect for FRsky RSSI. It has about 3 second time constant or 0.34 Hz cutoff . more details here http://www.ekswai.com/en_lowpass.htm

Hi,

viewtopic.php?f=8&t=2918&start=310#p33006

The one I made for myself works just fine and is tiny. Note: It does not have the R2 1K as in draw. This is to use on Minim OSD when soldering on ATmel pin, this way the capacitor will not discharge all at once.

Also the picture is inverted to the draw.







-KV

Thanks for all your reply.

But still, why make a physical filter instead of reading the PWM signal itself with the controller?
I think that would be much easier. BTW, my solution works, the only problem is that pulsein takes time to "run".

But we already have PWM reading for RC signals, so I think that would be quite easy to implement the RSSI reading too... the only problem for me that I don't have time enoughn to understand that code part...

BR
Adrian

If You want measure pulse time without waste time, You must use interrupts like PCINT and micros variable or any other timer value. You must write interrupt handler function, and inside "setup" function you must configure and enable PCINT interrupt. The interrupt handler must detect input high/low state, measure high and low time (simply micros from last interrupt). The calculation can be done in main loop, for shorter interrupt time. Interrupt should only measure high and low pulse time. That's all.

Yes, I'm talking about something like this.
Please correct me, but if I'm right, this is already done in RC channel reading.
If yes, one other input should be defined and that's all. Can anybody help doing this?

BR
Adrian

RC reading is little more complicated, but work with PCINT interrupts in similar way.
About help... This is easy with one configuration, like Mega2560 board with standard RC. But we have three different hardware versions (328, 32U4, 2560) and two receiver standards (normal and PPM-SUM) that use PCINT (other receivers not use PCINT's, and not collide with it). This number of combinations a headache, because PCINT interrupts share two or three interrupt vectors, and we must detect the interrupt source inside interrupt handler. Lot of checks, work, and tests. Interrups are delicate matter.

My conclusion. Forgot it and use RC filter, and analog input

Mis wrote:RC reading is little more complicated, but work with PCINT interrupts in similar way.
About help... This is easy with one configuration, like Mega2560 board with standard RC. But we have three different hardware versions (328, 32U4, 2560) and two receiver standards (normal and PPM-SUM) that use PCINT (other receivers not use PCINT's, and not collide with it). This number of combinations a headache, because PCINT interrupts share two or three interrupt vectors, and we must detect the interrupt source inside interrupt handler. Lot of checks, work, and tests. Interrups are delicate matter.

My conclusion. Forgot it and use RC filter, and analog input

Hi,

yes you are right.
The only thing I don't understand, why is it such a big problem?
The RX inputs are "readed" on the same way aren't? And the handlings are already written to any used boards.
The only thing should be done is to extend the RX inputs with one more channel, called RSSI.

BTW, forget my wish, I'll use RC filter....

BR
Adrian

Hi,

After seeing Mis last post I looked to the code for some time trying to see if I could help on that ( it would be nice...)
And... yep the RCFilter works just fine and it can be a "tiny" part with almost no significance

Probably no worthy the work around that.

-KV

Mis wrote:If You want measure pulse time without waste time, You must use interrupts like PCINT and micros variable or any other timer value. You must write interrupt handler function, and inside "setup" function you must configure and enable PCINT interrupt. The interrupt handler must detect input high/low state, measure high and low time (simply micros from last interrupt). The calculation can be done in main loop, for shorter interrupt time. Interrupt should only measure high and low pulse time. That's all.

im going to have a crack at this for the mega

ok so reading in another pwm via for example an aux channel would be easy, as all the interrupt and timing code is already there for the recievers servo signals, even if you had to make some small changel for a pulse rate / duty cycle 'midly' outside the normal 1000-2000 microsecond servo signals

but then i hit this road block:

ive found a few mentions of the frequency it puts out (110 kHz or 9.8 microsecond cycle) now split that 9.8 mics into 100 increments and you need a pretty fine resolution reader and fast processor, likely making the mega 2560 not up to the task, as i believe the best it 'may' be able to do is 1 mic resolution though possibly as 'poor' as 4 mics

to put this in perspective a servo signal is 1000-2000 mics duty with a 20000mic gap

why the heck frsky would choose such a fast rate seems silly to me...

Some FrSky receivers (D4R-II, D8R-XP, ...) provide RSSI as a PWM signal. The issue is that the frequency of the signal is way to high to be decoded by the ATmeg328 (110 kHz).

http://code.google.com/p/minoposd/wiki/AnalogRSSI

still researching though

oh and nhadrian you didnt have a chance with the pulseIn() function (disregarding blocking) as it turns out it only has a resolution down to 10 microseconds i read here: http://arduino.cc/en/Reference/pulseIn

update on this, x8r reciever puts out a pwm rssi signal that would be ok to read, not as fast as others mentioned in this thread.