41 replies to this topic

[Rics]

Ok, in these days i've checked more deeply the project, all is going fine, i've found almost all the componenents but only the BLM matrix is giving me some doubts.


Assuming the BLM MAP schematic and the BLM Module schematic:
BLM MAP
BLM Module

First:
I'm arrived to the conclusion that i'm fine with the classic single color leds.
I don't need duo led's.
I've reduced to a single macro the BLM MAP schematic in this way, original (using duo-led) and the hypothetical scheme when using the classic single led.

Duo Led


Single Led


From the second scheme, the Single Led one, i think that a 74HC595 chip can be deleted.
So in a single leds configuration the BLM module will use two 74HC595 and one 74HC165.

Another doubt is about the diode placed before the pushbutton, which type? There's a component name?

Then when using more BLM Modules chained, from the BLM Map i see that the first column of every BLM Module is linked to the last module:

(To "J4_5" I0 - To "J4_5" R0 - To "J4_5" G0)

I've not understood this passage, it is something only related to a connection between the BLM and a MIDIboxSEQ or is a basic setup needed to have the BLM working?

Edited by Rics, 27 October 2010 - 20:46.

[Rics]

Yesterday evening, after posting this two schemes i tought that the first one, the so called "duo-led", at the end can be considered also as two leds items connected, not only two leds in a single package.
So i think that i can still remain with the same original BLM Map scheme, but instead of using a duo-led packaging i will use two separated leds!
I'll try to do a schematic with the number of components that i need.

[Rics]

Almost a month and so busy that haven't found yet time to do my custom "single led blm schematic".

I'm waiting the core32 module pcb that should arrive in these days, at least i expect that arrives in this next week, hopefully.
In the meantime the other componenents for the project are arrived, knobs, sliders, pots and all the rest needed for my project.

So yesterday i went to buy a veroboard with the intention to create a basic BLM module to do a "small test before the great build" and to learn something about the "C coded app" behind the BLM connected to a Pic Core that i already had from previous projects.
(Take in mind that i'll use the Core32 for this projects, i'm using now the Pic Core just to learn something and because the Core32 board isn't arrived at my home yet.)

Here's a shot:


I've succesfully did a "make" in terminal for the blm_scalar app and then i've uploaded the .hex file to the Pic Core.
Without connecting it to any midi hardware or software app i've saw that the buttons behaviour, with their respective Single Leds, was like a toggle button:
-Press once to activate the led.
-Press once again to deactivate the led.

Ok, now i'll have to modify the BLM app and driver (For MIOS instead of MIOS32 in the meantime that the Core32 arrives to me) to have it working like a DIN+DOUT combo.

I went to this page from the MIOS8 C programming examples to understand something about the Leds control.
What i've read immediately was "We want to set/clear LEDs, which are connected to one or more DOUTX4 modules, with Note Events over MIDI Channel #1".
What i think is that i'm working over a BLM and not over a DOUT.
Isn't somewhere the same example of Led control with BLM modules like the one for DOUTX4?

I'll read the DOUTX4 example to see if i can understand something, but any hint would be appreciated!

Thanks and sorry if i wrote something confused or wrong!

PS:
I've just surfed over the Mios references (page) but haven't found nothing about BLM module functions.
Where i can find a BLM reference? Only by reading the blm docs in the svn?
Thanks! ;)

Edited by Rics, 21 November 2010 - 10:17.

[findbuddha]

From the readme in SVN for BLM_SCALAR:

As long as no MIDI data has been received after startup, the BLM is in test mode. The buttons cycle the colour of the corresponding LED: - first button press: green colour - second button press: red colour - third button press: both colours - fourth button press: all LEDs off - period

Looks like you might have to do a little coding to get it to work how you want. (DIN_BLM_NotifyToggle looks like a good starting point)

[Rics]

From the readme in SVN for BLM_SCALAR:

Looks like you might have to do a little coding to get it to work how you want. (DIN_BLM_NotifyToggle looks like a good starting point)

Thank you for the tip!
But i don't know at which files i have to put my eyes, i know that i have into the trunk folder two folders, apps and modules.
In the apps i have, under controllers, the blm_scalar app, and into modules the blm_scalar driver.

Sincerely i don't know the first thing that i've to do, yes, i have to study about DIN_BLM_NotifyToggle, but where i get infos about it?
It's all in the readme.txt and in the comments of the files?
Who calls the DIN_BLM_NotifyToggle? Where it get datas?

Any tip is appreciated, in the meantime i'll do some searches into the programmers forum to understand more basics.

Edited by Rics, 21 November 2010 - 15:19.

[findbuddha]

You want to be using the BLM_SCALAR app as a base for your own software. DIN_BLM_NotifyToggle is in app.c, and is called whenever a pin changes on the BLM. TK's code is very well commented!

(I'm seeing all this in the MIOS32 section, it's a little different in the MIOS8 section but you should be able to work it out)

[Rics]

I'm back!
In these last days i had to fix a problem with my core32 module and a character LCD, then i've some problems with my small BLM module that gave jitter because i was too smart to leave opened pins on the BLM IC's!
So i've decided to build a complete BLM module to do a complete hardware test. (As Thorsten said, "i will never do again", and i quote this for a single BLM module! so much wires! )

Ok, i've builded it, and seems that works fine, also if i've not did a complete test.
From the original module the difference is that i've not used the duo-leds, but the classic single color leds.

Pictures will explain better.

Please get schematic references here:
http://www.ucapps.de..._blm_scalar.pdf
http://www.ucapps.de...bhp_blm_map.pdf

-Here's the module builded on two veroboards

On the left side the leds are connected to the R (Red) jumpers on J4 and on the right side are connected to the G (Green) jumpers on J3.
Buttons are connected to the I (Input) jumpers on J4 and all the C (Catodes) jumpers on J3.

When i connect the core32 to the USB port i get a flash on/off state only from the left leds (R.).

Now that the module is powered and no midi connection with softwares is done i try to push the buttons to see the leds behaviour:

What i get is that the left leds (R.) needs to be pushed two times to be in on-mode and pushed two times to get back in the off-mode.
Instead, the right leds (G.) go in on-mode or off-mode with a single push of the buttons.

Another thing that i've noticed is a "pre-on" state of the left led (R.) if i do an "on-off cycle" (two times push) on a right led (G.).

The corrispective first row eighth led on the left veroboard gets this "pre-on", seems like a small power comes to it.

Now that i'm using these single color leds i'm wondering if i don't have to use only one 74hc595 for the leds and connect them all or to the J3 or the J4.
To be clear, all to the Red line or all to the Green line referring to the BLM map scheme ignoring one line between red and green line, without using the last 74hc595 IC, IC4.

PS
I've forgot to mention that when then i open traktor and i map the buttons and the leds to the midi mapping setting i get the left buttons and leds working correctly, i don't need to push two times the button to have a midi message output and the leds react immediately on the output message sent by traktor.
At the moment i've tried only with the first four buttons from the left veroboard placed on the first row.
Later i will try to map all the buttons and the leds to do a complete test.

So seems that all the problems reported in the upperside are relative to BLM module when not connected via midi to other hardware or software (midi via usb).

Edited by Rics, 11 December 2010 - 10:22.

[findbuddha]

What i get is that the left leds (R.) needs to be pushed two times to be in on-mode and pushed two times to get back in the off-mode.
Instead, the right leds (G.) go in on-mode or off-mode with a single push of the buttons.

Another thing that i've noticed is a "pre-on" state of the left led (R.) if i do an "on-off cycle" (two times push) on a right led (G.).

That would be the expected behaviour, as per the readme. As you're using single colour LEDs, you won't see (for example) the red LEDs turn green (first button press) or orange (third button press).

[Rics]

That would be the expected behaviour, as per the readme. As you're using single colour LEDs, you won't see (for example) the red LEDs turn green (first button press) or orange (third button press).

Yes, but i'm getting this behaviour only for the left board, not for the right one!
On the left one i've to toggle, on the right one i need only one press to get led on and one press to get the led off...

[findbuddha]

For the right hand (green LEDs), you'll get the first button press (green), you won't get the second button press (red), you'll get half of the third button press (should be orange but you'll get green as it's just a single LED)

[Rics]

For the right hand (green LEDs), you'll get the first button press (green), you won't get the second button press (red), you'll get half of the third button press (should be orange but you'll get green as it's just a single LED)

Ah ok, that's clear now!
I'll check the code to adapt it for the single color leds in the next days. I hope to have success with not so much questions here in the forum.

[Rics]

Well, i've not adapted the code, but to have an immediate check i've switched to a single 74HC595 and switched the left board red line to the other board green line as reported on the BLM schematic.
Now both the beards, left and right, works in the same way.
The code adapt will be done later as adviced from Thorsten:

For your usecase, just remove the code inside DIN_BLM_NotifyToggle() and APP_MIDI_NotifyPackage(), and add your own button/led handler

What i don't get yet is that "pre-on" state that i've reported with the third picture in my previous post.
Seems that a small amount of current comes to corrispective leds, i mean:

**=full led on
* = small power on the led (see third picture on my previous post)

First row of the 2 boards (Left and Right, all connected to the Green control line with 74HC595):

L1 L2 L3 L4 L5 L6 L7 L8 R1 R2 R3 R4 R5 R6 R7 R8
**____________________*_______________________

If i switch-on another Led, eg L6, R6 will have that small amount of power.
And so on for the other leds and belower leds rows.

That's all at the moment about leds, i hope that's something related to the code adapt that i've to do.

Then i've tried to connect in chain, after the BLM module, a DIN module with an Encoder.
I've did as Thorsten said in the first reply of this thread:

adding software handlers for encoders and pots isn't a big task, this would just be a 1:1 integration of existing programming examples:
http://www.ucapps.de/mios8_c.html

Obviusly with core32 i'm going to see the examples in http://www.ucapps.de/mios32_c.html
I've tried to insert into the BLM firmware both the examples #014 and #015 (one per time obviusly) but what i get, when i turn the encoders, are different midi note messages on different midi channels.
That's a small list of the output in mios_studio when i turn the encoder one time to the left and one time to the right:

[3354.074] 94 0e 7f
[3354.084] 95 0e 7f
[3354.094] 96 0e 7f
[3354.104] 97 0e 7f
[3354.114] 94 0e 00
[3354.124] 95 0e 00
[3354.134] 96 0e 00
[3354.145] 94 06 7f
[3354.155] 95 06 7f
[3354.165] 96 06 7f
[3354.176] 97 0e 00
[3354.187] 95 06 00
[3354.198] 96 0e 7f
[3354.208] 97 0e 7f
[3354.221] 96 06 00
[3354.232] 97 0e 00
[3354.242] 94 0e 7f
[3354.252] 95 0e 7f
[3354.262] 96 0e 00
[3354.273] 94 06 00
[3354.284] 95 0e 00
[3354.298] 94 0e 00
[3354.309] 96 06 7f
[3354.319] 97 06 7f
[3354.329] 94 06 7f
[3354.339] 95 06 7f
[3354.350] 96 0e 7f
[3354.360] 97 0e 7f
[3354.370] 94 0e 7f
[3354.380] 95 0e 7f
[3355.269] 96 06 00
[3355.279] 97 06 00
[3355.289] 94 06 00
[3355.299] 95 06 00
[3355.310] 96 0e 00
[3355.320] 97 0e 00
[3355.330] 94 0e 00
[3355.340] 95 0e 00
[3355.366] 96 0e 7f
[3355.376] 97 0e 7f
[3355.386] 94 0e 7f
[3355.396] 95 0e 7f
[3355.406] 96 0e 00
[3355.416] 97 0e 00
[3355.426] 94 0e 00
[3355.436] 95 0e 00
[3355.446] 96 0e 7f
[3355.456] 97 0e 7f
[3355.466] 94 0e 7f
[3355.476] 95 0e 7f
[3355.487] 97 06 7f
[3355.498] 94 0e 00
[3355.508] 95 0e 00
[3355.518] 96 0e 00
[3355.528] 97 0e 00
[3355.543] 97 06 00

As you can see there are midi ch.5-ch.6-ch.7-ch.8, notes are always 0e and 06 and the on off messages 0 and 127.

The encoders that i'm using are the Bourns PEC11-4015F-S0024 with switch, i've connected as reported in the wiki page, A C B pins, A & B to the Digital inputs and C, the common to 5v with the switch pins connected one to the Common and one to another Digital input.
I've tried also to disconnect the switch and to put to the ground the metal shaft of the encoder, but the midi output behaviour still remain the same as reported above.

I'll try other tests today but any hint will be appreciated as ever!
Thank you!

Edited by Rics, 14 December 2010 - 09:45.

[Rics]

I've investigated a bit more into the encoders area so i've decide to disconnect at the moment the BLM module and connect directly to the core32 a DIN module with one encoder connected to the first Shift register.
Used Pins are D0 D1 and D2 for the button switch.

It works perfect. Midi CC messages works flawlessy.
Ok, now i'm going to copy the code parts from Tutorial#14 and paste into the BLM_Scalar app.c file.
I reconnect the BLM module, then chained a DIN module.
After i compile the BLM_Scalar, got the .hex, uploaded to the core and now the encoder sends note values, no more CC like before. (See the previous post code snip)

The modified BLM_scalar is the following:
(i'll include here only the modified parts)

/////////////////////////////////////////////////////////////////////////////
// Local definitions
/////////////////////////////////////////////////////////////////////////////

#define PRIORITY_TASK_BLM_CHECK         ( tskIDLE_PRIORITY + 2 )
#define NUM_ENCODERS 64

/////////////////////////////////////////////////////////////////////////////
// This hook is called after startup to initialize the application
/////////////////////////////////////////////////////////////////////////////
void APP_Init(void)
{
  sysexRequestTimer = 0;
  midiDataReceived = 0;
  testmode = 1;

  // initialize all LEDs
  MIOS32_BOARD_LED_Init(0xffffffff);
  
  // initialize rotary encoders of the same type (DETENTED2)
  int enc;
  for(enc=0; enc<NUM_ENCODERS; ++enc) {
    u8 pin_sr = enc >> 2; // each DIN SR has 4 encoders connected
    u8 pin_pos = (enc & 0x3) << 1; // Pin position of first ENC channel: either 0, 2, 4 or 6

    mios32_enc_config_t enc_config = MIOS32_ENC_ConfigGet(enc);
    enc_config.cfg.type = NON_DETENTED; // see mios32_enc.h for available types
    enc_config.cfg.sr = pin_sr;
    enc_config.cfg.pos = pin_pos;
    enc_config.cfg.speed = NORMAL;
    enc_config.cfg.speed_par = 0;
    MIOS32_ENC_ConfigSet(enc, enc_config);
  }

  // initialize BLM_SCALAR driver
  BLM_SCALAR_Init(0);

  // initialize SysEx parser
  SYSEX_Init(0);

  // start BLM check task
  xTaskCreate(TASK_BLM_Check, (signed portCHAR *)"BLM_Check", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_BLM_CHECK, NULL);

}

/////////////////////////////////////////////////////////////////////////////
// This hook is called when an encoder has been moved
// incrementer is positive when encoder has been turned clockwise, else
// it is negative
/////////////////////////////////////////////////////////////////////////////
void APP_ENC_NotifyChange(u32 encoder, s32 incrementer)
{
  // toggle Status LED on each AIN value change
  MIOS32_BOARD_LED_Set(1, ~MIOS32_BOARD_LED_Get());

  // determine relative value: 64 +/- <incrementer>
  int value = 64 + incrementer;

  // ensure that value is in range of 0..127
  if( value < 0 )
    value = 0;
  else if( value > 127 )
    value = 127;

  // send event
  MIOS32_MIDI_SendCC(DEFAULT, Chn1, 0x10 + encoder, value);
}

The original BLM is here

Without the BLM Module (DIN directly connected to the core32) the encoder is working well and sends CC values using the code from C Tutorial #014. (code that then i've pasted into the BLM app.c as you can see above in the code snip).

Edited by Rics, 14 December 2010 - 12:23.

[Rics]

Ok, i went for exclusion, i know that's the right method as i'm not laerning nothing this way, but at least i've found the origin of the problem so i can investigate on it!

I've removed the following code from the" void APP_Init(void)" section:

// start BLM check task
 xTaskCreate(TASK_BLM_Check, (signed portCHAR *)"BLM_Check", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_BLM_CHECK, NULL);

Deleting this i get the encoder sending CC values when a DIN module is chained after the BLM module.
If i restore this code the encoder will send Note values.

What do this section of code to change CC values to Notes for DIN Encoders?

Edited by Rics, 14 December 2010 - 12:46.

[Rics]

Mhhm, things going interesting:

Now i've found that if i delete that BLM check task all the buttons on the BLM module will send midi CC events, no more midi Notes events.
So i've restored that code, uploaded and now i've the buttons sending midi Notes events, and also the encoder do not sends anymore CC events, but Notes events.

Accidentally i've leaved the midi Ch.1 CC024 assign in the traktor controller manager for a parameter.
So now i've the encoder sending midi Notes if i do a new midi learn and i can see that are midi notes also on the mios_studio monitor.
But the old midi Ch.1 CC024 mapped to a traktor parameter receive also messages from the encoder.

In two words:
I've the encoder that is sending midi Notes values, checked by midi learn in traktor and in the mios_studio midi events monitor.
But if i map a traktor parameter with Ch.1 CC024 this will receive data from the encoder!

I don't understand this...

[Rics]

Ok, back from the adventures!
I finished the controller, i've used in gig and (for my label) we did a totally "unprofessional" video to show my work.
Probably we have to change the subtititles as my friend, that did the video, got some mismatch into the translation about technical stuffs.

It was really exciting getting done this project, i was almost going to be crazy about getting done the PCB wirings...anyway, that's the video about the controller, credits for ucapps, community and all the people that helped me at the end.



Picture!



Of course it's not finished, i've problems with some leds because the pcb holes weren't done really well, anyway the BLM works great.
Last thing that i'm working on is the jitter that i've on the AIN, not really annoying when using the controller, but annoying when using midi learn functions.
I'm going to work over the deadband settings to see if i can manage it, otherwise i'll try to switch to pic-core from stm32-core to see if is something related to the deadband.

Edited by Rics, 11 December 2011 - 10:36.

[Rics]

I've solved for the AIN jitter!
I did a mistake into the pins connections on J5A-J5B-J5C and i've correctly set the deadband on the application.

Now works flawlessy without jitter!

The bad news is that a line of buttons don't work probably by the pcb card, i've found that if i tighten the screw near that line of buttons they could work in some cases and not work in other...i've not found a solution yet about this.

Anyway at the moment i'm happy to have solved the jitter problem, the pcb fix will come in the next spare time that i'll have!

[ilmenator]

The bad news is that a line of buttons don't work probably by the pcb card, i've found that if i tighten the screw near that line of buttons they could work in some cases and not work in other...i've not found a solution yet about this.

This sounds like you should re-solder all solder joints on that PCB - heat up every single one, you may have broken some mechanically when fitting the board to the frontpanel.

Edit: just saw that you have one single PCB underneath that frontpanel - so it's a big task to re-solder every joint... Of course, look at those that are related to buttons that don't work!

Edited by ilmenator, 18 January 2012 - 14:26.

[ranger930]

Hi Rics,

nice job !

i would like to see more detailed pictures.
is your controller really bus powered with the all led's?

how was your frontpanel printed ?

kindly regards

ranger930

[Rics]

This sounds like you should re-solder all solder joints on that PCB - heat up every single one, you may have broken some mechanically when fitting the board to the frontpanel.

Edit: just saw that you have one single PCB underneath that frontpanel - so it's a big task to re-solder every joint... Of course, look at those that are related to buttons that don't work!

Well, the main problem that i had is that who printed the 2-side pcb for me didn't a really good job, i had all the leds holes that were smaller than the leds pins, and also the buttons holes were too smaller.
The pcb was pricey and my uni final exam too near..so i tried the repair and try way!
This was the first time that i sent pcb file to be printed from a 3rd party service, so probably i did a mistake not evaluating some tolerance in holes size, but at the end i had to redrill all the leds holes to make leds to fit into their places and then i had also to reconnect and manually check all the vias that passed through the led pins to be sure that connections worked.
Of course when i'll have time i'll try to fix this annoying problem, it's a pity that this beast have this defeat. :(

Hi Rics,

nice job !

i would like to see more detailed pictures.
is your controller really bus powered with the all led's?

how was your frontpanel printed ?

kindly regards

ranger930

Hi, yes, it's bus powered, this thanks to the T.Klose BLM (button led matrix) module.
If i used in cascade multiple DIN and DOUT needed for that amount of leds, i had no possibilities to use only a usb connection, a power unit supply were needed because of the current consumption.
But the BLM module makes possible to save current, so i used the principle and i've adapted the scheme to my needs!

The frontpanel is a 1,5mm aluminium sheet, drilled with an industrial CNC (computer numeric control) machine from friends at their factory.
They did me as a favor and as a challenge for themselves because usually they work on smaller aluminium objects.
Both technically & cost effectively is better to do this panel in a laser cut environment with an amount of minimum 10 pieces, but for one piece, in a laser cut enviroment is too pricey, and with cnc my friends make me to pay only the used current because of their experimental process! I was lucky on this!

Almost all the pictures that i've did are placed in the previous posted video, if you aim to something more specific let me know, i will see to make a picture of it. ;)

Edited by Rics, 22 January 2012 - 10:07.