Byte Blaster v1.1.29

Byte Blaster v1.1.29

This prerelease adds phased launch and an interactive Launch Planner, plus startup power, launch-clock and estimated motor-current controls. Firmware and configurator ship together. These changes have passed automated tests; physical blaster validation remains outstanding.

Before flashing

• Re-run Tune Blaster after flashing. Launch control policy is now version 5, so stored PID validation is marked changed until tuning is repeated.
• Settings schema upgrades from 47 to 49 in place, preserving existing settings and the selected launch mode. Phased launch is opt-in (mode 3).
• Existing launch curves now use monotone cubic interpolation through the same 16 knots. Feedforward uses a fast 1 ms pack-voltage sample. Battery warnings and lockout retain filtered voltage.
• An estimated 60 A per-motor current cap is enabled by default, with 125 mOhm model impedance. This is a model estimate, not a measured-current limit, and can change existing launch behavior.

Launch Planner and phased launch

• New Launch Planner tab with draggable startup, BEMF-lock what-if, knee, landing, ramp-end and deadline controls.
• Phased mode runs startup until BEMF lock, then a constant-acceleration ramp with an optional second slope, and a landing that eases the slope to zero.
• Fixed-acceleration pacing is the default. Deadline pacing can steepen the ramp up to 2x after a late lock. An optional sync leash waits for a trailing motor and is off by default.
• Predictions show time to 90% target, estimated peak current, heat per shot, pack-voltage limits and limiter activity. Read last launch overlays measured data; Fit from last launch calibrates effective impedance.
• Apply to blaster writes the profile, selects mode 3 and verifies firmware readback. Phased acceleration feedforward uses the configured model impedance. From-stop targets below 5,000 RPM retain the timed linear ramp.

Startup and current controls

• Startup Power drives each motor open loop until its ESC reports BEMF lock, with a 300 ms maximum. Default startup power is 4 V; AM32 still applies its low-RPM duty limit.
• Launch Curve Start can use trigger time or BEMF lock. After-lock curve exports select the lock clock automatically.
• Current Cap supports off or 10-150 A per motor with configurable 20-400 mOhm impedance. It applies in the PID and final command, leaves glide uncapped, and requires measured speed.
• Launch traces report per-motor lock times, clock timing, current-cap activity, interpolation, startup policy and phased-profile metadata.
• The curve calculator adds drive impedance and RPM-at-lock inputs, defaults to 46 mOhm pack resistance and 45 ms lock time, and exports after-lock curves by default.

Older firmware compatibility

• Full settings writes and profile imports skip the new settings that the connected firmware does not report in its settings readback, so supported settings can still be applied to v1.1.28 and earlier firmware.
• Skipped settings are reported; skipped settings edits remain pending. Connected profile exports omit unsupported new settings.
• Phased-profile imports and Planner Apply require firmware that reports phased-launch support and are rejected before writing on older firmware. Flash v1.1.29 to use the new launch features.

Validation

• All 53 strict test suites pass with native checks required, including phased-launch math, planner integration, startup/current limits and older-firmware compatibility regressions.
• Hardware smoke testing remains outstanding: verify settings migration, existing-curve launches, tuning, phased-profile application/readback and measured-launch overlays before relying on this prerelease.
• Bundled AM32 F4A 4IN1 F421 v2.21 ESC firmware is unchanged.

Details and bench procedures: Phased launch, startup power and current cap.

Byte Blaster v1.1.28

Byte Blaster v1.1.28

This prerelease fixes profile imports stopping at the lifetime-counter setting and restores calibrated feedforward tables when copying a tuned blaster's profile.

Profile cloning

• Import restores both motors' calibrated feedforward tables, including validity masks and all ten stored drive values, then verifies them through board readback.
• Recover the actual saved launch curve and precise PID gains from older profiles with board readback metadata, preserving controls explicitly marked as unsaved edits. The older ff section is a launch-curve alias, not the calibrated feedforward table.
• Connected exports request fresh settings and launch-configuration readbacks and include explicit calibration and launch-curve sections. Failed readbacks do not produce an incomplete backup.
• Use the firmware's dedicated lifetime_counter on/off command instead of an unsupported generic setting command. The receiving blaster's lifetime shot count is retained.
• Reject unsupported calibration data before writing settings. Report command failures and readback mismatches; earlier accepted writes may already be applied because imports are not transactional.

Validation and use

• All 50 strict test suites pass with native checks required. The new suite covers complete, sparse, and empty tables; legacy exports; failed commands; connection changes; readback mismatches; and every representable drive value through the production learning function.
• The original reported profile passes the import harness with both calibrated tables, precise gains, and its saved 125 ms launch curve. Physical cloning on the receiving blaster remains to be confirmed.
• Refresh the configurator and re-import the original profile while connected. HUD layouts still require the editor's save action.
• These configurator fixes also work with existing v1.1.26 and v1.1.27 firmware; a firmware flash is not required to use them. The included v1.1.28 RP2040 firmware retains the v1.1.27 control and passthrough behavior with an updated version identifier.
• Bundled AM32 ESC firmware is unchanged.

Implementation details: Profile cloning.

Byte Blaster v1.1.27

Byte Blaster v1.1.27

This prerelease restores ESC passthrough access for an AM32 ESC that worked through Betaflight but failed through Byte Blaster, and includes the re-rev, launch diagnostics, and reliability fixes from October 1.

ESC passthrough

• Release the signal at the beginning of the final stop bit and clear pending PIO timing when switching from transmit to receive, allowing earlier ESC acknowledgments to be received.
• Validate the UART start bit so short signal glitches cannot become spurious 0xFF replies. Stop-bit checks remain active.
• Keep the last detected bootloader signature and mode visible in escdiag after a read failure.
• Confirmed on the user's OddityRC Vortex F65 AM32 ESC: the previously failing ESC reads through the updated RP2040 passthrough. No bootloader replacement was needed. The combined fix is confirmed; the individual cause was not isolated.

Re-rev and launch diagnostics

• Warm launches catch from the faster measured wheel and clear old controller state. A lower-preset re-entry keeps gliding until both wheels reach the catch band.
• Serial rev 0 preserves measured RPM during deceleration instead of falsely reporting stopped wheels.
• Launch captures include signed P/I/D/recovery contributions for both motors. Optional feedback curves and comparison findings expose unused command headroom and negative feedback while RPM trails the reference.
• Control policy advances to version 4. Stored gains, feedforward, and launch curves are retained; prior PID validation and paused tuning signatures are invalidated. Existing launch recordings remain readable.

Reliability and menu fixes

• Bound each motor-service pass so queued timer work cannot indefinitely block trigger-release and outer-loop handling.
• Require release before held FIRE/REV triggers become requests at power-up.
• Apply firing interlocks to direct solenoid tests and install the independent cutoff before energizing the coil. Failed cutoff allocation leaves the coil off.
• Stop an active solenoid pulse in the same motor tick when runaway protection trips.
• Menu Save preserves the stored solenoid base calibration and resets ammo correctly in count-up mode.

Validation and installation

• All 49/49 strict test suites pass, with native checks required. The new passthrough tests cover UART waveforms, glitches, framing, continuous replies, and production TX/RX handoff.
• RP2040 firmware builds for Waveshare RP2040-Zero. The passthrough fix has hardware confirmation on the reported setup; the wider re-rev and reliability acceptance checks remain documented in the game-day audit.
• Back up your profile, flash Byte_Blaster_RP2040_v1.1.27.uf2, and refresh the configurator to v1.1.27. Keep your existing ESC firmware and proven tuning for initial checks.
• Bundled AM32 F4A 4IN1 F421 2.21 binaries are unchanged. They are a separate ESC target, not a generic update for every AM32 ESC.

Implementation and acceptance details: ESC passthrough, game-day audit, and launch diagnostics.

Byte Blaster v1.1.26

Byte Blaster v1.1.26 — Testing prerelease

This release addresses two command restrictions identified in the 4S/125 ms hardware capture: a flat startup drive cap and a synchronization rule that cut the slower wheel's catch-up command. Software validation passes; improved hardware timing and a 125 ms launch have not been demonstrated.

Motor control changes

• RPM PID startup keeps the existing 4 V equivalent standstill budget and adds bounded slower-wheel RPM/Kv compensation as the wheels accelerate. At 2,000 RPM and Kv 3,200, the nominal ceiling becomes 4.625 V equivalent, subject to the existing 35% startup duty maximum. The shared slower-wheel handoff threshold remains in place.
• Startup Drive Budget is adjustable from 3–5 V in the configurator (startup_drive_mv in millivolts); default remains 4,000 mV. This is a throttle-command estimate, not measured winding voltage or a current regulator. TBH and direct ESC RPM modes retain their existing control laws.
• A clearly slower wheel can retain its already bounded catch-up request. The skew clamp still restricts the leading wheel and near-equal/noisy wheel speeds. Other controller ceilings, slew limits, telemetry guards and fault/overspeed protections remain active.
• EEPROM schema 47 preserves existing v46 settings and initializes the new budget to 4,000 mV. Gains, feedforward and curves are preserved. PID validation reports changed because the control policy changed; paused tuning cannot resume across a policy/budget change.

Diagnostic fixes

• Launch exports retain the startup budget, sync limit and startup policy from the time of capture.
• Comparison findings report observed startup-cap windows and synchronization restrictions on a slower wheel. Older v1.1.25 captures remain readable.
• Post-shot voltage samples no longer affect the launch voltage minimum. Stale/unavailable RPM cannot establish delivered-command lag or minimum-throttle overspeed; excluded samples are reported.
• Profiles, defaults and full setting writes include the new budget. No hardware tuning profile has been promoted to factory defaults.

Hardware test sequence

1. Back up the complete profile. Flash only Byte_Blaster_RP2040_v1.1.26.uf2, refresh the configurator and confirm both versions are 1.1.26. Keep the existing ESC firmware. An older firmware image may reset settings after this EEPROM upgrade, so retain the backup for rollback.
2. Keep the matched 4S/125 ms curve, gains/feedforward, 45-point rise limit, 80-point sync limit and 2,500 RPM handoff. Confirm Startup Drive Budget is 4.00 V. Do not retune or factory-reset between comparison groups.
3. With no darts, check normal startup and immediate rev-release response. Save five cold, no-shot launches at the usual 32,000 RPM preset, letting both wheels stop between runs. Read/download each last-launch comparison before the next launch overwrites it. Compare each wheel's 90%/95% rise, cap/sync windows, requested/applied commands, voltage sag and overshoot.
4. If baseline behavior is healthy, repeat separately at 4.20 V, then 4.40 V, with similar resting pack voltage and cool motors/ESCs. Use millivolt values 4200 and 4400 if setting through the console. Keep the lowest budget that improves timing without excess sag, heat, overshoot or faults; restore 4.00 V if it does not help. Do not jump directly to 5 V or disable sync to chase the deadline.
5. Check cold and already-spinning launches, 2,000/5,000 RPM diagnostics, HVZ single shots, other presets/modes and recovery. Confirm release, firing gates and dart counting. Stop a test if release is ignored or behavior is abnormal. This release does not claim to fix the 2,000 RPM startup overshoot.
6. Return the curve JSON, comparison downloads and defaults-candidate export for the best/worst runs. Include battery resting voltage, startup budget, ESC settings and any fault text. Current measurements from the external board would help distinguish command limits from ESC/motor response. Whole-blaster battery current is not per-motor winding current.

Detailed implementation and test rationale: startup drive headroom.

Validation and assets

• All 47 strict test suites pass with native tests required. Regressions compile the production controller/skew function, check startup budgets/bounds and old CRC compatibility, and exercise the recorder-to-configurator protocol.
• RP2040 compilation passes for rp2040:rp2040:waveshare_rp2040_zero. Hardware timing remains unverified.
• Byte_Blaster_RP2040_v1.1.26.uf2 / .bin: new RP2040 firmware.
• Bundled AM32 2.21 .hex / .bin: unchanged ESC firmware; no ESC reflash is needed for this comparison.
• manifest.json: asset hashes, sizes, source commit and prerelease channel.

Byte Blaster v1.1.25

Byte Blaster v1.1.25 — Prerelease

This release brings the optimizer reference, measured wheel speeds and motor commands into one launch comparison so a missed spin-up deadline can be investigated. It does not add a startup boost or claim to fix the observed 2,000 RPM overshoot.

Launch comparison and recording

• Simulation & Graphs now overlays optimizer RPM, the actual firmware reference and both measured wheel speeds. New calculator exports retain the dense simulation waveform and model inputs; older JSONs use their 16 knots.
• The board records the latest 320 ms launch at 2 ms intervals in the production motor service. Recording includes requested and applied commands, controller ceilings, feedforward, acceleration compensation, voltage, telemetry age, limiter flags and solenoid state.
• A capture includes an immutable snapshot of its duration, knots, target, gains and calibrated feedforward. Read and download it while idle before the next launch overwrites it.
• Findings distinguish configuration mismatch, firmware command limiting and lag after the requested command reaches the applied output. They do not claim to measure phase voltage/current or uniquely distinguish ESC limiting from motor/model error.
• Rise/peak analysis excludes stale RPM measurements and samples at/after the first recorded solenoid pulse. Separate 90% and 95% timing avoids confusing measured rise with firing-ready time.

Startup and defaults workflow

• Diagnostic target selection now includes 2,000 and 5,000 RPM with cold and already-spinning baselines. Use these to investigate startup overshoot; measurement does not automatically apply its proposed gains.
• Board tuning can be exported as a defaults candidate with actual readback, gain/curve/feedforward values and provenance. No factory defaults were replaced.
• Calculator cold-start exports now begin at zero RPM; the previous approximately 6 RPM origin was borrowed from the first integration timestep. Startup assumptions are included explicitly: ideal torque per amp, assumed handoff time, and no AM32 startup or winding-inductance simulation.
• The calculator is deployed alongside the configurator at https://parkerg16.github.io/Byte-Blaster/brushless_motor_thermal_calculator.html.

Hardware checks

1. Back up your profile, flash only the RP2040 UF2, refresh the website and confirm both show 1.1.25. Keep the current ESC firmware and tuning for comparison.
2. With no darts, confirm normal startup, rev and release. Upload the 125 ms curve through the existing burn control and load the same JSON into Launch comparison separately.
3. Save five cold no-shot launches at the usual preset. Read and download each last-launch capture while idle, before the next run. Confirm recorded duration/knots match the uploaded curve; record displayed timing separately from 90%/95% RPM rise.
4. Compare a 150 ms reference with the same normalized knots, preset, gains and similar battery voltage. Inspect requested/applied command and limiting flags where RPM falls behind.
5. Save three 2,000 RPM cold measurements and three already-spinning measurements. Compare motor peaks and command 48 during overspeed; do not apply diagnostic gains during this comparison.
6. Restore the desired curve and check single shots in HVZ, other presets/modes and a short burst. Verify firing gates, dart counting and rev release. Check USB reconnect and an intentional comparison-duration mismatch.
7. Export board tuning for defaults and retain the original curve JSON, comparison downloads and tuning report for review.

Detailed expectations and evidence to return: hardware checklist.

Validation and assets

• All 46 strict test suites pass, including native capture/serialization and actual configurator parsing/rendering/connection tests.
• RP2040 compilation passes for rp2040:rp2040:waveshare_rp2040_zero. Physical timing and UI operation still require the hardware checks above.
• Byte_Blaster_RP2040_v1.1.25.uf2 / .bin: new RP2040 firmware.
• Bundled AM32 2.21 .hex / .bin: unchanged ESC firmware.
• manifest.json: asset hashes, sizes, source commit and prerelease channel.

Byte Blaster v1.1.24

Byte Blaster v1.1.24 — Prerelease

This release fixes premature battery cell detection during startup and USB battery reconnects, along with dart counting and configurator write issues found in the follow-up audit.

Battery detection

• New-pack detection waits for 350 ms of stable voltage at rest. Motor output, including manual throttle tests, stays inhibited during qualification.
• A rising 5S voltage is no longer immediately latched as a 3S cell-change prompt when it first crosses 6 V.
• USB/absent-battery readings clear stale detection targets and reset voltage history. Reconnecting a higher pack updates the configured count only after qualification.
• Lower-voltage packs still require explicit confirmation before reducing the configured cell count. A stale ambiguous prompt clears if voltage subsequently settles back into the configured pack's range at rest.

Dart counting and configurator

• RPM drops observed after the shot detection deadline no longer falsely count a dart. RPM-drop counting and solenoid-pulse counting remain available.
• The configurator parses the actual firmware dart-detection status response as well as the legacy response format.
• Queued USB writes and acknowledgements are bound to their original connection. Disconnects cancel pending responses, and settings/profile batches stop if the connection changes.
• Profile/settings writes restore motor KV and cell-count limits before preset RPM values, normalize JSON booleans to the firmware's numeric format, and preserve newer edits made during a settings write.
• Profile PID controls update after each motor's acknowledgement, and Always On is enabled after gains and curve restoration.

Validation

• All 45 strict test suites pass, including native tests of the actual battery ADC/detection path and dart detection functions, plus actual configurator queue tests.
• Battery regressions cover 3S–6S packs, USB and zero-voltage disconnects, 5S voltage ramps, contact bounce, ADC noise, rest gating, late voltage recovery and millisecond rollover.
• RP2040 compilation passes for rp2040:rp2040:waveshare_rp2040_zero.
• This is a prerelease: physical battery reconnect testing and the 125 ms launch target still require bench verification.

Assets

• Byte_Blaster_RP2040_v1.1.24.uf2: RP2040 BOOTSEL firmware.
• Byte_Blaster_RP2040_v1.1.24.bin: Raw RP2040 firmware binary.
• AM32_F4A_4IN1_F421_2.21_v1.1.24.hex and .bin: Existing AM32 2.21 ESC firmware, bundled unchanged.
• manifest.json: Asset sizes, SHA-256 hashes, source commit and prerelease channel.

Byte Blaster v1.1.23

Byte Blaster v1.1.23 — Prerelease

Firmware and the web configurator are updated together. This prerelease repairs launch-curve handling, tuning/glide behavior, rejected configuration writes and firmware flashing. Flash v1.1.23 and reload the configurator to use the new atomic FPS calibration command.

Launch curves and preset changes

• Curve uploads now wait for firmware acceptance and verify the stored trajectory mode, duration and all 16 knots. A busy board, USB failure, timeout or mismatched readback is reported as a failure; disconnected imports are labeled as local only.
• Firmware and browser validate complete curves before changing active settings. Invalid stored curves are repaired after CRC validation while retaining other tuning.
• Each motor-control tick refreshes its launch reference and acceleration feedforward slope from elapsed time. Delayed/queued ticks no longer keep using a reference calculated before a main-loop delay.
• Calculator exports identify the actual programmed duration and preserve the requested optimizer deadline separately. Incomplete, descending or unsupported-duration references are blocked from export.
• Raising the preset while holding REV starts a new launch from measured RPM and re-arms firing readiness.

The imported duration is an RPM reference schedule. The HUD measures trigger-to-solenoid latency. The readiness gate normally waits for both wheels to reach 92% of target, subject to existing timeouts/fallback. A 125 ms curve does not guarantee 125 ms physical firing. Bench verification of the reported 125 ms versus 165 ms behavior remains outstanding; motor/ESC response and firmware output limits still apply.

Tuning and glide

• Cold driven-stop state resets for each glide, including glides beginning below 2500 RPM.
• Cold-stop drive is released when deceleration plateaus instead of always waiting out the full timeout when the ESC holds a low minimum speed.
• Removed the automatic flying-start redo introduced in v1.1.22: ESC startup acceleration could trigger it on genuine stopped launches.
• Tuning results report the drive-release/start RPM and time at STOP, and the configurator displays both.
• Both motors follow one decreasing glide reference with bounded per-motor feedforward correction. Default glide rate is 8000 RPM/s, minimum 3000 RPM/s. Independent runaway protection remains active.

Configurator, calibration and ESC connection

• Settings writes and resets require firmware acknowledgement. Rejected writes retain pending edits; preset limits are applied before preset RPM values, with Always On last.
• Profile import validates the complete file, restores PID gains with the correct m1/m2 commands and restores the launch curve. Partial failures are reported; imported HUD layouts explicitly require saving.
• FPS calibration validates all five points and saves them atomically. Invalid stored tables fall back without re-enabling a disabled estimator. Calibration mutations wait for actual STOP outputs, including after glide.
• Valid UF2 files are recognized using unsigned header reads and preserved intact. Both flash paths reject malformed/truncated files and incompatible flash layouts. Failed or superseded downloads cannot leave older cached firmware selected. Saving a file no longer claims a verified hardware flash.
• ESC passthrough retains fragmented MSP packets until complete and validates frame bounds/header/checksum before processing. Maximum-length MSP requests no longer wrap their length.
• Firmware selections label prereleases explicitly. The release manifest also records the prerelease channel.
• RPM-drop dart detection and the existing choice between confirmed-dart and solenoid-pulse ammo counting remain available.

Validation and release tooling

• All 42 strict test suites pass, including required native checks of production control, curve parsing, FPS storage and fragmented MSP transport.
• Tests run with four workers and separate suite logs; the release gate runs once before publishing. Firmware compilation uses four workers by default, adjustable through -BuildJobs.
• RP2040 compilation passed for rp2040:rp2040:waveshare_rp2040_zero. Hardware testing of launch/stop, preset changes, calibration persistence and ESC passthrough remains outstanding.

Assets

• Byte_Blaster_RP2040_v1.1.23.uf2: RP2040 BOOTSEL firmware.
• Byte_Blaster_RP2040_v1.1.23.bin: Raw RP2040 firmware binary.
• AM32_F4A_4IN1_F421_2.21_v1.1.23.hex and .bin: Existing AM32 2.21 ESC firmware, bundled unchanged.
• manifest.json: Asset sizes, SHA-256 hashes, source commit and release channel.

Byte Blaster v1.1.22

Byte Blaster v1.1.22 Release

Firmware and configurator are updated together. Flash the firmware and reload the configurator.

1. Fixed: "Cold" Tuning Launches Started on a Coasting Flywheel

• Driven to a Stop: In a cold tuning baseline, decel glide keeps the ESC actively driven down to 400 RPM (instead of 2,500 RPM) bounded to 1.5 s, ensuring the ESC maintains phase tracking all the way down to a genuine stop. Normal blaster operation and idle-baseline tuning maintain the standard 2,500 RPM freewheel cutoff.
• Time at STOP Required: A cold baseline now requires 300 ms with outputs at DShot STOP, preventing residual rotor momentum from being treated as stopped.
• Flying-Start Check: Early in a launch from a stop, the rotor must lag its reference trajectory. If it reads faster than reference by $\max(500\text{ RPM}, 15% \text{ of target})$ for 5 consecutive samples, the launch is flagged as a flying start, discarded without grading, and re-executed after a 2.5 s rest at STOP (up to 2 retries).
• Measured Start Speed: startRpm in tuning results is now explicitly measured (fastest reading in the first 80 ms) instead of assumed to be zero.

2. New: Resumable Autotune Sessions

• When a tuning run encounters a fault (low voltage, telemetry dropout, stall), fails a validation check, or is cancelled by the operator, progress is preserved in RAM. The previous validated tune remains active on the blaster.
• Retry: Re-runs the single measurement that failed or stopped the run.
• Re-Tune Failed Validation Points:
  • Validate FF: Re-measures feed-forward at the failed knot, verifies it, and resumes the sequence.
  • Validate PID: Re-tunes PID at the failed target, re-evaluates candidate gains across preset targets, and re-validates all targets.
• Start Over / Discard: Explicit options to reset or discard saved progress (autotune discard).
• Safety & Consistency Checks: Refuses resume if launch, motor, or preset settings changed while paused. RPM runaway faults and flash save errors are never resumable.
• Serial Commands & Telemetry: Added autotune resume retry, autotune resume retune, and autotune discard with status indicators (resume, resumeStage, resumeTarget, warn).

3. Changed: Fairer Validation Grading

• Preset vs Range Target Policy: Only preset RPM targets (targets nearest configured blaster presets) strictly require passing Validate PID. Non-preset range targets (e.g. 2k/5k floor) that encounter launch limits (rise time, settle, overshoot) generate non-blocking warnings instead of aborting the entire tune.
• Overshoot Floor: Overshoot only triggers if it exceeds both 5% and 300 RPM, preventing telemetry quantization noise from tripping false failures at low RPM.
• Informative Failure Detail: Failure messages now include the specific RPM target (e.g., M1 overshoot 35.2>5% @2k).

4. Configurator & Diagnostics Enhancements

• Tuning Run Export v2: "Download run" exports format v2 with per-sample phase, test target, pass numbers, board-time status timestamps, run options, firmware version, and formatted file names.
• Runaway Fault Display: Decodes faults 0x60 / 0x61 (ERR_RPM_RUNAWAY) and displays live health warning RPM RUNAWAY - CUT.
• Resume Control Panel: Web UI automatically presents Retry, Re-tune, Discard, and Start Over controls when a resumable session is detected.

5. Automated Tests

• Added tests/tuning_resume_tests.js testing retry, single-point re-tune, discard, stale settings refusal, validation warnings, and flying-start detection.
• Updated production_tuning_path_tests.js, guided_tuning_ui_tests.js, tuning_native_tests.js, and glide_freewheel_tests.js.
• All 30 test suites pass cleanly.

Assets

• Byte_Blaster_RP2040_v1.1.22.uf2: Drag-and-drop firmware binary for RP2040 bootloader.
• Byte_Blaster_RP2040_v1.1.22.bin: Raw flash binary.
• AM32_F4A_4IN1_F421_2.21_v1.1.22.hex: Pre-built verified AM32 ESC firmware.
• AM32_F4A_4IN1_F421_2.21_v1.1.22.bin: Pre-built verified AM32 ESC firmware binary.
• manifest.json: Checksums and release asset metadata.

Byte Blaster v1.1.21

Byte Blaster v1.1.21 Release (Safety Hotfix)

Everyone on v1.1.19 or v1.1.20 should update.

1. Fixed: Flywheels Could Speed Up After Releasing Rev

• Symptom: After letting go of rev, flywheel RPM climbed instead of coasting down, potentially reaching full speed.
• Cause: Introduced in v1.1.19 freewheel-emulating decel glide. While coasting down, glide held throttle for "measured RPM - 150 RPM". If the feed-forward (FF) table reads even slightly high (uncalibrated factory table, hot motors, or Kv variation), this produced positive feedback where held throttle accelerated the rotor, raising the subsequent command up to maximum RPM.
• Fix: The decel glide no longer depends on the FF table to remain safe:
  • Glide command is strictly monotonic (can only fall) and starts from wire throttle at release.
  • If the rotor climbs >100 RPM above its lowest recorded coasting speed, command is aggressively stepped down every tick in proportion to the climb until it ceases climbing.
  • Coast reference enforces a minimum decel rate of 5,000 RPM/s, ensuring all glides conclude within ~6s from 31,000 RPM regardless of FF table error, while maintaining regen under 1.4 A.
  • Single-motor tuning peer coast uses the same guard.

2. New: Independent RPM Runaway Protection (Safety_Monitor.h)

• Allowance Floor & Tracking: Independent supervisor monitor on each motor calculates an allowable speed ceiling (reference + max(1500 RPM, 10%)). On spin-down / release, allowance strictly falls with actual rotor deceleration so the rotor cannot climb beyond the safety margin.
• Trip Condition: Any motor exceeding its allowance ceiling for 30 ms latches a RUNAWAY lockout, immediately commanding DSHOT_CMD_STOP on both motors and recording fault 0x60 (Motor 1) or 0x61 (Motor 2) with voltage, RPM, throttle, and target.
• Comprehensive Coverage: Monitors every output path (PID loop, launch assist, decel glide, dart recovery, peer coasting, and tuning). Tuning runs abort safely with "RPM runaway - cut".
• Safe Clearance: Requires a minimum 2.0-second lockout period, both physical triggers released, and both flywheels stopped (<2,500 RPM or stale telemetry). Idle hold and Always-On spin are inhibited until an explicit user trigger pull.
• Configurator & Diagnostics: Added fault badges and explanations for ERR_RPM_RUNAWAY_M1 and ERR_RPM_RUNAWAY_M2, along with live status display (RPM RUNAWAY - CUT).

3. Fixed: Stale RPM Telemetry Identification

• RPM freshness timestamps (lastTelemetryValidMs) now require valid, plausible eRPM frames rather than non-RPM status/EDT frames or corrupted packets. Prevents stale RPM readings from masking speed changes during glide, stall, runaway, and tuning checks.

4. Verification & Automated Tests

• Updated tests/glide_freewheel_tests.js with FF-error sweep (+1% to +25% at 15k, 22k, 31k RPM, mid-launch release, and peer coast).
• Added tests/runaway_protection_tests.js verifying runaway monitor tripping, wiring, clearing constraints, and eRPM frame gating.
• All test suites pass 100% cleanly.

Assets

• Byte_Blaster_RP2040_v1.1.21.uf2: Drag-and-drop firmware binary for RP2040 bootloader.
• Byte_Blaster_RP2040_v1.1.21.bin: Raw flash binary.
• AM32_F4A_4IN1_F421_2.21_v1.1.21.hex: Pre-built verified AM32 ESC firmware.
• AM32_F4A_4IN1_F421_2.21_v1.1.21.bin: Pre-built verified AM32 ESC firmware binary.
• manifest.json: Checksums and release asset metadata.

Byte Blaster v1.1.20

Byte Blaster v1.1.20 Release

1. Launch Timing & Acceleration Feed-Forward

• Launch time follows imported curve: The launch reference duration is now a configurable setting (launch_time_ms, 60–300 ms, default 150 ms). Previously, the reference trajectory was stretched over a fixed 150 ms regardless of curve duration. Importing an optimized curve now transmits its simulated spin-up time alongside the 16 knots (launch_curve set <16 knots> <ms>).
• Launch Acceleration Feed-Forward (accel_ff, 0–250 %, default 100 %): Adds torque/voltage compensation proportional to flywheel acceleration along the reference curve trajectory, eliminating the ~11 ms PID lag during spin-up. Launches reach target RPM faster and track the reference much more closely. Set accel_ff 0 to revert to previous behavior.
• 5S Optimized Launch Curves: Added precomputed curves (145, 140, 130, 125, 120, and 115 ms) in Optimized Ramp/, along with a complete bench-testing procedure in docs/LAUNCH_TIME_LADDER.md.

2. Thermal Calculator Calibrated with Measured Values

• Motor Resistance Correction: Phase-to-phase motor resistance updated from 0.20 Ω to 24.7 mΩ based on 4-wire Kelvin bench measurements. The previous value included probe and contact resistance, artificially capping 4S spin-up model performance and overstating per-launch heat dissipation ~8×.
• Calibrated System Defaults: Updated model defaults to ESC $R_{ds(on)}$ 6 mΩ (Vortex F65 / VSP003N04MS-G), 5S 21.0 V pack, 30 mΩ pack ESR estimate, and a 60 A post-BEMF current ceiling.
• Dual-Motor Shared Pack Sag: Voltage sag modeling now accounts for both motors drawing from a single battery pack simultaneously.
• Firmware Resistance Model: Model launch resistance MODEL_LAUNCH_R_LL_OHMS adjusted from 29.4 → 31 mΩ (motor + FETs + PCB traces) for accurate launch current telemetry.

3. Autotune & Tuning Workflow Enhancements

• Hold FIRE (≥100 ms) to Cancel Tune: Autotuning can now be safely cancelled directly from the blaster at any time by holding the FIRE trigger for 100 ms. The motors glide down smoothly without hard active braking. The cancel only arms after the trigger is released, safety faults take precedence, and the solenoid pusher cannot actuate.
• OLED Live Tuning Diagnostics: The blaster display now shows real-time autotune progress: stage name, step progress bar, target RPM, pass number, individual motor RPMs, and "Hold FIRE to stop". Aborted or stopped runs display the exact failure reason and measured value against limits (e.g. M2 rise 320>300ms).
• Cross-Target PID Selection (TUNING_SELECT_PID): Autotune now evaluates distinct per-target best PID gains across preset RPM targets with normalized scoring weighted by mapped presets, rather than picking raw score minimums across disparate RPMs.
• Single-Motor Coast & Glide Protections: In single-motor autotune, the motor not being tuned now coasts via the decel glide law (hold throttle for RPM - slip) instead of being ramped into DShot 0 at speed. Stale telemetry glides decay smoothly from the loss point, and the autotune result screen keeps the production loop alive at target 0 until active glides complete.
• PID Integral Bleed: Replaced the abrupt zero-on-overshoot integral wipe with a gradual 50 ms bleed acting only beyond $\max(150\text{ RPM}, 1%)$, preventing eRPM quantization jitter (~110 RPM at 31k) from wiping trim.
• Configurator UI Improvements:
  • Stage markers are plotted using actual firmware timestamps (fixing a bug where all drew at $t=0$).
  • Clear messaging for feed-forward reuse, measurement, or recalibration.
  • Aborted runs show specific measured metrics and failure limits.
  • Results table includes Start column, Kp, Ki, and launch limiter attribution.
• Per-Tick Launch-Limit Logging: launchtrace now logs ref, lim1, lim2, bind1, and bind2. Telemetry streams output LIM1/LIM2, and tuning result packets track the percentage of launch time each limit was active.

4. Safety & System Fixes

• Deferred Flash Commits: Flash EEPROM writes (~50+ ms with interrupts disabled) now go through eepromCommitOrDefer() and are flushed from loop() once motors are idle (DSHOT_CMD_STOP), no pulses are active, and no decel glide is underway.
• Hardware-Timed Solenoid Cutoff: Solenoid ON pulses are backed by a hardware alarm timer with generation tracking, ensuring that a stalled loop cannot stretch the coil pulse and overheat the solenoid.
• Stall Lockout Protection: Stall lockout now latches for ≥ 1 second and only clears upon trigger release, preventing idle hold and Always On spin from repeatedly driving into a jammed dart.
• Global Flywheel RPM Limit (max_rpm): Configurable RPM ceiling (default 40,000 RPM, range 10k–60k) that caps all presets, Always On, and tuning runs. Exceeding 105% of the limit commands a gentle coast rather than slamming to minimum throttle. Configurator slider added.
• Menu Glide Servicing: Resolved an issue where control-tick timers were inactive during menu mode, ensuring that decel glides initiated on menu entry always finish smoothly.
• Full DShot Range: DSHOT_MAX_THROTTLE updated to 2047 for full DShot protocol range.
• eRPM Sanity Checks: Rejects corrupted eRPM telemetry decodes (0xFFFFFFFF or > RPM_ABSOLUTE_MAX).

5. Upgrade Notes

• EEPROM Settings Schema v45 → v46: Existing settings are preserved across the upgrade. Default launch time is initialized to 150 ms and acceleration feed-forward to 100 %.
• PID Validation Invalidation: Because launch settings are included in the configuration fingerprint, existing validation badges will show "changed since validation". Running a quick Tune Blaster session is recommended.
• Web Configurator Compatibility: Use the matching v1.1.20 web configurator to support the new launch duration and feed-forward parameters.

6. Automated Releases

• Added GitHub Actions workflow (.github/workflows/release.yml) for automated builds and testing on GitHub runners.
• Added tools/tag_release.sh for one-command tagging, verification, and status monitoring.

Assets

• Byte_Blaster_RP2040_v1.1.20.uf2: Drag-and-drop firmware binary for RP2040 bootloader.
• Byte_Blaster_RP2040_v1.1.20.bin: Raw flash binary.
• AM32_F4A_4IN1_F421_2.21_v1.1.20.hex: Pre-built verified AM32 ESC firmware.
• AM32_F4A_4IN1_F421_2.21_v1.1.20.bin: Pre-built verified AM32 ESC firmware binary.
• manifest.json: Checksums and release asset metadata.