[micheleamerica]

Hi forum
As I've got a few Oplink minis available as well as an FC without an embedded radio, I'd like to know if it would be possible to use two Oplink minis running LP, one in my remote and another in a vehicle connected to a FC running something other than LP, like BF or CF.
The point being that the Oplink mini on the vehicle would receive control data from the coordinator and supply a PPM (or other type of) signal to the FC running the other firmware, and (if possible) receive telemetry from the vehicle to send to the coordinator.
Would such a setup work? Does this even make any sense?
Thanks for any inputs on this idea.
Regards
M A

[f5soh]

This is possible, take a look here: https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/2818098/OPLink+Configuration#OPLinkConfiguration-Telemetry+RemoteControl+Bluetooth

You may need to select "Serial" instead of "Telemetry"

[micheleamerica]

Thanks for the quick reply.
I'm going to try it.
Regards
M A

[TheOtherCliff]

It looks like you are trying to do this for non-LibrePilot firmware.  It would really be best to get help "over there" because you will need to configure the FC and ground station according to their directions.  Our options won't help you configure their firmware and laptop.

That said, I have a couple APM telemetry boards that I got working with LP for about $18 shipped (now).  I would look for hardware that works natively with CF and spend an hour making extra money rather than 10 hours trying to find someone who has connected together what you have.

http://shipow.github.io/cleanflight-web/docs/telemetry.html

[micheleamerica]

Hi TheOtherCliff,
You are right in assuming that I'm trying this to (also) use non-LP firmware. This is mostly out of curiosity regarding the ability of the LP firmware on those particular pieces of hardware to fulfill their role when applied only to the air-interface.
I use a Turnigy 9x radio converted to use an Oplink mini plus a Bluetooth adapter as my main controller, and I'm trying to assess if LP on Oplink minis can replace a "regular" air interface based on other protocols/frequencies. I'd like to keep this radio (as it is today) and have some leeway on the FC/firmware I get to try out using that same radio.
I'm sure I'll need some help from "the other side" (BF, CF, iNav...) at some point in time... and please be sure I'll go there for help if and when required
In any case I'm thankful for all reactions/opinions/information I can get from this forum.
Regards
M A

[TheOtherCliff]

It sounds like what you are trying to do is to get the OpLink to act as an un-intelligent serial device that doesn't care what the protocol is.  I may be wrong, but I don't think it can work that way.  As far as I know, the airborne packets and the USB packets are required to be OP/LP UAVOs.  Those APM telemetry boards I talked about can be configured to act as a simple serial link, and that is how I got them to work with OP back in the day.

[micheleamerica]

It is more or less that yes.
I've made a simple diagram (attached to this post) showing how I thought things would/could work regarding the way data is encoded/decoded between the different protocols on the different interfaces.
Does your answer means that my assumptions are wrong?

[f5soh]

There is no issue here, this diagram will work.
Serial is transparent and you can access to a remote GPS (with stored/fixed baudrate) connected with serial over OPLink, same Serial link can be done for MAVLink as well.
If using Control, the serial link is done using the auxiliary stream redirected in OPLink ports in both ends.

Do you use the 16.09 or next ?

[f5soh]

Here is the configuration using Next matching your diagram and assuming the serial baudrate needed is 57600bds.

[micheleamerica]

Hi f5soh
Thanks for the information. Seems like I'll be able to do it after all.
For the time being I'm using 16.09. I've successfully compiled next on windows but is a version flagged "dirty" (I suppose the automated build noticed something not quite right) and for now I prefer to stick to the stable version.
Further, and as I'll be using the same radio (with a 16.09 OPlink mini) for both my current LP 16.09 Sparky2 and my future BF/CF/iNav FC (with the setup as I described) I'd rather stick to one single and stable version.
One day I'll indeed consider upgrading everything to next (when things get more stable), but not for the time being.
In any case, and again, thank you.
Regards
M A

[f5soh]

Current Next is even stable as 16.09 and also fixes issues

So, if you want to use 16.09, here is the diagram with configuration.
Still assuming the serial baudrate is 57600.

[micheleamerica]

Hi again f5soh
Thank you so much for the detailed answers.
Regards
M A

[TheOtherCliff]

"Dirty" only means that you have modified it since getting the source and it is not a "Release" version.  It is not a bad thing.

You should standardize on one version; 16.09 or the same version of next everywhere (OpLinks and FCs that run LP and LP GCS).

[micheleamerica]

TheOtherCliff
Thanks for the detail. In any case as far as I know I did not modify the next release after pulling it out with git before compiling, but I can see how easy it would be that some files generated by the build process would result in that "dirty" flag.
In your opinion is next up to par with 16.09 in terms of stability and reliability?
The only thing that will be less interesting is having to convert my settings to the next version (screenshots of all 16.09 screens/tabs to make sure I lose nothing plus a full export of the UAVObjects, both GCS and UAV).
In fact I was even thinking on trying to develop a quick and dirty application that would convert 16.09 settings into next settings, giving reasonable values to new settings or just keeping the default values. Do you think this is something that would be interesting?
Regards
M A

[TheOtherCliff]

In your opinion is next up to par with 16.09 in terms of stability and reliability?

I would listen to @f5soh about that.  Next has many new and interesting features and bug fixes too.

I was even thinking on trying to develop a quick and dirty application that would convert 16.09 settings into next settings, giving reasonable values to new settings or just keeping the default values. Do you think this is something that would be interesting?

That is something that would be very nice and has been discussed before.  It should take a '16.09' UAV file and produce a 'next' UAV file (or generally version X to version Y).  I currently do this file conversion by hand when I upgrade.