TK.

Today you replied to a posting which gives you a link to a C based application which is a much better example: Best Regards, Thorsten.

Hi Alex, I think that MIDIbox NG is the best choice in your case, no need to write a special firmware. Presets could be written into .NGR scripts, see also http://www.ucapps.de/midibox_ng_manual_ngr.html The script is directly executed from SD Card, there are commands to send any MIDI messages (including SysEx strings), so that there are actually no limitations. MBNG also supports graphical displays, see http://www.ucapps.de/midibox_ng_manual_lcd.html ST7920 GLCDs are not supported. If you don't want to write your own driver, please select a GLCD which is already supported by MIOS32. Best Regards, Thorsten.

Hi, this behaviour indicates a bad MIDI interface (as you've already noticed). SysEx strings sent by the PIC are correctly received, but the PIC doesn't receive well shaped MIDI messages. This could also be related to a problem with the MIDI cable. Is TEST MIDI2 passing at your side? However, the Neusonik interface is really worth the money. Best Regards, Thorsten.

Hi Sacha, two observations: does the lower waveform of the first picture really show the OE# line (Pin 13 of the 74HC595, resp. STM32F4 pin RC11, resp. J15:RW)? The OE# state should never change while new data is shifted into the 74HC595. If this is really J15:RW, then the problem is related to a connection error. Please also check the signal slope, it should be ca. 100 nS If a value transitions at the OE line takes more time (> 500 nS), then you are using the wrong pull-up resistors at R33, they should be 1k Best Regards, Thorsten.

I think/hope that I found the problem! :smile: You've used "SRIO num_sr=16" after the matrix configuration, and this caused an inconsistency in the selection line pattern configuration, because it has been prepared for num_sr=32 before the SR number has been changed. Could you please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre1.zip It doesn't fix the WARNING and ERROR messages. - some "#" (comments) are added at the end of the command line; this is currently not supported (but could be supported in future) - the appr. ERROR can be ignored - WARNING resolution=7bit: valid, because the resolution parameter is only supported for the AINSER device configuration command, not for EVENT_AINSER event commands Best Regards, Thorsten.

yes, however... in your default.ngc file I found following line at the end: DebounceCtr 20 please remove it Best Regards, Thorsten.

Hi Bartosz, (I will look into your .ngc file later if really required). But to your questions: yes, the cable length does matter. You already noticed with an earlier firmware version some unstable scan values. Which means that the construct was already in a critical range - each change in the firmware can change the situation. E.g. slightly more activity in the firmware can cause a higher power consumption and if your core module is powered from a weak PSU (or a weak USB based supply), the situation can get worse. For further debugging it makes sense to check: - if it gets better with a different PSU. Resp. if your core module is powered via USB, please use a USB hub with external PSU - if v1.032 is working properly with less modules connected > Question2: what maximum length of cables between modules would you recommend? as short as possible (until it gets unstable ;-) However, there are measures to compensate long cables a) starlike SRIO wiring: after the two DIO_MATRIX modules, use a Y cable to connect two DINX4 and two DOUTX4 in a chain. Don't mix DIN with DOUT in the chain b) termination of the last SRIO modules in the chain with a 100 Ohm resistor + optionally 100 pF cap (not important if not available) between SC+Ground and RC+Ground. See also http://www.ucapps.de/midibox_seq/mbseq_v3_din.pdf and http://www.ucapps.de/midibox_seq/mbseq_v3_dout.pdf c) the usage of line drivers (brand new): http://www.ucapps.de/mbhp_line_driver.html However, before you start to try these measures, please feedback on the power supply topic before deciding the next steps. Currently I can't 100% ensure that the latest firmware changes were uncritical under all conditions, but under the assumption that the PSU and cable length topic isn't clarified yet, I think it's better to discuss this first before proceeding with the time consuming SW debugging round (where I will need your help as well, it will cost ca. 2..3 iterations to identify the root cause at your side) Best Regards, Thorsten.

The modules have been tested successfully :) Here the new page which also contains a link to the .brd files: http://www.ucapps.de/mbhp_line_driver.html Best Regards, Thorsten.

Hm... it's more difficult to check the connections with this picture than expected. But since you've a scope: you should see some fast waveforms ca. 3 second after reset (after you've pushed the black reset button) for ca. 10..20 mS - thereafter communication will be stopped if no LCD has been detected. Ensure that you are using a 74HC595 (and no 74HCT595) If the signals don't toggle for 10..20 mS at SCLK/RCLK, then the issue must be already somewhere between the core<->74HC595 connection Best Regards, Thorsten.

The CLCD display should work by default without special re-configuration. So - this hint is only important if you've changed the configuration in the past. It could also be related to a HW connection issue, especially since the Displaytech 162a has no 1:1 pinning Could you please take a photo which shows the core<->LCD connections and post it here? Best Regards, Thorsten.

Yes, it's this order - your idea should work! See also http://www.ucapps.de/midibox_kb/midibox_kb_fatar_df_88_interconnections.pdf MK/BK lines are strobed individually, so that the 8 blue input lines at J3 and J4 could also be connected together. Best Regards, Thorsten.

Could you please post a photo of your hardware (especially pot connections)? This could help to analyse the issue further. Best Regards, Thorsten.

Hi Bartosz, unfortunately I'm still not able to reproduce the issue at my side. It's very interesting that the issue doesn't happen with pre1, because in this release I modified the SRIO scan handling so that optionally IO pins could be used instead of shift registers. In pre2 I introduced the SRIO command, but it only changes the way how the SRIO driver can be configured and shouldn't affect the behaviour. I need more input. Could you please attach your .ngc file to this thread (just put it into a .zip file to allow an upload)? Your HW setup would also be interesting. You noticed unstable inputs, the reason could be that the cables between the MBHP_DIN* modules are too long. So: which modules are you using exactly, and how long are the cables between the modules? Does it get better if some modules are removed? E.g. if only the two keyboards are connected, does this help? Best Regards, Thorsten.

Very strange! I need your help to isolate the problem at my side! Could you please try following versions and tell me from which one it isn't working anymore? -> http://www.ucapps.de/mios32/backup/midibox_ng_v1_032_pre1.zip -> http://www.ucapps.de/mios32/backup/midibox_ng_v1_032_pre2.zip -> http://www.ucapps.de/mios32/backup/midibox_ng_v1_032_pre3.zip -> http://www.ucapps.de/mios32/backup/midibox_ng_v1_032_pre4.zip Best Regards, Thorsten.

My proposal was to connect the ground/5V cables of the pots to J2 Best Regards, Thorsten.

It would be possible with the big brother MIDIbox SEQ V4 (without Lite) since the UI supports this - but the handling requires a LCD and GP encoders to shift the copied range to the new position. It isn't possible with MBSEQ V4L, and no, I won't add a special (difficult to remember and therefore never used) button combination. Best Regards, Thorsten.

Hi Bartosz, I've an assumption, but currently can't check it at my side. Could you please add following statement to your .ngc file: SRIO debounce_cycles=0 this should disable the debouncing - a potential function which could affect matrix scanning. Best Regards, Thorsten.

Good news on this topic: I got the PCBs and they are working! E.g. here I connected a TPD to the line drivers, a bidirectional SRIO is working over a long cable without flickering LEDs or unstable encoder/button scans: And I tried an AOUT_NG module which works as well: I'm surprised by myself that it works w/o issues, because I haven't found so many references to these wonderful chips in the DIY world :) Therefore I'm crossing fingers that I haven't overlooked something ;-) However, I will do some additional checks this weekend and release the .brd files if I don't notice issues. Best Regards, Thorsten.

It helps! As you can see, the code execution continues and you get a new error. The messages indicate an issue with the shell. Seems that adding MIOS_SHELL is indeed no expert option, but may be required for your Linux distribution. Could you please try: export MIOS_SHELL=/bin/bash Best Regards, Thorsten.

10k pots are fine, 1k pots would consume a bit more power which could explain the voltage drop of 0.2V So, I recommend to test the direct J2 connection. Best Regards, Thorsten.

Passt scho So hast Du zusaetzlich noch OSC1 aktiviert, doch das tut nicht weh. Gruss, Thorsten.

Fuer das zweite Quad-IIC Boards benoetigst Du eine spezielle PIC16F88 Firmware (*) fuer ID 18/1A/1C/1E, sowie eine modifizierte MBSEQ V4 Firmware, die Du Dir dann mit jeder Release selbst zusammenbauen musst, weil ich diese Bastel-Option nicht offiziell unterstuetze. Warum: weil es technisch und finanziell gesehen im Vergleich zu einem zweiten MBHP_MIDI_IO Board wenig Sinn macht. Schau mal in den Schaltplan rein: http://www.ucapps.de/mbhp/mbhp_midi_io.pdf Fuer die beiden OUTs benoetigst Du lediglich zwei MIDI Sockel sowie vier 220 Ohm Widerstaende, d.h. die Kosten liegen bei insg. 2 EUR (+ 1 EUR falls Du keine Lochrasterplatine herumliegen hast) (*) falls Du Dich doch fuer die IIC_MIDI Loesung interessierst: ich habe hier zufaellig 4 vorprogrammierte PIC16F88 herumliegen, die der Eigentuemer sicherlich verkaufen moechte. Gruss, Thorsten.

Na also! :) Die Port-Maske fuer USB1 und MIDI1/2/3 ist: ports=1000111000000000 Gruss, Thorsten.

This output would happen if Phatline has set the MIOS_SHELL variable by accident, e.g. to /bin/share/sdcc Actually this variable shouldn't be set at all -. I added this due to a special user request some time ago, but it's more or less a hidden feature and should only be used when you know what you are doing ;-) So Phatline: please enter unset MIOS_SHELL and try it again Best Regards, Thorsten.

Die Tasten haengen an D5 und D4 vom DOUT Shift Register (somit 74HC595, Pin 4 und 5), schon die entsprechenden Verbindungen ueberprueft? Gruss, Thorsten.