Jump to content

Upcoming MBHP_MF_NG module


TK.
 Share

Recommended Posts

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)


    Following circuit is the result: http://www.ucapps.de/mbhp/mbhp_mf_ng.pdf

    • 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

    mbhp_mf_v3_proto1.jpg

    mbhp_mf_v3_proto2.jpg

    Meanwhile PCBs are available (layout created by SmashTV - thank you!!! :) )

    mbhp_mf_ng_final1.jpg

    MIOS Studio got a new configuration tool:

    mbhp_mf_v3_config.png

    Especially the calibration is much easier now, not at least because of the new motor position tracing feature:

    mbhp_mf_v3_calib.png

    Currently following modes are planned:

      [*] PitchBender Chn#1..#8

      [*] PitchBender Chn#9..#16

      [*] CC#07 Chn#1..#8

      [*] CC#07 Chn#9..#16

      [*] CC#16..#23 Chn#1

      [*] CC#24..#31 Chn#1

      [*] Faked Logic Control

      [*] Faked Logic Control Extension

      [*] Faked Mackie Control

      [*] Faked Mackie Control Extension

      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. :)

      Best Regards, Thorsten.

Link to comment
Share on other sites

  • 2 weeks later...

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

Best Regards, Thorsten.

Link to comment
Share on other sites

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.

Thereafter more details.

Best Regards, Thorsten.

Link to comment
Share on other sites

Hi Thorsten,

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?

Best regards,

Axel

Link to comment
Share on other sites

Hi Axel,

welcome back! :)

By enabling the MIDI merger it will be possible to chain MBHP_MF_V3 with a common core module.

The "Faked Logic/Mackie Control" Mode will handle the Pitch Bender Events.

So: a Core32 won't be required, you can re-use your existing hardware and just only have to replace the MBHP_MF_V1 module.

Best Regards, Thorsten.

Link to comment
Share on other sites

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 hairy.png

Cheers,

Lorcan

Link to comment
Share on other sites

Basically I'm using the same algorithm that I described under http://www.ucapps.de/mbhp_mf.html

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

mbhp_mf_v3_calib_repos.png

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 :)

mbhp_mf_v3_calib_norepos.png

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 5 weeks later...

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).

Best Regards, Thorsten.

Link to comment
Share on other sites

(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

:)

Link to comment
Share on other sites

Hi.

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++

I will try and build it tomorrow and update SVN.

Cheers

Phil

Link to comment
Share on other sites

  • 3 weeks later...
  • 1 month later...

Hello TK,

is there a netlist of the MF V3 board available? I´m planning my first midibox(es) since a few months now and would like to try a PCB layout for the new MF boards. Of course I could just use the schematic and do it from scratch but I thought it´s worth asking to save some time.

Thanks for all your efforts!

Emre

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...