MAVLINK stream via WIFI on ELRS backpack

[Christoph-Hofmann]

It would be nice to have the possibilty to see the telemetry (gps;speed;hight) on a laptop/tablet.

A subset of Mavlink should be enough for this feature.

kind regards
Christoph

[sweebee]

Looks similar to this one #636. Although a bit "broader". BLE is more reliable and faster than wifi.

[Nordle420]

yesplease

[CapnBry]

I'm also tagging #390 in this because all three Issues are requests for spitting out telemetry via Bluetooth / Wifi over various protocols.

[0crap]

noplease, stick to the core functionality that makes ExpressLRS so good and forget all this telemetry crap.

[sweebee]

@0crap thats your opinion, a lot of people will disagree. The backpack is made for stuff like this. Good thing this is open source ;)

[0crap]

@0crap thats your opinion, a lot of people will disagree. The backpack is made for stuff like this. Good thing this is open source ;)

It sure is, nothing wrong with giving an opinion is it....

[wucke13]

Maybe it would make sense to streamline the three issues related to this feature (#390 , #636 & #672).

What do we need

1. A transparent, bidirectional data link, able to transmit arbitrary bytes
2. The link should be robust, e.g. a loss of a single frame should not result in a loss of transmitted information (otherwise using MAVLink for example will be close to impossible)
3. The link should be exposed as two pins on the RX side (in the for of a serial port)
4. On the TX side, the link should be exposed either as serialport (two pins, makes a HW mod for the latter easy) or via Bluetooth/WiFi/Whatever
5. The communication link needs to be fully optional. If a user does not want to use it, it should bear no extra cost during transmission than completely without it.

Completely orthogonal to that is how this is used.

Use cases

• MAVLink connection for QGroundControl
• MSP connection for wireless configuration of BF/INAV
• Literally any other application which requires a transparent, byte oriented data link

Also interesting

would be if this is instead of or parallel to the normal telemetry (SmartPort, ...) if that is ever supported by ELRS.
Then of course also there could be additional apps attached to ELRS which somehow process the data. This however should be out of scope for ELRS, IMO. Keeping the complexity low and only making ELRS responsible for the data link, not any data processing already might be considered as bloat by some.

Please feel free to comment anything which I missed, I'm willing to collect anything back in this comment. I'd rather prefer having a new fresh issue for this, but I do not see the point in opening a fourth issue asking for basically the same functionality.

[0crap]

Please feel free to comment anything which I missed, I'm willing to collect anything back in this comment. I'd rather prefer having a new fresh issue for this, but I do not see the point in opening a fourth issue asking for basically the same functionality.

Sure, what you missed is that the majority don't need this. (The ones you also don't hear on these topics.)
So please add to the list that this feature should not imply a performance hit for everybody. (Sensitivity, packet rate, ....)
That would disappoint a lot of users.

[wucke13]

@0crap I think by now everybody who read the comments above will know that you're not a fan of this feature. I do not think there is any value in it if you reiterate the same point.

However, I totally see your point regarding the performance hit for everybody. It's my understanding that ELRS is very configurable, and this should be no exception.

[0crap]

@wucke13 It has nothing to do with me, it's about consequences that new features might have.
I just replied on topic to your question if you missed anything. So don't give me that.

The second part of your reply is on topic, thank you.

[jonas-koeritz]

Without extra hardware on the TX side of things getting yaapu's telemetry script to work with Ardupilot on the copter through ExpressLRS would be a game changer for me. I'm currently using TBS Tracer for two of my quads because of this. I just need the Log messages to see what the thing is doing, no need (for now) to get a full Mavlink stream through ELRS, but that would be perfect of course.
To not interfere with other people's use cases this should be hidden behind a config toggle, I would happily give up some control rate for a nice, high bandwidth telemetry link.

[Moksh-2000]

Please feel free to comment anything which I missed, I'm willing to collect anything back in this comment. I'd rather prefer having a new fresh issue for this, but I do not see the point in opening a fourth issue asking for basically the same functionality.

Sure, what you missed is that the majority don't need this. (The ones you also don't hear on these topics.)
So please add to the list that this feature should not imply a performance hit for everybody. (Sensitivity, packet rate, ....)
That would disappoint a lot of users.

Hey sussy you don't know meaning of telemetry data on autopilot any RC models , it's only way to know what I'm doing and what my copter doing on air with windding with air so stop thinking this feature is not useful , @wucke13 you are absolutely right avoid this don't knowless person , and keep going on in also going to pull request but here I'm

[wucke13]

@Moksh-2000 While we seem to stay on the same side of the matter, we do not stand on the same site regarding the communication. I think its clear that the feature would be valuable for many, and harming for many others (hence it needs to be optional). I mean, there is a reason why ELRS has higher range on lower latency than FRSky Archer stuff despite both being based on the very same HW (Semtech Lora Chips).

[sweebee]

I’m sure this feature won’t harm the performance/latency in any way. This feature needs the backpack to send this data via WiFi or BLE. The backpack is currently not used at all. The main processor handles all the radio data.

But you need a tx with a backpack ofc.

[jonas-koeritz]

I'd be happy to trade some latency for a reliable data link any time. Of course making this optional (via a build flag?) would be of help to keep the latency low for the racers. My 12" will never need a super low latency link but it would benefit greatly from Mavlink connectivity.

[wucke13]

I’m sure this feature won’t harm the performance/latency in any way

I'm not a signals expert, but to me this looks pretty simple: If you transmit additional data (the telemetry), then you transmit more symbols (as in bits) per frame containing new controls. More symbols per frame -> requires higher bandwidth -> results in lower range if transmission power and update rate remain equal. So IMHO, the very opposite of your statement holds true: enabling (and then using this feature) would harm the performance. This has nothing to do with the processing power, but the RF link.

I'd be happy to trade some latency for a reliable data link any time

Perfectly valid. I too. But we must recognize that this is not the only view, ELRS is special precisely as it allows low latency without sacrificing range/reliability.

No one doubts that the feature is useful for some, it's just also conflicting with the performance metrics which are important for some others.

[sweebee]

I’m sure this feature won’t harm the performance/latency in any way

I'm not a signals expert, but to me this looks pretty simple: If you transmit additional data (the telemetry), then you transmit more symbols (as in bits) per frame containing new controls. More symbols per frame -> requires higher bandwidth -> results in lower range if transmission power and update rate remain equal. So IMHO, the very opposite of your statement holds true: enabling (and then using this feature) would harm the performance. This has nothing to do with the processing power, but the RF link.

I'd be happy to trade some latency for a reliable data link any time

Perfectly valid. I too. But we must recognize that this is not the only view, ELRS is special precisely as it allows low latency without sacrificing range/reliability.

No one doubts that the feature is useful for some, it's just also conflicting with the performance metrics which are important for some others.

Yes you’re right about additional data. But I personally don’t need mavlink, only telemetry data to my phone. For that there is no additional data needed.

[Moksh-2000]

I'd be happy to trade some latency for a reliable data link any time. Of course making this optional (via a build flag?) would be of help to keep the latency low for the racers. My 12" will never need a super low latency link but it would benefit greatly from Mavlink connectivity.

I'm still wondering why all people need low latency because video have 20 to 50ms so why radio link below and there for nothing you can change

[jonas-koeritz]

How about just supporting CSRF-Passthrough telemetry (packet types 0x7F and 0x80) for now? This would fit into the existing telemetry bandwidth (I assume) and shouldn't have any impact on packet rates or any other ELRS qualities. Ardupilot is supporting it (in latest versions) and the yaapu script will be fine handling it.
I'm not very familiar with this codebase but I think ELRS currently just throws away packets it doesn't understand. Passthrough would be just handing them over to the TX transparently.
Maybe @yaapu could have a look at this too? I'd love to run a fully open source software and hardware stack on my copters.

[0crap]

I'm still wondering why all people need low latency because video have 20 to 50ms so why radio link below and there for nothing you can change

The fact that you don't understand it doesn't mean it's not a good thing.
Low and consistent latency is one of the key features of ExpressLRS.
We like to keep it that way.
Otherwise grab a ppm receiver and let us know your results.

Don't forget, ExpressLRS is not designed to be a replacement for TBS crossfire and the like.

[sweebee]

I'd be happy to trade some latency for a reliable data link any time. Of course making this optional (via a build flag?) would be of help to keep the latency low for the racers. My 12" will never need a super low latency link but it would benefit greatly from Mavlink connectivity.

I'm still wondering why all people need low latency because video have 20 to 50ms so why radio link below and there for nothing you can change

The lower the latency the better, because the latency is added. You have to account for the whole latency loop.

[markandkymward]

I too am very interested in this feature and I'm waiting to confirm it will exist before moving over. Any consensus?

[padcom]

@0crap You say ELRS is not designed to be a replacement for Crossfire... a) how do you know that? b) does it mean it can't and won't do it? c) what is your role in the decision-making process?

Kinda depending on where you are in all this, it should either be a compilation-time setting (at least on the RX) or a runtime setting for both RX/TX (much like wide switches recently in 2.0)

Also, there are different link capabilities that are interesting for different types of flying. For long range cinematic stuff on a self-leveling drone, you're mostly interested in having communication between your drone and the ground station. In the case of racers, freestyle and other flippidy-floppy around the tree, low latency is very important. I don't see a reason why ELRS wouldn't have different modes of operation, even one with more than 12 channels and/or transparent telemetry passthrough.

[fabi9163]

If the backpack would only outputs the telemetry from the main-esp via Wifi there wouldn't be additional delay, right?
You could connect with the smartphone and use apps like "telemetry viewer" to search for lost models or view the flightpath