latigid on

It creates more wiring work/mess and potential for mistakes, but can be simpler to address individual elements. With the NG if you have a missing/swapped connection, it should be quite simple to identify and fix. It doesn't matter if you go for single wiring, because you're addressing individual LEDs, with the DOUT pin via a resistor to the anode, and the cathode tied to ground. However, when using a matrix, you want a constant current sink on the cathode side, so you bridge the resistors only on that DOUT section with wire. Otherwise, your total series resistance is ~440 ohm at a duty cycle of 0.125, and this will lead to dim LEDs! The other method is to connect the sink side resistors to the base of NPN transistors (collector to LED cathodes, emitter to ground/0V), or you could consider the ULN2803 octal Darlington driver. (The latest rev DOUT boards from SmashTV can fit sink or source driver chips directly on the PCB.) For red/yellow/yellow-green LEDs with Vf ~2V, your consumption is approximately (5-2)/220 = 13.6mA for each LED. Don't forget the OLEDs can have reasonable consumption too. Keep at it, you'll get there eventually!

LEDs in matrices are only on 1/8 of the time, so naturally they're dimmer. Are you using sink transistors, or at least no resistor on the sink side? Matrices are designed to save pins, but it only makes sense when you have close to a grid arrangement. Count your pins for individual wiring: 30 encoders = 60 DINs 60 buttons = 60 DINs 90 LEDs = 90 DOUTs 120 DINs /8 per chip = 15 165 chips = 4 DINX4 modules 90 DOUT /8 per chip = 12 595 chips = 3 DOUTX4 modules MIOS32 allows for a maximum of 32 shift registers (I think this is 32 DIN + 32 DOUT), so you're okay. I hope we get to see it one day.

When choosing caps, aim for a voltage rating ~2-3 times the expected maximum input. If you want to protect for reverse polarity, try a 1N5817 Schottky diode. The Vf is low, so it doesn't drop the rail much.

So, probably either no bootloader is installed, the MIDI communication has a hardware issue or the PSU is causing the PICs to not initialise properly. You can perform a reset at the PIC: once the PSU has stabilised, briefly (< 1s) connect pin #1 to 0v (ground) with a jumper wire -- make sure it's on the PIC side and not on the other side of resistor R1. Do you have other PICs to test with? If you have a known hardware build it might be worth swapping some parts around

Back to device ID, the ID is set as part of the bootloader burn. Even if all of your chips are the 0000 address, you'll need to change them to work with the MB-6582. Maybe order a reputable crystal rather than one from Tayda. If it's out of spec the Core won't know what to do. For swapping Cores, what is correct? all of the PICs work in some of the positions implication: the PICs are fine, the PCB is not at least one PIC works in all of the positions implication: at least one of the PICs is fine, the PCB is good. some PICs work in some positions, but not others, implication: SNAFU

If you have one "Core" position where one PIC works and another doesn't, maybe it's a problem with those PICs? If you're in Germany, you could send me the PICs and I'd check them for you.

Are you using the correct device ID (left hand side) for your PICs? If the set was for MB-6582, there should be different IDs printed on the top of each.

Both are true :) The SEQ v4+ will work fine with the Wilba front panel, only it will require the STM32F4 Core (the LPC and STM32F1 don't have sufficient memory). This isn't really an issue, especially for new builds as the earlier boards were retired a while ago. The new version I'm working on will be enhanced with some cross-compatible features, nicer hardware, full metal case from Adrian etc. But it won't be ready for at least a few months. If your soldering iron is itchy, then go ahead with the current version.

Doesn't the audio DAC overlap with the SD card/SPI port? Is this mind control device running MIDIbox-like apps or totally standalone? You could consider some of Olivier's ideas (Clouds and Rings), many use STM32F4 with audio DACs e.g. I see WM8731 for the latter. https://github.com/pichenettes

Yeah, I think some others also had trouble with pirate DISCO boards. But if it works, there's no problem!

Good perseverance! I'm glad for you that everything's up and running. Sounds like there were myriad problems with funky SD cards to clapped out logic. If you were able to get the chips off easily, that suggests a hot air rework station? If so, you should probably discard chips removed in this way unless you control the temperature very carefully (or they're super $$). It's not quite as quick as swapping out a socketed DIP, but almost :). FWIW, my method of soldering SOIC is to tack a corner pin then run down one side, then go to another chip. This gives a bit of time for the first to cool down. If possible I also like to do a third run where I hold the iron at a low angle and gently push the solder fillet towards the pin. I find this gives a more uniform joint that bonds underneath the leg. Enjoy the SEQ, and thanks for sharing your troubleshooting tips.

Maybe an addendum; what was the issue? Still a faulty 595 and a loose cable? Or was the original okay? If anything wasn't plugged in properly I'd think nothing would be working.

Nice!

Whoops, wrong row. LEDs out on GP11/12, rewind and stepview? It points to a bad 595 chip (U7) or broken connection somewhere. You might even find reseating the IC helps.

If it's a row of the matrix, I think the problem is on the sink side. Are LEDs out in the trig buttons, pause and GP 13/14?

In _NG, you can also access LEDs directly using MIOS Studio's terminal, without an SD card mounted. set DOUT 0 1 set DOUT 8 1 (don't turn on too many LEDs at once. also note that it's not a proper scan matrix, so you don't have full control over the LEDs illuminating.)

That's right, a missing or reversed diode should mean only that position doesn't switch. So in general, it does work? You mentioned previous trouble with your SD card, so that should be eliminated . FWIW, I'm having trouble following where you're at; the more explicit you are with a description of what you've tried/what you're seeing, the more I can help. Let's see if the SRIO works, ignoring the SD card for the moment: Eject the SD card Download the v4l firmware on the wiki Open MIOS Studio, connect to the Core, upload the .hex After successful upload, the Core will reset and MIOS Studio will be unresponsive to the Core do the LEDs chase up and down the rows? This will take a few seconds as it searches for an SD card if yes, then the DOUT sides of anodes and sinks are working if not, then there's a problem Possible causes: J8/9 SRIO isn't being sent properly is the HCT541 chip on the Core okay? is the header connected the right way around? is the cable correct with all pins connected and no shorts between? Problem with the HC595 chips on the v4L CS were the chips handled improperly (e.g. static discharge, overheated during soldering)? are there any shorts between the pins? are any pins connected to +5V/0V (ground)? Some are by design, so be sure to check the DOUTX4 schematic The LEDs are non-standard with anode/cathode swapped. you can verify this with a multimeter, +lead to round side (anode), -lead to flat side (cathode). They probably won't light up as there are multiple LEDs connected. Assuming the light show works, you can try to push a few buttons. Most should give some response, but the positions might be out of order due the absence of a config file. Do the buttons work? If not, then it's an issue with the DIN side. Carry out the same checks; you can reference the DINX4 schematic. It's a good idea to test with NG and the basic BLM. You should use the following NGC: # BLM8x8 without button/LED emulation RESET_HW LCD "%C@(1:1:1)Simple 8x8 BLM" # HW definitions: DIN_MATRIX n= 1 rows=8 inverted_sel=0 sr_dout_sel1=1 sr_din1=1 DOUT_MATRIX n= 1 rows=8 inverted_sel=0 sr_dout_sel1=1 sr_dout_r1=2 # note: actually the sr_dout_sel1 in DOUT_MATRIX could be removed, # since DIN_MATRIX already outputs the selection pulses there # this is just for the case that somebody copy&pastes the definition... # which events should be sent by the button matrix? # the key number will be automatically incremented depending on the button index of the matrix EVENT_BUTTON_MATRIX id=1 fwd_id=LED_MATRIX:1 type=NoteOn range=0:127 lcd_pos=1:1:1 label="Matrix1 Pin %2p %b" this assigns each button to its respective LED. If it doesn't work, it could be the SD is failing to read properly (although I'd expect some sort of error message). try formatting the SD try another SD Best, Andy

The build looks pretty clean, so I don't think it's a problem with the CS (unless you managed to zap/cook the CMOS), or the connecting cable is faulty or connected to a port other than J8/9. Was the Core ever verified to work with anything else? It's true that MB_NG fails to upload? We need to check the Core side in that case. You might consider reflashing the whole chip from the ST LINK side. Note, on Windows it's normal behaviour to have to (annoyingly) restart MIOS Studio each time the Core reboots.

Do the SEQ and SIDs share the same power rails (I guess not, as one is +5V and the other is +9 or so). They will be electrically isolated if you have separate transformer-based PSUs Not sure, maybe an issue with the STM pin? A long shot, as you're not even using the Quad I2C, but it is "pushing the limits" to have double quads. Good luck!

R5 and R10 are the output pullups. As Il said, the voltage is not as important as the current, which I believe is moreso configured on the opto side. Some hacks that spring to mind: Separate the power/grounds of the devices. With an optoisolated input, this shouldn't be a problem, but often loops can cause issues. Try to buffer O4 through another MIDI device, if it works then the problem is electrical. Disable your second quad I2C module by defining fewer ports in the SEQ app (and disconnecting the second module). It could be that the increased latency causes timing mismatches.

Okay, I've just tested two of my white OLEDs (AL4002A model). They're a bit easier as both the data and power expect 3V, so everything is fine with the simple pullups. To check, I used both the M997C and D revs of the DISCO board. The current is ~50mA each so that was okay for at least a few minutes. Quite nice displays, maybe a good candidate for a bulk buy at some point :). Although, there is a faint whine from the charge pump -- do other displays make he same noise? What's interesting is the controller is listed as KS0066 or Equivalent 8-bit 68xx-Series and there are no config jumpers, but all is well. I don't know if that's an error, or there's some internal magic going on, but lcd_type 0x02 is working fine. Something else to consider is that OLEDs (and LCDs) normally expect a power down sequence to extend the life, rather than yanking out the power cord. I wonder if this could cause the displays to fail, but it really should be implemented at the controller level IMO.

I don't see a need to drop the LCD voltage rail with a diode, unless you're using a DISCO board without any Core PCB ( @norbim1 ). All data should be supplied at the same level as the rail according to the jumper settings. The overcurrent of the DISCO Vreg could be an issue as @CJ55 said. Also the 74HC595 chip has a maximum voltage of +7V, was this replaced yet? @Karg same deal, there shouldn't be an issue with the data voltage level as the jumper settings take care of it, no?

Perfboard for sure! http://www.midibox.org/midibox_sid_photos/

http://www.ucapps.de/midibox_sid_cs/mbsid_v2_dout_default.pdf http://www.ucapps.de/midibox_sid_cs/mbsid_v2_din_default.pdf http://www.ucapps.de/midibox_sid_manual_fp.html lots of info on uCapps. Wiring is a big task, and it's easy to make mistakes. But if you're motivated to put the time in, you'll get a cool MIDIbox in the end :)