Add an option so that user can select which type of 'display' is shown when 'no signal' is detected.

ie. when no signal is detected, currently it first shows a screen full of 'rainbow pixels'.
It would be nice to be able to select if the user wants to see either a full color that you could choose (ie. black, dark blue, etc.), or a picture that the user could upload beforehand (ie. a race logo).

Existing Behaviour

With Auto Scan setting set to
Auto Scan = On
Default = HDZero

When powering up the goggles, the user is taken to the Scan menu.
In order to scan for a transmitting video signal from an aircraft, the user is forced to trigger a scan by pressing the left centre button.

Expected Behaviour

When powering up the goggles with Auto Scan = On, the goggles should automatically scan, and give the user a choice of channels which were detected on the scan. Apart from removing redundant user input, which harms the user experience, this behaviour is consistent with the way that HDZero VRx products operate.

If Auto Scan = Off, and Default is set to HDZero, the goggles should automatically attempt to tune to the last HDZero channel which was selected on a previous session.

Goggle DVR can record in MP4 format. However, file is not recognized as valid by Apple/Mac video editing software. Mac users still need to use Handbrake, ffmpeg or VLC to access the files, similiar to a TS file.
The advantage of the MP4 format was to be able to directly import into video editing software, but this is not the case for Mac users.

Request to add an option to display a full screen "Back Focusing Chart" image (black & white) to help with manual IPD/Focus adjustment.

1. Select "Focus Chart" in goggle menu (to be added)
2. Display full screen image of "Back Focusing Chart" - its a black and white chart wheel in the center and small ones in each corner
3. Allow user to adjust mechanical IPD/Focus nobs on goggle
4. Use a button to return to the goggle menu, return to menu

The image should be stored in firmware (not on SD card), several "Back focus chart" examples can be found on goggle. Since its sole purpose is focus, it is preferred over colored TV test screens. It is crucial the image has small circles on each corner and one in the middle.

Example applications are ORQA Pilot.One goggles, they have this as an option "Deep focus" which is awesome. Some users adjust IPD/focus looking at the camera footage (inaccurate) or their OSD on their camera footage (depending on where your OSD is, inaccurate). A back focusing chart will make sure you get the best sharpness out of your setup.

Add an option such that when the SD card is full, the oldest file is deleted to make space.
Obviously, with no accurate timestamp, this is not completely trivial.
I would guess that file index could be used instead of timestamp, but I guess over time, unless the recordings were completely cleared, this would result in the indexes getting ever bigger. A quick glance at the code however indicates to me that filenames are a max of 128 characters, so this would leave us with billions of indexes, rendering this issue effectively moot (Although how long would a filename have to get for it to start to be a problem in the UI?)

If implemented (And if #96 / #99 ends up being merged), hot clips should not be deleted when freeing up space

When using the playback feature, if the video is played, then paused, and then fast forward/rewind is used, video begins to play, but the playback icon is incorrect. User must tap the play/pause button twice in order to get the icon correct, and to then pause the video from playing. If the intended function is to play upon fast forward/rewind, the icon should correctly indicate that. Better functionality would be to allow for fast forward/rewind while paused and maintain the paused state.

Please add an equivalent of BetaFlight's average cell voltage
If you implemented #67 , then this would always be accurate-ish

ie, if (Once #67 is implemented) I have set the cell count set to 4S, and the current voltage of the pack is 12v, I want to see 3v in the OSD for the voltage

I'm not sure if this would be possible, but it would be great to have a way to add Bluetooth support to the goggles.
This way you could connect any type of devices (keyboard, mouse, microphones, gamepad, etc.) to the goggles.

When starting the remote dev container, the setup.sh runs and after the media is extracted, there's a CMake error that a simple test program cannot be compiled. The same process of cloning into the container and building on my Windows machine had no issues.

I am new to Docker in general but i'm doing the same thing on both systems and getting different results.

C++/CMake/CMake Tools are installed as extensions within the dev container.

[variant] Loaded new set of variants
[proc] Executing command: /usr/bin/aarch64-linux-gnu-gcc -v
[proc] Executing command: /usr/bin/aarch64-linux-gnu-gcc-11 -v
[proc] Executing command: /usr/bin/c89-gcc -v
[proc] Executing command: /usr/bin/c99-gcc -v
[proc] Executing command: /usr/bin/gcc -v
[proc] Executing command: /usr/bin/gcc-11 -v
[proc] Executing command: /bin/aarch64-linux-gnu-gcc -v
[proc] Executing command: /bin/aarch64-linux-gnu-gcc-11 -v
[proc] Executing command: /bin/c89-gcc -v
[proc] Executing command: /bin/c99-gcc -v
[proc] Executing command: /bin/gcc -v
[proc] Executing command: /bin/gcc-11 -v
[proc] Executing command: /bin/c99-gcc -v
[proc] Executing command: /bin/c89-gcc -v
[proc] Executing command: /usr/bin/c99-gcc -v
[proc] Executing command: /usr/bin/c89-gcc -v
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[kit] Found Kit: GCC 11.3.0 aarch64-linux-gnu
[proc] Executing command: /usr/bin/aarch64-linux-gnu-gcc -v
[cmakefileapi-driver] Removing /workspaces/hdzero-goggle/build/CMakeCache.txt
[main] Configuring folder: hdzero-goggle
[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE=/workspaces/hdzero-goggle/toolchain.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/aarch64-linux-gnu-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/aarch64-linux-gnu-g++ -S/workspaces/hdzero-goggle -B/workspaces/hdzero-goggle/build -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is unknown
[cmake] -- The CXX compiler identification is unknown
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - failed
[cmake] -- Check for working C compiler: /workspaces/hdzero-goggle/toolchain/bin/arm-openwrt-linux-muslgnueabi-gcc
[cmake] -- Check for working C compiler: /workspaces/hdzero-goggle/toolchain/bin/arm-openwrt-linux-muslgnueabi-gcc - broken
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "/workspaces/hdzero-goggle/build/CMakeFiles/CMakeOutput.log".
[cmake] See also "/workspaces/hdzero-goggle/build/CMakeFiles/CMakeError.log".
[cmake] CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
[cmake] The C compiler
[cmake]
[cmake] "/workspaces/hdzero-goggle/toolchain/bin/arm-openwrt-linux-muslgnueabi-gcc"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: /workspaces/hdzero-goggle/build/CMakeFiles/CMakeTmp
[cmake]
[cmake] Run Build Command(s):/usr/bin/ninja cmTC_d1209 && [1/2] Building C object CMakeFiles/cmTC_d1209.dir/testCCompiler.c.o
[cmake] FAILED: CMakeFiles/cmTC_d1209.dir/testCCompiler.c.o
[cmake] /workspaces/hdzero-goggle/toolchain/bin/arm-openwrt-linux-muslgnueabi-gcc -Wall -o CMakeFiles/cmTC_d1209.dir/testCCompiler.c.o -c /workspaces/hdzero-goggle/build/CMakeFiles/CMakeTmp/testCCompiler.c
[cmake] qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
[cmake] ninja: build stopped: subcommand failed.
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]
[cmake] CMake will not be able to correctly generate this project.
[cmake] Call Stack (most recent call first):
[cmake] CMakeLists.txt:3 (project)
[cmake]
[cmake]
[proc] The command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE=/workspaces/hdzero-goggle/toolchain.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/aarch64-linux-gnu-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/aarch64-linux-gnu-g++ -S/workspaces/hdzero-goggle -B/workspaces/hdzero-goggle/build -G Ninja exited with code: 1 and signal: null

I've seen/heard this feature request before, but could not find it mentioned here, so here goes:
Using the the WiFi module to stream the video seen on the goggle screen, to an external device would be awesome.

Perhaps create an rstp endpoint, so that smartphone or computers or the same WiFi network could access the live streaming?

This would allow the live stream to be processed and recorded directly in an external device, and could be used to add effects to the video stream live.

Double tap the menu button to cycle the goggle input to the next input source. This may be used in conjunction with a new menu setting to define the quick switch sources to reduce the cycling options if the pilot only uses 2 inputs regularly. Otherwise cycle through HDZ/HDMI/Expansion Module/AV.

Optionally, cycle through only detected inputs, but unsure if the goggle is able to detect all active/connected inputs.

While navigating the menu, it would be nice to have the Func Button act as a back button. This saves time navigating around the menu eliminating the need to scroll to the bottom of a sub-menu to return to the previous menu. Still keep the current <Back in the menu as some people may prefer to scroll. Similar functionality is offered on the other goggles and would not disrupt the manual DVR recording.

The analog modul is permanently on. Is it possible to power it off by firmware/software?

What's the source/license of the media.tar? Why is it distributed like this?

Personally, I use auto-record, so the record button on the right of the goggles serves no purpose, and also while you in the menu system, it serves absolutely no use at all.
Even for people using manual record, a long-press of it could serve a purpose as a "Context menu" (Similar to right clicking in windows)

Some examples of how it could be used:

• While in the playback menu, allow deletion of files (Or provide a way to trigger #96 or #97)
• While viewing camera view, open a menu for quick access to various functions - eg switch input source, or access the image settings menu. Currently, if you are viewing the camera feed, you must enter the menu, then select the image settings option, which puts you back to the camera feed and shows the image settings overlay, then when done, you exit and go back to main menu, then you must exit the main menu and go back to the camera view. It would be much much better UX to open the context menu, select image settings, the overlay pops up, make your change, then exit the popup and you are straight back to the camera view

Using me Fatshark HDO2 with the Foxeer Wildfire analog module, a luminier omni antenna and a sniper patch antenna, I got very good results and my analog image is stable and clear.

However when using the same Foxeer Wildfire analog module with the same antenna, the same orientation and the same flight conditions, I see a pretty bad analog signal, with lots of break ups, lots of rolling frames (that I never experienced before with the HDO2).

Help!

(I can provide a flight recording to the devs if needed)

Obviously not high priority, but probably something to fix.

To replicate, just put in an SD Card with a format other that exfat and go format it under Recording Options

Currently, corrupted pixels show up as a random color, leading to a rainbow static across the image. This has often been seen as an issue, particularly folks coming from other systems.

Assuming it is possible to detect corrupt pixels (I don't know if the HDZero protocol has any kind of checksum or other error-detection), it would be nice to be able to select from one of a few different error handling behaviors, aside from the current. Some possible options:

• Color error pixels black or a medium grey.
• If the information for the pixel from the previous frame was not corrupted, reuse that information. In the event of multiple, sequential errors for a pixel, fall back to another method.
• The nearest neighbor method discussed in #40.

(If this is not possible due to hardware limitations just close the issue)

Problem

High gain patch antennas have narrow fov so how you point your head can have a big difference, and in long range you have limited patch of sky to fly in forward and back

Solution

Add osd element which points to the direction where you should point your head for best reception

This would allow:

• Long range pilots to optimize their head orientation for best signal reception
• Long range pilot to fly in any 360 direction at long range, because they can turn their head with the drone and always have range of patch antennas

Hardware capatibities needed

• Drone should have GOS receiver
• Drone GPS data should get back to googles. This part I'm not sure how it would work, maybe from elrs telemetry from radio or something like that
• Googles need absolute positioning for yaw and pitch axis (or relative but with small drift during flight like 2deg or so)
• Googles doesn't need GPS because you could assume pilot position to be same as first arm position, at longer range angle error would be minimal

Please change the video files naming convention for something like 2023-01-24 16h46 HDZ_0042.ts (in the VRX as well), so that the files could be ordered chronologically (alphabetically), even if they come from multiple HDZero goggle (which would then not have the same index counter).

Also, make sure the extension is .ts, not the uppercase .TS.

When flying, a lot of clips tend to accumulate on your DVR, most of which you are probably not interested in keeping.
Typically, when I get home, I have to review the DVR files to see what I want to keep.
Sure, you could delete stuff as you go, but that's a bit time-consuming.
It would be really cool if there were some way to mark a DVR file as "Hot" - eg you have a flight and did something cool, so after the flight, you go into the DVR menu, select the last file, and select a menu item to tag it as "Hot".
Then, when you get home, you know that all you have to do is copy off the "Hot" clips and can ignore the rest.

Maybe a simple solution would be that you can go into the DVR thumbnail view, and press the record button while a clip is highlighted, and it moves that video into a "Hot" subfolder, or maybe renames the file to put a Hot_ prefix at the start of the filename

Right now, you need to use fat32, which is simple yes, but very limited and subject to fragmentation.

Since the goggles are using Linux, it would be great to allow reading and writing to sd card formatted with ext4, btrfs, f2fs, xfs, etc.

This would be transparent to Windows/Mac users, where they would just use their usual SD card.
For Linux users though, it would mean not having to use an obsolete FS, and fully use 256GB+ cards.

You could even support exfat for Windows users.

If the top fan is set to 0, when the goggle starts overheating the top fan goes to 5 but the side fans are not working and the manual control in the fan menu is not working when that happens. The result is the goggle keeps overheating until they are turned off. See video
https://www.youtube.com/watch?v=NaSG6zxUZBI

It would be great to be able to able to use the gyro headtracking information and feed it into a computer, so the goggle could be used like a VR headset.

I'm not sure exactly how such information could be sent (and with what latency), perhaps via the Wifi module?

Do note that this feature request, in my opinion, is very, very low priority.

During video playback via HDMI out, the audio portion is not being streamed. While audio is working from the headphone jack, via HDMI out there is no sound.

I have investigated both DM5680 and IT66121 and the commands are cryptic as I do not have any reference development documentation. Would anyone have a link to where I can download the SDK for these devices?

While in the field, the only way (Obviously without removing the SD card and using another device) to clear out DVR files is to format the SD card.
This will mean, for example, that any firmware files (And any custom boot screen logo?) that are stored on the SD card will be lost.
An option should be added that clears out all the DVR files without deleting the rest of the contents of the SD card.

It would be great to be able to ppdate the goggles firmware via the Wifi module.
One of the way would be to create a small localhost server on the goggle, that would serve a simple webpage where you could drop the zip or bin files to be flashed.

Also, that web server could display an information page with all the settings, versions, and configuration used.

I use an external microphone, but when the analog modul is mounted, it destroys the audio.
I made a video to show the problem:
https://www.youtube.com/watch?v=PS3IaPrHgcI

Used HDZero Goggle with Rapidfire and external Mic.
Same problem if you fly analog but want microphone audio only, the analog sound is also written into audio file.
Please change to use only 1 input source.

Repro:

1. In the power menu, set the voltage slider to 2.8v
2. Power the goggles up from a 12v source (Simulating a 4S 18650 pack at 3v per cell)
3. The goggles show 3S
4. You will therefore not get a warning when the voltage drops to 11.2v (4 cells at 2.8v each)

Solution:
The cell count in the power menu needs to be able to be manually set

The source for the audio recording resets to default internal mic after updating firmware, instead of retaining user setting.

It would be great if the fan noise when recording from the internal microphone could be eliminated.
Right now this has to be done in post-production (using the likes of Audacity), but this could be done live using open-source software (like Cadmus: https://github.com/josh-richardson/cadmus).

To avoid any problem is specific environments, there should be an option to activate the 'fan noise cancellation'.

It would be great (if that's even possible, technically and legally) to reverse-engineer the DJI protocol, so that the HDZero googles could receive and display the signal from DJI vistas.

It would be nice if the format process re-created default folder structures.
ex, "Resources/OSD/FC".

A better spectrum analyzer in the menu that allows you to see the real time RF noise. Even though there already is one it isnt very nice bc you can only see HDZero channels. It would be nice to be able see the RF usage of all things on the 5.8 spectrum.

Instead of showing random pixel data when there are missing info, make an interpolation from the neighboring pixels (or even from the previous frames).

I assume this could take more CPU power, and hence time, so this feature should be togglable in the settings.

Hdmi passthrough will be good for people using external input devices such as the walksnail system for others to spectate or record on a dvr.

Optional menu setting under Power that turns goggle completely off at a given voltage or after no input signal detected for a given time. Not just a warning, but completely off. Idea is to save the screens from burn in or the battery past 3.0v, for example, if goggle is accidentally left on and unattended.

Most of the quads out there do not have a RTC, hence there are no dates/times in the DVR.
It would be useful to have an option to put a small timestamp on the top of the OSD.
For instance, 2023-01-14 16:27.

If this is too much info for some pilots on the OSD, perhaps only display that information on disarm (not sure the goggles can know when the quad is armed, perhaps via the VTX?).

Problem

When I fly usually my head little by little drops down, which mean patch antennas are pointing down and are useless

Solution

Add setting for min and max google angle and if out of range for set amount of time warn user with visual or audio warning to correct his head

For example if patches have verticla fov of 30 deg you'd set angle_min: -15, angle_max: 15
If patches are pointed up 10deg then -25, 5 or whatever range user chooses

When using a HDMI source it would be helpful to record this input. This is useful for keeping DVR recordings in a single spot when used with complementary VRXs such as the WS VRX.

Suggest minimal goggle OSD whist the recording happens (record, goggle temp warning and goggle battery warning) with goggle OSD not recorded.

Hey,

I'm wondering, why we're using h264 and not h265, from a quick reading, it seems like hevc should be capable of lower data rates and we should have hardware support on the googles.

https://github.com/hd-zero/hdzero-goggle/blob/main/src/player/vdec2vo.c#L30

Cheers

The playback menu still shows recordings after the SD card has been formatted on the record options menu.
This page is correctly cleared after removing and re-inserting the card (or powering off/on).

REC icon shows up, but DVR is not saved. File format, AUTO/Manual doesn't matter. Tried Latest stable FW and compiled current GH version, but still no recordings. In manual mode on current GH version REC icon blinks only once. SanDisk Ultra 32GB and it's worth to notice that few first flights were recorded.

Well, knowing this is a Linux machine, I can't help but want to get access to the cmdline :>
Would it be possible in the future to ssh to the goggles via the Wifi module?

Add a PiP (Picture in picture) mode to display sources in a small rectangular window, on top of the main feed (ie. Main analog + pip HDZero, Main HDZero + pip analog, etc.).

This could be very interesting in Races if you use HDZero as the main feed, and get an additional Analog feed from the referee that would broadcast the times and position of everybody, or if racing in teams the feed from your teammate.

This could also be useful of bigger quad with a second analog rear camera.

Ideally should be able to change the size of such PiP display, and move it around the screen to best fit the user needs.

Is there more documentation for developer?

Like high level block diagram how hardware connected what sensors available. What's possible with video postprocessing. What kind of OS is running. How to test custom firmware. Some example code for some simple projects like reading sensor data and displaying in terminal, osd or whatever sensible? Other info to help to start on basics without needing to read through all source code to understand what does what

I think something like that would lower entry barrier for developers to join the development

It would be great if we could store the file that contains the firmware for each VTX locally on the goggles in their zipped format, and select which VTX we're flashing in the goggle menu then have the goggle unzip that file, flash the VTX, and delete the HDZERO_TX.bin file from the SD card, so I can flash the next VTX.

Hi all, I don't know if this is the place for my issue but I give it a try. I have received my new hdzero goggles and that are very nice. But I have some problems with the fc osd. I use kiss ultra fc and it is working but on the new goggles the screen is full of lines (so a -) the osd elements are showing but there rest of the screen of full. On the old farshark Rx this is not the case and the osd is working fine. Updated the kiss fc but no difference, updated the vtx aan goggles but still the same. If I disable the osd in the fc then the lines are gone. Is this a known issue?
Thanks in advance