Interfacing with the GBFans Sound Board #15
Comments
|
Spongeface, the creator of the GBFans Sound Board was generous to explain exactly how the signal schema works from the sound board to the light kit. As it turns out, it is much more in-depth than I had expected. Each of the 4 wires is a 4 bit (0-15) signal that expresses each state the sound board is in and forwards that data to the light kit. Pin 7 = MSB
* Only available in standalone mode Upon boot, if all pins are pulled low, it is assumed that the board is under the control of the sound board. If all pins are pulled high (through pull up resistors) it is assumed the board is in standalone mode. |
|
Updated with a basic control scheme in this branch: https://github.com/gbfans/afterlife-lightkit/tree/feature/effects-with-ramping-colors-controls |
|
Well, that looks more complex than I was expecting. Your example Control code looks similar to what I'd think we could do. I'm still a little fuzzy on bit operations but I did see some example code for it. This is entirely untested obviously, but maybe it's something like this? const int CONTROL_PINS[4] = {7,8,9,10};
byte result;
for ( int count = 0, count <= 3, count++ ) {
bitWrite(result, count, digitalRead( CONTROL_PINS[count] ));
}
# Do something with resultBecause if we're interacting with the GBFans board, we don't really need to name the input pins anymore, they're just Pins The difficult part is that I don't know how the above states behave. For example, I assume at some point the "Red Cyclotron Color" state will be set, but how is this different to "Normal Operation (Idle)"? Does it quickly flash "Red Cyclotron" then change to "Normal Operation"? If you change to "Green Cyclotron", does it flash that once to change modes then stay on "Normal Operation" too? Or how many milliseconds does it pulse the Cyclotron color change signal? We probably need to write a little test script which dumps the State to the Serial console so we can record exactly what the Soundboard is doing during all modes. Then we can document this in the code to ensure consistent behaviour. |
|
That method of reading the states looks like it may work. I was originally trying to use bytes as well but switched to an INT when I saw that you can't use bytes in Switch / Case. Though I could have made it a large If / Else ladder. That being said, I think we do want the aspects of the Bounce2 library for two reasons:
I think we will need to brainstorm that part a bit more. There are the following other modes:
Each of these modes will need have their own Idle, Firing, Venting, Shutdown.. etc. configurable animations, see my example here: #10. So I believe by sending the Byte command to trigger Green Cyclotron mode for example, it would be a temporary command sent and the pack would continue in whatever mode it was already in (idle, firing, venting.. etc). It isn't going to be a priority for the main code, but as long as everything is kept as customizable as possible, it should be no problem to expand later on. The most basic implementation will simply do a |
|
Added a branch called "Button-Testing". This is just a simplified version of the Control.cpp code I am working on in my branch. I have it connected to the GBFans kit and ran it through a few things, which produced an output like this at the serial port:
There are some strange abnormalities occurring. For example it was switching between the different firing modes when I believe it shouldn't have been. It also triggered test mode momentarily. I believe the debounce time of 5ms (or whatever it is set to) may actually be too low. It appears to be catching a few signals as it is changing to another one. |
|
I was playing with my own prototype here and I was getting unreliable readings too.
So, we should probably enable the Secondly, I think Bounce2 is potentially causing us problems here, it's possible that there's an issue with the millisecond timers that are being used (these are separate instances, after all). You got a random Test Mode ( We should ditch Bounce2 and handle the debouncing ourselves. We can use a single timer and just I think I can write up a test sketch for this by building on what you have already. I also think we should keep this test sketch (and any other useful tests we have) as part of the main repository, so that we can continue using them for troubleshooting in the future. It's definitely easier than having to run multiple working copies of the code, every time I need to troubleshoot my wiring. |
|
You are correct the inputs need to be On V3 of the board, the pullups are built onto the board, all others need to have When Bounce 2 may need to go. I will let you look into doing that as it is a little bit beyond my understanding at the moment. That being said, since these are only lights having a few seconds entering I just pushed a bit of code I've been changing a little bit here: https://github.com/gbfans/afterlife-lightkit/tree/feature/effects-with-ramping-colors-controls/SOFTWARE/AfterlifeLightKit I was just starting to implement the JSON config and switching between modes and states. States = Classic, Slime, Stasis, Meson, Party(?) I would like to have the ability to switch from Inactive -> Start Up -> Idle and have it read the configuration and change patterns each step of the way. |
|
@ajquick OK, I've rewritten the button-testing control class completely and I'm getting much more useful data out of it now. Here's my code: EDIT: I've added another commit to streamline this and remove a few unnecessary variables, the latest version has been pushed to the Uploading this sketch should spit out some useful Serial data. On boot, it should tell you which mode you're running (Standalone or Controlled). If I leave all 4 pins HIGH, I get Standalone mode. Anything else, I get Controlled mode. So this part seems to work now that we've got rid of Bounce2. I removed the references to different pin functions (ENABLE, FIRE, VENT, CHANGE) because these don't seem to apply anymore? Instead I'm just listing the pins in a constant (corresponding to IDC pins 7,8,9,10; or MSB=>LSB): I was wasting too much time trying to get int inputState = 0;
if (digitalRead( INPUT_PINS[0] ) == HIGH) {
inputState += 1;
}
if (digitalRead( INPUT_PINS[1] ) == HIGH) {
inputState += 2;
}
if (digitalRead( INPUT_PINS[2] ) == HIGH) {
inputState += 4;
}
if (digitalRead( INPUT_PINS[3] ) == HIGH) {
inputState += 8;
}But after all that it does work. If I set the third pin HIGH, I get a value of We won't be doing any of the "business logic" inside the Controls class, so I've added some more methods to help us with this. Here's an example: void loop() {
controls.update();
if (controls.changed()) {
Serial.print("CHANGED - Old: ");
Serial.print(controls.getPreviousState());
Serial.print(", New: ");
Serial.println(controls.getCurrentState());
}So we can tell:
I'm not sure if there's anything else we need here if the sketch works for you. Feel free to make adjustments if you need to (eg Once it all seems to be working, we'll merge the branch, close this ticket, and move onto the next objective. |
|
Can confirm. It works and there are no errant signals detected that I can see. Here is an example of turning on the power, firing, hitting the vent a few times:
As long as the inputs are correctly mapped while in "Standalone" mode, you should be okay. That mode would have you connect your switches directly to the header. (Which basically no one will do.) |
|
I have completed this via #16 and merged it in so I can proceed with the remaining functionality. |
I was not anticipating this, but it appears the signals sent from the GBFans sound board are not as straight forward as I had anticipated. I was originally operating under this assumption:
These are the inputs on the Powercell light kit for standalone operation.
However when a GBFans sound board is used, there is a much different signaling scheme used!
Start up: Pin 10 is high, all others low.
Idle: Pin 7 is high, all others low.
Firing: Pin 7, 8 and 10 are high, Pin 9 is low.
Venting: Pin 7, 9 and 10 are high, Pin 8 is low.
Shutdown: Pin 7, 8 and 9 are high. Pin 10 is low.
Change state: Pin 7 and 10 are high, Pin 8 and 9 is low. (I am assuming this one).
Off: Pins 7-10 are low.
This is actually quite useful as it helps with the timings. Venting is actually signaled when we previously thought it wasn't. Overheating however is not.
I believe it would be good to allow for both GBFans Sound board connections and the standalone mode to be supported. This can be done by seeing how long the enable pin is held high for. If it is held for more than ~3 seconds we know we're in standalone mode.
I believe a class handling the inputs can get created now.
The text was updated successfully, but these errors were encountered: