Product Updates

New Mercury V1 firmware - v2.41 - Changelog

NNeil Bowen9 min read

New Mercury firmware is out.

The Mercury V1 has a new udpate packed full of improvments and new features. This is the biggest firmware update we've done so far.
The Mercury logs faster than ever and the new rules system is a big improvment allowing you to do far more as well.

Firmware update tool

Mercury Firmware Changelog: v2.3 → v2.41

Changelog for Mercury FW v2.30 (SUBREVISION 125) to Mercury FW v2.41 (SUBREVISION 308)
There have been183 internal edits bundled into this release.


1. General summary

Logging speed up to 300Hz

The Mercury started life at 32Hz and it can now log data at up to 300Hz. The default setting is now 250Hz with Hybrid 1:5 sample ratio also the default there.
This means that your Mercury will log at 50Hz before launch, 250Hz during launch until 5 seconds after apogee, it then drops to 50Hz (1:5 Hybrid ratio) during descent and pops back to 250Hz for landing once the altitude drops below 20 meters.
This lets you see great detail for your motors thrust and other events when you zoom in on them in the chart. A 1 second motor burn now has up to 300 acceleration points.

Log size increased and more efficient

We have increased the Mercury's maximum samples for each log from 12000 to 18000.
We also now store the logs on the device in a binary format rather than CSV. This offers almost a 250% space saving efficiency.
The logs are converted to CSV when downloaded from the device or once uploaded to the AltimeterCloud from their binary version. 

Action Rules v6 - full replacement of the previous system

The old fixed six-slot rule builder has been removed, and while it was capable we wanted to improve this in to something much more capable.

  • You can now configure up to 12-rules on the Mercury V1 and use them to trigger outputs, move or configure servos, or adjust settings during flight.
  • Rule conditions can now be built with groups and multiple conditions in each group to compare as you choose. This allows you to build simple rules or highly complex ones too.
  • You can now trigger rules either Once per flight, every cycle it's valid or on a time system for example up to once every 3 seconds.
  • Rule behaviour can also be edited to allow rules to run before launch is detected, skip rules during lockouts, prevent the device turning off while the rule is active or act on a single valid output or require 5 valid outputs in a row over 5 cycles.
  • Rules can reference custom data sets where you can generate computed values to reference based on any equation you choose to use. We permit up to two custom data sets evaluated every cycle on the Mercury.

Output safety gates (new, applies to every automatic/rule-driven output)

The Mercury now has new output safety gates that protect high current outputs by default. You can choose to apply them to other outputs such as servos also in the rules system.

Found under the new output settings page you have the following options.

  • Startup lockout (seconds) - This setting prevents outputs from firing until this many seconds have passed from turning the Mercury on. Default is 10 seconds and you can configure 10-600s. This can not be turned off.
  • Altitude floor (meters) - This setting prevents outputs from firing unless launch has been detected and the altimeter is at least this altitude above the launch pad. Default is 50 meters and you can set this between 50 and 150 meters. This can not be turned off.
  • Launch confirm delay - This setting prevents outputs from firing until at least this many seconds after launch. Default 2 seconds, you can set this from 2 to 500 seconds and it also can not be turned off. 

You can also now use GP6 input/output solder terminal for an ARM switch. When enabled you just have to connect a switch between GP6 and GND on your Mercury, and when the switch is closed it will permit firing and when open it will block it. 

Custom dataset expressions

Two user-definable arithmetic expressions, parsed and recompiled live are available as rule trigger sources ("dataset1"/"dataset2").

Web/AP login system

The local device wifi access-point webserver now requires users to login. This ensures nobody can change your settings if they connect to it's wifi network, or if they find it over the wifi network you are connected to.
You can login either by entering the AP wifi password, or by pressing the button on your mercury when prompted to do so.

eNOW mini-chart broadcast

After a flight, the device can now broadcast a downsampled profile (240 samples) over ESP-NOW LR so a lost/unrecovered rocket's flight can still be reconstructed remotely.
This is along side the general flight summary data that the Mercury can ping out using ESP-NOW LR after flight.
You can typically recieve a ESP-NOW signal for 200-800 meters depending on your recieving hardware. 

"Maintain power" setting

Post-save behaviour is now an explicit 3-way setting independent of eNOW: sleep immediately, blink last apogee forever, or blink apogee for 10 minutes then sleep. Last apogee is persisted to NVS so a short button tap while idle re-blinks it on demand.

Truepath B 1.0

The Mercury can't quite handle our Truepath filter algorithm we created for the Nano V1 altimeter as it has less RAM, however we've put together a light version of it which is pretty much just as good. You would be hard pressed to see the difference in their outputs from our tests.
This is now included in the Mercury altimeter also.


2. Detection & recording algorithm changes

  • Higher sample rates: 150/200/250/300Hz added alongside 50/100Hz (250Hz now the default on all revisions, up from 50/100Hz before). "max_samples" is raised 12000 to 18000. Hybrid decimation modes extended: 1:3, 1:5 (new default), 1:7, 1:10.
  • Launch-floor tracking rewritten: was a flat average of the oldest ring-buffer slots (which could be all-zero right after the new early-calibration-escape change, causing false launch triggers); now a slew-rate-limited tracker seeded from real, time-windowed samples.
    This helps prevent accidental launch triggers when pushing on nose cones or pulling them off with small or no vent holes.
  • Flight calibration can now exit early (~6s of real pre-buffer data) instead of waiting for the full ring to fill, which at high sample rates took ~27 seconds. The stable calibration floor also work with the slew rate launch floor to prevent accidental triggers.
  • Launch detection is now a dual rate system. On low acceleration it requires an extra second above the launch detection threshold to trigger recording, and at high acceleration it uses the shorter window. This helps to prevent accidental launch detecion under vacuum events.
  • Lockout (post-launch spike/dropout) detection redesigned as a timestamp-based dual-speed trigger (sustained vs. instantaneous descent rate) instead of a fixed 3-consecutive-sample counter. This makes it's start and end points accurate and prevents a flat rate time lockout blocking rules even if the event has passed for some time. It's also now rate independant.
  • Apogee detection: settling window now decays from 1500ms at burnout to 400ms, protecting against the brief pressure transient right at motor burnout being mistaken for descent.
  • IMU re-sync: max resync offset now scales with sample rate (was capped at a fixed 25/50-sample window tuned only for 50/100Hz; a 100Hz flight had already been observed hitting that ceiling).
  • Stable-altitude auto-stop rewritten to use a real-time window (9s/18s) converted to sample offsets at the current rate, instead of hardcoded sample counts.
  • "Truepath" post-flight altitude filter: diagnostics for the filter are saved and uploaded to the AltimeterCloud for the filters operation.
  • Pre-buffer reconstruction: unfilled ring-buffer slots from an early launch (before the pad buffer fully fills) are now rebuilt as sane pad-baseline data instead of being saved as zeroed garbage. This only effects those of you who are trigger happy and get your launch going really quite soon after turning the altimeter on!

3. Reliability & fault handling

  • Two-tier thermal shutdown replaces the old single-sample 60°C trip: ≥80°C sustained 5s (fast runaway) or ≥70°C sustained 30s (sustained over-temp), both wall-clock timed so brief spikes don't nuisance-trip. Only operates in WiFi mode.
  • Fatal sensor errors (no pressure sensor / no IMU found) now flash for 10s then reboots. Sensors get re-powered and bring-up retries.
  • Reset-reason tracking: Boot reset reasons are captured every boot (poweron/SW/panic/watchdog timeouts/brownout), plus cumulative lifetime counters per reason persisted in NVS and reported on every ping.
    This lets you tell "what happened this boot" from "this unit's whole crash history."
  • I2C bus recovery: sensor reads are now wrapped with a timeout; on failure or timeout, a manual 9-clock/STOP bus reset recovers a glitched bus without a full sensor re-init (which would cost 50+ms and reset ODR mid-flight).
  • RAM/heap snapshots captured at key points (flight-mode entry, first flight-loop iteration, button-triggered stop) for post-flight diagnostics.
  • Allocation-failure handling: If the flight ram buffers fail to allocate the device will restart to try again after a 10 second notification period on the status LED.
  • Factory reset via button hold now genuinely clears all NVS settings (previously it only reset WiFi to open/no-password mode).
  • AP password: previously an 8-digit number now an 8-character mixed-case+digit string from the hardware RNG with visually-ambiguous characters excluded. A minimum 8-character length is now enforced.

4. Networking, cloud & security

  • All cloud calls moved from raw HTTP to a resolved IP address, to HTTPS.
  • HMAC-SHA256 signing (via the ESP32's hardware HMAC peripheral, keyed from an eFuse key block) added to upload/notify/verify calls, replacing a simple checksum-style. This proves data from your device is from your device as well as catching any data corruption. 
  • eFuse key deployment check: one-shot check-and-request flow for provisioning the unique per device HMAC key on first successful internet connection.
  • DNS cache refresh interval extended 30 min to 2 hours.
  • WiFi TX power ceiling changed from 17dBm to 15dBm well within the 20dBm EU limit with the stock PCB antenna.

5. Data & storage format

  • Flight logs moved from CSV to a compact binary format (.bin 34-byte fixed records) for both storage and cloud upload; CSV is now generated on the fly from the binary log when a .csv is requested (AP download or cloud upload), via a shared expander that mirrors the old CSV exactly. This offers a huge space saving allowing more logs and more data to be stored on the Mercury. 
  • JSON metadata sidecar (2.40+) the old metadata files were plain text format relying on specific line numbers. JSON format is a good improvment. 

6. Air brake control

  • Bug fix: the "urgency multiplier" thresholds (70%/40% over target) were being compared against the wrong baseline (overshoot is already a ratio ×100, so "on target" = 100, not 0). Meaning the multiplier was permanently active, rather than only when significantly over target. 
  • New: Air_initial_angle to hold a configured pre-position from burnout until active modulation starts, instead of sitting fully retracted with no authority in either direction.
  • New: Air_apogee_lock and air_apogee_angle: optionally drive to and hold a fixed angle at apogee instead of always retracting.
  • Target-altitude and overshoot-allowance settings now range-checked before being applied.