[hwh]

I did a lot of tests a few months ago and found that some of my oplinks were enough off frequency that they wouldn't connect.  I fixed two of them by replacing the RFM22b modules with good ones.  For the others I made a test branch in my repo that allowed me to tune the oplink frequency manually.  The tuning range was enough to tune the oplinks I had so they worked.

I didn't feel up to making a GUI for this so I gave it to @f5soh and he cleaned up my test code and built a GUI for it.  There's probably only two or three lines of my code left.   He made a really nice slider and tuning meter that shows how far the AFC is having to fine tune the frequency so you can get a pair on exactly the same frequency for maximum range.  If it's off too far to connect at all his GUI still lets you blindly try shifting the frequency until it connects and then use the meter to fine tune it the rest of the way.

I think it's still just in his repo and there hasn't been a pull request to merge it in yet.  I'm not sure but I think it's intended for merge after the 16.09 release is finalized.  https://librepilot.atlassian.net/browse/LP-346   In his repo it's part of https://bitbucket.org/f5soh/librepilot/branch/LP-345_RFM22_band .  I was supposed to test the band switching but damaged one of the oplinks I converted to 915MHz and forgot to order another one to convert.  In fact until now I had forgotten all about it. 

[karla]

Thanks a lot TheOtherCliff and HWH.
Very promising that a tuning tool might become available.
It seems this will be needed for all of the Oplinks sold today since they are all from China to my knowledge.
Will that be part of the GCS as some kind of option in the menus or a standalone thing?

Meanwhile, and as an option, considering replacing the rfboard with a good one as I think Mateusz suggested below by using this http://shop.top-electronics.eu/20dbm-transceiver-module-433mhz-smd-p-16847.html
but this would mean to de-solder the bad one and mount a new one on to it.
Im not sure I have the skills to do that. (the OSH park thing is way over my head).
HWH, How did you do it?

I just feel its worth spending the effort to get the Oplink to work since its so convenient to have control and telemetry in one radio solution.

[hwh]

I did the first one by sliding a sharpened wooden toothpick under the edge of the rfm22b and then running a soldering iron down the contacts on one edge of it until it lifted slightly.  Then the same thing with the other edge.

The second one I used a hot air rework station I purchased on eBay.  While this probably is the "correct" way to do it the first one with the toothpicks was actually easier to do. 

The tuning GUI will be added to the GCS software as another adjustment on the oplink configuration tab.

[karla]

Fantastic!
Will try. Have several boards to play with now and a hotair solder.
Thanks
K

[karla]

The way I anticipate this to unfold is You get a really good Oplink transmitter board on the GCS side and then you will tune the the Revo boards on the frames you fly to adjust to it. Since the Revo boards will have the same rf chip 100% from China (bad), they will also need to be tuned.
You experienced guys, you agree or not?
Best
K

[hwh]

Using the ground oplink as the reference and tuning the flight ones to it makes sense to me.  It doesn't really matter what frequency they're on as long as all of them end up tuned to the same frequency.

[karla]

Got it. Thanks.

[karla]

Wanted to share recent progress trying to fix my OPLM boards.

So i have already fixed the short circuit of the antenna on the board. This gave a much better signal strength and range (from before some 3-10m). But from that good level there were short radio drop outs happening like 1-2 times for every 5-7 minutes. So to fix that I hoped that replacing the RFM22b chip for a good one could possibly eliminate it.
I got some RFM22b's from the shop mentioned below.
http://shop.top-electronics.eu/20dbm-transceiver-module-433mhz-smd-p-16847.html
Its actually printed on the back of them 'RFM22B-S REV 3.0'.

I managed to successfully desolder the old chip from the OPLM and also to solder the new one in place without destroying other small components 

I have the OPLM on the ground side and then 4 different Revo boards on different frames. I tested the Link meter values of the connections before and after the swop to the new RFM22b chip.
Basically the signal becomes stronger but the dropouts are still there, unchanged.

1. Revo: signal before 9 to +10, with new chip +20 to +25, still have dropouts
2. Revo: signal before +10 to +20, with new chip +25, still have dropouts but maybe fewer
3. Revo: signal before +30, with new chip same +30, still have dropouts
4. Revo with a OPLM as receiver: signal before +20, with new chip same, still have dropouts but maybe fewer   

. Distance between TX and RX the same ~7m
. Antennas same for each frame and all of them the same type (dipole half w.lenght)
. Transmitter power set same on all boards, 1.25 mW
. Max and Min channels set same to 250

The video clip show a typical dropout but they can also go all the way to red end bottom and stay there 2 sec before bouncing back to good signal again.

Knowing there will be radio dropouts for sure and failsafe kicking in to ground my frames is not acceptable to go flying with.

So maybe next step is to try that upcoming frequency tuning method?
Any other ideas?

How about I swop another one of my OPLM boards with the new trusted good RFM22b chips, then use it as receiver to the Revos (not using the onboard chip of the Revo as receiver). The same supplier should be consistent with radio frequency across his own chips right? So then we can rule out the radio frequency as the culprit if the radio dropouts is not disappearing?

Thanks a lot.

[TheOtherCliff]

Do you have anything else on 433mhz like an LRS RC that might cause interference?

I wouldn't run min=max.  I think it has been fixed to override this with reasonable values, but I would keep 15 channels between them at least.  I recall that it can use 12 channels at highest data rates?

It might save you some unuseful work if you can determine that the OpLink is just rebooting.  The LEDs will show a reboot.  Then the question would be "why?"  Dirty power / missing caps would be a first guess.  Laptop USB power is sometimes a bit low.  Maybe try a short cable to a powered hub or desktop PC.

[karla]

Thanks a lot for 3 new ideas!

. I dont think there is any 433mhz sources around here, however a lot of WiFi networks but
What is LRS RC?

I wouldn't run min=max.  I think it has been fixed to override this with reasonable values, but I would keep 15 channels between them at least.  I recall that it can use 12 channels at highest data rates?

. I am just using the default settings of min=0 and max=250 (maybe I expressed myself unclear).
Should it be set to something else?

. Will try to determine if the OPlink is rebooting or not, but I don't think so. Can it reboot and connect again in 2 sec?
For the power source on the TX ground side I feel confident its stable, 5.0 volt (to the OPlink).
On the air side, I have several different configurations, but the below result was with a 5-6 volt source (same source used both before and after). 

This weekend I decided to try and desolder the RFM22b chip from another (non-short circuited) OPlink and replace it with one from the same good source as the one I use on the ground side. Then put the 'new' OPlink as a transceiver to the Revo and disable the Revo's Oplink. All that process went fine.
I was expecting (at least hoping) a higher signal strength, but above all, a stable connexion that would not have any dropouts in a 5 min time. However, the result was not any improvement, really the opposite. Before, the Link meter showed connection at a steady strength of 10+ but after, a deterioration to a steady 8.
I tested for dropouts a number of times, each time 5 min and then I rebooted and connected the units again.

1. 0 dropouts
2. 2 dropouts
3. 17 dropouts
4. 0 dropouts
5. 4 dropouts
6. 8 dropouts
7. 0 dropouts
8. 18 dropouts
9. 2 dropouts
10. 0 dropouts

Intriguing 

[TheOtherCliff]

Run with 115200 data rate on both sides and set min=0 and max=15 both sides (I use max=31).  That is what I use.  Maybe it will make your reboot times shorter.  Also, the higher data rate will keep the channel from being flooded.

[karla]

Thanks!

I did change the max setting to 15 but did not change the data speed to highest 115200 data rate but kept it at second fastest 57600, for other considerations its not an option for me to permanently use faster speed.
Then I tested for dropouts 5 times, each time 5 min and then I rebooted and connected the units again. Everything else the same.
Effect seems to stabilize the connection a bit, variation is much lower and the average number of dropouts are down from 5 to 3 but still in every 5 min connection there will be more that 0 dropouts!

1. 4 dropouts
2. 3 dropouts
3. 4 dropouts
4. 2 dropouts
5. 2 dropouts

Worth mentioning is that even though there are Link Meter dropouts, the failsafe did not kick in, I have a buzzer that goes off if real failsafe.

Since reducing the max setting down from 250 to 15 had a good effect, are there any trade offs reducing this number further like to 1 or 2?
What does this setting do?

[hwh]

Since reducing the max setting down from 250 to 15 had a good effect, are there any trade offs reducing this number further like to 1 or 2?
What does this setting do?

Unless you carefully set it to a known unused frequency range the smaller the number the more likely that some interfering signal will block you.  The fields are what they're labeled on the screen, the minimum and maximum frequency the oplink will use.   It constantly hops between frequencies in the range you give it. The GUI restricts you to at least 11 channels (high = low + 10).  I've used the UAVOBrowser to set it to a lower range when testing but the first time you save on the oplink settings page it sets it back to it's minimum range.

If you set it so it hops between say 430 and 430.5 MHz while there's an interfering signal covering that range you'd be blocked all the time.  If it's set to the full 430 - 440 range then that 430.25 interfering signal will only block you a small fraction of the time.  If you knew that say taxicabs used 432 - 433 and something else the range 438 - 439 you could set the low to 433.1 and the high to 437.9 to avoid their frequency range.

Another consideration is local laws.  Your local laws may restrict what frequencies you can use.  You can set the min/max to restrict operation to a frequency range that's legal in your country.

[f5soh]

Maybe you can upgrade to 16.09 and try to reproduce the "dropouts" ?
Since one year, there is some fixes related to the Rssi and connect/disconnect state for OSD.

Here is a one hour scope, just put on/off the transmitter at end to show the failsafe status.
There is the Rssi, Connect state, Throttle value and Receiver status.
Rssi changes are due to various places in the house where i put the transmitter.

[TheOtherCliff]

Regulations about number of hopping channels aside, IIRC limiting the channel range to something like 0->15 doesn't limit the frequencies to the low range.  There is a translation table that is basically random, so you are actually getting 16 random channels spread evenly throughout the full range?

As an aside, the higher the baud rate, the larger the group of adjacent channels it uses simultaneously when broadcasting.  I don't remember how this relates to the translation table.