Tryna catch me drivin’ dirty

We decided to use the TLC5957 LED driver of Texas Instruments with Broadcom RGB LEDs: ASMB-KTF0-0A306.

Configuration

Brightness control

First, we have to determine the maximum current which will be used. The 3 colours of the RGB LEDs can get a 20 mA input current max and the driver can handle 20mA sink current max. So we choose a maximum current of 20mA.

We decided to configure the driver with the maximum value for the Brightness Control (BC) (and by consequence, the maximum gain) to provide the intensity to go over 20mA. So we have to choose a value of BC equals to 7. And to limit the current to 20mA max we have to put a 9.27kΩ IREF resistor between IREF and IREFGND pins.

After that, we have to choose the Colour control for each colour. This parameter is used to choose for each colour, the ratio between the maximum output current for this colour and the maximum output of the driver. This is used to tune the white balance. According to the LEDs datasheet, the mean intensities are 490mcd for Red, 1100mcd for Green, 215mcd for Blue. So, to have the same mean intensity for each colour, we have to choose those values for CC: 224 for Red, 100 for Green, 511 for Blue.

Display control

The main mode of this driver is done to be used with 16-bits colours. However, we want to use it with 9-bits colours. So, we have to use the other mode: the Poker Mode. When we choose the Poker Mode, we have to activate the ES-PWM and the XREFRESH.

Data configuration

The driver contains several registers. We will use the 4 main ones. The first one is the Common shift register (48bits). Every data one wants to input has to be written in this register. The second one is the FC data latch (48bits). This register is used to configure the driver. Both last ones are GS data latches 1 and 2 (768bits each). They are used to save the data and prepare it to be sent to the LEDs.

The communication between registers is led by the SCK clock and the LAT signal.

How to use the driver

Initialization

First, we have to configure the driver so, we have to configure the FC data latch. To do so, we send bit after bit the 48bits configuration from the MSB to the LSB. In this configuration, we specify different values like the BC, the CC for each colour. We also activate the Poker mode, the ES-PWM and disable the XREFRESH. After sending the 48bits, we send the FCWTREN (LAT high for 15 rising edges) command then the WRTFC (LAT high for 5 rising edges) as below.

Poker Mode

In the traditional mode, we input in the common register the 16bits of each colour from Blue to Red and from MSB to LSB. But, in Poker mode, it is different. We input the bit n of the Blue of the 15th LED then, the bit n of the Green of the 15th LED … until the bit n of the Red of the 0th LED.

So because we use 9-bits colours, we have to first send le Bit 8 of the colours of 16 LEDs then the Bit 8 etc until the Bit 0. Then we output everything. So how does this work? When one has input in the common register the 48 bits data which represent the Bit 8 of the colours of 16 LEDs, one sends WRTGS command (LAT high during one rising edge). This command will copy the 48 bits of the common register in the 1st GS Latch at the address of Bit 8 (address given by the GS data bit address counter). Then the GS data bit address counter is decreased 1. The process is the same for Bits 7 to 1. For Bit 0, one uses the LATGS command (LAT high during three rising edges). This command will do the same thing as WRTGS but, it will also copy the entire 1st GS latch into the second one, it resets the GS data bit address counter to 8 and increased 1 the LINE counter (it will be useful later). But it also forces out the new values which will be sent to the LEDs.

Just below, an example with 10-bits colours. For 9-bits colours, it is quite the same but there are only 8 calls of WRTGS and the GS data Bit address counter starts at 8.

ES-PWM

This is a different approach to realize a PWM. The high state period will be cut and spread to minimize the time between high and low states and get a better result.

Multiplexing

For this project, we decided to multiplex LEDs by 4. Indeed, this driver has enough pins to control 16 LEDs but on each column, we have 64 LEDs. The process to write data is quite the same as without multiplexing. However, they are some things new. First, we will now also use a line counter. This counter is here to know in which step of the multiplexing we are; do we display the first 16 LEDs, the second, the third or the fourth ones. This counter is used by the LED Open Detection which is used to prevent the caterpillar effect but we will explain this after.

So now how do we write our data? For the three first groups of 16 LEDs, it is still the same: 8 WRTGS + 1 LATGS. However, for the fourth group, the LATGS method will be replaced by the LINERESET command (LAT high during seven rising edges). This command will do the same things as LATGS but instead of increasing the LINE counter, it will reset it to 1. That means we sent the data on every LED.

There is an error in this graph, you should replace XREFRESH=0 by XREFRESH=1

Caterpillar cancelling

The caterpillar effect is a problem caused by broken LEDs in multiplexed architectures. As a result, the LEDs multiplexed with the broken one can blink whereas they should be off when the driver tries to switch on the broken one. The Line Counter and the LINERESET command help the Caterpillar cancelling function to detect the broken LEDs and to automatically turn off the output channel for the specific line (so only turn off the output for the broken LED and not to every LEDs multiplexed with it).

Going back and forth the H-Bridge

We need to be able to drive our little magnet marbles and flip them according to a magnetic field direction or the opposite one. To do so current must be able to flow both ways through our self-inductances. Moreover we’re going to need current’s intensity of a much higher value than what is able to flow out of or flow in the GPIO.

One way to do so, is to use a H-Bridge as we can see on this site that we’ve already mentionned in an earlier post.

What’s an H-Bridge

Basically an H-Bridge is a electronic circuit built with drivable switches in a way that allows us to flip the voltage on a load and thus allows us to flip current polarity.

H-Bridge circuitry in red | Source : en.wikipedia.org

There are two important configuration for us :

  • the configuration where S1 S4 are closed and S2 S3 are open and
  • the opposite configuration


By switching from one mode to we are able to revert current polarity by changing which voltage source terminal is connected to which load terminal.

FET transistors are usually used as switches to drive the load. Below we can see a typical implementation with NMOS and PMOS.

H-Bridge implementation with MOSFETs | Source : os.mbed.com

How we plan to implement the H-Bridge

There’s two ways to implement H-Bridge circuit. Either we do it ourselves hand picking the transistors and doing the circuitry ourselves or we pick a H-Bridge driver integrated circuit. We choose the later solution as implementing the H-Bridge by hand can be tricky and unnecessarily complicated for our project.

Moreover, H-Bridge drivers are more advantageous as they have protections against over-voltage, under-voltage, overcurrent etc.

How we choose the driver

There’s two ways to implement H-Bridge circuit. Either we do it yourself hand picking the transistors and doing the circuitry yourself or we pick a H-Bridge driver integrated circuit. We choose the later solution as implementing the H-Bridge by hand can be tricky and unnecessarily complicated for our project.

Moreover, H-Bridge drivers are more advantageous as they have protections against over-voltage, under-voltage, overcurrent etc.

How to choose the driver

There are many criterias that we considered to choose the driver.

First of all, one criteria that seems obvious but we didn’t know about before talking with our professor in charge, is that the driver must be designed to be used with inductive loads. This is not always the case as we can find H-Bridge drivers for capacitive loads.

Initially we’d like to have a 32×32 marble matrix and if not possible a 20×20 matrix at least. It is consequently obvious that price is a critical criteria. As each of our marbles needs to be individually drivable, we often need for one component to order as many as we have marbles.

One way to reduce the number of H-Bridge drivers we’ll need, is to look for drivers designed for multiple loads. This is an important criteria as it possibly allows us to reduce the final cost for this component but also because it may also allows us to gain space on our PCB.

Likewise, driver package size is equally important as we’ll need for each marble a set of components (self-inductance, Hall effect sensors, H-Bridge drivers). It’d be too bad to have to space out the marbles because we don’t have enough space under them to fit all components.

Last but not least are the voltage of the power source and the maximum current that can drives through. We estimated that we won’t use currents higher than 1A to generates the magnetic fields so we looked for drivers in this range. As for the power source, we thought that 7V should be more than enough.

Giving all these criterias we looked for a good compromise and we ordered these two drivers for testing :