AU/Vista input voltage in OSD without fc about msp-osd

[bri3d]

This could be implemented as an additional feature on the air side in one of several ways:

• Read the input voltage and send a DJI DUML message. This could even be implemented using a shell script and the dji_mb commands in /system/bin provided we find the correct message to send. Benefits: Shows up natively in DJI Glasses OSD (so warnings etc. work), should be pretty easy. No tampering with the system, can probably be done without even writing any native code. Drawbacks: Maybe the message we send will conflict with HDVT or get overridden? And need to find the message to send.
• Send a fake MSP "reply" over the serial mux to the DJI HDVT service, populated with the voltage read from the input pins. This also should be pretty easy. Benefits: Same as previous method, plus only relies on things we know (MSP and the mux service) instead of researching things we don't (DUML message for voltage). Drawbacks: Requires the serial mux service to be installed and run, so a little "heavier weight" in terms of tampering with the system.
• Send an MSP OSD with only a Voltage widget, populated by reading the voltage. Benefits: 100% in code we control. Drawbacks: Requires you to kill glasses on the goggles side and lose all DJI functionality to get only a voltage display. Heaviest weight in terms of tampering with the system.

I think approach #2 is the best - basically, extend the serial mux with a "fake flight controller" function which can reply to various MSP queries with data populated off of the Vista/AU. The existing DJI OSD functionalities can be used.

I'll take a look at this later, I had no idea the air side stuff even had voltage sensing so I'll play around.

[bri3d]

This has been done for awhile now.

[SCMicroMike]

Nice!! I will look at the project and see if I can get a wing up and running to test it.

[bri3d]

Oh, actually, I do need to make a small fix for use without FC altogether, as right now the FC triggers the on screen drawing. I’ll update when this is done.

…

On Mon, Aug 22, 2022 at 11:37 AM SCMicroMike ***@***.***> wrote: Nice!! I will look at the project and see if I can get a wing up and running to test it. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTO2IXGF3URDP7GNVMVRLV2O3ENANCNFSM5SQGDZKA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[SCMicroMike]

Copy that. Will be on the lookout. Thanks for addressing this. I have a couple questions but will ask on the discord to not clutter this.

[driedger]

Following this issue, and request that it gets reopened to ensure it doesnt fall through the cracks.
Would be great to modify the au_overlay_enabled option, or create a new option on the air unit side, to send temp and voltage without having a fc detected. As an AU option it could be enabled only as needed,
In the code it appears this only fires when we process_data_packet, which only happens while receiving msp data. @bri3d I suspect you already have a plan on how to implement this so I will stop digging though the code!
Thanks

[bri3d]

0.6.11