Cheap UHF spectrum analyzer (and RC tx rx) using RFM22 module

Here is the new code with hardware servo, hardware tone, telemetry, and updated RF22 library

By default, pin 5 generates a tone for RSSI warning and bad packet. I'm using a piezo buzzer in series with a 1k resistor.

Currently the tones are:
4000Hz tone for bad packets
2000Hz tone for RSSI warning

Frequency and duration of the tone can be changed.

You can easily send more data back by modifying the telemetry data structure which is currently:

struct TELE_DATA_STRUCTURE{
  byte RSSI;
  byte RxBad;
  float Alt;
};

Just add your own variable in there.

RF22-TXRX-tele.zip (652 KB)

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. :slight_smile:

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 it
seems 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.

I started using your new code and the issue was fixed. But I was curious about was causing it in the older version.

I already implemented PPM but it makes the RF22 stop working.
I've set the timer1 to do the work, similar to what the Servo library does, so shouldn't be any issue...

If there is interest maybe host this somewhere, google code or github.

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.

I'll create a Google code page later and share it there.

Here it is: Google Code Archive - Long-term storage for Google Code Project Hosting.

That version the PPM sum runs fine on pin D8, perfect 18ms like FrSky but no RF22...

This is the output from a FrSky D4FR

And this is from the code of the LRS

The channels interval is showing the ~1500ms the default value I've set because it can't get data from the RF22.

zitron:
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.

Hello zitron. Can you summarize what modifications you have made to your RF22 lib? What problems did you need to fix?

Best Regards,
George

Here it is: http://code.google.com/p/zlrs/

Sorry I don't know how to use google code, where is your code?

MGeo:
Hello zitron. Can you summarize what modifications you have made to your RF22 lib? What problems did you need to fix?

I am really bad at documenting stuff, I think I basically moved the read data stuff from the interrupt handler to only run when you call the receive function.

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.

...and it's fixed! :slight_smile:
Took some ideas from openLRS code and ended up only using Timer1 as overflow interrupt.
I'll be submitting the updated code soon and start adding a failsafe feature.

Update1: Code submitted and video made of the test

Update2: FrSky telemetry support added. RSSI+Voltage levels working on a modded 9x radio.

Wow awesome! I like the changes.

Which version of the 9x firmware do I need?

I'm thinking about building a tricopter, I might just copy your setup!

I'm using the er9x, but I think open9x will work as well they use the same mods for telemetry.

In multicopters and for FPV I just love the tricopter, the super responsive tail makes it really fun to fly.
If you need any details just let me know.

I'm trying to determine with platform will be the one making the first test running the LRS. :slight_smile:

Just a video showing the maiden flight. :slight_smile:
Next step is to make some proper antennas, you can hear the drop packets beeps (as well as me speaking loud).

Nice! Were you flying on 1mW? 1mW Should be good for 100m with normal antennas.

arghh... thanks for that!

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. :wink:
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.

I couldn't tell from your video, but make sure you also check the hardware power selector/switch next to the RF22. You shouldn't need to change the software if you just add a jumper.

For power I just soldered a wire from the 5V reg on my 9X.

I've disabled the jumper check code, so it's always using the same power.
What I had forgotten to do was check the initialization settings on the TX.

As for the power regulator I recalled I had here a tiny pcb with a voltage reg from a old Wireless camera kit.

Couldn't be better, it converts from 12v to 5v and has place to solder two more wires that I'm using for the PPM and Serial TX.
It's a 78L05 so It's pushing it a bit, but I let it on for quite some time and it didn't burnt.

How does one change the frequency easily on this? I'm looking at Radio Control Modules - 433MHz (and also the one from Sparkfun) and they all seem to indicate that the parts on the board constrict it to specific frequency and it wouldn't work on others, yet you guys seem to be able to switch along the entire range with no problem.

You can change normally using the registers. It can work all over the full range allowed by the SIL chip.
What happens is that hoperf adds some filters that will make it work better on model range. So don't expect to have the same
performance on 866Mhz if you're using a model for 433Mhz.
Example, for the purpose of acting as a frequency scanner is it ok for a LRS I'd stick to the model frequency to get the maximum performance.