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.
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.
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.
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
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.