Transmit Betaflight MSP "SET_NAME" packets from tx to fc

[jappyjan]

What does this add?

This PR enables the transmission of Betaflight SET_NAME MSP commands for setting the "Craft Name" field.

Why should we add this?

In order to support (e.g.) racetimers sending lap time information and other messages to the OSD,
currently Betaflight does not (yet) support such information in a native way so we "abuse" the craft name field (like DJI V1 did ^^).
Once Betaflight supports this type of information we will refactor to use whatever new logic will be there...

Any reference to how this will/is beeing used?

I am working on an extension/PR to this RotorHazard plugin, which displays lap time information in FPV Goggles using a variety of techniques.
https://github.com/i-am-grub/VRxC_ELRS

This is my Fork, though its not yet 100% complete, therefore no PR exists yet.
https://github.com/UAV-Painkillers/VRxC_ELRS

[CapnBry]

Hey, jappyjan! I'm interested in the work you're doing to integrate this sort of information directly into the BF OSD. I want to start off with the positive because the rest of this message is going to be a real downer....

Queueing this MSP command from the backpack to the TX module to be sent over the OTA causes a few major major (sic) problems:

1. When the TX module has data to send (MSPSender is not empty), telemetry turns on in 1:2 mode. This will absolutely destroy performance of the link during a race because it will start running at half packet rate.
2. If the packet were sent, it would have to be split across multiple TX packets with multiple acks, unless the payload was 4 bytes or fewer, which it does no appear to be. This consumes uplink bandwidth that could have been for channels data to help win the race instead of for informational purposes.
3. Also if the packet were to be sent and not telem boosted: Racers should be running RACE telemetry mode. This means there is no telemetry while armed and the MSP packet will not be sent at all. Or rather that it would try to be sent over and over and over and over again until it times out in like 100 retries or whatever.

It is likely this "just works" in its current form but if you look at what is happening under the hood to the link, I believe it should be obvious that we can't send data during a race that isn't channels data. Maybe for practice it is fine, but nobody is going to read the docs to know they shouldn't be using this at an event.

I'm not sure if there is any resolution to these issues, so I think the only way this might be considered is to receive the ESP-NOW at the RX end of the link. However, I am not sure that's a great idea either as it might degrade the performance there due to the extra CPU usage, power / heat cost of running the wifi at the same time as the RF, or having ESP-NOW ack transmissions clobber the receiver functionality.

[pkendall64]

I have to agree with @CapnBry, there are just too many downsides to this approach.
There is the ability to send OSD messages to some goggles already, notably the HDZero goggles and I think the TBS fusion module. This is a far better approach as it does not interfere with the main control link.

[jappyjan]

Hello and thanks for your comments.I totally understand your points when it comes to real race where every packet/ms counts.For training days and races that happen for fun every  day this is not true though and having the race time in the osd for those would increase fun by a lot.Also this is like an optional thing to do, if I don’t register my binding phrase/osd with the races racetimer, I won’t be getting any msp messages and therefore no extra data would need to be sent.If one wants to be extra careful we could even put it behind a flag that checks if the functionality is activated through the LUA or if race telemetry is active.Would you consider this being a good option?

[CapnBry]

Eeee I am not sure. I wouldn't want to add a Lua option because that slows down the loading for everyone and it is already RAM constrained. Tying it to Race telemetry mode (disabled if Race) isn't a bad idea, but I often forget to change my settings back at an event and I'm sure I'm not alone. It also creates a headache with it transparently not working unless someone knows they have to turn off Race telem to get it to work the first time, which adds to the ELRS Frustration.

You're right about just not giving your bind phrase to the Race Coordinator, but the best part of supporting ESP-NOW in Rotorhazard would be that it would send VTX Admin commands. My goggles and quads would automatically just be on the right channel for every race because Rotorhazard could just send a VTX Admin command to set me to the right frequency when my channel needs to change. The warnings and caveats should be first and foremost in Rotorhazard, where the race coordinator would have to know that if they enabled the lap time OSD feature, it will kill everyone's ExpressLRS performance. Stop it at one source and not at 20-150 individuals.

I don't like how this creates a real performance issue that is completely transparent to the users. I do think the idea is cool, it just needs to be executed in a way that does not require the user to know anything about it, but I am not sure how to do that.

I thought further about how to make this work and an issue with the option of turning on the ESP-NOW on the RX (or adding a second ESP to the quad's FC) is that now the user needs two bind phrases, because unicast ESP-NOW packets should only go to one receiver, not have two receivers with essentially the same MAC which will interfere with the opaque ACK/retransmit algorithm.

This is why some VRX Backpacks support the MSP_ELRS_SET_OSD packet, for displaying this information directly on the goggles instead of through the pipeline you're suggesting. I'm still open to discussion about how we can make this work if you can come up with other ideas, or maybe someone else from our dev team has an idea how to make this less detrimental?

[jappyjan]

Hmm again fair points 😅

I do have some more ideas though 😂

We could:

• hide it behind a user define so only people who don't care about possible performance issues will install it and the remaining can still use the vrx channel setting feature

Also I just noticed that it won't send anything if the hardwaretype is not specified in the rh plugin, it would still set vtx channels but not send any osd messages, maybe this is already enough?
People could just tell the racemanager they don't want osd messages, he sets hardwaretype/osd type to "no osd, only vtx channels" or something like that and done.