[karla]

Is RC control over telemetry also supposed to work on LP 16.09?

[f5soh]

No, this feature is introduced with LP-548

[karla]

okay thats why
I think this is a really nice improvement.
Seems so redundant to have a separate PPM thing going separately while you have a perfect data communication going anyway with telemetry.
I have some unexpected results using it though and maybe I start a separate thread about this.
It feels very much worth it to get it running smooth.
Thanks a lot
Karl

[TheOtherCliff]

One of my new, cheap clone OpLinks has a 43khz AFC Correction shown when testing it with next.  That is more than a whole 40khz channel.  It seems to work better than expected in low power testing, but one of the things I noticed was that the Rx Level jumps back and forth from OK (say 50) to bad (say 75) without moving anything.

If I were to move these apart a little more, the 75 would turn into a regular drop out like you are seeing.

I suspect that the "channel order" of this device doesn't match the good devices.  "Off by one channel" would cause the 43khz AFC Correction, but maybe the "channel order table" (actually frequency synthesizer divisor) is wrong in other ways too.  I have played with the min and max channel settings (didn't help).  I could have tried different combinations of OpLinkSettings->HopChannel but I just grabbed a different OpLink when I found this problem.

[f5soh]

OpLinkSettings->HopChannel setting is related to OpenLRS, nothing to do with OplinkReceiver or OPlinkCoordinator usage.
In all cases the OpLinkSettings->HopChannel do not need changes at all, this is populated according to the OpenLRS binding and updated on binding.

In OPlink setup channels used for hopping are simply generated using min/max channels defined by user.
Since the limits are the same in both devices the channel list are the same and "in phase" in both devices.

Except if you are using low baudrates the frequency deviation (and almost channel bandwidth) is set as follow:
 100 kbps - 60 khz
 128 kbps - 90 khz
 192 kbps - 128 khz
 256 kbps - 150 khz

A AFC correction is not really a problem at short range but a Xtal tuned (aka AFC~0Khz) can help for quick reconnect when link is lost at larger range.

[xfce]

Hi all,
does GPS assist flight mode have be supported by Heli now ?

[karla]

Hi xfce, nothing has changed yet.
Still working to complete a successful position hold using Next.

The progress is
. verifying, setting and using Collective as Thrust and using Governor mode on heli ESC, this works as expected using AltitudeHold in Basic AttEstAlg.

The remaining issues for me are
. the RC control and telemetry is not stable, many unexpected failsafe's.
. vibrations must be sorted out before even attempting INS13 AttEstAlg and position hold.
. the compass had too much disturbances last time (have changed to a DJI unit now).

Please go ahead and try it yourself.
You need to change setting the FlightModeSettings > DisableSanityChecks to True.
Otherwise it will be a Red CONFIG.

[karla]

Lots of work here, will not bore you with it all but seems
. I got the RC control and Telemetry okay now (touch wood).
. the vibrations under control (sooo much time to locate it and order new parts).
Done AttEstAlg Basic and next is to do INS13 and see how the new compass will behave.
/K

[karla]

Oh, two steps forward and one step back today ...

Good news first

Very happy with the AltHold using AttEstAlgo basic, really!
This Heli is an align trex450L with the onboard ESC set to Governor mode, and the LibrePilot GCS set to
System - SystemsSettings, ThrustControl = Collective (not throttle)
This setting is not often around here ...

The video show that after the sudden drop of altitude its all controlled by the LP fc on AltHold with EstAttAlgo basic. Lovely, who could ask for more?
Maybe the initial drop is to adjust the setting in Settings, AltitudeHoldSettings, ThurstLimits - neutral?



This could go one forever keeping the Altitude and felt very stable.
But then I had a disconnect of the radio control channel.
This have nothing do to with barometers, but a lot to do with OPLM.



1. There is a disconnect and system goes to fail safe. Means Throttle zero and collective up 70% to let it land smooth.
2. Pilot understand the state and switch to Attitude mode (not AltHold).
3. System OPLM reconnects and resumes controls.
4. Pilot fighting to get control and land
5. Successfully land.

I am unable to locate the problem of the disconnect of the OPLM


I have attached the Config file as well as the log file from the whole flight below if anyone can spot something to change.

[TheOtherCliff]

If you are using "next" there is an issue with AltHold/AltVario; it drops and then holds:
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197

If you have good antennas, you do not need much OpLink power to fly locally.

One of my OpLinks has an issue.  It seemed to work.  I finally tested it with next and the tuning is off by 46khz (too much to tune) and the RSSI signal level looks OK for a while, but will suddenly jump down about 30db and then will come back up to normal.  I am just suggesting that for a bench test you run everything at 1.25mw and just watch the RSSI and error/reset counts.

Also, your OpLink/Revo must have matching Data+Control on both sides.  You shouldn't have for instance Control Only on one and Data+Control on the other, or Data Only on one and Data+Control on the other.

[karla]

Ah, I saw that post but was not sure it was about this issue. I can live with this, no problem at all.
Good to hear also others have 'mysterious' drop of signal. This is the 3rd OPLM I am testing.
I thought it was was a good one.

I tested having both OPLM units connected indoors at 1.25mw.
Heli is in another room with a concrete wall in between. It appeared stable to me, OPLinkStatus RSSI show mostly less than 10db fluctuation, like between 68-78db, mostly 3db fluctuation during any 1 min period of time. I don't know if normal or not but AFC correction usually at 45khz or more. Typical values in picture below.



However, if I move around in the room, (tx and rx are stationary, but i move) then there will be short disconnects, like in the picture, and similar to when I was flying. In the picture and in the attached short log file (some 30 seconds) there are 3 disconnects with immediate reconnects, just to show it.



Is this normal behavior? I think its surprising it goes from a pretty good signal to a total disconnect directly. I would expect the signal to drop much lower first then lose connection. Right?

If I was flying, this would have been a failsafe and most likely a crash.
In the flight video i was using 100mw at both OPLMs and was standing not more that 10m away.

I have tested the OPLM units and there are no short circuit in the antenna like some have.

[f5soh]

I don't know if normal or not but AFC correction usually at 45khz or more.

You should not see big AFC value like this, this mean at least one side is untuned.
Check if the Xtal frequency value is set to 127 in both sides.
You should keep the side usually working with zero AFC value with others OPLink devices with a 127 value.
Some Oplink clones like the one provided with Revo mini will need tuning.

Before changing xtal value you may try increasing the air data rate to 256000 if the disconnect issue still.

[TheOtherCliff]

I had problems where it was 46khz off and tuning would not bring it all the way back.  I don't use that OpLink any more.

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?

2 - I wonder if it is the clone RFM22B module that is the issue.  I have several other clones with no problems, but this OpLink even has the CPU/MCU mounted diagonally where the originals have it mounted square to the PC board.

It may be coincidence but I get the feeling that it is off by whole 40khz channel width which may mean that it is a problem with the frequency synthesizer, maybe something wrong (crystal, tuning cap, code, etc.) with the clone RFM22B.   I am actually hoping it is a bad RFM22B and that I can reuse the OpLinks by replacing the RFM22B (I have two of these OpLinks, I haven't tested the second one).  I already have the 1 watt modules. 

[TheOtherCliff]

However, if I move around in the room, (tx and rx are stationary, but i move) then there will be short disconnects...

Is this normal behavior? I think its surprising it goes from a pretty good signal to a total disconnect directly. I would expect the signal to drop much lower first then lose connection. Right?

OpLink disconnects/reconnects are not normal, at least I never see disconnections at -70dBm with my good setups.

I loose link at maybe -85dBm.  You are playing around -70dBm.  I see a drop of about 30 dBm sometimes.  -70-30 is -100 which would be disconnected.  For a test, do you get disconnections at a distance where you have about -40dBm?  At that distance, -40-30 is -70 and maybe you will stay connected.  This may show that you have the same issue I do.  Well it is a thought anyway. 

Then again, I have two of these OpLinks and I should test them together to see if they then work correctly so we know they are all "bad" and the frequency is always wrong for some reason.

[karla]

Thanks guys, let me digest this and come back