Possible Features
Retired in favor of: https://github.com/orgs/fpv-wtf/projects/3/views/1
Plese see the above Github project board for the latest.
Here's an attempt to discuss some of the frequently requested features and what might be good ways of solving them or what's already been tried. When will they get done? When somebody with the skills to do so can be bothered. Feel free to jump in. Or if you donate a generous sum and add a note as to what you'd like to see, we might just prioritize it. But no promises, some of this stuff is a lot harder than others.
If you don't see a feature you'd like on here, hit us up on Discord or open an Issue and we'll at least document it here.
There's already disabled code in the Goggles/AU for live audio and we have it working, but it's still hacky at the moment. Expect this to be one of the first mods available when package management is done.
Probably not going to happen as Canvas mode is a full bitmap overlay on top of the video stream and would require a ton of bandwidth. Doing it Air Side would be a bad time, because of focus mode / bitrate drops.
Can't really be done (with reasonable effort) due to how the video pipeline works. It should however be possible to record MSP displayport data and create an offline renderer on the PC.
While the Goggles do not have the required hardware to do HDMI in (or out), it should be possible to re-use the DVR / iOS simulator code-path to enable video in on Goggles. This would take the form of an h264 stream. A good start would be to port the Moonlight Embedded client for compatibility with Nvidia Gamestreaming/Sunshine server.
An alternative approach could be the use of USB HDMI capture dongles, but that would require achieving the capability of building Linux kernel modules (see Wifi dongles/Ethernet adapters below) and would likely have worse delay than using direct GPU encoding on the host PC.
Currently USB video out only works for digital transmissions, no image in AV-IN/analogue mode. Needs research. One possible approach is to try and make the RTOS encode the merged framebuffer rather than the digital video only one, that would also solve having OSD display in video out mode.
Current behavior means if there's an issue with the analog signal, you'll get the DJI logo and auto resuming takes a while, which can lead to crashes that would've otherwise been avoidable. Needs research.
The main issue here currently is that when a USB host is connected the SD card gets exported as storage to the host and de-attached from the Goggles. It should be possible to override this one way or another.
So you don't forget to unplug your Goggles and drain your battery. Ideally timeout would be configurable. We can probably use some trivial memread to determine RTOS streaming state for example.
Would allow one to get all the gory details of all those crashes. Shouldn't be too hard, relevant code is probably somewhere in dji_glasses (dji_gls_wm150 on V2).
This could enable live streaming directly from the Goggles. The main obstacle is being able to build new modules for the kernel, for which we don't have sources. Anybody have the capability of brining a serious legal threat to DJI in regards to their GPL violations? They've published sources previously here but all the old links are dead and no new ones have been published. Note: V1s don't support USB host mode, may be possible to work around, see next topic.
Theoretically Vistas should be able to support USB OTG (like the V2 Goggles do), to enable USB storage. We suspect the main problem is power not being routed properly to the USB port. Wiring up external power (with common ground to the Vista) might do the trick. If anyone can be bothered to give it a shot with a USB keyboard or USB Flash Drive and check your dmesg output afterwards let us know the results!
Is possible by overwriting pairing id-s in CP memory. Needs packaging up into a usable solution.
We tried forcing the appropriate pairing id-s in CP memory, no luck. Needs more research.
Someone once mentioned this. I don't know anything about Mavlink or why you'd want it. Hit me up on Discord if you want this and you'd like to enlighten me.
It's probably somewhere deep in the CP RTOS code. The limit was increased in 0600, so diffing CP for earlier versions against 0060 might be a good start. 0600 also added 50mbit mode though, so good luck digging. jaanuke spotted that in 0600 a parameter in CP RTA7 was changed from 32 to 63, which could be LTE Timing Advance. The experts all agree: here be dragons. Proceed at your own risk and be sure to share pics if you bring forth the apocalypse, get raided by the FCC or just have your wing crash and burn.
FPV Drone users get a version mismatch warning otherwise and USB Video out is not supported on the DIY mode 0606 fw. Users may need to run the initial exploit on 0606, but since adb sticks around on the V2s after firmware upgrades we would just need to re-patch the startup scripts to enable mods for DIY mode on V01.02.0000. Mods not relying on direct binary patching/fixed memory addresses should be compatible.
Requires a fundamentally new exploit chain. Some day for sure, but don't hold your breath.
Not currently required, but can be useful in future if DJI stops serving vulnerable FWs. DUML + ftp, easy to capture with usbpcap.
Unlikely to be ever released as this enables theft and warranty fraud.
