"Invalid amp id: 0" on Mustang I V2

@Odzinic

@Odzinic

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

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

Can you build and test with the minimal executable (#3 (comment))? 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;

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.

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

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.

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

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.

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

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?

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.

Looks ok.

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.

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

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?

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 😄

Contributions are always welcome 👍

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.

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.

plug/src/com/Mustang.cpp

Line 164 in cb55af5

const std::size_t max_to_receive = (recieved_data.size() > 143 ? 200 : 48);

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 (c422e8f) itself is already a firmware update from 142 (4bd030b).

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

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.

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.

@dalareo

@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.

j824h@b43b9e1

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!

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?

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

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)

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

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

Merged.

Released as v1.4.4.

Navigation Menu

Repository navigation

"Invalid amp id: 0" on Mustang I V2 #6

13 remaining items

Loaded packets

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

"Invalid amp id: 0" on Mustang I V2 #6

Description

Activity

offa commented on Jul 16, 2021

Odzinic commented on Jul 16, 2021

offa commented on Jul 16, 2021

Odzinic commented on Jul 16, 2021

offa commented on Jul 16, 2021

Odzinic commented on Jul 16, 2021

offa commented on Jul 16, 2021

offa commented on Jul 17, 2021

Odzinic commented on Aug 11, 2021

offa commented on Aug 12, 2021

Odzinic commented on Aug 12, 2021

offa commented on Aug 12, 2021

Odzinic commented on Aug 12, 2021

Odzinic commented on Sep 5, 2021

offa commented on Sep 10, 2021

13 remaining items

offa commented on Jul 22, 2022

offa commented on Jul 22, 2022

j824h commented on Jul 26, 2022

Loaded packets

offa commented on Jul 26, 2022

dalareo commented on Nov 27, 2023

j824h commented on Nov 28, 2023

dalareo commented on Nov 28, 2023

offa commented on Nov 28, 2023

offa commented on Nov 28, 2023

offa commented on Nov 28, 2023

dalareo commented on Nov 28, 2023

offa commented on Nov 28, 2023

offa commented on Nov 29, 2023

offa commented on Dec 3, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions