Credit to Shannon Baker for contributing this content.
The ONLY difference between the 2 version's functionally, is one version supports DVR files individually that can be greater than 4GB in size, and one version that does not and is limited to a single file size of 4GB max. This is related to the Linux kernel (operating system component) of the Avatar HD system (sky and ground), supporting the exFAT file system format. To enable exFAT support (>4GB file sizes), an updated kernel is needed to be installed.
Arguably, the most sensitive part of most operating systems is the kernel, as it is the part of the operating system that interacts with much of the hardware directly. During the kernel update process, if an interruption to this is experienced such as power failure, the kernel will be corrupted and as a result unrecoverable by tools typically available to users. As the kernel is the part that talks to the underlying hardware, if it is corrupted you essentially have hardware that is equivalent to a ‘brick’. Hence the term ‘bricking’ or ‘bricked’.
Whist this sounds bad the risks of this happening are small and can be mitigated. The primary risk is power interruption whilst applying the kernel update. Applying the ‘kernel’ version of the FW can be done very safely if you ensure the power supply to the hardware is stable and securely connected and sufficient to last for the duration of the update.
Fortunately, the process is reasonably quick and if you ensure your battery is securely connected and charged enough to meet the minimum voltage requirements of the hardware it’s connected to (+ maybe 10%), then you have essentially mitigated most if not all of the risk. But to be extra safe use a fully charged battery that you would normally use for the device. If you use a desktop power source that is connected to mains power, then I suggest caution in the unlikely event of a power outage.
Recorded at 50mbit, a 4GB DVR equates to roughly 10-11 minutes of flight. Recorded at 25mbit, a 4GB DRV equates to roughly 22 mins of flight.
The following examples should help guide you on the behaviour of FW version:
Recommendation/summary:
If your typical recording of a single flight is less than 10 minutes, you will experience no benefit from the 'kernel' version and can choose to install either. If you choose the ‘kernel’ version you do so accepting any outlined risk and how best to mitigate.
If your typical flight time is greater than 10 minutes, you should upgrade to the ‘kernel’ version accepting the outlined risk and how best to mitigate.
There is a planned future companion app for mobile devices that will be able to play back DVR captured on the Goggles X. The functionality is for the Goggles X via connectivity over the Wi-Fi/BT hardware. As high bitrate DVR files have a large file size in the context of transfer over 2.4ghz Wi-Fi or BT, would be subjectively slow, the option to capture DVR on the goggles at a lower bitrate was introduced. This DVR bitrate is set via the ‘GND Bitrate’ setting in the Goggles X menu. Given that Wi-Fi/BT hardware does not exist in V1 Goggles or VRX, and there is no concern with SD storage sizes warranting a different encoding bitrate, this option does not exist for this hardware.
After updating the VTX FW, check your VTX mw power setting. Due to the goggles now recognising the connected VTX, you may find the mw reset back to 25mw in some instances. This is only on FW flashing. Once mw is set after, it will be persistent. Thanks Keith Luneau for reporting this.
The release notes contain the following instructions for setting the date and time of your ground side hardware:
Method: Create a new .txt text file on the root of the SD card, name it as "Avatar_time.txt" (case sensitive), fill in the time format: year, month, day, hour, minute, and second (yyyy-mm-dd hh:mm:ss) e.g. 2023-12-31 23:59:00 Save the file. Put the SD card in the goggles and reboot. Goggles will update the time as per the date and time in the Avatar_time.txt file.
Some further help may be in the below information:
Note that your operating system may be hiding the file extension so be careful not to name the file "Avatar_time.txt.txt". Before proceeding confirm the correct file name.
You can check that the process of changing the date and time is working by:
The recorded DVR should then have the date and time as per the Avatar_time.txt file contents.
As the VTX does not have a RTC battery to retain date/time, the VTX will get it's date/time from the goggles/vrx when it connects, so there is no VTX specific process to follow.
If you're using V1 goggles, HD Recon goggles or VRX, you may find the time doesn't 'stick' between power cycles. This is because the internal RTC (Real Time Clock) battery is not charged enough to keep the memory alive to retain the date/time. As suggested in release notes, keep power connected to your goggles/VRX for 15-30 mins to allow the RTC battery to charge. The 36.42.4 FW also includes code that enables charging of the RTC battery, whereas this did not happen on prior FW releases, meaning the time was eventually lost after RTC battery dropped below a certain voltage. For the Goggles X, this unlikely that due to the age of the Goggles X, the battery would be depleted enough yet to lose date/time.
The purpose of the proximity sensor in the Goggles X is to reduce usage of the OLED screens when not being held to the user’s face. The proximity sensor detects via infrared, when a face is within a certain distance and enables (turns on) the OLED panels. It does this using values that change when proximity is sensed and at a configured value threshold, the OLEDs will either turn on or off as long as that threshold is maintained greater than or less than the threshold value.
Users may be faced with a black screen (OLEDs turning off) that prevent the user from seeing the Goggles X menu screen, despite having the goggles as normally worn in use. This can be due to the proximity sensor being unsuitably calibrated.
Note that if you have only one OLED that is not working or has unexpected colouration, this is unrelated to the proximity sensor.
There are 2 methods that this PSA will outline: Calibration and Disabling.
If calibration works, you do not need to follow the disabling process.
Review the quick-start guide and locate the ‘5D Button’.
Shout out to Ian Lewis from Mads Tech for the work on pulling together some great info on this. Noting that you don't actually need to power the goggles with the 5D button pushed forward to enter calibration mode, this can be done after the boot sequence completes. Here's a link to Ian's video.
The process of calibration will force the OLED screens to ignore the proximity threshold value and enable the OLED panels.
1. Power on the goggles and wait for them to boot (usually ~30 seconds)
2. Hold the goggles in an orientation that mimics how you would wear them
3. Hold the 5D button in a forward position for 3-5 seconds
4. The OLEDS should turn on and you should be in proximity sensor calibration mode and see a proximity value and a save button.
5. Release the 5D button.
6. Moving the goggles up to your face will adjust the proximity value. When you have the goggles suitably close to your face (~1-2cm away is good to ensure no unexpected OLED blanking), short press the 5D button to save the calibration value.
7. Test that the OLEDs turns off when removed from your face and OLEDs turn on when fitted to your face for use.
If the above process is not seeming to work and your OLEDs remain off, then please follow the disabling process.
If you cannot see the menu to be able to disable the proximity sensor, you can still do so using the following process.
1. Power off VTX as this will interfere with the following process steps
2. Power on the goggles and wait 1 min (usually take ~30 seconds) for bootup completion
3. Hold the goggles in an orientation that mimics how you would wear them
4. Short press in the 5D Button in the following sequence, noting the down direction is to the ground (i.e. pressing the button):
Down, Right, Right, Down, Down, Left, Down, Forward, Down
5. The proximity sensor should now be disabled.
The ‘Moonlight Kit’ comprises of a 4k camera, and a case that houses 2 discrete components. The 2 discreet components are a DVR board with SD card slot, and a VTX (a dual antenna V2 Avatar VTX). The VTX still retains its own onboard storage and can be accessed using the V2 VTX USB fly lead, but DVR is not recorded to this.
The FW for the Moonlight kit, upgrades the FW for both the DVR and the VTX in a single operation. When you initiate the FW upgrade process (hold the bind button), in the background the DVR board FW will be applied and the FW upgrade process will extract the VTX FW part and put in on the VTX onboard storage for upgrading the VTX at the same time.
The FW file naming (AvatarMoonlight_Sky_15.1.15.img) contains both the VTX and DVR FW versions. The VTX FW version will be what is implied with the FW release (typically the overall zip file naming).
As of the 37.42.3 firmware release, CADDX introduced a method to upgrade ONLY the DVR board. You would conceivably only need to do this if you wished to retain a prior FW version of the VTX but wish to upgrade the FW of the DVR component only.
The Avatar VTX embedded OS is based on Linux and cut down to strictly needed components only, to fit on as small a footprint as possible. As such, when removing files (‘rm’ command), it does so without any implied protections such as a ‘Trash Can’ or ‘Recycle bin’. This means that files on Linux are immediately deleted and not hidden (for potentially recovery of the file). For MAC OS deleted files are placed in the ‘Trash Can’ so that the file may be recovered later if needed, but the implication of this is that the storage is not released for the device until the device is either formatted or the ‘Trash Can’ is emptied.
Options in dealing with MAC OS:
1. To avoid the trash can when deleting a file on MAC OS, use ‘[command] + [option] + [delete]’.
2. Format the [external] drive/device from MAC OS.
3. Empty the ‘Trash Can’ for the device from MAC OS.
4. Format the device from the Avatar goggles/vrx menu.
The MIPI lead between the camera and the VTX can be subject to EMI (electro magnetic interference). This can be particularly evident when you run the MIPI over the top of your ESC. It will interfere with the data trans-versing the MIPI lead resulting in missed or corrupted data. Requiring this to be resent from the VTX. This would be observed as high latency and/or short pauses/freezes in the video received. A sub-optimal experience
2 solutions to consider:
1. Reroute your MIPI away from the ESC with some amount of physical separation.
2. Shield your MIPI with copper tape or similar if rerouting is not an option.
38.x FW (amongst other improvements) has introduced support for head tracking with Goggles L and Goggles X (external module and embedded head tracker). This has meant changes to the communication between ground and sky devices to support the addition of head tracking data. Due to these changes, 38.x FW is incompatible with 37.x FW and below. The immediate symptom of this, is the inability to bind a 38.x FW device with a 37.x (or below) FW device.
To ensure compatibility, you are required to update 37.x devices to 38.x FW, otherwise 37.x FW will not bind to 38.x FW and below.
You may downgrade FW on the 38.x device as long as you understand that you will lose functionality, features or improvements introduced in 38.x FW, such as head tracking support.