offa
Could it be, that the amp uses a different order of packets, thus leading to a non-amp packet being parsed as an amp packet? The current implementation isn't that clever...
I have added a commit to investigate this. It'll print the actual bytes considered as amp packet and the value at the amp id position. Let's see what is decoded...
Sorry, I made a mistake – logging after parsing doesn't make much sense if the former fails :man_facepalming:. Could you do the test again with the updated commit? One is...
As expected there's garbage decoded instead of amp data … It could be that Broncos transmit a different number of packets. At least we have found the root of the...
The slot isn't involved yet. The value would be wrong, but the amp packet itself is complete garbage: ``` 00 00 00 00 00 00 00 00 00 00 00...
While Mustangs transmit presets with two packets each (first starts with `0x1c 0x01 0x04`) plus an additional for the current preset, the bronco does something different: After 24 preset (each...
Branch updated: It'll print the number of presets received (should be 48) and the 7 packets, that contain the current settings. Expected are a `1c 01 04 …` and `1c...
Thanks for the suggestion. The project still seems very new to me. There's a F-Droid release, but not that much activity (18 commits). I'd suggest we give it some time...
Please provide more information to reproduce the issue.
> (I have both test and Test buckets) Using two names that only differ in case sound's a bit risky. > It happens on 2 different machines, but doesn't happen...