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.