Qu-Pac forced firmware reinstall — the key combination is Channel + Sel 10 (confirmed by A&H Support)

Qu Qu Troubleshooting
1

Posting this because the Qu-Pac forced-firmware combination does not appear anywhere
public, and the question has been asked here several times over the years without ever
being answered — including “Qu-PAC frozen on boot up” (2017, still zero replies) and twice
inside “Qu 16 does not boot” (2019).

I got the answer from A&H Support and it worked. Sharing it so the next person finds it.

The combination

Channel + Sel 10, held while powering on.

Steps:

  1. Load the firmware .QUU file into the ROOT of a FAT32-formatted USB drive. No folders —
    not even the AHQU folder. Exactly one .QUU file on the drive.
  2. Insert it into the front USB A (Qu-Drive) port WITH THE UNIT POWERED OFF.
  3. Hold Channel + Sel 10 and power the unit on.
  4. Perform a hard reset (Reset + Setup at power-on) AFTER the forced reinstall — A&H
    specifies this step.

Note: the widely-repeated USB + HPF In combination is real, but it is for the
Qu-16/24/32 and is physically impossible on a Qu-Pac — neither key exists on that model.
This is the Qu-Pac equivalent.

macOS users — read this or it will silently fail

Two separate macOS problems, both documented by A&H:

  1. Rename the firmware file to QUPACU~1.QUU (six letters before the tilde: Q-U-P-A-C-U).
    See A&H article 27372432963729. Some renderings of that article show QUPAC~1.QUU with
    five letters — that is wrong.

  2. macOS silently writes a hidden AppleDouble sidecar named ..QUU. It also ends
    in .QUU, it is 4 KB of garbage, and A&H’s own docs say the Qu “will attempt to load the
    first version file it finds.” Remove it:
    dot_clean -m /Volumes/YOURUSB
    rm -f /Volumes/YOURUSB/.    *
    Then verify only one .QUU is present.

How to recognise your case

Before the fix, my Qu-Pac sat on the boot splash indefinitely — screen on, logo showing,
never rebooting, never reaching the UI, so Setup / Utility / Firmware was unreachable.

Diagnosing it over Ethernet and USB-B showed a very specific pattern:

ALIVE — pingable, DHCP lease, TCP 51325/51326 open and accepting
ALIVE — MIDI Active Sense (FE) heartbeat over TCP, per the Qu MIDI Protocol spec
ALIVE — USB-B enumerating as QU-PAC and streaming 32x32 audio at 48 kHz, real-time clock
DEAD — no reply to Get System State or Get Name SysEx on any transport
DEAD — every one of the 32 USB audio channels reading exactly 0.000000, no noise floor

So everything autonomous was running, and everything depending on the main application and
the DSP was not. That is what a corrupt DSP firmware section looks like. Qu-Pad would find
the mixer on the network but always fail to connect, because the mixer cannot answer the
first request Qu-Pad makes.

After the forced reinstall the same audio capture showed a real per-channel noise floor
(RMS between -106 and -115 dB, different on every channel) instead of absolute zero. The
mixer is fully working again.

Thanks to A&H Support for supplying the procedure.