[jdl]

I'd like to get some comments and thoughts about a problem I have with one Oplink module range.

Currently I have two vehicles controlled via OpLink. The transmitter module (Coordinator) is one and same, running Telemetry and Control, 57600bps. Transmitter uses DIY dipole, quite precisely made. I use 16.09 RC1.

The first vehicle, 250quad, uses Revo and DIY coil-loaded dipole for antenna. Flies happily to over 4km away without even single dropout, at some 250m height above ground. RSSI shows about -78dB @ 4km. No packet loss. Based on my experience, that quad's receiver starts losing packets at -82-83dB and loses connection at -86dB, so I expect the max range with these antennas to be about 7-8km. Pretty good, as I cannot go further than 6km and return with this quad!




The other vehicle is Wing Z-84. Revo again, and the antenna is DIY dipole, practically identical to the one on the transmitter. I expected even better performance compared to the coil-loaded dipole on the quad. Unfortunately with 16.09 RC1 I can barely get 1.3km range and start rapidly losing packets. RSSI shows values around -66db in that moment, very, very far away from -83dB (quad's receiver). Almost immediately the connection is broken and RTB engages.

The flying area is the same, and I have made numerous test flights with both vehicles one after another to exclude possible RF interference.

Yesterday I built "next" r269 and fine-tuned the Revo RFM22B module (used value 129 instead of 127). Distance test measued about 2km before connection loss, still at -66-70dB. So XTAL tuning proves to be great feature but cannot solve the particular problem. Unfortunately, I found some major imperfections with this "next", so I have to revert back to previously used 16.09 RC1.

Lockups in telemetry on the OSD started after upgrading to "next" r269. When the Revo is connected on the desk via USB cable to the GCS, no such lockups, but when connection is via radio, telemetry data from Revo to MinimOSD seems to stop in irregular intervals for some seconds. Need further investigation, though...

Sorry, I cannot upload OPL log file of the flight, seems that all log files I recorded with GCS r269 are broken, all are sized 3kB. BTW, although insignifficant, I have to report that the Link Meter gauge in PFD is also not working in "next" r269.

I understand that mapping Mag to Z plane is a new test feature in this "next". Seems nice to have it if there are problems with magnetometer but I personally prefer using Mag for Pitch and Roll too. This gives much better attitude estimation and can help with horizon drift caused by vibrations.

Also tested INS13+CF on the Wing, but test flight ended with a crash for some reason. I initiated RTB and the plane rolled (this was expected as it had to turn back to home point) and then pitched down in relatively small angle (15-20) and hit the ground at almost full throttle. Cannot judge what caused the problem. Using just INS13 works fine for me. Cannot look at the telemetry logs, as GCS spoiled them... Luckily, the wing survived the crash, no big damage, just needs some boiling water on the nose and little re-lamination

Previous lines are off-topic, but I thought it might be helpful to share these impressions.



I don't think the dipole antenna on the Wing Z-84 is guilty. It seems to me that maybe the sensitivity of the particular RFM22B module on the Wing's Revo controller has deteriorated after two crashes in the past and maybe after some soldering work when I replaced its problematic MPU6000 chip, which caused the crashes.

Do you have any other ideas what can cause such packets loss at -66dB only?

The only other thing I can think of is replacing the whole Revo board on the Wing Z-84 and repeating the tests...

[f5soh]

Signal strength looks similar in both setups, the only difference seems related to noise floor.
Can be interference or spurious from Ubec, Vtx, camera or something around.
Try moving the antenna in other place, add some shielding around expected noise sources.

First you should swap the Revo from Quad and fixed wing and know if poor noise floor performance comes from the modem himself.

Unfortunately, I found some major imperfections with this "next", so I have to revert back to previously used 16.09 RC1.

Reporting those issues should be great instead of go back to 16.09RC1. Why not using the 16.09 release instead of a RC ?

[jdl]

Thanks! Yes, I'll swap the Revos. As I currently don't want to disassemble the quad, I will use one of the two new spare Revo boards I have, which has better XTAL match with the Coordinator OpLink, and look for different performance.

UBECs are both on Matek "5-in-one" boards. They have noisy regulators indeed but that's not a problem on the quad. Of course, this means nothing... May try putting a thin grounded (and properly isolated) copper sheet between matec board and the Revo.

VTx are almost identical, Eachine TX526 and Eachine ET600R, so are 5.8GHz Aomway antennas. Distances between antennas and between the VTX and Revo are bigger on the wing. One difference with the quad is that ZMR250 has carbon frame that shorts antennas grounds... In theory that should be worse, as ground loop is created. But I previously tested the quad with 433MHz antenna ground isolated and noticed absolutely no difference.

Relocating antennas will be last attempted as I prefer to keep current setup.
I upload an older photo of the wing setup before lamination, also some minor details changed meanwhile, but major components locations are the same.

As for reporting spotted issues with "next" builds, where is the appropriate place for such reports? I like the Librepilot project and the way the development team pushes it forward. If and when I have something that can be in help or that can contribute to the project, I'll be happy to share it with the community.

BTW, I just remembered one old issue that still persists in r269 - importing previously saved UAV file to board does not restore battery sensors calibration values!


I stopped updating after RC1 first, because I'm satisfied with RC1 stability, second, because RC2 introduced a problem with telemetry when OPLink not connected, and third - laziness - seems to me that nothing signifficantly changed between the RC1 and official 16.09 to justify upgrading all vehicles I currently have (CC3D and Revo based quads and the wing), OpLink based relays (2.4G-to-433MHz with Bluetooth GCS link and back-telemetry to AT9) and their telemetry reading MinimOSDs and back-telemetry modules to Radiolink AT9 (perhaps some UAVObject IDs changed from RC1 to official 16.09, but I didn't really check that). If I'm wrong, please point that to me.

[f5soh]

BTW, I just remembered one old issue that still persists in r269 - importing previously saved UAV file to board does not restore battery sensors calibration values!

https://librepilot.atlassian.net/browse/LP-173
You should import, save, reboot and import config again after the modules are enabled/running and associated UAVOs 'writable'
Happens for all the 'default disabled' modules like battery or TxPID

second, because RC2 introduced a problem with telemetry when OPLink not connected

Are you talking about this ? https://librepilot.atlassian.net/browse/LP-408
This issue should still between RC1 / RC2 or next

Whatever the version you should not use any CF+Mag based algorithm, keep INS13 instead.

[TheOtherCliff]

Your 4km jaunts using OpLink controls are a source of inspiration.  I have Taranis transmitter OpLink conversion that got moved higher on "my list" because of your video.    Do you have your ground antenna mounted on a pole or on the transmitter?

What are you using for FPV video at those distances?  I had a 700mw 1.3ghz rig on a pole that I flew to 2km with zero fuzz.  I guess now days it would probably be a boosted 2.4ghz rig.

[jdl]

f5soh, thanks for clarifications! Import - reboot - import sequence works. Not absolutely sure, but I think the GPSSettings are imported on the first import attempt, even if GPS module is disabled in HWSettings at the moment.

I should try and migrate to official 16.09 then, as this issue  https://librepilot.atlassian.net/browse/LP-408 persists in RC1 too. No real other excuse to stay with RC1. I have some doubts that telemetry works in RC1 even if OpLink modem is not connected at boot, but I'll test and report back.

Got it about INS13+CF. Any source of info about this INS13+CF fusion algorithm?


TheOtherCliff, 10x!

The OpLink has a lot of potential, obviously. Just needs good antennas, because of low transmitter power.

Found in RFM22B datasheet it can support diversity antennas setup with a few external components. This would be a nice and exciting future enhancement for Revo boards!

As for the FPV video, this ZMR250 has 5.8GHz 600mW Eachine TX526 VTX on channel B1 (5733MHz).
The transmitter antenna is my favourite budget DYS https://www.banggood.com/DYS-FPV-5_8G-Antenna-4dBi-Mushroom-Antenna-RHCP-TX-RX-SMA-RP-SMA-Male-p-1065852.html. I found that it noticeable outperforms the not-bad-at-all Aomway Cloverleafs (my former favourites) - either for long distances, or for park flying in the woods.

2.4-to-433 relay station with dipole antenna stays on a tripod, 1.3m above ground. If I put the tripod on the roof of the car, additional height makes connection noticeable better But that day it was so windy that the tripod was blown away twice, together with the relay box, 5.8VRx and antennas and I had to put it on the ground and additionally fix its legs. Still, the distance test was a success.

For that particular 4km video (with known flight direction) the receiver was Boscam FR632, fixed below the 433MHz transmitter on the tripod, 1m above ground, with two directional antennas - Aomway 7-turn helical and TrueRC Crosshair, both pointed in the expected flight direction.

For normal range flights the same omnidirectional DYS cloverleaf on the receiver is OK for me for distances up to 2km, where some noticeable snow begins. I'm planning to build antenna tracker station (already got parts) when I have some time to spend with it. Also bought 1.3GHz VTX/VRX to put it on the wing, if and when I hit the limits of 5.8GHz. Still, the wing cannot go further than 2km with its (possible faulty) OpLink, I'll replace its Revo soon and I hope to go much further

Here is what my relay box looks like inside, not beautiful but tough enough. And a photo (other day) of the tripod with VRX and relay, this time VRX is on the top.

[jdl]

Today I scored even better result with OpLink: ZMR250 broke the 5km barrier.

Looks like a rhino with this big 3S 5200 battery wrapped in heat insulation

Was lazy enough not to put the FPV receiver on the tripod, so the glitches in the video record are due to my head movemets.





About he initial problem: I replaced the Revo board on the fixed wing with a new one. Its RFM22B seems genuine, and it has the marking on the chip. The old Revo board probably has a clone oplink module, as its markings on the chip are grounded...
The result is that the range almost doubled, but I still cannot go further than 2.5km with the wing, nothing comparable to the quad

I have to do additional simultaneous tests with both vehicles in one and same area to check if external RF interference is the culprit, or there is a "noisy" electronic module in the wing itself. There is one obvious difference between the quad and the wing - Revo board is almost "sandviched" with the switching BEC - 5mm spacers (on the wing). On the quad there is a carbon-fiber plate between the BEC and the Revo board, and the total space between them is bigger - maybe 10mm. So screening the BEC on the wing is a good idea.

P.S. I did a brief test with 16.09 RC1: Telemetry (to MinimOSD) works fine even if the Revo OpLink is not connected (on boot) to its paired coordinator OpLink module.

[Brian]

I think your problem is with the switched BEC.  We had plans at one point of making a 1W OPLink radio.  The prototypes had a switched voltage regulator on them, and the noise floor was so high from the voltage regulator that the signal to noise was no better than a standard OPLink.

I would either switch to a linear BEC or somehow shield the BEC.

[jdl]

The problem is solved! 

Thanks to all for info and suggestions!

Not having access to any RF measuring tools, I started a trial-and-error, eleminating one by one every electronic module on board. Surprisingly, the noise was coming not from the 5V 3A SBEC, that is sitting just near the Revo board, but from the voltage regulator on the Eachine 600R VTx. It backfired terrible noise through its power supply wire. After tons of experiments I managed to get rid of this noise completely without relocating anything. The solution in this particular case was shielding the power supply positive wire (PDB to VTx) - ground connected at the power distribution board side only, and adding a pass-through ferrite tube on the same power supply wire (one winding only).

This greatly improved the noise floor - link loss occured at -80dB. Still not happy, I replaced the Eachine ET600R VTx with the older model Eachine ET600 that I had as a spare, and bingo! - link loss @ -88-90dB! Either ET600R has design fault with its voltage regulator, or this particular ET600R was a defective one.

Out of curiosity, I tested if the replacement ET600 will inject noise without the wire shielding and ferrite tube, and - yes, terrible noise floor again. So, in this particular case, shielding and ferrite are mandatory!

Real life distance test results are excellent: Wing Z-84 went to 6km distance without any troubles / failsafes / lost packets and RSSI stayed around -74dB at that distance!

Low power (1.25mW) tests I did show that up to -80dB the link is 100% reliable, up to -83-85dB some packet loss occurs but there is no interruption and at -88-90dB the connection breaks.

So I expect the wing can go at least 12km away with the OpLink as control & Telemetry @ 57600bps. Of couse, using 5.8GHz for video-link requires antenna tracker (I'm just building one) or migrate to 1.3GHz VTx/VRx.


Sorry for bad quality, I got unexpected RF interference in the VRx from some nearby RF equippment, I suppose.

[Brian]

Good work!  It looks like that VTX has a switched regulator on it as well.  Obviously it's not a good one.  I'm glad you got your problem solved.

[TheOtherCliff]

I have some questions about your relay box.  I will ask here instead of PM so that others can see the answers too.

OpLink:  Are you feeding PPM in and getting telemetry out and sending it via 2.4 bluetooth board in the back left?  Have you ever had issues with 2.4 bluetooth and 2.4 RC receiver being so close?

Receiver:  2.4ghz?  Is that an SBus to PPM converter attached to it?  Is the second servo connector for power?  Also there seems to be red, black, and blue wires coming out of it and going to a board.

What is the board between the RC receiver and the OpLink for?  Is it an Arduino?  It seems to have processor signal markings on it in addition to serial markings.

Is everything powered with 5V from the center power supply?  2 black external connectors look like they go to the center power board.  What are they for?

[jdl]

OpLink: Exactly - PPM in, coming from the 2.4G receiver. The bluetooth (HC-06) is used for connection with GCS on the laptop - telemetry and sometimes changing the FC parameters. Never had any issues running both 2.4G modues so close, but I've never used the relay box too far away from the RC transmitter (Radiolink AT9) - less than hundred meters typically. The bluetooth link with the PC is also stable in the 10 meters range.

The 2.4GHz receiver is Radiolink R9D. It has SBUS output, so I had to use this SBUS to PPM converter. The second servo connector is for power.

The Arduino board listens the UAVTALK stream from Oplink. It gets some data from respective UAVOs (GPS Sats, Position, Altitude, Distance, Pitch, Roll, Yaw, Battery voltage, etc.) and then sends it through I2C to Radiolink R9D (the red,black,blue wires). The R9D itself transmits this telemetry data back to the RC transmitter (AT9). Useful for warning if battery is low and for having the most recent GPS position on one more display if something bad happens during flight.

All modules are powered with 5V from the switched voltage regulator (center board). XT60 connector (yellow one )on the side wall for battery connection. I've used (just for peace of mind) additional LC filter after the voltage regulator.

The thick black cable from OpLink USB port to the side wall of the box is just an USB extention cable.

[TheOtherCliff]

That's everything I needed to know, but for curiosity, what is the other external black connector?  Power switch maybe?

And great setup with the Arduino helping send FC telemetry back to the RC transmitter!  I'm jealous.  Do you know of a project where someone has already done that for FrSky/Taranis (even for some other firmware like CleanFlight)?

[jdl]

but for curiosity, what is the other external black connector?  Power switch maybe?

Sorry, I cannot spot the connector you are talking about? May I ask you to encircle that object on the photo and post it back?

And great setup with the Arduino helping send FC telemetry back to the RC transmitter!  I'm jealous.  Do you know of a project where someone has already done that for FrSky/Taranis (even for some other firmware like CleanFlight)?

I was really happy when I managed to send the telemetry back to RC transmitter Spent weeks digging the web for pieces of info regarding the I2C protocol between RC receiver and its PRM2 module (Radiolink proprietary). Found them in Russian and English forums, don't remember exactly where, but I can check if necessary.
And, sorry, no, I have not looked for or accidentally stumbled upon similar project for FrSky/Taranis. Taranis was too expensive for me when I started in the hobby and not knowing will I stay there for longer, I looked for cheaper alternative. I must admit I was lucky to buy Radiolink AT9, it proved to be an excellent option for me! After swapping the antenna with 5dB one, I'd got easily over 2.5km reliable range on 2.4GHz with it.

[TheOtherCliff]

Sorry, in a hurry just now.  One black connector is at the bottom left and the other is at top, next to the yellow XT-60.  It may be a power switch.