Potential for Pod Go support?

[jamesremuscat]

As mentioned on Reddit - wondering about the potential for Pod Go support as at least some of its software is very similar, if not identical to, the Helix line.

It even has a USB PID of 0x4247 which slots neatly between two other known devices...

Please find attached a USB packet capture containing POD Go Edit's initial handshake - hopefully enough for you to be able to see if this is an immediate dead end or if there's potential for support here.

Pod Go init.zip

Very happy to provide further captures as required.

[john-baxter-dev]

Thanks for sharing this! Initial signs looks good. I think this will be doable if you can do some more captures and some testing! More info incoming.

[john-baxter-dev]

This helped a ton!

Not a dead end. Every decoder we have parsed it unmodified: the frame codec, the three channels
and their ids, the handshake, the MessagePack envelope and the op numbers (it even asks for the same
two setting ids at startup), and the paged preset stream reassembled into a valid l6-helix blob.
The POD Go identifies as P34 — from the handshake's "P34Main" and the streamed preset's own
stamp, which is the two-source standard the Stomp XL's P36 was accepted on.

What differs is the data, not the protocol. A block's model is an index into the device's symbol
table, and the POD Go's is its own: PodGo.sym, 627 entries against Helix.sym's 833, with no
mapping we can compute — three models line up at exactly +8 and then Simple EQ is 473 against 132
and it falls apart. Decoded against HX data your preset came out as ten wrong models and a 120.6%
DSP load. With POD Go Edit's res/ imported, the same bytes give 33.7% and every block resolves to
the name the preset itself carries — Scream 808, Minotaur, Fassel, Transistor Tape, Glitz, Simple EQ.

That's on a branch now: the device entry and udev rule, per-family reference data (POD Go Edit's
files import into their own subdirectory, since the .models names collide with HX Edit's), and
show-preset picking the right table off the stream. Your capture also turned up a real bug
affecting the HX — the two editors disagree on whether a symbolicID keeps its Mono/Stereo
suffix, and we only ever handled one convention.

So reads should work; writes are the open half. Nothing has ever been sent to a POD Go, so none
of the edit builders is reconciled against one, the footswitch mapping is the Stomp's rule applied
blind, and the fixed chain means add/move/delete need their own work.

If you're up for more captures, three would settle most of it — a parameter tweak, a bypass toggle,
and a block model swap, each on a slot you can name. Same three that pinned down the Floor's write
path.

[john-baxter-dev]

BTW, it's on the branch pod-go-support

[jamesremuscat]

Amazing!

Hopefully these are what you need - I've tried to keep the captures as short as possible.

Changing value for slot 6, parameter 1 (Amp -> Lead Gain)
Pod Go param change.zip

Toggling bypass on for slot 9 (Reverb, Dynamic Room):
Pod Go bypass slot 9.zip

Swapping block 8 model from Elephant Man to Adriatic Delay
Pod Go swap block 8 model.zip

Let me know if you need more.

[jamesremuscat]

Just tried running from the pod-go-support branch: the POD Go is detected correctly. In lieu of autodetection I needed to hack editor.rs to force it to load the POD Go reference data:

     pub fn load() -> crate::Result<Catalog> {
-        Catalog::load_family(crate::import::HX)
+        Catalog::load_family(crate::import::POD_GO)
     }

(I don't really speak Rust but could manage that much!)

With that done fretwire pull could pull data off the pedal and I could even get the GUI working, with changes mirrored in both directions; though there are a bunch of missing items (half the delay models, and the entire wah and reverb categories, possibly others).

Managed to make it fall over by trying to add an extra block (which I'd expect to fail!):

thread 'tokio-rt-worker' (582173) panicked at crates/fretwire-core/src/session.rs:1784:14:
dst is an effect block in this row

The pedal itself then crashed when trying to switch to a different preset but a power-cycle solved that.

It did let me replace the wah (mandatory and not editable in POD Go Edit) with a delay block, though, which is lovely!

[john-baxter-dev]

This is so awesome/exciting! You're telling me it let you do swap a block that you normally can't do, either on the device or the OEM software??

[john-baxter-dev]

Regarding the captures: These were perfect! All three reconcile byte for byte — every edit builder we have was written
from HX Stomp traffic and reproduces your POD Go's bytes unchanged, no edits:

your edit	op	builder
slot 6 param 0 (Lead Gain)	30	set_value
bypass slot 9	41	bypass
slot 8 → Adriatic Delay	40	swap_model

Plus the refresh POD Go Edit does afterwards (read_switch, read_info, stream_start). The
bypass one is my favorite — against the Stomp's captured bypass in our golden tests:

HX Stomp  8366cd03f1 6429 6582 62 07 3bc2
POD Go    8366cd03f1 6429 6582 62 09 3bc2

One byte apart, and it's the slot number. There's no POD Go dialect.

Your three problems are all fixed on the branch:

1. No more hacking editor.rs. Session::connect now picks the data family off the connected
   device's PID.

2. The missing models were a real bug, and a bigger one than it looked. HX Edit keys 344 models
   by the stripped symbolicID and 8 by the full …Mono/…Stereo one. POD Go Edit keys 180 by
   the full symbol and zero by the base. We looked up the base, so every suffixed POD Go model
   silently vanished — that's your whole Wah and Reverb categories (both are entirely …Stereo),
   and EQ, Volume/Pan, IR, Looper, and Delay down to 10. Fixed, and it turned out 8 DL4 delays were
   quietly missing from the HX picker too. Thanks for spotting that one.

3. The panic is gone. insert_block hardcoded the Helix's row windows (slots 1-8 and 11-18).
   Your ten blocks are one row, so slots 9 and 10 hold blocks where a Helix has bounding nodes, and
   it fell off the end. It refuses now instead of panicking. Sorry about the power cycle.

Bumped to Reported.

If you're up for more, three things would close out nearly everything left — and the first isn't
even a capture:

1. A .hxb backup exported from POD Go Edit. Highest value by far. It's the only place
   preset_device_id lives, and that single field is the one thing keeping this at Reported
   instead of Verified — the protocol side is already done. Just a file export, no capture needed.

2. A footswitch assignment — assign some block's bypass to a switch you can name, and capture it.
   We currently map blocks to switches by the Stomp's rule applied blind, which is why you'd see it
   claim things like FS9 on a four-switch pedal. One capture pins the real rule.

3. Anything that shows how setlists work. How many there are, how big, and how the pedal's own
   screen numbers presets — a capture of switching setlists plus a sentence about what the display
   says would do it. Your first capture asks for bank 1, so we know there's more than one, but
   nothing in it names them.

No need for more param/bypass/swap captures — those three are settled exactly, more wouldn't tell us
anything new.

On the wah: I genuinely don't know why it let you yet, and I'd be careful leaning on it until I do.
Add/move/delete on that fixed chain are still unmapped, and that's exactly where a wrong guess
writes something odd to your pedal. Does POD Go Edit itself refuse that swap outright?

Branch is updated!

[jamesremuscat]

Backup

POD Go Edit's backups use a .pgb file extension. Given what we've discovered so far, hopefully it's just a name change and not a format one:

POD Go Backup 2026-Aug-27.zip

Footswitch assignment

Setting FS3 to control bypass of slot 6:
Pod Go FS3 bypass slot 6.zip

Setlists

On the POD Go there are two banks of presets: "Factory" and "User". Each has 128 slots labelled from 01A, 01B, 01C, 01D through to 32D. Despite the names the only functional difference is that the former is pre-populated with the stock presets and the latter has empty presets.

In the samples I've given you and in the backup, Factory 01A is called "US Deluxe Nrm" and User 01A is called "Acoustic split". For this capture, I set the pedal to the "Factory" bank before loading the app, then changed to the "User" bank in the app. It shows the app loading data for each bank in turn.

POD Go switch banks.zip

The preset lists on the pedal and Edit UI operate somewhat independently until a preset is loaded, at which point the app and pedal both switch to displaying whichever bank contains the selected preset. Switching between banks on the pedal sends a USB MIDI Bank Change message followed by a Program Change one which (I assume) the desktop editor uses to toggle which list it's displaying. No equivalent message is sent when changing banks in the editor.

[jamesremuscat]

Fixed blocks

In POD Go Edit and when editing on the pedal itself, the following constraints are enforced for each preset.

• It must contain one volume pedal.
• It must contain one wah pedal.
• It must contain one FX loop (either mono or stereo; the POD Go only has hardware support for one loop)
• It must contain one amp block.
• It must contain one cab/IR block.
• It must contain at least one EQ block.

These can occur in any order, and leave four blocks for free assignment. In the editor this is implemented as blocks of fixed type that cannot be changed to another category (e.g. you cannot change the type of the "fixed" EQ block, etc)

However, the community have been aware for some time that it's possible to bypass at least some of these restrictions by exporting a preset to JSON, manually editing one or more of the "fixed" blocks, and reimporting the file. It's been assumed that the restrictions are some mix of technical (limited DSP) and commercial (distinctiveness from Helix/HX ranges). As far as I'm aware nobody has encountered significant issues with this method, though I'd love to know if anyone's tried to go "full send" and create a preset full of empty blocks!

[john-baxter-dev]

Super helpful, thank you! The POD Go is now Verified — the same tier as the HX Stomp
and Helix Floor, every field measured, nothing assumed.

The backup did more than asked

.pgb is .hxb — but your file's payload didn't start where the Helix Floor's did, and chasing
that exposed something better: the AF6L container was never "a header plus concatenated zlib
streams" at all. It's a tagged archive with an index table at the end (36 bytes per entry:
reversed FourCC, offset, length, compressed flag). Sections: device info, comment (HX Edit only —
POD Go Edit writes none), setlist names, globals, IR slots, the model-usage table, the setlists.
The two header fields we'd marked "unconfirmed" in the Floor docs turned out to be the table
offset and entry count, and a third unknown is the firmware build sha as an integer — your header
says 0x6e984472 and your preset build string says v2.01-19-g6e98447. So your backup improved
the Helix parser too.

And it carried the prize: preset_device_id = 0x210007, stated twice (container header +
the L6UMDArchive's "device": 2162695). That was the last unknown field. fretwire show-backup
reads your .pgb directly now:

device POD Go (0x00210007), fw 0x02500000, 11 streams
  [0] Factory      123/128 slots used
  [1] User         12/128 slots used

And hxb-convert now converts it: 101 of your 135 presets turn into restorable form,
verified against the two presets we hold in both shapes — your backup's JSON and your own
pedal's wire stream of the same preset ("US Deluxe Nrm", and "AC30 Ambient", which turned out
to be the preset your very first capture streamed). Converting the JSON reproduces the pedal's
own bytes slot for slot. Along the way your files taught us the POD Go's own @type vocabulary
and block-class bytes (its EQs, cabs, FX loops and IRs all differ from the HX's), and one
curiosity: POD Go Edit rounds parameter values to three decimals in backups, so a restore from
a .pgb — by anyone — is at that precision, while .hxb keeps full precision.

The 34 that don't convert are honest refusals, not failures: 32 presets with an IR block
(the wire stores a sixth value next to the IR's parameters whose rule we can't pin from the one
sample we hold) and 2 with a looper (never yet seen in a POD Go wire preset).

The footswitch capture: byte-exact, and it solved the FS9 mystery

Your FS3 assignment is op 56 with switch 2, and the follow-up read asks op 33 for switch 3 —
the HX Stomp's exact opcodes and its deliberate one-based-read/zero-based-write numbering. Our
builders reproduce both bytes unchanged; they're golden tests now, alongside your earlier three.

And the phantom FS9 is real after all — it's the expression toe switch. In your backup's
presets the wah and the volume pedal both sit at @fs_index: 9 with one enabled at a time, which
is exactly the toe toggle. So the editor was never inventing a switch; it just didn't know that
position 8 is under your heel. (Labelling it "Toe" instead of "FS9" is on the list.)

Banks: everything you described checks against the wire

read_info at startup answers bank 0 slot 0 = "US Deluxe Nrm" — your Factory 01A. Switching
lists in the editor is nothing but a browse of the other bank, with the familiar 128 stride
(your first populated User entry arrives keyed 136 = 128 + 8). With your panel description the
device entry now carries Factory/User × 128 and 4-per-bank numbering, so the editor labels
presets 01A–32D — the derivation reproduces your "01A, 01B, 01C, 01D through to 32D" exactly.
The MIDI Bank/Program Change detail is recorded as your report (the capture only covers the
control interface, so we don't hold those bytes — and don't need them).

The fixed-chain writeup

Documented, and it explains a lot — including why add/move/delete may simply not exist for the
POD Go in the form the HX uses, and why we won't send them until that's understood. On the JSON
export-edit-reimport trick: good to know the community mileage, but fretwire won't take that
route on the wire — a preset the pedal builds for you after a refused operation is recoverable;
one it accepts and mis-runs may not be.

Housekeeping

Everything is on master now and the pod-go-support branch is deleted — switch your checkout
over (git checkout master && git pull) to keep getting updates.

Is anything left?

Two things, both optional:

1. Add, move or delete a block in POD Go Edit and capture it — or just confirm the editor
   refuses those outright on the fixed chain. That's the only write family still unmapped.
2. Any second IR preset read off the wire — e.g. load a preset containing an IR block in
   POD Go Edit and capture the startup, like your very first capture. Two samples of the IR's
   mystery sixth value would pin its rule and lift the conversion refusal that covers 32 of
   your presets.

[jamesremuscat]

In this one I move the volume pedal from slot 1 to slot 10:
Pod Go move slot 1 to pos 10.zip

There is no facility to add or delete blocks; it's possible to set a block to empty.
Pod Go set block to empty.zip

Startup capture of POD Go Edit with a different IR-using preset loaded:
Pod Go second IR preset.zip

FYI - the POD Go can connect to an external expression pedal (EXP2) or two external footswitches labelled FS7/FS8 - which will explain those positions in the array (re this comment).

[jamesremuscat]

FWIW I've been playing around with Things We Aren't Allowed To Do because I like living dangerously, apparently...

With current master I'm no longer able to change out the wah or volume for another type of block, as I managed to do before: the pedal rejected the edit op=Some(40) txn=530 code=-19 target={98:2, 100:{23:true, 25:485, 26:1140850689}} - after which the pedal's internal state is broken and it no longer switches presets correctly. A reboot of the pedal fixes it.

I continue to be able to swap out the EQ and FX loop blocks out for other types with no problems.

Somehow in all of this, I ended up with a preset that had no blocks in it! I was able to construct a (fairly hideous) almost-arbitrary chain of blocks but some combinations would end up with some variation of the pedal rejected the edit op=Some(39) txn=182 code=-306 target={98:9, 99:{19:6, 20:{24:{23:false, 25:372, 26:-1}, 9:1, 10:true}}}, and I couldn't fill the tenth slot with anything.

The pedal reliably loads this preset, though, so clearly it can work if the mandated blocks aren't present in a preset. I'm going to keep the empty one around as it might end up being useful...

[jamesremuscat]

Also noticed that the labels of the parameters for In and Out are missing:

They should be (left-right) Gate, Threshold (dB), Decay (in seconds) These are Pan (0.5 = centre), Level (range -120dB – +20dB)