"Invalid amp id: 0" on Mustang I V2

[offa]

3 / https://github.com/offa/plug/issues/3#issuecomment-877725723

/cc @Odzinic

[offa]

@Odzinic did you record the data with the full plug executable or the test one?

[Odzinic]

That was run using the full executable since I ran it on my system that has a display.

[offa]

Can you build and test with the minimal executable (https://github.com/offa/plug/issues/3#issuecomment-881531520)? It just connects to the amp and loads the stored data.

I'm not sure if it's really necessary, but better flush the output by changing these two lines:

test/integration/Main.cpp (40):

std::cout << "---\n\n";

to

std::cout << "---\n" << std::endl;

src/com/Mustang.cpp (47):

std::cout << "\n--------------------\n";

to

std::cout << "\n--------------------" << std::endl;

[Odzinic]

Definitely. I changed those two lines and ran the test executable and got the following log: plug_debug.txt. Looks like we got a new amp id in the error this time.

[offa]

Thanks, that's interesting. Do you get the same id on each run or does it change?

[Odzinic]

Yes. I just tested it about 10 times with unplugging the usb and restarting the amp and I received ERROR: Invalid amp id: 32 every time. Even changing the selected amp setting didn't change the id.

[offa]

That's interesting, especially since the plug executable receives 0 id's instead.

[offa]

I have updated the branch for a more readable formatting and preset data only. There should be 7 packets, 64 Bytes each. The 2nd packet contains the amp info, where the first byte of line 3 is the amp id.

[Odzinic]

Sorry for the long delay. I was away from my amp for a few weeks.

I updated the branch and ran CommIT but didn't get much useful data out of it. Seems like the 4th packet is the only one that isn't completely 0s. plug_debug.txt

[offa]

Oh … it seems the amp id is one of the smaller problems here …

Sorry if I have asked before, but udev rules and plugdev group are setup correctly?

[Odzinic]

As far as I know, I'm pretty sure it's setup properly.

I have a group named plugdev and the udev rule 50-mustang.rules. 50-mustang.rules contains:

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0014", GROUP="plugdev"

which matches the vendor/product id of my amp:

Bus 001 Device 025: ID 1ed8:0014 FENDER MUSICAL INSTRUMENTS CORPORATION Mustang I (V.2).

Now that I think about it though, I have tried deleting the rule and redoing it several times but have never tried deleting and remaking the group. I'll give that a shot.

[offa]

Looks ok.

[Odzinic]

I've also tried to run plug as root to "skip" the plugdev permissions and still get the same Invalid amp id: 0 error followed by Error: Resource busy when trying to connect a second time. I'll try to setup the testing branch of plug on my RPi and run CommIT on there to see if it could be an issue with my PC setup.

[Odzinic]

I finally setup plug on my RPi and ran it but got even less favorable results.. Seems like everything is 0s. Running a diff between the log from my PC and the log from my RPi only showed one line on difference in the fourth received packet:

d1 5e 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Double checked all my udev permissions stuff on the RPi and it all looks like it should. Here is the RPi log: plug_commIT.log

[offa]

Thanks, at least we can eliminate another possible cause.

In case I haven't asked yet: Is there any version of plug (earlier release, original version) that works?

[dieggsy]

I'm similarly seeing "Invalid amp id: 159" on a Mustang I v2

[offa]

Stays the value same? I've not seen it before.

[dieggsy]

Oh, I don't think the value stayed the same after I tried again on a reboot

[offa]

But the error still occurs, with different values though?

[dieggsy]

Correct

[offa]

I don't have a v2 device around, but at first glance I'd expect the communication getting out of sync. v2 still uses the same protocol – at last as far as I know.

Does re-plugging, restarting or changing amps on the device make any difference?

[jezekra1]

Hi, I have the same device and issue: "Invalid amp id: 0" every time. None of the above helps (didn't try factory reset of the Mustang though).

I also tried version 1.3.0 of plug. That connected successfully but with some strange behavior. I was unable to change the amp, changing anything just muted the mustang.

Let me know if I can help somehow. :)

[offa]

I also tried version 1.3.0 of plug. That connected successfully but with some strange behavior. I was unable to change the amp, changing anything just muted the mustang.

Earlier version have ignored any package errors, so everything read afterwards may just be garbage.

—

An amp id of 0 indicates a broken amp data transmission, you can see all available values here.

Since the issue occurs on different devices (all still v2 though), it's unlikely to be caused by a sync issue. Now, what we can do here is either a.) try to gather information about the v2 protocol used and/or b.) capture the initial transmission of a v2 device and compare with v1.

The later can be done by tools like Wireshark or a kind of self written dumper. Maybe some kind of "test version", with lots of logging could work here too – at least we could compare each transmission step with the expected data.

[j824h]

Can this be related to the fact that V2 has additional amp models, which are not implemented here yet?

https://www.middle8reviews.com/comparison-fender-mustang-amp-v1-vs-v2/

[offa]

If they are just additional amp models, but the transmitted uses the same format it should fail with some non-0 id.

Has someone some spare time to take a look at the communications?

[j824h]

Now I have installed Windows VM with Fuse & USBPcap. I saved a dump file which should contain the transmissions from Fuse initialization and subsequently switching to every amp model and stompbox. I gave a brief look in it with Wireshark, but not very sure how to proceed.

[offa]

Do you see initialization steps as listed the docs (§ 2)?

You can compare the amp packets too; when switching amp there should be a transmission of format described in §3.

[j824h]

Mostly yes, with "0x03" in the init packet being "0xc1" instead! Other corresponding outgoing packets seem consistent. I will see if matching that one byte works.

Additionally, would it be good if I work a little bit on documenting the V2 features and maybe implementing them?

[offa]

Mostly yes, with "0x03" in the init packet being "0xc1" instead! Other corresponding outgoing packets seem consistent. I will see if matching that one byte works.

Interesting, thank you!

It would be really annoying if a single byte causes this trouble :smile:

Contributions are always welcome :+1:

[offa]

Another approach I have thought about: Some kind of test suite, which runs a communication sequence step by step and asserts the result. So we'll see where in the sequence it fails and can dig deeper without running a gui etc.

[j824h]

Fixing the byte, I could indeed wake my Mustang I V2.

Loaded packets

Another observation: when loading, Mustang I V2 returns 6 unidentified packets after the last 12th effect knob preset. (Firmware version: 2.2) That makes received_data.size() to be 147, invalidating the smallAmps vs. bigAmps condition in the ternary. https://github.com/offa/plug/blob/cb55af575dcd6ef19091fda078e6b8b8f08a4b26/src/com/Mustang.cpp#L164

I'm not sure why the number is set as 143, so I get cautious updating it. What can I do to ensure I don't break other devices? Blame does show 143 (https://github.com/offa/plug/commit/c422e8ffabce2a75edc33d8992af338e5ac2107d) itself is already a firmware update from 142 (https://github.com/offa/plug/commit/4bd030bd2a69190293bb31257fca9e01ad05ea87).

What would the 6 additional packets mean? I guess we have no choice but to just ignore?

[offa]

Oh, these are good news 👍. So v2 still uses the same protocol, but with some extras.

Are there any additional features v2 has over v1 that would need additional data transmitted?

The lines after the marked do two thins: a) receive a list of all preset names on the device and b) receive the selected presets data.

[dalareo]

Can you please provide a fix to make Mustang I V2 recognized? I've read that "fixing the byte" did the trick, but not really sure where/what is that byte! I am using 1.1 with Ubuntu 22.04 whithout problems but not able to run Plug in MacOS.

[j824h]

@dalareo Would you take a look at my fork?

The upstream codebase might have changed since then, but I remember I had this version tested in Ubuntu 22.04.

https://github.com/j824h/plug/commit/b43b9e1b25a3724f3a933b80df5461d605e6d8a9

[dalareo]

Just changing init1 value at Packet.cpp and const std::size_t max_to_receive = (recieved_data.size() > 147 ? 200 : 48); // 147 is the number of packets for Mustang I v2.21 at Mustang.cpp did the trick!

[offa]

Using the number of transmitted packets for calculation of presets isn't that stable – as shown for other devices. It might be better to replace the calculation with known values (where possible).

Is it safe to use 24 Presets (= 48 related packets) for Mustang I v2?

[offa]

I have tested the 0xc1 init1 byte on a v1 device and it seems to work too :thinking:.

[offa]

Can you give this experimental branch a try experimental/240-v2_support?

It contains the init1 0xc1 byte and doesn't calculate the packet number where possible, but uses a fixed number (100 Presets to Mustang III+ v2 and 24 for Mustang I/II v2)

[dalareo]

It works like a charm with my Mustang I V2 in a mini Mac with M2

[offa]

Thanks for testing. GH Actions have some issues at the moment; I'll merge the branch once the CI build works again.

[offa]

Merged.

[offa]

Released as v1.4.4.