LED module pin assignment

The Dot Matrix Display (DMD) is a 32x16 array of high-brightness LEDs for visually striking effects. [Product Page]
Post Reply
Joined:Wed Oct 09, 2013 3:03 pm
LED module pin assignment

Post by Shinobi » Wed Oct 09, 2013 3:06 pm

Hello everyone,

i was hoping you could provide me with a pin assignment layout, so that we can control this LED module with our Arduino board.

http://www.freetronics.com/collections/ ... lVvnyRJlXB

Thank you very much in advance!

User avatar
Joined:Sat Jan 14, 2012 2:44 pm

Re: LED module pin assignment

Post by stryker » Wed Oct 09, 2013 9:29 pm


This schematic should provide what you're after.

Cheers ! Geoff


Re: LED module pin assignment

Post by TheRevva » Wed Oct 09, 2013 10:18 pm

Shinobi wrote:Hello everyone,

i was hoping you could provide me with a pin assignment layout, so that we can control this LED module with our Arduino board.

http://www.freetronics.com/collections/ ... lVvnyRJlXB

Thank you very much in advance!
Hi Shinobi,
Take a closer look on the link you included. Down at the bottom you'll see "DMDCON DMD Connector board Schematic (PDF) ". This pdf file contains the pinout of the DMD input connector as well as the corresponding pins on the Arduino that they connect to.
Only 7 of the 16 pins on the DMD are actually used:
GND - Hopefully obvious
nOE - Enable / Disable ALL the LEDs on the DMD
A - A&B pins select which 1/4 of the DMD is selected (see below)
B - A&B pins select which 1/4 of the DMD is selected (see below)
CLK - Used to clock each pixel into the DMD shift registers
SCLK - Latches the current content of the DMD shift registers
R - The raw pixel data stream (NB: The 'R' stands for RED. You might notice an unused 'G' pin which is for Green on a HUB12 connector)

Note on A and B pins:
Only 1/4 of the LEDs (128) are enabled at any given time. The controller should rapidly cycle through each 1/4 so fast that the human eye sees ALL the LEDs. This is called multiplexing. The A and B pins select which 1/4 of the panel is enabled. Rows 1+5+9+13, Rows 2+6+10+14, Rows 3+7+11+15 or Rows 4+8+12+16

Other pins on a HUB12 connector:
As mentioned above, the 'G' pin is intended for Green LEDs. (Panels exist with BOTH red _and_ green LEDs). I strongly suspect that ALL the Jaycar single colour DMDs only use the R(ed) pin no matter what colour LEDs are loaded onto them!
There is also a 'C' and a 'D' input pin. These are for different panels (NOT the Jaycar DMD) that use 1/8 scan or 1/16 scan.

While the DMD I grabbed comes with a small connector PCB to connect your DMD to an Arduino, it's designed to work with the 'smaller' Arduinos. The larger Arduinos (eg: Mega2560) don't output the SPI bus signals on the same Arduino pins and thus the standard DMD Arduino library code will NOT work unless you jumper the wires to the correct Arduino pins.
The other option is to rewrite the corresponding Arduino library to 'bit-bang' the equivalent pins on a Mega to 'emulate' an SPI bus. (I'm intending writing this code over the weekend).

I'm designing an simple Arduino Mega 'shield' that has eight largely independent HuB12 connectors on it. (My 'project' is to drive a large screen of up to 64 panels arranged as 8x8 panels - yep, that's 32,768 LEDs!!!). The shield only contains two 'active' devices (both 74LVC245). These two devices simply 'buffer' the raw pins. (They also allow conversion of 3.3V logic signals to 5V logic signals which allows use of the ARM based Arduinos which have far more CPU grunt).

And finally, some 'panel trivia'...
I suspect most will people have seen those HUGE video panels at sports venues. The Jaycar DMD is a very close relative to those panels. The differences are that the video panels have three (Red/Green/Blue) or sometimes even four (Red/Green/Blue/Cyan) LEDs at every pixel location. Generally speaking, those panels are 1/2 the size of a Jaycar DMD (160mmx160mm instead of 320mm*160mm) and thus only contain 256 unique pixels. They also tend to use a HUB75 interface - same 16 pin connector but with different signals on different pins!


Joined:Wed Oct 09, 2013 3:03 pm

Re: LED module pin assignment

Post by Shinobi » Thu Oct 10, 2013 9:48 am

thank you for the quick and very useful reply! in our project, we want to make a big LED display with 4x4 of these modules (128x64px).

do you have any suggestions, how we can realize that without making too many trial and errors? what kind of microcontroller board would you suggest? we were thinking about an ardunio. is the arduino one powerful enough?


Re: LED module pin assignment

Post by TheRevva » Thu Oct 10, 2013 11:26 pm

Shinobi wrote:thank you for the quick and very useful reply! in our project, we want to make a big LED display with 4x4 of these modules (128x64px).

do you have any suggestions, how we can realize that without making too many trial and errors? what kind of microcontroller board would you suggest? we were thinking about an ardunio. is the arduino one powerful enough?
HUGE warning... This is going to be a L-O-N-G post. Go grab a cup of something now... (Make it a strong one... LOL)

It's difficult to state categorically whether an Arduino is 'powerful' enough to do what you want as the answer depends upon variables that you haven't included in your post.

Technically, it IS possible to daisy chain quite a large number of DMD panels and send data to ALL of them with an Arduino. Something you haven't mentioned though is WHICH Arduino you're considering using. You need to keep in mind that there are many different variants of Arduino and each has it's own unique constraints.

So let's start by considering some basics...
DMD Panels are not 'static' displays. They can only 'statically' display 1/4 of their pixels at any given instant. Therefore, the controller (Arduino) needs to continually refresh each and every DMD panel all the time. If the display isn't refreshed often enough, the panels will appear to 'flicker'. In all the DMD examples, 1/4 of the display is 'refreshed' on every TimerOne tick which occurs every 5000 microseconds (5 milliseconds). Since it requires four successive refreshes to refresh the entire panel, this means a full refresh occurs every 5mS * 4 = 20mS. In other words, the panels are fully refreshed at a rate of 50Hz.
Let's now compare a DMD panel with an old analog television set...
With a TV, each 'field' is sent at either 50Hz or 60Hz (depending upon which country you're in). While the DMD panel is a 1/4 scan device (every fourth row of pixels is sent with each update), the old TV is a 1/2 scan device (every second row is sent with each update). Therefore, the REAL refresh rate on a TV is either 25Hz or 30Hz (country dependent) since only 1/2 of the full frame is sent at a time. A big difference between a DMD and a TV is that the TV screen uses 'phosphor' which has a certain amount of 'persistence'. When the phosphor is 'turned off', it doesn't immediately stop emitting light... It gradually dims down over a short period. With the LEDs on a DMD, they immediately turn off when they are not being driven. (OK, that's probably not 100% accurate, but the true 'persistence' of an LED is several orders of magnitude less than the phosphor on a CRT. Even the PCB tracks to each LED act as tiny 'storage capacitors' that will delay the actual turn off by a femto second or two... LOL)
Anyway, getting back to the point... Let's simply assume that we must COMPLETELY refresh each and every DMD panel at a minimum rate of 50Hz to avoid flicker... (It's quite a 'reasonable' assumption... Just trust me on that!!!)
In your case, you have 16 DMD panels (arranged 4 x 4) each containing 512 LEDs. That's a total of 8192 LEDs that must be refreshed at our 50Hz minimum refresh rate. If all 16 panels are 'daisy chained', this will require all 8192 pixels are sent out on a single data pin which tells us that our minimum 'average clock frequency' must be 8192 * 50 Hz = 409.6kHz.
In the default DMD library, the refresh clock is set at 125kHz. (Look inside DMD.cpp for the line containing SPI_CLOCK_DIV128. While the comment to the right states a 8MHz frequency, it also states a 'divide by 2' whereas the REAL divisor chosen is 128 which makes it 16Mhz / 128 = 125kHz!!!). There is nothing to stop you using a much smaller SPI clock divisor to increase the clock frequency (providing you keep all your data cables SHORT and you don't mind creating a whole bunch more RFI!). For example, if you were to use SPI_CLOCK_DIV16, you'd end up with a 1MHz pixel clock (assuming your Arduino is using a standard 16Mhz clock). Since your 4 x 4 display needs a 409.6kHz clock to achieve a 50Hz refresh, then 1MHz clock implies that you'll still have just over 50% of your CPU 'free' to do other tasks. (For example, doing any 'processing' to decide what is actually going to be displayed!)
OK, time for next step...
With 16 panels you will need to have a screen buffer large enough to hold all the pixels in the Arduino memory. (Looking at the library code, this is the bDMDScreenRAM byte array). This equates to 16 * 512 bits = 8192 bits or 1024 bytes. I don't know WHICH Arduino you're considering using. Some have more RAM than others. My Mega2560 beasts each have 8kB of RAM so this would leave 7kB free for all the other aspects. By comparison, an Arduino UNO only has 2kB of RAM so you'd be left with only 1kB available. It's up to YOU to decide how much you'd need for 'other stuff'!!! An issue that you might need to consider is that the current library code is totally reliant on using the SPI bus. On the lower end Arduinos, the SPI bus is on outputs D10 thru D13 but on my MEGA2560 Arduino boards it's on D50 thru D53! If I tried to use the DMD library code without connecting the wires to the right places, it simply would not work!!!

Anyway, I hope that helps a bit to answer your questions... (Perhaps you're now more confused than ever? I hope not!)

The remainder of this post details an entirely different path that I am looking into for my project. It's up to you whether you think this is 'applicable'...

In my project, I'll have a somewhat larger display - initially 8(H) x6(V) panels (yep, 48 of them, but even that might increase) and there will be TWO completely independent displays thus giving 96 panels!!!. The 2 * DMD panels I've grabbed from Jaycar are intended only as a 'proof of concept'. They'll not be part of the final product. The two reasons for that are:
[Edit: I obviously cannot count!!! I MEANT four of course!!!]
1: The Jaycar price is a orders of magnitude above the price I can directly import units from China
2: The Jaycar DMDs are definitely NOT suitable for installation in a fairly humid environment.
3: The 'cheap chinese' panels I am looking at have all the LEDs 'potted' in a silicon compound
4: The 'cheap chinese' panels I am looking at have a far better mounting arrangement
I don't want to undermine the fine efforts of Jaycar by informing people whom I intend importing panels from (although I'd seriously doubt many others would be considering purchasing 100 odd panels from Jaycar which is one reason why I can import them for a great price... LOL)

The next aspect is that I definitely will NOT be 'daisy chaining' all 48 panels of each display together in a single string! (Keep in mind that equates to 24576 LEDs!!!). In order to keep the refresh rate 50Hz, that would require a MINIMUM pixel clock of 1.228800MHz!
Instead, I'll be grouping the panels into 6 'strings' of 8 panels each. In other words, I will be needing several 'pixel streams' (i.e. the 'R' pin) each carrying 1/6th of the overall pixel traffic! (Actually, I am allowing for 8 independent pixel streams, but I am only going to be using 6 of them to begin with).
This raises a small issue... The underlying Arduino only has a SINGLE SPI bus that I am aware of and I'm basically needing at least 6 of them (and allowing for up to 8)! I'm achieving this by effectively implementing the SPI bus requirements in software instead of hardware. All the 'control' signals (SCLK, CLK, A, B, and nOE are 'common' to all the strings, but each string has its own unique 'R' pin).
I've quickly thrown together a PCB design for a (Arduino MEGA 2560 style) shield that supports 8 HUB12 outputs. (If anyone is interested, I might throw the eagle files online).
Since there's a good possibility that I might want to have a substantially faster refresh rate in future (to allow for individual pixel PWM brightness control), I wanted the shield to be usable on both a MEGA 2560 style Arduino as well as an the Arduino Due style. The only significant difference being that the Due uses the ARM CPU which is significantly faster, has more Flash / RAM etc. The primary concern was that the Due is a 3.3V Arduino while the Mega 2560 is a 5V Arduino. Therefore, the shield contains a pair of 74LVC4245 chips that act both as buffer amplifiers as well as 3.3V -> 5V level translators if the 'brain' happens to be a Due!
(I've intentionally selected the biggest 'footprint' for these 2 chips with the largest 'pin pitch' just in case someone wants to hand solder these two SMD parts). Furthermore, if anyone is CERTAIN that the 5 volt Mega2560 style Arduino will do, they can install the cheaper 74LVC245 onto the pads leaving out the 2 pads on each end of each chip.

OK, that's (more than?) enough from me...
Anyone who has made it down this far deserves a medal (and / or a frontal lobotomy!)

Good luck to ya Shinobi!

User avatar
Joined:Sat Jan 14, 2012 2:44 pm

Re: LED module pin assignment

Post by stryker » Fri Oct 11, 2013 3:48 am

Very nice explanation. Thanks again TheRevva. I've modded the library to use the clock divider of 16 for our 3x2 pannel array and the code compiled and ran here without the display, indicating the previous race condition has been avoided with the faster SPI clock. When we tried it on the proof-of-concept display (located in Florida, a little distant from me) the feedback is only 2 displays were showing anything but while the flicker has gone, the displays are corrupted and not showing anything recognisable.

I think we'll need to reduce our signal line length and try again based on what you've said. Our display is presently over a metre from the first DMD as the ATmega328 and all supporting circuitry is in the hand-held controller box. If the cable length is an issue we may need to have one ATMega on the DMD display itself to keep the SPI length down, and one in the controller to work the LCD, keypad and buttons; and run pure serial (or wireless) between them such that the task is split to one for UI and one for the DMD array.

Thanks for fleshing out the concepts here. Cheers ! Geoff


Re: LED module pin assignment

Post by TheRevva » Fri Oct 11, 2013 5:49 am

EXTREMELY interesting observation there stryker!!!
What your Florida results are telling you is that the DMD is not able to cope with a 1MHz (i.e. divide by 16) pixel clock!!!
Looking at the raw devices I am seeing on the two panels in front of me, I'm mildly surprised!
Here's a quick DMD BoM summary (per DMD panel):
A bunch of decoupling capacitors (1 per chip)
1 * 74HC245D (primarily for signal buffering)
16 * 74HC595D (shift registers / latches thus giving you 128 outputs)
1 * 74HC04 (Inverter)
1 * 74HC138D (1 of 8 decoder - I assume it's only 1/2 utilised as a 1 of 4 decoder)
4 * 4953 (dual fets to drive the _other_ side of the LEDs)
2 * 4-way 300ohm resistor packs (I assume these are the LED current limiters)
1 * 4-way 4k7 resistor pack (uncertain, but definitely used in the input signal processing arena)
1 * 4-way 10k resistor pack (pull up is my guess on the '245 dir pin?)
ALL of those chips (74HC series) can easily cope with 1MHz (in fact they should even be able to handle 20MHz without breaking much of a sweat!)

With a 1 meter cable, you'll definitely get some pretty horrible signal degradation. (I would LOVE to see a 'scope trace...). However, I didn't expect it to be bad enough to cease functioning!
You ARE still using ribbon cable between the Arduino and the DMD? (The signals on the ribbon cable are carefully arranged such that there is a GND conductor between MOST signals which will help tremendously to alleviate crosstalk issues! The only exception is the 'nOE' pin which is right next to the 'A' pin on the ribbon. However, the effective frequency on these pins would be fairly low until you start doing PWM based brightness adjustments using the nOE pin)

You do, of course, have another option you could use...
Instead of daisy-chaining all the DMD panels you could run them in parallel. However, this would mean using a 'bit-banged' bus since the Arduino only has a single SPI bus available.
That way, you'd be able to keep your pixel clock far slower which would dramatically help the signal integrity over comparatively long cabling.
Here's some caveats for you to consider:
1: Bit-banging an SPI clone DOES impose additional CPU overhead, but if you select your pins carefully (specifically, the 'R' pins) such that they're all on two native ATMega ports, you can send 8 'red' bits with a single CPU instruction and the remaining clock / latch / nOE / A / B pins with another single CPU instruction. (NB: This involves MAJOR rewrites to the DMD library - Something I will be tackling this weekend!)
2: Since you would be _sharing_ the clock / latch / nOE / A / B pins among ALL DMDs, you would have to 'buffer' those signals somewhat. (Which is why I've designed a 'shield' specially for the purpose. I aim to be sending off the gerbers for a batch of 10 PCBs to be made this weekend. I only need 6 of them. (Two immediately, two more soon after, and two for 'spares'). I suspect I'll not get my hands on them until November!!!

Taking my 'mental reverse engineering' of the DMD panel a little further I've come up with the following:
The 74HC595 shift register + latch chips provide 128 unique outputs (1/4 of the panel) and each of these 128 pins is attached to 4 LEDs (let's assume the anode for now although I might have it wrong).
There are only 8 FETs (4 * dual FETs) and 8 current limiting resistors. Since only 1/4 of the panel can be 'lit' at any given instant, I'm assuming this is done with the FETs which implies that each FET is providing the cathode return for 64 LEDs through a SINGLE resistor. This seems weird to me! I feel I _MUST_ have a flaw somewhere in my logic!
Perhaps the panel's are relying on the output current clamping of the '595 output pins? This should keep the LED current limited to 20mA. If so, then the 300 ohm resistors must serve some other purpose (eg: FET gate current limit? Unlikely!!!)
It's interesting to note that the '595 datasheet has always specified a maximum supply current of 70mA but it appears quite common practice to push them over 160mA by loading all 8 outputs with the full 20mA!!! If the datasheet is correct in telling me that each output is 'clamped' to 20mA, then they're largely immune to short circuits... NIFTY!!!
(The way I've interpretted the '595 datasheets, it appears that the 20mA 'clamp' current is only applicable for voltages outside the VCC - GND range. Of all the datasheets, the one from ST is the only one that even attempts to clarify this! Kudos to them!)


Re: LED module pin assignment

Post by TheRevva » Fri Oct 11, 2013 6:06 am

Forgot to add a few bits...
I am very happy to hear that you've (effectively) confirmed that a 125kHz SPI clock is unsuitable for 6 DMDs chained together. It implies I was on the right track...
I completely forgot to include perhaps the 'most obvious' suggestion...
Assuming all the _other_ tasks you want to run on the Arduino are trivial and not hugely hungry on CPU resource, you could try selecting an SPI clock divsor somewhere between the 128 (standard 125kHz) and 16 (1MHz) rates....
For example, using SPI_CLOCK_DIV64 would give you a 250kHz SPI clock which is _enough_ to handle 6 panels at a 50Hz rate and still leave some CPU grunt for 'other things'.
Here's my calcs:
6 panels * 512 LEDs per panel = 3072 LEDs.
Each LED must be 'refreshed' at least 50 times per second so that requires a MINIMUM clock of 153.600kHz. If we set the clock at 250kHz it would mean that the Arduino is going to be 'busy' refreshing the display for 153.6 / 250 of the time (61.4% of the time it's doing refresh). Thus, it will leave you 39.6% of the time 'free' to do all the other tasks put together...
(That's SLIGHTLY optimistic since the refreshing of the display is a little more than just shitfing out pixels. It also needs to toggle the A / B / nOE pins as part of the refresh cycle. However, that would only be a couple of extra percent at worst).

I've yet to do all those calcs for MY project. I'll be chaining 8 panels (possibly 9!) together horizontally. Then I'll multiply ALL of that by having 6 copies of that vertically!!!
It's looking more and more like I will need an ARM based CPU as a bare minimum!!!
(If only for the fact that with a base CPU clock of 84MHz I should be able to use an interrupt driven quasi-SPI bus clock)

User avatar
Joined:Sat Jan 14, 2012 2:44 pm

Re: LED module pin assignment

Post by stryker » Mon Dec 16, 2013 9:49 am

I've assembled a 3x2 array for myself now. I've got a lot of corruption on my display yet so need to sort out what I've done to cause that before more testing but at least I'll be able to press on a bit more speed now.

Have you had any more joy in your testing of larger arrays since this most recent post?

Joined:Fri Sep 20, 2013 7:25 am

Re: LED module pin assignment

Post by Brissieboy » Sun Dec 22, 2013 4:36 am

Just a thought based on my experience:
If you're using the SPI clock as suggested by TheRevva above (using SPI_CLOCK_DIV64) and the default timer initialisation of 5000 uSec, you might be running out of time in the interrupt routine. I'm using SPI_CLOCK_DIV2 and the interrupt takes about 44 uSec per DMD plus a little overhead.
Running 32 times slower for 6 DMDs should then take about 8.5mSec.
Not sure how well a chain of 6 DMDs will handle the high frequency, but keeping the leads as short as possible will help. It works fine with my setup of 2 DMDs.

Post Reply