[TheOtherCliff]

I also would guess that no one else (other than OP derivatives) breaks up a 10mhz band into 251 channels.

At least for OpenLRSng, used in common UHF rc modules, the min/max limits you can use are 413-463MHz...

LP GCS shows a 4khz channel width for what it calls a channel.  When you divide 10mhz into 4khz channels, you get 250 of them, not 251 because you are breaking up the range from 430 to 440 mhz into 4khz chunks, and with that you get 250 chunks.

Speaking of OpenLRSng, it looks like they do it the way I suggested:

The best way to handle this would be to input the min and max frequency and have the code determine min and max channel centers and channel separation based on air baud rate.

[karla]

Some news here,
I got delivery of 4 new OPLM from source mentioned as okay over here ... Cliff

First I put the new OPLM in the heli and kept the other OPLM as before on the ground side.
Then not so impressive, having lower dBm and still disconnects like before.



Then decided to use them in pair, so swopped the tx side at ground to one of the new batch OPLMs. Then much better, no disconnects even operating at a lower dBm level.


This makes me think I should try the old 'bad' OPLMs in pairs, like tx and rx and see if they are good to go.

I dont understand the reasons of this, and i am really frustrated with the unpredictability of the OPLMs. They hold a big promise of ease of use if working, but seem very difficult to get to work.
The new pair is oprating with only 1 to - 1kHz correction.

[TheOtherCliff]

I bought two of the OpLink Ground / OpLink Air combination.  I can't use the Air since I don't have that kind of Revo, but I wanted the Ground because it has SMA.  Both sets show the -46khz deviation.  The RFM22B on these has the main IC chip identification ground/etched away in a square area.

My checkout procedure for anything with OP RF now includes testing (with next) with a known good OpLink for the -45/-46khz deviation issue.  I have some 1 watt RFM modules that I might get around to soldering on the bad OpLinks some day.

The best OpLinks seem to be from Kevin Finisterre : Sasquatch Labs.  All his stuff (Nanos too) seem to be OpenPilot "new old stock" from old OP store.
https://sasquatchlabs.org/product/openpilot-oplink-mini-modem-bundle/

[karla]

Is he still in operation?
Did send an email just the other days since I wanted some backup Nano and working OPLMs but never got answer back.
He has limited list of countries he can ship to...

Found these OPLMs from your other thread about good/bad suppliers (can't find that threat at the moment though).
I would like to report back where I got the bad ones.

These good OPLMs (so far) got here:
https://www.ebay.com/itm/172353558651? They also have a real store in Hong Kong and their own site http://www.porcupinerc.com

[TheOtherCliff]

I buy OpLinks, Nanos, etc from Sasquatch Labs once or twice a year.  Probably 5 orders total with the one I made just now.

I have never had problems with orders but I am in USA.  ... While writing this I ordered some OpLinks from Sasquatch since the two I had in stock ( ) were the -46khz bad frequency offset kind (OpLink Ground/Air NOT from Sasquatch).

He has the previously mentioned bundle of 2 OpLinks with some goodies for $29, but shipping is $15.  Getting 2 bundles the shipping is $30 so no quantity discount for shipping.  So I bought some single unbundled ones for $13 each because shipping was only $5, and shipping for 4 was only $6 so $14.50 each, shipped.  This shipping is to USA though.
https://sasquatchlabs.org/product/genuine-oplink-mini-modem/  (sasquatchlabs.org web store has closed)

If you want real OP Nanos, Sasquatch is the only game in town.  $25 + $4 shipping.

[karla]

Very glad to hear he is still out there
I will ask a friend in CA if he can receive delivery and resend to me.
Thanks

[karla]

Ill be darned,

This makes me think I should try the old 'bad' OPLMs in pairs, like tx and rx and see if they are good to go.

Did try the 'bad' OPLMs, one as tx and other one as rx, worked as good as the new 'good' ones.
Corrections at 0, 1 or -1 kHz and link quality similar and not disconnects.

Not sure what to make of this, but I will move on with the GPS assist

[TheOtherCliff]

So it seems that they just use the wrong frequency, and it is consistent.  It would be nice if we had an LP option to shift by +45khz so these could be used with normal OpLinks.  Even just a compile option to have two different OpLink firmwares.  I will look into doing this in the next few days if someone doesn't beat me to it. 

It worries me that when testing with a good OpLink, it runs along with -46khz offset, at say -40dBm and once in a while jumps to -70dBm.  It makes me worry that it could possibly be offset by a changing amount when compared to a good OpLink.

[TheOtherCliff]

Well that was pretty easy.  -45khz frequency offset fixed, but bad news.  The occasional 23dBm drop is still there, so it may be that individual channels need to be shifted differently, or that I have a doubly strange OpLink.  I originally called this about a 30dBm drop, but with this fix and on a different bad OpLink, I now see a 23dBm drop?

Here is the change if you want to play with it or check to see if your disconnects still happen.  I assume that your disconnects are the same as my 23dBm drop.

About line 75 in file:
flight/pios/common/pios_rfm22b.c
you will find this:

Code: [Select]

#define RFM22B_NOMINAL_CARRIER_FREQUENCY_433 430000000
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_868 860000000
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_915 900000000

Change it to this to fix the -45khz issue.  Build ONLY the oplinkmini because everything you build will have the frequency offset in it (see below how to easily disable that):

Code: [Select]

// enter whatever your delta frequency shows when that device is connected to the GCS
// my oplink shows -46khz when connected to the GCS
// if it were my Revo had this problem and the oplink was good
// then the good oplink would probably show +46khz
// which means that if the Revo were connected it would show -46khz
#define DELTA_FREQUENCY                      (-45000)
#if !defined(DELTA_FREQUENCY)
#define DELTA_FREQUENCY                      (0)
#endif
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_433 (430000000 + DELTA_FREQUENCY)
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_868 (860000000 + DELTA_FREQUENCY)
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_915 (900000000 + DELTA_FREQUENCY)
After you build oplinkmini and save off the fw_oplinkmini.opfw file to something appropriately renamed, disable this built in frequency offset by commenting out one line.  Change it from:

Code: [Select]

#define DELTA_FREQUENCY                      (-45000)to:

Code: [Select]

//#define DELTA_FREQUENCY                      (-45000)
Recall that maxing out the Xtal Capacitor tuning it would only bring it back to -17khz from -46khz, so this helps you to run bad OpLinks with other good stuff without detuning the good stuff.

[karla]

Holy macaroni Cliff
This is way beyond my level of comprehension

Maybe you are right, I do not know.
I can just add to my findings, that the bad OPLMs do not connect at all to my other Revo boards when i use them as transmitters
They are off ~ 40kHz and do not work as TXs from the ground to the flight side based Revolution modems.
However, the new ones connects just beautifully.
I will scrap these bad OPLMS...

[TheOtherCliff]

If you are interested in tinkering with it you could try the code change.  You will probably see the -45khz deviation go away.  I expect that your Revos will connect with it then, but you would need to test to see if you still get disconnects.  I bet you do.

I get random decreases of 23dBm several times a minute.  You have to watch it for 10 seconds to see it happen sometimes.

Oh yea, I guess it's possible that it is made worse by the fact that I run my channel set from 0 to 31, not 0 to 250.  That shouldn't matter, but there is an issue somewhere so it might matter.

[karla]

Last weekend I had rebuilt the crashed heli and calibrated everything and had some test rounds in the field.
.OPLM issue solved
.Vibration issue solved
.Seems the new position of the mag/gps unit is good and I swopped to a DJI one.

Before I crashed it again (basically just clumsy)  I got some experience trying Positionhold.



This initial drop issues has been discusses here https://forum.librepilot.org/index.php?topic=4155.0
If I use that next version, could I also expect this big drop in switching from manual to PositionHold to disappear?

[TheOtherCliff]

It is not merged into next yet.

If you follow instructions here to edit pid.c then you can just use the version you are already using.  It works without any changes to settings, so just change file, build firmware, flash firmware, fly. 
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197

By the way, I find that VelocityRoam is better than PositionHold since you can move around with VR but not PH and VR is the same as PH if the sticks are in the center.

[karla]

Thanks Cliff.
If I venture to try edit pid.c, will that also effect PositionHold? Not just AltitudeHold/AltitudeVario.

My final goal is GPS assist, but Velocityroam could maybe work as well, just have not tried it much yet. Thanks.
PositionHold is a useful mode for me in any case, to park the heli firmly if someone (construction workers) grabbing my arm or worse 

[TheOtherCliff]

Yes, PositionHold.  I think it is anywhere the GPS / baro are used to (help) control altitude.  So even AltitudeVario and AltitudeHold thrust modes.