MatriX build questions

17703227d9536da1

Sure, you can plug one board in at a time. Heating up can be attributed to reverse power or short circuits, so check

PSU polarity (must be center-positive). Also, what PSU are you using?
Series diodes on each board
Cable harness: was it wired properly? Do check that the connection is really solid. An intermittent contact here can make things very weird.
Voltage regulator orientation
IC orientation

Measure resistance across any 100nF capacitor to see if you short-circuit the +5V supply anywhere.
Do you have a wirescanner board? Please check the cables for shorts and missing contacts.

If you post some photos, I might be able to spot something amiss.

0da6a0f95b3c9e1a

Zuerst einmal: Frohe Weihnacht! Merry Christmas to all.
MCU still getting very hot emediatelly after power on. Even with no display or neo attached. I resoldered every pad on the board, double checked all resistors and other parts. Here some photos.
(I do not expect you to reply during the holydays…)

0da6a0f95b3c9e1a

With installed neo boards: First, lightshow, then only red shimmering. No button response. (leds seem to be o.k)

0fc5608d995b44ff

@Synthfox: thanks and have a happy xmas time as well!

Andy can say more about the hardware, but some good news: from the software side what you’re seeing is fully expected - the green animation is the “MatriX” startup animation - the red shimmering buttons are the initialization standard when testmode is started (when no SD card is inserted), where every LED is continously lit up in red using low-power to save energy.

When you move the sliders on your Axes board, the red LEDs will be recolored. But: key input should work on this page, so the problem with the missing keyboard input and the hot MCU could be related.

Do you see anything on the OLED? How hot does the MCU get? Do the LEDs change color when you move the Axes sliders? This should be solveable, maybe a short somewhere on the core?

Many greets,
Peter

0da6a0f95b3c9e1a

It gets so hot, i cant let my finger on it for more than 10 sec. Definetly hotter than any Cpu I ever worked with. Still cant find any shorts on the board. Some voltages I can check? I also have experiance using an oscilloscope…

17703227d9536da1

The question is if the Waveshare board by itself gets hot when not connected to the Core PCB? You can test this individually with a miniUSB cable (you also have to change the +5V switch to USB). Are you able to recognise the MCU in MIOS Studio?

Something that we learned a few days ago from Mechie is that the BOOT1 jumper should actually be soldered to 0V, so try to bridge BOOT1 to 0V (GND).

I don’t think that I could see any other issues. Please just check if the IC is the right part (74HCT125). Maybe touch up some of the 2×25 header pins?

f054269ae83d673a

Hello again Midiphy team and merry X-mas!

I have some issues in the testmode that i do not understand.

First, the amount of LEDs that are darker is quite high, it is about 3-5 LEDs in each row, seems randomly distributed.
This surprises me, as i made quite sure LEDs did not get to hot. I used 295°C on my soldering station and made sure to only solder one pin at a time, move to next LED, solder one pin there, go back to previous LED, and so on.
Also what i am wondering about: i had an IC mix-up and needed to use a heatgun to remove it. I expected some darker LEDs in this area, but this is not the case. So i am wondering what could be the cause for this high amount of darker ones?

Other thing is, that from time to time, when i play around with the pots or the joystick, LED state “freezes”, but not for all, first 2 ½ rows continue to work and get updated (i see it when i press a button in this area). Strange thing is, after some random time (few seconds mostly) it resumes LED updating, and i also see it remembered my pressed keys (the cross-like pattern is now visible).
With the joystick it can be even more strange, when i push it into the upper right corner and move it around there, i get some different colors for some LEDs, sometimes also very random ones.
I have no idea where to debug the PCBAs for this, any idea what could be going on?

Enjoy your holidays, i do not expect a fast reply here 😉 🙂
Have a great time!
Enginerd

17703227d9536da1

Regarding the colours, there could be slight differences in the LEDs from manufacturing, though they should be binned. I have one or two on mine where the actual hue is a bit different for certain colours because (I think) one LED is slightly dimmer than the other two. Heat could play a role here and maybe the number of thermal cycles. I would still do it as you did though, so soldering 1-2 pins at a time and then going back for the others. The positioning might affect the relative brightness i.e., how centered the LED is relative to the switch.

When MatriX is being used as a sequencer, I think you’ll find that the brightness differences don’t add up to much. But you can always mark out the different ones and simply replace the LEDs. I suggest to play with it a little before doing that though.

For the freezing issue, it sounds like it could be related to the power, so what power brick are you using? You can also:

check the Molex cable wiring that all contacts are good
check the ribbon cable wiring (simply swap the ribbons around to check if the fault moves with them)
- even try to connect the J44 ribbon from the Core to the second board and check if the behaviour remains for the same board
- rework the components near the J44/J44A headers and clean off flux residues
scope the signal from the THT resistors to check if the integrity is still good
install BAT54S diode(s) in D71 to bring the 0V level closer

Merry Christmas!
Andy

f054269ae83d673a

Hi Andy,

thanks for all the thoughts!

I will stop caring about the LED brightness differences for now, i will do as you recommended and play around with it for a while. 🙂 (no interest here in changing 50+ LEDs right now…)

For the freezing issue: when i moved the PCBs around while turned on, i found 2 LEDs to be somehow “unstable” and interrupting my LED chain. After replacing those with new ones it now seems to be stable.
I did not install the BAT54S diodes (yet).
Just out of curiosity, i have a scope at hand, what would the signal integrity look like on the THT resistors? Maybe i check those before i close the case and install all the screws.
Btw, all ribbon cables are wirescanner-approved and the 12 V & 5 V rails look fine.

And one more question: on the OLED of the Matrix it only says “1: Legacy BLM”. Is this OK? Was a little bit confused by the “legacy”.

My MatriX seems to work so far, but the human needs some sleep 🙂
CU

17703227d9536da1

Enginerd_0x12F For the freezing issue: when i moved the PCBs around while turned on, i found 2 LEDs to be somehow “unstable” and interrupting my LED chain. After replacing those with new ones it now seems to be stable.

Nice, it is “just” a linear chain of LEDs, so it makes sense to fix the problem at source.

Just out of curiosity, i have a scope at hand, what would the signal integrity look like on the THT resistors? Maybe i check those before i close the case and install all the screws.

As far as I know, the digital data signal of each LED is buffered/driven, so in effect the signal should be just as clean coming out of each LED. You can compare the “datatrain” at the THT resistors (to check entry/exit of a neo board) or at any LED: input pin is next to the 0V pin (marked on the silkscreen) and output is diagonally opposite that (or: next to the +5V pin/100n capacitor). If the pulse shape becomes round or distorted, that would indicate some data corruption. Over a relatively long chain and several interconnects, one could expect non-ideal datalines, but it seems to work okay!

0fc5608d995b44ff

@Enginerd_0x12F very good that everything works - i had a similar neo board situation a while ago - a few LEDs were visibly a bit less bright - as Andy says, this is no problem to use in normal sequencer context - but if you want to replace them at some point in time, it is easy to do with a hot air reflow station.
Why could they be darker? Some ideas:
a) too hot soldering (you excluded that)
b) electrostatic discharge (also when handling the full boards, when they were touched, or by the soldering iron)
c) boiling off internal moisture when soldering (that’s why they come freshly repacked to vacuum bags)
d) “unaligned” positioning - a lot of light needs to go through the Matias switch and the keycap, if they don’t sit in similar positions everywhere, the light intensity arriving at the keycap may slightly differ.
e) damage due to other external factors, i.e. PSU spikes, wrong ICs at some point, cables being plugged in/out during operation.

Regarding scope measurements: Andy knows more what to expect, but in our first MatriX dev years, we had had a very noisy 12V PSU - to a point where the ePixels emitted noise under certain lighting situations - while I never measured the spikes with a scope, i would think one could see quite big switching noise/ripple on the 12V supply lines - this can lead to all kinds of trouble, i.e. the audible noise from the LEDs, but also some jitter on the ADC (for joystick and axes sliders) - if you want to measure, i’d recommend to take a look there and as a first measurement have a look at ripple on the 12V input - and maybe (as it is not super expensive) compare with the 12V PSU we recommend - i think the filtering ferrite ring near the barrel plug of the PSU plays a big role: with the recommended PSU, any previously audible ePixel noise was just gone (or became inaudible when your ears are >10cm away).

The “Legacy BLM” mode is correct and is more of a “honor designation” - this says the MatriX is operating true to TK.s original BLM specs and that it would also be compatible with a MIDIbox SEQ v4 (not only a v4+) - should we add some MatriX extensions to the SEQ v4+ mode in the future, this display message would change, but if there is such a software extension, we will keep the legacy mode additionally in MatriX to stay compatible with the big amount of existing SEQ v4.

Best regards and enjoy your new MatriX!
Peter

f054269ae83d673a

latigid on Hawkeye
wow, are you guys always online and checking/answering? Do you do other stuff at any time? 😉

Thanks for the, as usual, detailed answers and explanations. I will monitor some signals with the scope and share my observations.

I also use a 12 V power-supply with ferrite bead at the end. I do not hear any noise of the LEDs so far. I did check the PS voltage when i got the powersupply, but without load at that time, looked fine to me on the scope. (i wrote about it in the “alternative parts” thread)

f054269ae83d673a

so i scoped some signals, 12V rails, digital comm. signals, everything looks fine to me.
Digital signal quality/integrity could be a little bit better, bit away from a nice square signal, but as long as this works with the slopes it is fine for me.
Worst digital signal i found (the others look better) is like this:

So i gonna put in all the screws now…. 🙂

f054269ae83d673a

timebase is set to 2µs in the picture above, +-10 V range

17703227d9536da1

Yep, looks fine! Sure, the traces could be a bit sharper but I think that’s okay and normal for this sort of thing. Have fun with the last assembly!

0da6a0f95b3c9e1a

Time to go to bed…
As it seems, all lights are now working properly, same as the sliders and joystik. It was a weak pin in the power harness!
But now: not a single Matias is working. Although I had some response of them in earlier attempts, I noticed the white crosses going out from the pressed buttons. Checked the cables, connection between core and neo. Can you give me the routing of the button-bus? Where I can detect which signal goes from the core to the neos?
Still worrying about the cpu temperature. It will also get hot when the disconnected core board gets its power via mini usb. Many thanks for now…

17703227d9536da1

Did you already switch the BOOT1 jumper?

How is the chip IC3? Are any of the control signals shorted to the 0V pads?

Here’s a schematic snip of the same thing connected to J89. You can also read back the signals to the MCU pins from this chip, namely PB12, PB13, PD10 and PB15

What happens if you connect the J89 cable to another neo board?
Can it be that the micromatch headers are the wrong way around? There is a slot that permits the cable going in only one way but some connectors have a slot on both sides. Still, the PCB would prevent improper insertion as long as the cable was wired correctly.
Maybe post a picture of the neo boards too, especially of the ICs.

0da6a0f95b3c9e1a

Boot 1 soldert to gnd. Tried j89 on any neo bord, no effect. Wired the cable exactly as shown on the photo at 6.4. (Always pin1 to pin1) I just measured the output potentials on J89. Do they make sense? ½=0v connected to gnd, ⅔=5v, 5=2,3v, 6=2,3v, ⅞=2,2v, 9=4,8v, 10=1,5v. Would it make sense to put an oscilloscope on those? Now i need the further routing of these signals on the neo board, wether there is an interruption.

17703227d9536da1

No photos of the neo boards? Maybe you put a chip in backwards or the ICs in the wrong positions?

17703227d9536da1

Would it make sense to put an oscilloscope on those?

Sure:

½=0v

Right

¾ =5v

(if 3+4) Right

5=2,3v

Is the serial data input. You should see pulses here if switches are pressed.

6=2,3v

Is the serial data out from the Core. It should be a sequence of pulses that look similar to the clock, I think circulating a “low” state.

⅞=2,2v

Serial clock

9=4,8v
10=1,5v

Chip selects/latch/shift in+out. You should see a transition at the beginning/end of the datatrain.

If you have a SEQ v4+ around, you could consider swapping out the MCU board to see if it is local to that. Just be careful not to bend the pins when inserting/removing.

(had 5+6 swapped, above is correct)