MIDIbox NG Release + Feedback

T.K · December 16, 2012, 3:16pm

Hi *,

this thread informs you about the latest release, and gives you the possibility to write down your feedback (bug reports, questions about existing features, suggestions for new features, etc…)

MIDIbox NG is in beta state!
Not all planned features are implemented, but the existing functions should (hopefully) work stable.

The latest build for MBHP_CORE_STM32 and MBHP_CORE_LPC17 can be downloaded at:
-> http://www.ucapps.de/mios32_download.html

List of planned/implemented features (press refresh button in your webbrowser to display the latest state):
-> http://www.ucapps.de/midibox_ng.html

Documentation (in progress):

Best Regards, Thorsten.

Marxon · December 16, 2012, 3:57pm

Ja ist denn heut schon Weihnachten?

FantomXR · December 16, 2012, 4:22pm

Is it normal, that the ICs of my DIN are getting very hot after upgrading to NG?

T.K · December 16, 2012, 5:56pm

Is it normal, that the ICs of my DIN are getting very hot after upgrading to NG?

No, this is definitely not normal, but it’s also very likely not related to the firmware, but to your hardware.

If you are not able to determine the root cause, please open a new thread in the of this forum.

It’s especially important that you describe your hardware setup, otherwise remote diagnosis will be impossible.

Best Regards, Thorsten.

Duggle · December 16, 2012, 9:22pm

Some questions:

How about LCD display of dynamic text as in patch name(s) contained within a received Sysex message?
Previously the 16SR limit was advised rather than forced. I have a project (in development, still after ~2 years!) that uses long chains, a linear LED display for keyboards, not so suited to matrix wiring. I assume it will still be possible to use MIOS32 functions to address long(er) chains of SR’s? (when integrated into a NG framework device ,that is)

thanks!

T.K · December 16, 2012, 9:46pm

Some questions:

How about LCD display of dynamic text as in patch name(s) contained within a received Sysex message?

I’ve no solution for this yet, but to ensure that this won’t be forgotten I just have added this topic to the MBLC page.
It will probably work in conjunction with a EVENT_RECEIVER which listens to multiple bytes instead only one - but this would blow up the memory storage format, because each EVENT would need to store the byte range.
Once a solution has been found, the label could be inserted into outgoing SysEx, but also displayed on LCD with a special formatting directive (such as %t)

Previously the 16SR limit was advised rather than forced. I have a project (in development, still after ~2 years!) that uses long chains, a linear LED display for keyboards, not so suited to matrix wiring. I assume it will still be possible to use MIOS32 functions to address long(er) chains of SR’s? (when integrated into a NG framework device ,that is)

thanks!

http://discourse.midibox.org/t/topic/17031

Addressing longer chains would be a more elegant solution than the introduction of a second SRIO chain, but it needs a certain awareness about the HW constraints.

In any case, enhanced SRIO chains will always work if buffers are used between the DIN/DOUT modules - but there is no standardized way for this approach yet (no tiny MBHP module) -> but newbies always request this

Anyhow - the MBNG concept itself is prepared for both solutions!

Best Regards, Thorsten.

T.K · December 16, 2012, 11:42pm

Meanwhile I’ve finished the major part of the .NGC file documentation, and I’ve also started with the “First Steps” tutorial which will be continued in the next days:

Have fun!

Best Regards, Thorsten.

Duggle · December 17, 2012, 3:20am

http://discourse.midibox.org/t/topic/17031

Addressing longer chains would be a more elegant solution than the introduction of a second SRIO chain, but it needs a certain awareness about the HW constraints.

In any case, enhanced SRIO chains will always work if buffers are used between the DIN/DOUT modules - but there is no standardized way for this approach yet (no tiny MBHP module) -> but newbies always request this

Anyhow - the MBNG concept itself is prepared for both solutions!

Normally the signal integrity potential problems can be solved/prevented by:

Good layout and wiring (e.g wire clock in a point to point (not star) manner, reduce the area of the loop formed by the signal path and it’s ground return,etc.)
drivers and termination.
- I notice the LPC17 core has a 541 driver. That’s good, but I predict that potential problems may be caused by the fast edge transitions onto the transmission line of DIN/DOUT connections. The fix is very simple: a (typical) 100 Ohm resistor in series with the signals at the output of the driver. This helps in a couple of ways: it slows down the edge transitions by enough to reduce excitation of resonant modes(ringing). It also provides a closer match of driver to line impedance resulting reflections getting absorbed rather than reflected -> reduced or eliminated line ringing.
- The STM32 core has an open drain and 220R pullup driving the line. The effect of this can be seen pictured in this article <___base_url___>/blog/17/entry-33-signal-integrity-for-long-srio-chains-mios32/.?do=embed The rising edge (driven by the 220R pullup) is fine, but the falling edge ( driven by the port pin drain) shows the signs of ringing. Since I wrote the blog article, I’ve discovered the best termination that fixes this is a diode in parallel with the series termination resistor at the driver source. In other words a 220R resistor in parallel with a signal diode (anode towards the driver, not the line). The affect of this is that a high is driven onto the line by the 220R pullup (passing through the diode) and a low is driven through the 220R series termination resistor.
- Its a bit late to change/improve the PCB layout of 16LED ring PCB, but I think the way to drive a large string of these modules is with the termination schemes I’ve just outlined.

To guide newbies, it may be possible to explicitly state the conditions where it is possible to exceed the 16SR limit. That is, you can use nn of module yy with xx cm of standard ribbon, terminated in such and such way.

Anyhow it’s a subject area I can see myself involved with a lot in the future. I’m interested in taking the keyboard display in the direction of 6 (or so) octaves of RGB. To get good colour resolution and variable brightness and invisible flicker, It may be necessary to address the DOUT chain with higher frequency updates (even faster clock rate, if it be necessary) so I’ll be headlong into signal integrity issues, sooner or later!

novski · December 17, 2012, 7:46am

@Duggle: Am I going right that you mean pin 11 (Y7) on the 541 (IC1) by LPC17 Core?

Duggle · December 17, 2012, 8:23am

@Duggle: Am I going right that you mean pin 11 (Y7) on the 541 (IC1) by LPC17 Core?

Yes, and also (more importantly) pin 12 which is the clock. The clock is distributed to all SR’s in the chain (the data line is re-transmitted between each SR, so less prone to integrity problems, RST line won’t cause problems either ), so it’s much longer, more prone to problems such as ringing, which can introduce extra transitions and corrupt data in the SR’s.

FantomXR · December 17, 2012, 9:51am

TK, you are awesome.

Programming was never so easy! I read through the first steps and everything seems pretty obvious.

T.K · December 17, 2012, 12:53pm

Thanks for the valuable input!

[*]I notice the LPC17 core has a 541 driver. That’s good, but I predict that potential problems may be caused by the fast edge transitions onto the transmission line of DIN/DOUT connections. The fix is very simple: a (typical) 100 Ohm resistor in series with the signals at the output of the driver. This helps in a couple of ways: it slows down the edge transitions by enough to reduce excitation of resonant modes(ringing). It also provides a closer match of driver to line impedance resulting reflections getting absorbed rather than reflected -> reduced or eliminated line ringing.

I fully agree that this measure will help.

A workaround could be to insert the resistors directly into the cable:

I should nominate this picture for I fixed It

Ok, so in the next release 32 SRs will be enabled, and I also increased the number of “virtual button/LED functions” to 1024 (considered that button/led matrices are connected)

[*]The STM32 core

…won’t be supported from my side anymore to simplify the documentation

Programming was never so easy! I read through the first steps and everything seems pretty obvious.

Thanks - seems that this is the right balance between technical details and user experience!

Best Regards, Thorsten.

mbhp_srio_cable_termination.jpg640×345 44.3 KB

novski · December 17, 2012, 1:31pm

TK, that doesn’t match with my understanding of the description of Duggle.

I just took out my multimeter to check and found out, that you hooked a resistor in RC1,RC2 and SC.

You didn’t solder a Resistor in the Y7 output (SO). Why?

best regards

novski

T.K · December 17, 2012, 2:01pm

You didn’t solder a Resistor in the Y7 output (SO). Why?

The serial output (SO) is a simple point-to-point connection between the '541 output and the serial input of the first shift register in the chain.

So, only a single input pin is involved (-> low capacitive load) and the connection is short (-> low cable impedance).

This is the big difference to the SC and RC line, which is loaded by the appr. input pins of all DIN and DOUT shift registers in the chain!

Best Regards, Thorsten.

Duggle · December 17, 2012, 8:43pm

Great TK, I assume what wasn’t working (reliably) now is?

If I’m correct regarding the signals going to the SR’s, the RS line is non critical as it’s transition latches the register data to the output pins (in the case of DOUT), and samples the input pins into the register (in the case of DIN). If there is bounce on this line it does not change anything.

[sTM32 core]…won’t be supported from my side anymore to simplify the documentation

Does this mean no source code for STM32, or no documentation? It’s just that I’ve been doing an additional side project with what I’m calling a “MiniCore” .

It involves the STM32 chip soldered to a LQFP SMD adaptor board. It’s small, very cheap $0.90, plus $6.90 for the STM32F103RET6.

Its best suited for projects where you don’t necessarily need heaps of I/O options connected to the core.

Anyhow, it works great with MIOS32 so I guess that is enough (heaps,actually!!!). It will come to light when I post details of my novel take on BLM (coming soon!). If NG can be used on this MiniCore platform it would be a bonus.

Oh yeah, I have a method of soldering the LQFP that I recon even the greenest newbie could successfully do! (It involves solder, iron, wick, and flux paste).

T.K · December 17, 2012, 11:05pm

Great TK, I assume what wasn’t working (reliably) now is?

I can’t confirm this, since I don’t have a setup ready which would allow me to test longer SRIO chains.

Currently I strongly focus the firmware development and test it with existing hardwares, such as MBSEQ, MB16E, MBLC

The modified cable was only an idea how we could provide a simple solution without PCB re-design (which could take months till it’s phased in - and many people would still own the previous PCB version - therefore no feasible ad-hoc option)

If I’m correct regarding the signals going to the SR’s, the RS line is non critical as it’s transition latches the register data to the output pins (in the case of DOUT), and samples the input pins into the register (in the case of DIN). If there is bounce on this line it does not change anything.

You are probably right. On the other hand, spikes on the RS line could probably influence the SC line as well.

This is just an assumption, as mentioned above I haven’t checked this by myself.

By adding resistors to both lines we should be at the safe side.

Does this mean no source code for STM32, or no documentation?

The release package contains a binary for STM32, but I won’t mention this in the MBNG documentation as a HW option, because the “if” and “whens” could confuse newbies too much.

Main reason is, that the performance of STM32 is worse, so that the MBNG firmware doesn’t show the same excellent latency than on a LPC17 core (in fact benchmarks are showing a performance of only ca. 50..60% of a LPC17 core).

Another reason is, that since some months the MBHP_CORE_STM32 module can’t be purchased from SmashTV anymore.

However, for experts (like you) it shouldn’t be a problem to handle this.

Best Regards, Thorsten.

FantomXR · December 17, 2012, 11:42pm

at first: I’m very happy, that many many things are working out of the box… the programming is self explaining… nice!

but allow me just a few questions…

a.) Where to set the LEDs of a LED-ring? For testing I’ve connected just 8 LEDs.

I tested with main stage and even MIDIfeedback works great (very very nice…).

b.) I need to turn the encoder on and on again till I get to the maximum of the assigned pot in main stage. I used the “Inc00Speed_Dec40Speed”-mode so I think there is no more speed. Is there a chance to get faster to the maximum?

c.) My encoders (EC11) are detended. As fas as I can see, removing it is not easy… I read the article in the wiki about it but I’m not sure, if it works the same way on mine. Anyway: The encoder just sends a signal after the “second” click…so: Turn - Send… Turn - Nothing… Turn - Send, etc. It is possible to send an event every step I do?

So long: THANKS!

T.K · December 17, 2012, 11:42pm

A new beta release is available:

MIDIbox NG V1.001
~~~~~~~~~~~~~~~~~

o maximum length of DIN/DOUT shift register chain increased to 32.
This means that up to 256 digital inputs, and 256 digital outputs are available.

o Number of virtual button and LED functions increased to 1024

o New meta event for speeding up ENC movements (EncFast, see .NGC documentation)

o New meta events for emulating SCS buttons/encoder (see .NGC documentation)

o Ethernet and OSC setup now stored with ETH/OSC commands in .NGC file

o SysEx variables are now stored with a SYSEX_VAR command in .NGC file

o EVENT_BUTTON_MATRIX and EVENT_LED_MATRIX now properly supported
See cfg/tests/blm8x8.ngc for a simple configuration example
[/code]




Unfortunately the command format changes for ETH/OSC and SYSEX_VAR mean, that previously generated DEFAULT.NGC files will be incompatible (you will see some error messages after power-on). But I preferred to to change it now than never!

To solve this, just store a new DEFAULT.NGC file by typing:
[code]  
save default

in the MIOS Terminal.

The LED_MATRIX and BUTTON_MATRIX functions have been tested with the MBSEQV4 hardware!

See also following configuration file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftk%2Fmbseq.ngc

This file proves, that even exotic Button/LED matrix scramblings can be handled by MIDIbox NG!

Best Regards, Thorsten.

Duggle · December 18, 2012, 12:06am

That’s great to know!

For large and performance critical stuff I am, and will, use LPC17 for obvious reasons. Its nice to have the possibility of smaller, cheap, and simple processor where appropriate.

T.K · December 18, 2012, 12:45am

a.) Where to set the LEDs of a LED-ring? For testing I’ve connected just 8 LEDs.

As already mentioned in another thread (I guess by Ilmenator), LED rings require a DOUT_MATRIX configuration.

See following schematic: http://www.ucapps.de/mbhp/mbhp_doutx4_ledrings.pdf

A configuration example which gets use of LED Rings can be found here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fencbanks.ngc

With 8 instead of 11 LEDs, you also have to change the preconfigured patterns with the “LED_MATRIX_PATTERN” command.

b.) I need to turn the encoder on and on again till I get to the maximum of the assigned pot in main stage. I used the “Inc00Speed_Dec40Speed”-mode so I think there is no more speed. Is there a chance to get faster to the maximum?

V1.001 handles detented encoders better than V1.000

If you still want to get faster encoders, assign the new “EncFast” meta event to a button.

Configuration example:

# use button 9 as "FAST" button
EVENT_BUTTON id=9 type=Meta meta=EncFast range=0:5 lcd_pos=1:10:2 label="FAST%d"
[/code]





-\> encoder movements will be 5 times faster whenever this button is pressed.



But probably the changes in V1.001 are already sufficient (they have been tested with my MBSEQ V4 HW).











> c.) My encoders (EC11) are detended. As fas as I can see, removing it is not easy... I read the article in the wiki about it but I'm not sure, if it works the same way on mine. Anyway: The encoder just sends a signal after the "second" click....so: Turn - Send... Turn - Nothing... Turn - Send, etc. It is possible to send an event every step I do?







Did you already try other enoder types, such as detented1, detented2 or detented3?



The "type" has to be configured with the ENC command -\> see [http://www.ucapps.de/midibox\_ng\_manual\_ngc.html](http://www.ucapps.de/midibox_ng_manual_ngc.html)







Best Regards, Thorsten.