In the last days I worked on a major MBHP_MF update, mainly triggered by Screaming Rabbit who gave me a big package of different Alps faders for free!
Design Targets:
find a solution to handle high-quality faders like Alps K faders with “coreless” motors
find a solution for MBHP_CORE_LPC17 which doesn’t deliver stable enough ADC conversion results due to the reduced 3.3V voltage range
find a solution for MBHP_CORE_LPC17 which cannot handle touch sensors properly without heavy CPU load (resp. without an additional external device or microcontroller)
find a solution which is compatible with PIC based projects for best usability
find a solution which is DIY friendly and doesn’t require additional gear (e.g. chip programmer) for something which isn’t part of the MBHP yet
find a solution which can be easily tested and troubleshooted (no need to learn new processes)
a dedicated PIC controller controls the motorfaders directly
it can be accessed via MIDI (only) - this allows standalone usage, cascading (to chain multiple modules), and the re-use of existing infrastructure such as MIOS, MIOS Studio and MIOS Bootloader
the module can either be connected to a PC directly, or controlled from a second PIC or STM32 or LPC17 (note that MBHP_CORE_LPC17 has a third and even a fourth MIDI IO port at TTL level so that the available two MIDI IO pairs are still free)
native support of various protocols (e.g. PitchBender, CCs, even Logic Control and Mackie Control Emulation)
support for 8 touch sensors
instead of TC4427 I’m using L293D now - not at least because of the integrated diodes.
due to the direct motor control connections, the PIC is now able to generate PWM with 50 uS steps for improved motor speed control while a motor is moved
since the firmware is dedicated for this task, there was enough memory free to integrate advanced features, such as runtime-calibration and motor position tracing
Two snapshots of the prototype - currently I’ve only tested the circuit with high-quality K Faders, which were not properly controllable with MBHP_MF_V1
Meanwhile PCBs are available (layout created by SmashTV - thank you!!! )
MIOS Studio got a new configuration tool:
Especially the calibration is much easier now, not at least because of the new motor position tracing feature:
There is no real need to add more modes, considered that MIDI events can be mapped on the host PC and/or from another microcontroller (like Core32) which uses MBHP_MF_V3 as a companion.
By using Pitchbender events, the highest resolution (10bit) is available.
More about this topic (e.g. test of different motorfaders) after holidays.
When you compare the MBHP_MF_V2 schematic with MBHP_MF, you will notice that the motor control pins are now directly connected to the PIC.
The same can be done with the old module - just remove the two 74HC595 chips and use a 16-wire ribbon cable for direct connections between MBHP_CORE and the TC4427 based H-bridges.
You should also add the status LED, and a 470 Ohm resistor between the MF potentiometer (P1) and ground for improved voltage control.
Note that the MBHP_MF_V2 firmware hasn’t been released yet, it needs some more work until it will run perfectly. If nothing unexpected happens I will release it in ca. 2..3 weeks
I haven’t compared this with my RSAON11M9 faders yet, but I’ve the impression that the new method leads to better results, not at least because the increased PWM resolution allows more exact control over the speed so that probably *any* fader will reach the target position w/o overshoots.
The “sine” function of the MBFM tool moves all faders concurrently with slow target position changes -> this is the noise test -> this allows to optimize parameters for less noise.
Can’t say more about this topic yet - after this posting I stopped the development, and I will continue in some days.
haven´t been around here for some …eh.. years, mainly because my LC emulations are still working nearly perfectly and do what they are supposed to do (help making music?!).
Once in a while i have problems with some faders moving slowly or not completely reliable, so this new development could reanimate my former Midiboxeritis. To avoid sleepless nights thinking about it, i have a quick questions right now:
Is it necessary to use the new STM32 Core to provide the Midi I/O for the new MF Core?
Very impressive ! The pcb layout looks very tidy, even in prototype form.
It’s great that you still invest your time in this project. Apart from Tango (very expensive) and Euphonix Studio (not too sturdy looking and Mac only) controllers, there hasn’t been much innovation on the commercial side, so I guess this is even a bigger incentive to build one yourself.
Out of curiosity, may I ask what type of algorithm you use for tracking and control of the fader ?
I guess you use of some kind of regularization of the control curve, or movement / speed prediction, so the motor speed is as smooth as possible.
I know very little about automation theory (more about dsp) but as I said, I’m curious
The biggest differences compared to the previous solution:
Duty cycle has much higher resolution for more precise motor speed control
Duty cycle depends on distance between current and target position -> than closer the target position, than slower the motor
separate values for upward/downward movements, now for each motorfader individually. This is important to ensure that even after years all motors are running synchronously, because some get a bit slower, some others are still fast (the same problem which probably Alex noticed)
Following picture shows how precisely a fader can be positioned now
This is a ALPS RSAON11M9 fader at 5V.
It overshoots the target position at t=100 mS, but can be precisely repositioned at t=180 mS to exactly the middle value (512)
Such a control wasn’t possible with the old solution.
For those who prefer slow faders: just reduce the Max Duty Value
Greetings! I’ve been doing a lot of reading about the midibox project and I think I’m about ready to take some steps. I’m particularly interested in this new MF V3 board. Any further progress made as of yet?
I haven’t continued yet as this is a low-prio project for me.
My Core32 based MBLC is already stuffed with a module, communication goes through a STM32 module via USB to Logic Pro - it works perfectly.
I built a second module for testing different faders, but haven’t found the time yet to run the tests and to find + document the best calibration values.
Also a PCB layout is not available yet…
However, if anybody wants to build this on a veroboard: just do it!
The schematic is final, the firmware is released in the repository and I can send you an MIOS Studio update for calibration (or you can compile it by yourself).
Anyone know how to compile MIOS Studio on windows?
Using JUCE 1.52, VC++ Express 2010, I get this sort of fail:
1>------ Build started: Project: mios_studio, Configuration: Release Win32 ------
1> MbCvTool.cpp
1>..\..\src\gui\MbCvTool.cpp(94): warning C4244: 'argument' : conversion from 'juce::juce_wchar' to 'unsigned char', possible loss of data
1>..\..\src\gui\MbCvTool.cpp(145): error C2440: 'initializing' : cannot convert from 'juce::TableHeaderComponent' to 'juce::TableHeaderComponent *'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\..\src\gui\MbCvTool.cpp(741): warning C4244: 'argument' : conversion from 'juce::int64' to 'size_t', possible loss of data
1>..\..\src\gui\MbCvTool.cpp(742): warning C4244: 'argument' : conversion from 'juce::int64' to 'int', possible loss of data
1>..\..\src\gui\MbCvTool.cpp(751): warning C4244: 'argument' : conversion from 'juce::int64' to 'const juce::uint32', possible loss of data
1> Midio128Tool.cpp
1>..\..\src\gui\Midio128Tool.cpp(145): warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(150): warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(211): error C2440: 'initializing' : cannot convert from 'juce::TableHeaderComponent' to 'juce::TableHeaderComponent *'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\..\src\gui\Midio128Tool.cpp(412): error C2440: 'initializing' : cannot convert from 'juce::TableHeaderComponent' to 'juce::TableHeaderComponent *'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\..\src\gui\Midio128Tool.cpp(975): warning C4244: 'argument' : conversion from 'juce::int64' to 'size_t', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(976): warning C4244: 'argument' : conversion from 'juce::int64' to 'int', possible loss of data
1>..\..\src\gui\Midio128Tool.cpp(985): warning C4244: 'argument' : conversion from 'juce::int64' to 'const juce::uint32', possible loss of data
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
JUCE and the JUCE example progs build successfully
I haven’t build the latest SVN for Windows for a while (I usually only build it when TK wants to release a new version). Those errors are all in the latest additions and usually just require specific casting of the variables as GCC is a bit more tolerant than VC++
Try Juce 1.50 (as that is the recommended version). Juce seems to change prototypes between versions so it is likely that the definition for TableHeaderComponent has changed!
