RGB DOUT confusion

[Duggle]

I've had my 8x8 array of RGB LEDs working perfectly for some time now.

The DOUT SR setup being (predictably):

DOUT_MATRIX n=1  rows=8  inverted=1  sr_dout_sel1=1  sr_dout_r1=2  sr_dout_g1=3 sr_dout_b1=4   led_emu_id_offset=1001

 

The array uses the 1st 4 SR's in the chain.  The id's go from 1001 (row1,col1) to 1064 (row8, col8)

 

Now, as I develop the application I realise I have 3 spare DOUT SR's that I could use to change the array into 4 rows of 16.

The expected benefits are:

• more colours (hues)
• less flicker (1/4 duty rather than 1/8)
• brighter output

So I break the columns in the middle of the array (easy to do,  because I constructed the rows as modules, with a plug connection down the columns). Then I wire the new SR's to the disconnected columns.

 

DOUT_MATRIX n=1  rows=4  inverted=1  sr_dout_sel1=1  sr_dout_r1=2 sr_dout_r2=5  sr_dout_g1=3 sr_dout_g2=6 sr_dout_b1=4 sr_dout_b2=7  led_emu_id_offset=1001

 

This is what seems to work right. The first point of confusion is that sr_dout_r2=5 is actually SR#6 in the DOUT chain as I use #5 to drive 8 standard LEDs.

What is the method of counting SR's here?

 

As for the row ordering, I have the row drivers (inverted) connected the same as the 8x8 array (that is unchanged).

I did this because the manual says:

 

rows=4: 4 selection pulses are output by the DOUT register specified with sr_dout_sel1. The pulses are available twice: at D7:D4 and D3:D0.

 

 

I find the ordering of the rows is thus:

 

addressed row  LED row lit
1              1
2              5
3              2
4              6
5              3
6              7
7              4
8              8

 

 

I admit I'm confused.

Is there a simple way to unscramble the rows in the way I declared the shift registers?

I don't intend to rewire anything. If I have to, I'll create a lookup table in the macro processor to provide for LEDs in a linear sequence. But I'd rather not have to if there is a way of declaring them that avoids this.

 

[TK.]

This is what seems to work right. The first point of confusion is that sr_dout_r2=5 is actually SR#6 in the DOUT chain as I use #5 to drive 8 standard LEDs.

What is the method of counting SR's here?

 

I'm surprised about the difference, because it doesn't make sense (from my point of view).

The SRs are linearly addressed. The 5th DOUT in the chain should be sr_dout_r2=5

With the lre8x2x4.ngc it's proven that the numbering works (and it should be independent from the number of rows): http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Flre8x2x4.ngc

 

Are you able to isolate this issue a bit more?

 

 

 

Is there a simple way to unscramble the rows in the way I declared the shift registers?

 

no

 

The implementation of scrambling options are error prone, and they especially won't be tested with each new MBNG version.

Therefore I don't like such options.

 

 

 

Is there a simple way to unscramble the rows in the way I declared the shift registers?I don't intend to rewire anything. If I have to, I'll create a lookup table in the macro processor to provide for LEDs in a linear sequence. But I'd rather not have to if there is a way of declaring them that avoids this.

 

I guess that currently you don't use EVENT_LED statements, but address the LEDs with "virtual events" based on their emulated id, right?

You could try to do the mapping by defining EVENT_LED events for each LED function, and map the ids to different hw_ids

 

I've no oversight if this trick will really work under all circumstances, but if it works, you are done.

If not, it's less likely that I will enhance the firmware to solve such a mapping issue (as mentioned above)

 

Best Regards, Thorsten.

[Duggle]

Are you able to isolate this issue a bit more?

When I had it with sr_dout_r2=6,sr_dout_g2=7,sr_dout_b2=8 I was missing blue. I'll try it, or similar, again and post back if I notice anything different.

But now all colours show correctly except the row thing.

I'm not requesting a firmware change, just to find out if I've missed something that's easy to fix. As you understand, too much flexibility can be confusing!

A lookup table is easy for me.

I've done this already when converting the the lre8x2 to be addressed as 2 rows of 8, rather than 8 cols of 2, if you follow. That took a bit to get the Ledrings in the right order, but now it's done I can forget about it completely.

[Duggle]

Well, it's working perfectly now.

I had already set up lookup tables that provide a standard way of addressing UI elements e.g. R1C5 means 1st row 5th col, etc.

So I just edited this table for the RGB LEDs!

 

As for the SR counting, (real) SR#5 is driving 8 standard LEDs.  The control panel's 8 buttons are using fwd_id=LED:33 to  fwd_id=LED:40. (I'm still unsure of why 33..40 but it works.)

 

Anyhow maybe there is a glitch in the matrix SR counting.

 

Also the objectives of using the extra 3 SR's on the RGB matrix has been realised: They do look even better than before (which was already very good, btw).

 

[Marxon]

Hi again Duggle,

now i have another question :smile:

Can i wire the matrix also this way?

[Duggle]

You would have 4 row drivers (1 shift register, 4 pins) and 16 r,g,b columns (6 shift registers), right?  

This is what I effectively have on my big NG now. It gives brighter, more colour resolution, and "smoother" appearance than the 8x8 that I set up initially (8x8 worked very well, though).

[Marxon]

OK Thank you!