Wireless PRO TX (0x19F7:0x0056): delete-all confirmed working with the same 01 4A 01 command

[lgnap]

Update: tested since — 01 4A 01 works unchanged on the Wireless PRO TX
and deleted all 23 recordings. Details, including the progress-report
behaviour, are in the comment below. The original text is kept as written.

Thanks for krode — and especially for documenting the protocol rather than
just shipping a binary. This is a request for Wireless PRO support, but
mostly it is a data dump, since I have the hardware and you may not.

When first posted, nothing below had been sent to the device: it was passive
observation only — USB descriptors, and a trace of RØDE Central's own HID
traffic. I have since run the command; see the update above and the comment.

Devices

All under VID 0x19F7:

PID	Product	Interfaces
0x0056	Wireless PRO TX	HID 03/00 + Mass Storage 08/06 when connected directly
0x0058	Wireless PRO RX	HID 03/00, plus Audio 01/01 + 01/02 in some modes
0x007A	Charge Case+	HID 03/00
0x007C	Charge Case+	Mass Storage 08/06

Docked in the charging case, the TX and RX expose HID only — the case
itself presents the aggregated storage through two internal 1a86:8091 hubs.
A TX connected directly presents its own storage.

Your read-only observation holds here too

Your README notes the Interview PRO's mass storage is read-only. Same on the
Wireless PRO, and it is the block device itself that says so:

/sys/block/sdb/ro = 1

Both when the storage comes from the charging case and when a TX is connected
directly. So deletion cannot go through the filesystem on this model either —
which is what led me here.

The interesting part: same command shape

I traced RØDE Central's HID traffic (it runs under Wine/Bottles, and the
device list, battery levels and firmware version all work — only the
Recordings tab fails). Wine's WINEDEBUG=+hid gives the raw reports.

Three report families are used:

id 1,  17 bytes   01 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
id 1,  17 bytes   01 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
id 9,  37 bytes   09 00 01 00 ...   (1478 occurrences — polling)
id 9,  37 bytes   09 01 01 00 ...
id 15, 64 bytes   (2 occurrences)

id 1 / 17 bytes is exactly the shape your delete command uses
(01 4A 01 00 …). Different opcodes — I observed 0x36 and 0x77, you
document 0x4A — but the same report id, the same length, and the same
[id][opcode][param][padding] layout.

That makes it plausible the Wireless PRO shares the command family, with
0x4A possibly meaning the same thing. Plausible is not verified.

What I did not do, and why

I did not send 01 4A 01 to a Wireless PRO. An unknown vendor opcode against
firmware on hardware I use for fieldwork is not a risk worth taking blind, and
a negative result would be indistinguishable from a bricked setting.

Since resolved: I ran it. It works, and the device answers with a
progress percentage rather than a single status code — see the comment for the
full exchange.

Environment

Fedora 44, kernel 7.1.12, hidraw access via a udev rule tagging
ATTRS{idVendor}=="19f7" with uaccess across the hidraw, usb and
block subsystems. Wireless PRO firmware 1.3.3 (from the BWF bext chunk),
RØDE Central reports 1.0.2 for the case.

Happy to run further captures if any of this is useful.

[lgnap]

Confirmed: 01 4A 01 works unchanged on the Wireless PRO TX (0x0056)

I tested it. Same command, same report shape, and it deleted every onboard
recording. My files were already copied off and hash-verified, so the only
thing at risk was the device state — nothing went wrong.

before:  23 files, 3.2 GB used
after:    0 files,  32 KB used, 29 GB free

The device replies with progress, not a status code

This is the part worth adding to your README. The response is not a single
status — the device streams progress reports while it erases:

02 4A 41 00      report id 2, opcode echoed, ACK 0x41,  0
02 4A 41 05                                             5
02 4A 41 0A                                            10
02 4A 41 0F                                            15
   …

Byte [3] is a percentage, counting 0 → 100 in steps of 5. So the "status
100 = success" in your README is the device reporting 100 % complete, not
an arbitrary success constant. On a 3.2 GB transmitter the whole sequence takes
a few seconds, and the device re-enumerates on the USB bus when it finishes —
its hidraw node disappears and comes back under a new number, which is worth
knowing if you poll for the final report.

Practical notes

• Sent with a plain write() on /dev/hidrawN, 17 bytes, no hidapi needed.
• The mass storage should be unmounted first — I unmounted it before sending.
• Expect the node to vanish mid-poll; reopen by VID/PID rather than by path.

Suggested wording for supported devices

0x0056 (Wireless PRO TX) can be listed as confirmed working for delete-all.
I have two of these transmitters and can re-test anything you want.

Thanks again for documenting the protocol rather than just shipping a binary —
that is the only reason this was a five-minute check instead of a capture
session.

[lgnap]

Three more findings, from erasing the second transmitter

Follow-up to the comment above. I wiped my other Wireless PRO TX as well, this
time through the charging case, and three things came out of it that seem
worth having in the README.

1. It works through the charging case — no need to undock

The transmitters expose HID only while docked (the case presents the storage
itself, through two internal 1a86:8091 hubs), but the delete command reaches
the transmitter over its own hidraw node all the same:

01 4A 01 …   sent to the docked TX
02 4A 41 00     ACK,   0 %
02 4A 41 05            5 %
   …
02 4A 41 64          100 %

6.1 GB / 28 recordings, 1.8 s from 0 to 100. For everyday use this is the
convenient path: one cable, both transmitters, nothing to unclip.

2. hid_open(vid, pid, NULL) cannot address two Wireless PRO transmitters

This one is a real limitation for this model. The Interview PRO gets away with
hid_open(RODE_VID, pid, NULL) because its two units have different PIDs
(0x0063 / 0x0068), so trying each PID in turn reaches both.

Both Wireless PRO transmitters share PID 0x0056. hid_open with a NULL
serial returns whichever one enumerated first, and there is no way to reach the
other. Selecting by serial — hid_open(vid, pid, serial), or hid_enumerate()
then hid_open_path() — is required here.

Conveniently, the serial is easy to map to a human-meaningful thing: the HID
serial is the FAT volume UUID of that transmitter's storage.

/dev/hidraw10  HID_UNIQ=800A92D6   ↔  volume UUID 800A-92D6
/dev/hidraw12  HID_UNIQ=800AF63E   ↔  volume UUID 800A-F63E

So you can identify which physical transmitter you are about to erase by
mounting its volume and looking at the filenames, then target it by serial.

3. Node numbers are not stable — verify the serial immediately before writing

Unplugging and replugging the case swapped the two hidraw numbers:

before replug:  hidraw10 = 800A92D6      hidraw12 = 800AF63E
after replug:   hidraw10 = 800AF63E      hidraw12 = 800A92D6

Anything that resolves a path once and writes to it later can hit the wrong
transmitter. I had a guard re-reading HID_UNIQ from sysfs right before the
write; it was not a theoretical precaution, it would have caught exactly this.

Also worth documenting: a replug is needed afterwards

After the erase, the transmitter re-enumerates and its volume comes back
without a filesystem — I/O error on the block device, and a stale extra
node appeared alongside. Unplugging and replugging the case restored both
volumes as empty FAT32. I first thought it recovered on its own; it did not,
and someone following the procedure would sit waiting for a volume that never
comes back. Replug is part of the procedure.

Both transmitters are now empty and recording normally. Happy to test anything
else on this hardware.

[lgnap]

Why the official app can't be the fallback on Linux — traced

Closing note on this issue, since it explains why a native tool is not just
nicer here but necessary.

The obvious question was whether Linux users could simply run RODE Central
under Wine and skip all of this. The answer is no, and it is worth recording
why, because the failure looks exactly like a permissions problem and isn't.

With the right udev rules (TAG+="uaccess" on ATTRS{idVendor}=="19f7") and
PROTON_ENABLE_HIDRAW, RODE Central under Bottles lists devices, names,
battery and firmware correctly. The Recordings tab still fails with
"Something went wrong during the device connection. Please unplug and plug the
device again." Replugging does not help.

I traced a full session with WINEDEBUG=+hid,+hidp,+usb:

write output report (app → device)	1489
process_hid_report (device → app)	1489
NACK responses (0x4e)	0
HID errors of any kind	0
volume / mass-storage enumeration	0

The vendor HID exchange is bidirectional, one-for-one and completely
successful. The device ACKs (0x41) every command and refuses nothing.
Responses decode correctly too — report 0x0f returns the serial:

→ 0f 00 01 ...                         (report id 15, 64 bytes)
← 10 00 41 00 d6 92 0a 80 ...          (report id 16, 64 bytes)
            ^^^^^^^^^^^ LE 0x800A92D6

0x800A92D6 is exactly that transmitter's HID_UNIQ. The protocol works
under Wine.

What does not work is one call outside the protocol. The same trace contains,
from the same thread, throughout the session:

0180:fixme:setupapi:CM_Get_Child_Ex child 0000000006FBF960, node 0x7, flags 0, machine 0000000000000000 stub!

973 times, always the same devnode, always the same stack slot, at the
cadence of the app's refresh loop: each cycle polls over HID (fine), then tries
to walk down the device tree to the child interface (fails). An app that got
its answer doesn't ask 973 times.

CM_Get_Child_Ex is how a Windows app descends from a composite USB devnode to
its child interfaces — the standard way to find the storage endpoint belonging
to the same physical device as the HID interface. In Wine
(dlls/cfgmgr32/cfgmgr32.c)
it is a stub, and the stub is worse than a plain failure:

CONFIGRET WINAPI CM_Get_Child_Ex( DEVINST *child, DEVINST node, ULONG flags, HMACHINE machine )
{
    FIXME( "child %p, node %#lx, flags %#lx, machine %p stub!\n", child, node, flags, machine );
    return CR_SUCCESS;
}

It returns CR_SUCCESS without ever writing *child. The caller believes
it succeeded and reads an uninitialised DEVINST off its own stack.

That also explains the intermittency I originally mistook for flakiness in my
own setup: all those calls target the same stack slot, so the garbage there is
stable within a run but differs between launches. Same bottle, same
devices, working on one launch and failing on the next. No configuration change
involved.

Why this matters for krode

• Nothing on the Linux side fixes it. udev rules, mount points, drive letters,
  removable device types, DXVK — all tried, none of it is even reached,
  because the app never touches a filesystem in the failing path.
• Fixing it properly means implementing CM_Get_Child_Ex in Wine. Making the
  stub return CR_NO_SUCH_DEVNODE instead — as was done for CM_Get_Parent
  back in 2018 — would at least turn undefined behaviour into an honest
  failure, but probably won't make the tab work.
• Meanwhile the vendor protocol itself is entirely healthy, including under
  Wine. Which is the encouraging part: everything krode needs is reachable, and
  a native implementation is the only path that doesn't depend on an
  unimplemented Windows API.

So "just use the official app in a bottle" can be ruled out as an alternative,
and this issue's 01 4A 01 findings stand as the practical route. Happy to
re-run the trace or test further commands on my two transmitters if useful.

[LinuxRenaissance]

A side question: Can you see both of your Wireless Pro devices at once, in the official Windows app, while only one is on USB and the other one is wirelessly connected? If yes, does the official app allow you to wipe both at the same time? As I only have one device with storage - I can't quite test this, but I have ideas.

[lgnap]

I'm not sure about what you're asking.
I create a repo https://github.com/lgnap/rode-raconteur that tested a LOT of combination.

But I can explain quicly some :

• settings available always when usb connected.
• for RX into charging box => only usb settings,
• RX connected directly to usb => sound card detected and the data from mics can be streamed to computer
• any TX connected to USB => MTP/mass storage available with all records on it (but no audio source/sound card)
• for TX (with/without charging box) is always this behavior

But when wirelessed I don't have accessible settings. and the RX must be usb/jack connected to output the 'direct' sound somewhere.

But (and this is explained into pr #1) the both system can be clean in one pass. Just need to make the call to the both devices (and @zinic do that ;-) )