X2 Firmware 2.0 BETA testing!

Ok, I’ve now put up firmware 2.0.3 with the following changes:

  • Mode revert feature:
    • if the X2 detects freefall incorrectly but the aircraft maintains altitude or climbs, it will go back to aircraft mode after 5 seconds.
    • if the X2 detects canopy mode incorrectly but the descent rate remains high, go back to freefall mode.
    • if the X2 detects landing but descent resumes within 10 seconds, stay in canopy mode.

This should fix the issue reported by @Model and @Wexi but there are risks of edge cases causing wrong mode switching.

THIS IS A BIT OF A RISKY UPDATE. MAKE SURE YOU HAVE A SPARE ALTIMETER WHEN TESTING THIS!

My question is. How does quick come back to FW 2.0.2 in case of trouble?

EDIT:

My next wish is to introduce waypoints by coordinates :slight_smile:

I’m getting this when trying to run the beta firmware updater on Linux:

** (x2_fwupdate:3547396): WARNING **: 14:00:13.614: Failed to create OpenGL context: Unable to create a GL context
[FATAL:flutter/shell/gpu/gpu_surface_gl_delegate.cc(77)] Check failed: gl_version_string. The GL proc resolver’s glGetString(GL_VERSION) failed
Aborted (core dumped)

The non-beta updater works.

@Model I think in case of trouble, just describe the problem to me and I’ll fix it quickly and release another version.

@Wexi I’ll have a look at this and get back to you.

1 Like

Hi Wexi,

What distro are you using? Are you running Wayland? What graphics hardware is your system running?

Hello,

Kubuntu 25.10, X11, Nvidia RTX A4000

Hmm might be an issue with my desktop computer… On my Linux laptop I was able to run the beta firmware updater just fine so it’s probably not an issue with the updater itself…

Did one jump with the 2.0.3 firmware. The X2 stayed in freefall mode after detecting free fall until landing and I had to forcibly power off the X2 to exit freefall mode.

Thanks for the report! The logic is a bit tricky here…I’ve now uploaded 2.0.4 with fixes to the logic.

I also haven’t had the time yet to test it in a pressure chamber, but as before please take appropriate precautions when jumping this beta firmware.

1 Like

Ok, I’ll try the 2.0.4 on Friday and report my findings.

2 Likes

Did two jumps with 2.0.4 firmware and did not encounter any abnormal behavior.

3 Likes

I did also two jumps with offset altitude, everything was ok. FW 2.0.4. I am waiting for new features.

1 Like

Thanks for the feedback.

I’ll slow down the beta firmware development a bit, as I need to focus on finding a way to retrieve the data from older X2s with 1.x firmware. But keep making more suggestions of features and I’ll put it in the list.

As we accumulate more jumps with 2.0.4 it will likely become the stable base version going forward.

I’ll also look into improvements with the X2 phone app, there’s a lot that can be improved there.

1 Like

One thing I’ve noticed—though I’m not sure if it’s specific to version 2.0.4—is that it sometimes takes a while to acquire a GPS signal; consequently, when you download a jump to the mobile app, it doesn’t display the map of your jump because the altimeter failed to capture any location data.

Thanks, I’ll look into this - this is more on the app side.

What is the app and where can I get it for an iPhone?

Upgraded to Firmware 2.0.4 and when I was synching Waypoints from iPhone to X2 they were duplicating with each synch initiated from the iPhone.

I went through and deleted the extra ones.

The X2 did erroneously detect free fall yesterday again and did not switch back to plane mode. I’ve noticed that (if I recollect correctly) this does not happen when we are doing a jump run at 1000m altitude and I dispatch static line students. But if there’s a jump run where one jumper exits at 1600m and we then continue to 4000m and especially if I’m the one who closes the jump door, the X2 tends to switch to free fall mode. Yesterday it logged a whopping 771 seconds of free fall from 1600m :smiley:

I’m running the 2.0.4 firmware.

A short video of the X2 behaving badly: Dropbox

Thanks for the report!

The current conditions for reverting I think are too strict:

  • within 5 seconds of changing to freefall mode:
    • if there are 3 seconds of vertical speed < -2.0m/s
      • revert back to aircraft mode

I think we need to change this condition to -8.0 m/s (because of phase lag and slight aircraft descent rate might not meet those conditions above). Normal freefall speed is at least -60.0 m/s.

I’ll release another firmware update for this.