[TheOtherCliff]

Questions: 

1 - It is a style of OpLink that I liked because it has an SMA connector on it.  It also has the CPU/MCU mounted diagonally.  Does your "bad OpLink" have an SMA connector and have CPU mounted diagonally?

[f5soh]

The tuning feature was added to support correctly those OPlink version with cpu diagonally mounted + SMA called "OPLink Ground" or "OPLink Air".
Since they are tuned, there is no issue. Sometimes, when frequency offset is too big a "untune" is needed into the other side.

[TheOtherCliff]

I wanted to know if his OpLink was the same as mine which might say that his can't be tuned (without untuning others).  And mine does this thing where it drops 30 dB and then comes back up to "normal" in 10s of seconds.  That could be his disconnects.  I had complete disconnect with this bad OpLink at 50-100mw and good antennas at only about 200-300m.

It might be good to have code that actually adds a constant number to the frequency divisor.  It should be simple to hard code for a test.  Doing that would require configuring to not use the top or bottom channel.  Could even offer this hard coded version for +40khz and another for -40hkz for a quick fix.    Or does it only for certain channels if that is required.

[f5soh]

It might be good to have code that actually adds a constant number to the frequency divisor.  It should be simple to hard code for a test.

I wonder how you can play with divider in one side and get a matching set of channels with the other side.
Quick fix is use the tuning feature, as documented by the manufacturer.
From user point of view, moving the slider in the OPLink tab, saving and check the AFC value.
40Khz can be done easily and even if small AFC value still, there is no issue where a oplink cannot connect at lower rates while untuned.

[karla]

Sorry for delay. Here are some answers.

. yes, both OPLMs are set for data and control
. yes, both have Xtal capacitor set to 127
. no, the bad OPLM has the standard MMCX antenna connector and CPU not mounted diagonally (see pic)
. yes, I will keep the OPLM that nomally work with little AFC corrections (-4Khz I noticed when connected to a Revo)
. When changing the air data rate to 256000 the AFC correction goes to a steady Zero!?
(but the RX Good drops to just around 15% and it disconnects and reconnects every 2-3 seconds)

Cliff, It seems I do not get disconnections at a distance where I have about -40dBm. I can first make it happen  at lower then -65dBm.

[TheOtherCliff]

@karla it sounds like your 256khz test is so bad that it can't even calculate the deviation correctly.  That is my guess anyway. f5soh talked about it working better at lower data rates.

It might be good to have code that actually adds a constant number to the frequency divisor.  It should be simple to hard code for a test.

I wonder how you can play with divider in one side and get a matching set of channels with the other side.
Quick fix is use the tuning feature, as documented by the manufacturer.
From user point of view, moving the slider in the OPLink tab, saving and check the AFC value.
40Khz can be done easily and even if small AFC value still, there is no issue where a oplink cannot connect at lower rates while untuned.

I tried next and even with full tuning offset, it (my bad OpLink with 46khz offset) was not even close to 0khz.  I tried larger and larger tuning offset so it was not that I went too far.

I am assuming that all channels are off by 46khz, so shifting all channels by say 40khz (one standard 40khz channel width) in the correct direction would bring all channels to "just off by 6khz".  If it is "just some (not all) channels are off by 46khz" then it would need a list of which channels to perform offset on.

With his OpLink off by 45khz and mine off by 46khz it seems that there is a batch (of clone RFM22B) that have this same problem.  If a fixed offset works then it would be easy to hack a firmware that everyone with this problem could use.

[f5soh]

That is my guess anyway. f5soh talked about it working better at lower data rates.

No, it's the contrary.
While using faster baudrates the Tx deviation is wider (150 khz@256Kbps) and also the Rx bandwidth is a bit wider than tx deviation so a 46Khz offset has less effect using faster baudrate.
This also mean a untuned OPLink will not connect at all using the "PPM only" (control) @9600bps.

If the disconnect issue still @256Kbps, you can assume the issue is not related to fine tuning.
Can you try changing the channel range (like min 80 - max 120) and look if you get similar disconnects ?

If it is "just some (not all) channels are off by 46khz" then it would need a list of which channels to perform offset on.

All the channels will have similar offset assuming they use the same reference clock.

[karla]

Tested 100kbps air data rate, 1.25mw power, Bands from 80 to 120.
That gives around -75 dBm, AFC correction at 64-65kHz and lots of connects and reconnects.
I did not provoke it by walking around, sitting still, location of tx and rx same as before.

Then tested with all else same but changed over the air data rate at 256kbps
Then its same dBm, AFC correction at 0kHz but more disconnected than connected. But if just improve the location ot the tx a little bit, then connected with disconnects like above.

[f5soh]

When using a Revo or a Sparky2 you can do a simple test allowing to monitor both sides at same time.
Oplink ground still connected using HID and give the local RSSI.
Remote radio stream is redirected to VCP and a second GCS window can show the remote RSSI from Sparky2/Revo.
This test can highlight one side not transmitting correctly or one side with noisy Rx.

[karla]

hm... yes I have been thinking, how this link looks from the Heli side, so far we only monitor from the OPLink ground perspective.

I have an OPLM unit on the Heli side, not a Revo/Sparky2. Can your set up be accomplished in such case?

I notice you use Link type Data and not Data and Control, as in my case. Will it make a difference for the radio link quality (Control being more important than Data) if I change to Data only?

Also, for the OPLink ground I use a bluetooth link to PC, will it make a difference to the radio link quality if I connect it via a USB cable?

[f5soh]

Dual monitoring can be done only using a revo/sparky2.
Data or Data+Control do not change anything about the disconnect/connect behaviour, just a little more data to send from ground to air.
Since your bluetooth link do not cause issues using others remote, it will work the same using the remote oplink in this particular setup.
Bluetooth module will not disturb the UHF link since the frequency is above.

You should change your remote Oplink and see if issue still, or fix the modem in your Revo.

[TheOtherCliff]

By the way, are there actually 251 (40kHz) channels (0 to and including 250)?  It seems to say that we put a 40kHz channel at 430.0 mhz which would actually splatter down to 429.980 and the same at 440.0 actually goes up to 440.020

It should be 40khz channels centered at 430.020 through 439.980 for a total of 250 channels?

===================================

That is my guess anyway. f5soh talked about it working better at lower data rates.

No, it's the contrary.

This is the piece that made me think you implied lower rates are easier to connect. 

40Khz can be done easily and even if small AFC value still, there is no issue where a oplink cannot connect at lower rates while untuned.

(can always connect at lower rates, so maybe there is an issue at higher rates)

Can you try changing the channel range (like min 80 - max 120) and look if you get similar disconnects ?

Assuming that KarlaDisconnects==Cliff-30dB I tried changing channel range from 0-31 32-64 16-47 1-32 I forget now.  Still had same 30dB drops.

If it is "just some (not all) channels are off by 46khz" then it would need a list of which channels to perform offset on.

All the channels will have similar offset assuming they use the same reference clock.

That is my assumption too, but I am at a loss to explain why there is a -30dB change in RSSI sometimes (while showing constant 46kHz deviation), so I wonder if these clone RFM22B have some problem such as only some channels are offset.

[f5soh]

It should be 40khz channels centered at 430.020 through 439.980 for a total of 250 channels?

What's the issue here ?
We simply talk about the nominal frequency, like every transmitter/receiver in the world and user need to define the min/max channel according to the local regulations.

[TheOtherCliff]

Nominal frequency at 430.000mhz with 40khz width is actually a range from 429.980 to 430.020
Transmitting on 429.980 is illegal (but OK in USA).

Same at top end where if it truly is nominal frequency of 440.000mhz then it actually is a range from 439.980 to 440.020 ... and transmitting on 440.020 with this license is illegal everywhere in the world.

Splitting 10mhz of band (from 430.000mhz to 440.000mhz) into separate 40khz channels yields exactly 250 channels, not 251.

it is like saying the band is from 10.0 to 20.0 with bandwidth of 5.0
you should have just two channels, one from 10 to 15 and another from 15 to 20:
- a channel from 10.0 to 15.0 with center at 12.5
- and another at 15.0 to 20.0 with center at 17.5

but we have 3 channels, one centered on 10, another centered on 15 and third centered on 20:
- a channel at 10.0 which is really from 7.5 to 12.5
- a channel at 15.0 which is really from 12.5 to 17.5
- a channel at 20.0 which is really from 17.5 to 22.5

I raise this because the hardware may not even allow 251 channels and that may also cause an issue.  It could even be that the clone RFM22B is working correctly, but handles a presumed 251 channel setup differently than the authentic RFM22B does.  I don't think this is it because I have personally tested it with it configured to avoid channels 0, 124, 125, 126, and 250.

I just wonder if you already know what goes on in the code and have an answer to this.

[karla]

Okay, thanks for all answers and advice both of you.
/Karl