• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by radu7

  1. Hi Jack, Yes, I purchased the Wii-Chucks along with the Wii Wings from the Gadget Factory store earlier this month. Anthony
  2. I've purchased a couple of Wii Wings and Wii Nunchucks from gadgetfactory.net and I'm having no success getting them working with my Papilio Pro and the WiiChuck example in DesignLab 1.0.8 I've connected the Wii wing to slot AL on the Papilio Pro and loaded the circuit and sketch for it, but the only output I get in the serial monitor is: Starting I2C at slot 9, instance 1, base register 0x0c800000 0 Chuck: 255 255 buttons 0 0 Chuck: 255 255 buttons 0 0 Chuck: 255 255 buttons 0 0 Chuck: 255 255 buttons 0 0 Chuck: 255 255 buttons 0 0 ... Pressing either button or moving the joystick does not cause any change in the output values. As a test I powered the Papilio Pro up without the Wii wing connected and after starting the serial monitor pressed the reset button on the Papilip Pro and get: Starting I2C at slot 9, instance 1, base register 0x0c800000 0 with no further output, as expected. I've tried both Wii wings and both nunchucks that I purchased and both give the same result. As another test I wired the Wii wing with the nunchuck connected to an Arduino Uno and used the library and example at this site: http://todbot.com/blog/2008/02/18/wiichuck-wii-nunchuck-adapter-available/ and received the same output values via the serial monitor as when connected to the Papilio Pro. I've got the nunchucks connected to the Wii wing so that the nunchuck's pinout matches the silkscreen (The 'indented' side of the nunchuck connector that has no middle pin facing up) and I've verified connectivity from the pin on the wing to the pin of the nunchuck via a DMM. Any ideas on what may be going on? I wouldn't think that I managed to get two bad sets of Wii wings and nunchucks so I'm at a bit of a loss as to what the issue could be. Best regards, Anthony
  3. Update: I decided to try a newer Arduino library for the Wii chuck and a test sketch to read the buttons and joystick position and surprisingly it worked perfectly. I then took a Digilent Analog Discovery and used the Waveforms software to have a look at what was happening on the I2C bus on the working Arduino example and then the non-working DesignLab example on the Papilio and I could see a difference in the initialization sequence being sent from each. I guess I should have compared the two libraries and found the issue without breaking out a scope, but where's the fun in that, right? The Arduino example was sending hF0, h55, hFB, h00 as the init sequence. The Papilio example was sending h40, h00, hFB, h00 as the init sequence. After doing a bit more reseearch I changed the following section in the WiiChuck.cpp in the WiiChuck library in DesignLab as below: int WIIChuck_class::init_nunchuck() { int err = 0; if (I2C.start(WIICHUCK_ADDRESS,0)!=0) err = -1; if (err==0) // if (I2C.tx(0x40)!=0) - this is for OEM Wii nunchucks if (I2C.tx(0xF0)!=0) // for clone Wii nunchucks err = -1; if (err==0) // if (I2C.tx(0x00)!=0) - this is for OEM Wii nunchucks if (I2C.tx(0x55)!=0) // for clone Wii nunchucks err = -1; I2C.stop(); I recompiled the sketch, uploaded to the Papilio and I'm now getting the following results when testing: No Joystick or button activity - Chuck: 128 127 buttons 0 0 Joystick left - Chuck: 46 127 buttons 0 0 Joystick right - Chuck: 255 127 buttons 0 0 Joystick up - Chuck: 128 255 buttons 0 0 Joystick down - Chuck: 128 46 buttons 0 0 Button C - Chuck: 128 127 buttons 0 1 Button Z - Chuck: 128 127 buttons 1 1 Button C+Z - Chuck: 128 127 buttons 1 0 I was not aware that some (all?) clone chucks do not respond properly to the standard init sequence. The following comment was in the Arduino library that I used (https://playground.arduino.cc/Main/WiiChuckClass): // instead of the common 0x40 -> 0x00 initialization, we // use 0xF0 -> 0x55 followed by 0xFB -> 0x00. // this lets us use 3rd party nunchucks (like cheap $4 ebay ones) // while still letting us use official oness. // only side effect is that we no longer need to decode bytes in _nunchuk_decode_byte // seehttp://forum.arduino.cc/index.php?topic=45924#msg333160 Thanks for the advice Alvie, using the scope certainly revealed the issue even if it wasn't due to a hardware fault or misconfiguration. Regards, Anthony
  4. Thanks for the reply Alvie! I can get access to a DSO and an openbench logic sniffer that I can use to troubleshoot this. I'll try and get to that after work today. I'll verify that 3.3V is getting to the Wii chuck and then test for activity on the SCL and SDA pins while pressing the buttons, etc... If you have any specific test scenarios I should try please do let me know. Regards, Anthony
  5. Hi Jack, Thank you for the response. I've tried both the 'Audio_RetroCade_Synth' circuit and sketch from DesignLab 1.0.8 (loaded circuit first via lowest numbered com port for the Papilio Pro, then sketch uploaded via the higher numbered port) and also the: RetroCade-1.3-lcd-contrast-fix-zpuino-2.0-PapilioPro-S6LX9-RetroCade-1.3.bit bitfile which is the latest one I could find and seems to be the same one you linked to above. Those are the ones I tried from the first time I unpackaged the RetroCade and both behave the same way with the issues listed. I did try the 1.1 bitfile just for the heck of it and that was a no-go for sure. Any other ideas on how I might troubleshoot this? It is a bit perplexing to see the the erroneous midi commands show when looking at the debug via the RetroCade, but not seeing them when watching the midi traffic from the midi controller itself and also not seeing the issue at all when using the PC keyboard via a com port connection to the RetroCade Synth Dashboard. Unfortunately I currently don't have access to another midi Keyboard to test with. Thank you, Anthony
  6. I just recently started testing my new RetroCade synth along with a Papilio Pro and, aside from the LCD on my RetroCade having issues (not all of the characters on the bottom row display properly and only a vertical line moves across the top row rather than a 'space invader'. Pressing on the black frame on the edge of the display while using male/female jumpers to connect it to the Retrocade fixes this so it seems it's just a bad connection on the LCD itself and not on the RetroCade PCB so I can probably find a way to fix that myself.) and it was also missing the small black cover for the five-way switch (I left a message via my GadgetFactory account regarding the button, but I think there may be an issue there since I didn't get a response so I just ordered a few spare button covers to have). Those are fairly minor things, but I'm also having the issues that were described in the post linked below: http://forum.gadgetfactory.net/index.php?/topic/2713-problem-with-the-channels/ All 8 Channels are called "SIDV1". Shouldn't there be at least one YM2149 channel? Channel 0 Drums don't produce any sound Channel 1 seems to be the same as Channel 0 Channels 2 - 7 are playing the last key pressed constantly, I can only stop when turning off the power When I press keys on my Midi Keyboard in Channel 0 too fast one these things will happen: a broken bass noise appears note off doesn't work until I press another key random notes are being played I followed-up on that post by checking the chat session on gitter that was linked to in the post, but I didn't see anything about #4 and 5 in the chat log. I'm using an old Kaysound MK-4902 midi controller that I've been using for ages and I have no issues with that controller and my other midi applications so I'm guessing there is something between it and the RetroCade that isn't quite right. I was thinking I just got a faulty RetroCade unit due to the odd issues aside from the ones above I was seeing such as the LCD not working correctly, stopping, starting or changing examples files from SID, YMD, etc... on the smallFS via the onboard five-way switch will often cause the RetroCade to either lock-up, start playing white-noise, random clicks/tones, or sometimes all of those odd things at once and I have to power it off/on to get it going again. Using the RetroCade Synth Dashboard and the computer keyboard while connected via the com port doesn't seem to produce issues #4 or 5 above and switching between the three available MOD and YMD loops via the deshboard doesn't freak it out like it does when using the onboard joystick. I've tried different USB power supplies with known good +5V and plenty of mA and the issue presents regardless of that so I don't think it is a power issue when using the MK-4902 external controller. I've also used a midiplus USB 2-channel controller through my PC rather than MK-4902 directly to the RetroCade and that made no difference. I'm using v1.3 of the bitfile. When I load the .ino RetroCade exapmple from DesignLab 1.0.8 and enable debug I can see when the 'random' notes occur. I will see the note I play, then an immediate noteoff (even though I didn't release the key) and then the message for a random note nowhere near the one I was playing and no noteoff msg for that random note. I have to press another key to stop it. It happens if I am playing slow or fast, but, 'seems' to occur more often when playing fast because it has more opportunities to show the issue. I'm hoping there is a way to resolve these issues. Seeing how at least one other person is having/had very similar issues I'm think there isn't anything defective with my RetroCade itself, but I suppose that is still possible. I'd rather not have to purchase a new midi controller, but would be open to doing that if it will resolve the issue since I can't use the RetroCade 'stand-alone' with these issues at present. My thanks for any suggestions or fixes for the issues I'm seeing. Best regards, Anthony
  7. Update: Even though I'm having no issues with the midi controller I'm using with other midi hardware/apps I decided to use a midi monitoring app to watch the messages being sent from the controller to rule out any issue with it. When the 'random note' or note off issue occurs on the RetroCade I see no data being sent from the controller that would cause it within the monitoring application. This controller is of the type that sends continuous 'Active Sense' messages, but I don't see how those would cause this issue with the RetroCade.