-
-
Notifications
You must be signed in to change notification settings - Fork 757
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
base: master
Are you sure you want to change the base?
Conversation
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:
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. |
I have to agree with @CapnBry, there are just too many downsides to this approach. |
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?
|
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 |
Hmm again fair points 😅 I do have some more ideas though 😂 We could:
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? |
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