Thanks. In the mean time went back to some code you had shared before and changed it to include downlink telemetry. (I really didn't like openLRS code)But I'll use the one you shared now that is better tested than mine.

One question, on your old code that you shared I was getting servo glitches at a regular interval, any idea what was it (I suppose it was the RF22 irq messing the servo library?I didn't spent much time as I need to generate instead a PPM signal (for the Multicopters FC's) but I was curious about itseems like the

One other thing, do you get a stable RSSI reading? I'm getting something like 104, 80, 70, 90, 60,... ended up adding a moving avg filter to help. I was expect some fluctuation but not so big as this.

Hmm... are you using my modified version of the RF22 lib? Because I thought I solved that particular problem, my servos seem fine. Try the new code, and see what you get. I will investigate a bit more. I guess I could think about adding PPM out, but because I implemented autopilot directly on the receiver, I never had the need... It might be simpler to have the receiver talk to multicopter FC directly over serial port instead of the convoluted digital->PPM->digital thing.

Also, my new telemetry code is not fully tested!! Make sure you don't put it on something expensive! And because the rx defaults to transmit telemetry data at full power, make sure you have an antenna on the receiver all the time!

My RSSI values are very stable, down to the last digit. The trick is the read RSSI right after receiving a packet, otherwise it will be wrong.

The key to good interrupt handling is to make sure the code in the interrupt handler is as small as possible. IIRC the original RF22 lib had all kinds of stuff in their interrupt handler function, including reading data from the module, which meant everything else (like servos) had to stop when it receives a packet. When this coincides with a servo pulse, you have a glitch. I move the data reading outside so the actual interrupt takes almost no time.

Does you PPM code work on its own? Debugging these interrupt and timer issues are quite difficult! If you share your code I will have a look at it sometime this week. Can't promise anything though...

Thanks, I noticed that you're not using the latest version of RF22 so I wanted to check the changes to port it to the latest version.

My PPM code it running fine on it's own, I set some static values and the signal generated is clean. I matched the time intervals to what FrSky receivers do. (I'll post some screenshots later)Is still not optimal as I lock it during the signal generation, but I saw a good example on how to release the control between the intervals of the pulse shifts. As soon as I made the current model work I'll try the better one.

There you go: http://code.google.com/p/zlrs/source/browse/#git%2Frf22_RCrxHWS_tele

I prefer GitHub but I decided to give a try to Google Code GIT hosting.

Got some time today to look into this, seems the way I've set it is consuming too much time not allowing the RF22 to process data.I've changed the timer to only trigger and even on the pulse shift and the RF22 started to work. Now I need to correct the PPM output as it's not been generated correctly.

I remembered seeing that code but when checked I saw that it was using the full power, 20dBm!Problem was I checked on the RX and forgot to check on the TX side, so yes I was only using 1dBm on the TX side. ;-)If the weather keeps good, I'll test it again with more power.

PS: What have you used to power the TX module? Both Futaba and 9X output 12v so it needs to be converted. For testing I ended up using a ESC+LiPo. So I was wondering if you have a new board layout that includes a voltage level converter.