Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmit Betaflight MSP "SET_NAME" packets from tx to fc #2504

Closed

Conversation

jappyjan
Copy link

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
Copy link
Member

CapnBry commented Dec 18, 2023

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
Copy link
Collaborator

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
Copy link
Author

jappyjan commented Dec 19, 2023 via email

@CapnBry
Copy link
Member

CapnBry commented Dec 19, 2023

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
Copy link
Author

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.

@JyeSmith JyeSmith added the closing 🚪 Will close if no new information is reported label Jun 17, 2024
@JyeSmith JyeSmith closed this Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closing 🚪 Will close if no new information is reported do not merge 🚫
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants