latigid on

Alright then, have fun!

Did you purchase anything through midiphy? Just email a reply to your purchase order and we can supply certain schematics (some are based on uCapps designs).

What HW config file do you have on your SD card?

Tried it! The LEDs flicker/pulse rather than dimming as the PWM/clock rates are not syncronised...

Interesting solution! Do you use the tiny ICs or SOIC ones? Did you use a power supply resistor for each? The bonus with WS2811s is you can get better dimming effects than with SRIO scan (and dimming is practically unusable in a matrix).

Cool chip and not too bad to solder!

Padding would define the number of spaces; the width of each is defined by the font in use or simply a blank character if such an OLED or LCD was used. I also haven't messed around with .NGL files.

Here is the reference: http://ucapps.de/midibox_ng_manual_ngl.html

If I recall, the pin order was determined by PCB layout (might have something to do with the AINSER64 too? So backwards scanning it is if you use the MIOS routine.

Fancy! If these are custom PCBs they would've been very expensive back in the day!

What LCD driver is set in the Core bootloader? Maybe check that?

Is there a specific problem you are trying to solve? My gut feeling is that we should minimise the length of high-speed digital signals (lower impedance/inductance causing signal-integrity loss; less EMI) and buffer them to take load off the MCU, also minimising the number of interconnections. Things that interface to the shift registers (LEDs, switches) are much slower and could run over longer traces or cables. In practice I'm not sure if it really matters. Try for logical layouts and see how the performance is.

Thanks for the follow up! You're certainly not to blame for this, so I'll ask the fab what happened. Looks like the copper substrate was scratched from the beginning or some of the mask rubbed off before etching. Let us know privately with any subsequent order and we can spare you some $$ for the trouble.

I think you need to define your parameters. How many LEDs? How many spare I/O or GPIO can you use? Does an LED matrix with multiplexing go far enough?

Hi Adam, I don't fully get it: are you able to illuminate both superflux LEDs (red) in this column? Also, is it the _L or _R board and what is the version number? You can see the board trace should connect all "red" LEDs in this row, but the SJ part will not be connected to the LED until the resistor is placed. This sets the output for the MEC LED but you were talking about superflux? I can see a scratch on the board in your picture, is it related? If you're feeling masochistic you could sand back the solder mask and see where the copper stops (if it does). If the trace I marked with a "?" really doesn't connect, I would suggest to use a 1k THT resistor as indicated with the red mark. It would also be possible to use one of the 2/3 positions, but the matrix addressing will need changing in the HWCFG file.

You're welcome. Device IDs are hardwired using IO pins directly on the PCB (or selected with jumpers on oldschool I2C modules).

Here you go: http://ucapps.de/mbhp/mbhp_iic_midi_v1_0c.zip http://ucapps.de/mbhp_iic_midi.html is the parent page with all info.

I mean RS-422 is supposed to drive almost a mile, but I'm not sure if the MIDIbox would like that :).

Hi, We currently use this one from Reichelt: https://www.reichelt.de/d-sub-kabel-1-1-25-pol-stecker-stecker-1-8-m-2-0-m-ak-4010-p3997.html?&trstct=pos_0 TK. suggests up to five metres (so <15') would work but I haven't heard otherwise yet.

Might be my favourite one so far!

Hi Paul, The modules should be compatible with all Core versions. The digital gates etc. were typically done with GPIO pins for older Cores. Best, Andy

Impressive and elegant design crammed into a DIN socket with a 3.5mm jack output.

You cannot substitute for HC logic in this case. HCT is required to level-shift the logic to +5V, whereas a 3v3 3V signal pushes the threshold limits of a HC chip powered at +5V. 595-SN74HCT541N should be suitable.

True as far as I understand the structure of the chips, though I think the maximum current drawn could be 150mA per chip IIRC? Normally if they are overloaded the supply voltage begins to sag. In this case it's academic though, as we use bipolar driver transistors for both sides of the matrix. So the actual current could be somewhere near the ohmic value.

Four hours of stress testing just done. In MIOS Studio "set dout x 1" where 0<x<7 inclusive sets the sink sides active and "set dout y 0" where 8<y<15 inclusive sets the source sides active. I tested a mixture of red, green and mixed LED colours. No burn out or overheating of any parts. Colour and brightness after the test are identical to those of a non-stressed board (running in normal multiplexed mode for both). This doesn't mean that you should run your matrix like this (and if you did you would lose control over LED and switch registration), but it shows that a "failure" with the LED drawing the full theoretical current will not instantly damage the LED. At least there will be enough time for you to notice and reset the unit :-).