next topic »

[Reply #120 on:]

I'm not sure you can change output power with voltage. Some versions of the datasheet says you can change power from 1dBm to 30dBm with register settings, just like the RFM22, however, the datasheet on hoperf website has incomplete info...

[Reply #121 on:]

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.

[Reply #122 on:]

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

[Reply #123 on:]

$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: http://www.hobbyking.com/hobbyking/store/__24965__RMILEC_TS4047_10CH_2_5W_UHF_Module_System_w_Receiver_JR_module_.html $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.

[Reply #124 on:]

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.

[Reply #125 on:]

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

[Reply #126 on:]

Hello
Can you show yours antennas ?

[Reply #127 on:]

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.

[Reply #128 on:]

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.

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

[Reply #129 on:]

@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.

[Reply #130 on:]

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.

[Reply #131 on:]

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.

[Reply #132 on:]

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.

[Reply #133 on:]

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.

[Reply #134 on:]

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:

Code:

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

Just add your own variable in there.