The topic says it. While reworking the RCrx part in Harakiri I came across http://code.google.com/p/multiwii/sourc ... RX.cpp#406
computeRC(). I may be wrong but I think it could be done less memory intensive.
First of all the static rcDataMean[RC_CHANS] definition is not needed, since it is cleared on every run and the stored value isn't used. A simple int16_t tempvariable would do it as well, right? When doing a 4 point moving avg, why not use the actual value buffered in another temp int16_t? On the other hand a mov avg with 3 values is sufficient and would boil down to storing two values per channel.
I post here how I've done it right now in my project. Works well.
Code: Select all
static void computeRC(void) // Just harvest RC Data
{
static int16_t rcData2Values[MAX_RC_CHANNELS][2];
static uint8_t bufindex = 0;
int16_t rawval, avg;
uint8_t chan;
for (chan = 0; chan < cfg.rc_auxch + 4; chan++)
{
rawval = rcReadRawFunc(chan) << 2;
if(cfg.rc_lowlat || SerialRCRX)
{
avg = (rawval + rcData2Values[chan][0]) >> 3 ;
rcData2Values[chan][0] = rawval;
}
else
{
avg = (rawval + rcData2Values[chan][0] + rcData2Values[chan][1]) / 12; // GCC would do the same with a "for" loop
rcData2Values[chan][bufindex] = rawval;
}
if (avg < rcDataSAVE[chan] - 3) rcDataSAVE[chan] = avg + 2; // rcDataSAVE can pass unchanged here
else if (avg > rcDataSAVE[chan] + 3) rcDataSAVE[chan] = avg - 2;
}
bufindex ^= 1;
}
EDIT: Note: I buffer the data in rcDataSAVE (instead of the direct use of rcData) because of the serial rx.
EDIT:EDIT: uint should do it as well - maybe shorter when compiled.
Cheers
Rob
. Maybe that 4 point moving avg was relevant with pure analogue systems but at least my frsky ppsum setup works very good with a 2 element moving average (due to digital airlink, of course) and rewards the pilot with a noticeable lower latency. Just saying, maybe a #define for those radios that are just analog on the last step would be fine.