latigid on

N'oubliez pas la Suisse romande!

Well done, #25! You can be a midiphy trusted builder now :)

Lack of beat LED was a bug introduced with a new software update a few years ago. Mute/unmute button behaviour has to be enabled and will also depend on the display mode. I can't remember the details sorry, but try different combinations of shift + extra column.

You could swap the resistors around or simply the pins in the HWCFG: # SR Pin ##default LED_BEAT M5B 0 LED_MEASURE M5B 1 # SR Pin ##swapped LED_BEAT M5B 1 LED_MEASURE M5B 0 There is also a setting in the options menu to invert the LED colours (MENU>UTILITY>OPT.; maybe this has an effect somehow?: OPTIONS page: new option "Swap LED colours" (relevant for Wilba and midiphy Frontpanels)

The observations suggest interference on this clock line such as antenna effects (EMI) from sub-optimal trace routing/cabling, or transmission line reflections. Hence a suggestion of an RC (resistor + capacitor) shunt termination (forum search will turn up more info). Grounding to the "chassis" seems an odd choice and means there is relatively high resistance between the chassis and system 0V. Otherwise the clock that is wired in parallel to all circuits would be shorted out, no?

Inrush current issue? Though the LEDs seem to be driven with 1k, so not terribly high. Grounding issue between power supplies? Check all 0V are common. SRIO integrity? Try buffering the J8/9 signal and/or terminating the chain with an RC shunt.

Hi Laurent, That's probably it, there is no power supply to the OLEDs in this case and they are likely parasitically powered somehow. Here you can borrow the jumpers from the v407 board: https://www.youtube.com/watch?v=QaN26uzUA1A&t=3357s I'm on holiday and the internet is too slow for me to find the tutorial step where the jumpers are inserted, but yes, you must connect the middle pin of J15_S to the 3v3 side. Hope that solves it! Best, Andy

Hi Adam, Nice work, thanks for investigating! Could you share the exact part that you used? Best, Andy

^Destpane is a variable, not a string. It's likely that there is a character limit on those.

Maybe use an oscilloscope to trace the LED signal? What is it connected to?

How about https://www.midiphy.com/en/shop-details/138/2/wcore-pcb-and-usb-pcb-midibox-diy-do-it-yourself-solder-midi-microcontroller-stm32f4 ?

I like the idea @k2z3k0 !

Nice, thanks for reporting back! Now trim that contrast!

Hi Laurent, The part is correctly oriented as pictured, with the "vertical" bar closest to pins 1/16. Bon courage! Andy

You'd need to reassign the pins, so use GPIO or a spare SPI for the SSD1206. Look maybe at the MBCV code?

Hi Laurent, feel free to post a clear photo/part number and I can check for you. The line should go along pins 1-2-3-4 etc. so the text of the part is readable with the line along the bottom. Best; Andy

sr_dout_r1= is for 8x matrices sr_dout_r2= is for 16x matrices I suppose you only use 8x8 matrices, thus keep sr_dout_r1 for the second DOUT. Here's how you address one DOUT PCB: sr_dout_r1=1 sr_dout_r1=2 sr_dout_r1=3 sr_dout_r1=4 and here's how you address the next DOUT: sr_dout_r1=5 sr_dout_r1=6 ...

POIDH!

Hi Adam, Everything works, unless it doesn't . Yes, you should be able to use a controller keyboard and route the USB MIDI to another port for example. Try here; in essence the hardware is the same, only the FET switch that senses current doesn't feature in the wCore/USB. http://midibox.org/forums/topic/18906-usb-host-support-for-mbhp_core_stm32f4/#comment-165136 As noted, there are a few other jumper settings on the 407v breakout. I've read a few things in passing that require a different pull-up or so depending if the device is self-powered or not. Have fun! Andy

Is the Korg self-powered? Did you jumper the +5V on the Core USB PCB? I don't have time to investigate at the moment but you may also look into the jumpers on the Waveshare board. Read up on OTG handshakes; it might be that certain pull-ups or other data routines are required. https://www.waveshare.com/w/upload/5/58/CorexxxV-Schematic.pdf Best, Andy

Hi, Defines the matrix to be addressed. You could have one matrix for 7-seg digits and another as a simple LED dot matrix. Each one needs a unique address, otherwise MIOS wouldn't know what one to turn on when assigned. Simple case: 8 rows is typical. 4 rows will repeat the selection pulses. 16 rows would need two SRs for 16 selection pulses. Use rows-8 unless you need a 16x16 matrix. Determine where the common pin of your LED segments go. Then connect them to this SR in order. If it is the first SR in the chain, then sr_dout_sel1=1. If it is the nth SR in the chain, then sr_dout_sel1=n r1 refers to red1, for the case where you're defining an RGB matrix. Then you have g1 and b1, and also r2, g2 and g2 if you want a 16x16 matrix. Not pull-up resistors, these are series resistors to limit the current and they probably should be bridges to sink more current for the common cathodes. So assign the sr_dout_sel1=n where those bridges are. If you have common cathodes, then inverted_sel=0 is probably correct. At least that is the case for matrices that I have configured (not including those with sink drivers!) Tell me about it! Have fun! Andy

Could be anything from incomplete NGC file, dodgy breadboard or wiring, corrupt SD card (saving often doesn't work well, upload always worked better for me) etc. etc. Draw a functional map of how it should work and see if you connected the dots properly. Adapt the NGC file to suit your hardware and again just playing with it might help.

Define the shift registers connected to the "sel" and "dout" parts, at the moment they all = 0 and so no data are sent.

It's too hard to follow your text sorry. Can you provide the actual wiring that you use and the type of 7-seg displays? How many shift registers are you using and is this accounted for in the .NGC? To light up an LED you need a current source (high side) and a current sink (low side). For common cathode (CC) displays, the segments are sourced from DOUT pins driven high and "sinked" also into a DOUT pin that is driven low. If the sink pin is high, then the potential is the same on both sides of the LED and so no current flows and the segment remains off. The pattern updates with each RC1 pulse for each LED individually, defined by the pin used for CC. I am not 100% familiar with the logic here, but inverted=1 probably means "to turn this digit on, turn the DOUT pin off"- For common anode (CA) displays, the digit is sourced from the DOUT pin and the segments sinked into DOUT pins. Note that the .pdf says Common Anode (inverted_sel=0, inverted_row=0) i.e. not inverted! Try a simpler setup first of all. Just use a simple single LED that you know the polarity of (i.e. test with a multimeter diode mode) and make sure you can get the LED DIGIT pattern working with that LED.