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

Although I have recently moved home and have no workshop or modelling facility (yet!) I'm still watching what is going on.
I see Flytron has announced their 1W modules...
http://www.flytron.com/openlrs/212-openlrs-m3-1w-tx-module-for-futaba.html

Would be useful to be able to fly with 100mW and hit a 'get out of jail button' for 1W.

Nigel.

Unfortunately he hasn't yet posted the correct schematics and source code :(.

$110 is a lot of money. I don't think he will be able to sell many at that price considering that you can just get this: Radio Control Planes, Drones, Cars, FPV, Quadcopters and more - Hobbyking $180 with diversity receivers.

A bit of a update, I lost my glider while testing autopilot. Stupid mistake, pulling too hard out of a dive. So I had to get a new one, spent all summer trying to get that flying. During that flight I was able to log RSSI vs distance, you can see the plot. I didn't go very far, only 200m, but if I extrapolate the trend I will probably start to get occasional packet drops at 1km and lose signal completely at 10km.

On the RF22 front, I have managed to get telemetry working on my boards, and fixed some bugs, unfortunately also introduced some new ones that causes the board to lock up randomly and other weird problems.

Yeah for us who know how cheap it is to actually build such an unit 110$ is very high.. That Rmilec unit is crap people say..

Thanks for the progress report, sorry about the glider.

Hi guys,

Just to let you know that I found a problem with my board design. It the way I am using the resistor dividers to shift 5V from arduino to 3.3V for the RFM22. Because I have modified the RF22 library to run at very high speed, the resistors and the capacitance of the traces begin to act like a RC filter. This can corrupt the SPI data, causing lockups. This means that the SPI bus is operating very close to the limit, voltage problems with power supply can easily cause a lockup, especially if you run a lot of servos. If you only use the board for spec scan or telemetry you may not have this problem at all.

As you can see here, the SPI clock out from arduino (blue) is distorted when it gets to the RF22 module (yellow). This screen shot is a bit exaggerated because I was using X1 probe, it's better with X10.

Solutions:

  1. Software solution: reduce SPI speed, change the SPI speed down to 2MHz in the RF22.cpp file. Change the line in RF22::init() to SPI.setClockDivider(SPI_CLOCK_DIV8);
  2. Hardware solution: reduce resistor values. I tried halving the resistor divider values (R2 - R7), and it works much better. Replace 1K with 470 Ohm, and 1.5k with 680 Ohm.
  3. Both. <-- I recommend this for best reliability

Hello
Can you show yours antennas ? :slight_smile:

I'm not really a RF person. Actually, I'm not even really a electronics person! I just made simple dipoles from a SMA connector and coax cable.

Funny, I had to put this project on hold. But yesterday I picked it all up and finished to assemble the boards.
Seems I'll have to do some more modifications. :slight_smile:

@zachwiej, check here for example: http://fpvlab.com/forums/showthread.php?3156-433MHz-Half-wave-dipole-for-LRS

@Zitron, I see that you mentioned you've added telemetry to the code. Is that a custom implementation?

I was considering using the FrSky protocol, I have a 9X modded to get FrSky telemetry as well as a Android app in the works.

I donno much about the FrSky protocal, but that would be pretty cool. I was thinking about making an android app as well, but my app making skills is at the "hello world" stage.

How would you transfer data from the 9x to the phone? I was thinking some kind of bluetooth?

My telemetry is basically the same as my RC link, passing data structures directly, I will upload some example code this weekend. But if the FrSky is easy enough to implement and standard we should use it or at least have it as an output option. Being able to use the 9X to display telemetry is something I am also interested in.

There is already implementations of the protocol in the Multiwii Flight controller that run in arduino so it would be basically copy/paste.
I've hacked the current code to add it and it fits perfectly in 328p already full with the Mwc code.
I'll upload it to my site later today so that you can give a look.

I'm currently using BT like you said, on my 9x I made a converter from RS323<>TTL and I plug it in the back of the radio.
And at the same time you still have it showing in the 9X LCD.

On my 9C because it has a FrSky DIY kit inside I actually placed the BT dongle also inside the radio. So it becomes a much cleaner solution.

So far I've hacked one fo the existing frsky apps to add what I needed, log rssi:

But I'm not too happy and I have some other ideas on what I want to do.

PS: I was also looking into putting a buzzer in the TX PCB to signal low RSSI as FrSky does. I've received today a spare ATMEGA from Farnell along with the resistors to swap. So I'll be giving total attention to this in the upcoming weeks. :slight_smile:

Here it is: http://www.xrotor.net/wp-content/uploads/2012/11/FrSky_Telemetry_Mwc.c

This is the main code for the FrSky telemetry. The data sources are mostly the sensors from the Multiwii board.

Here it is: http://www.xrotor.net/wp-content/uploads/2012/11/FrSky_Telemetry_Mwc.c
This is the main code for the FrSky telemetry. The data sources are mostly the sensors from the Multiwii board.

I'm currently updating the code from thUndeadMod v.4 for the openLRS to be able to use it with these boards. Hope to
run the first tests next weekend. :slight_smile:

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.