-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Invalid amp id: 0" on Mustang I V2 #6
Comments
@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; 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 |
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 |
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 |
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
which matches the vendor/product id of my amp:
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 |
I finally setup plug on my RPi and ran it but got even less favorable results.. Seems like everything is 0s. Running a
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? |
I'm similarly seeing "Invalid amp id: 159" on a Mustang I v2 |
Stays the value same? I've not seen it before. |
Oh, I don't think the value stayed the same after I tried again on a reboot |
But the error still occurs, with different values though? |
Correct |
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? |
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. :) |
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. |
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/ |
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? |
Now I have installed Windows VM with Fuse & USBPcap. |
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. |
Mostly yes, with "0x03" in the init packet being "0xc1" instead! Additionally, would it be good if I work a little bit on documenting the V2 features and maybe implementing them? |
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 packetsAnother observation: when loading, Mustang I V2 returns 6 unidentified packets after the last 12th effect knob preset. Line 164 in cb55af5
I'm not sure why the number is set as 143, so I get cautious updating it. What would the 6 additional packets mean? |
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! |
@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. |
Just changing init1 value at Packet.cpp and |
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 |
Can you give this experimental branch a try 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. |
#3 / #3 (comment)
/cc @Odzinic
The text was updated successfully, but these errors were encountered: