RS485 signal transmission - LED panels

[martin69]

Hi everyone,

I'm trying to build large LED panels (3x128 LED modules) using WS2801 LEDs, with data coming from a Teensy 3.0 microcontroller. I'm having difficulties transmitting my Data and Clock signals between the different panels. The three panels have a separate power supply, so I can't transmit my signals directly because of ground problems.
I want to transmit my signals using RS485, so I got myself MAX485 chips, and am using them to symmetrize my signals. So far, it works without any problem if I want to get my signal to the first panel (Teensy output TTL -> Max485 => (RS485) => Max485 -> TTL).
However, when I want to get my signal to the following panel, I'm having a problem. I want to get Clock and Data coming out from the last LED, and RS485 them to the next panel - and this is precisely what does not work. What I want to do is : Teensy output TTL -> Max485 => (RS485) => Max485 -> TTL -> Max485 => (RS485) => Max485 -> TTL.
I know RS485 is in fact a 3-wire system, and I do have a common ground routed from my microcontroller.
I was thinking it might be a ground problem, but I don't know exactly where my problem comes from, since my reception MAX485 and my emission MAX485 are all powered by the same 12V power going to the LED (brought down to 5V, using a LM7805 regulator).

Note : the signal and clock signals output by my last LED are correct, if I route them directly to the following panel, it works alright, but I'm getting artifacts when all 3 panels are connected - that's why I switched to RS485

 

[KrisBlueNZ]

Hi Martin and welcome to Electronics Point

So you're driving the LEDs using shift registers, and you want to cascade the second panel from the first panel by feeding the serial output of the last shift register on the first panel into a TTL-to-RS-485 converter and converting it back on the second panel?

I'm assuming that you're using the RS-485 transceivers with fixed direction settings, and a separate pair for clock and data, right?

I suspect the problem is a race condition between the clock and the final shift register output.

With the clock and data signals from the microcontroller to the first panel, you have probably arranged a phase difference between the signals. That is, the micro drives the data line to the desired state, there is a delay, then the micro drives the clock line in the direction that gives the correct edge to clock the data into the shift register. Right?

The problem is that the data at the serial output of the final shift register actually changes at the same instant as the active-going edge on the clock. To be exact, it changes in response to that clock edge, after a very short propagation delay. If you look at the timing relationship between the clock and the final serial data output, the data changes immediately after the active edge of the clock. There is no enforced delay. So when you feed those signals into the next shift register, small timing differences will cause incorrect data to be clocked.

When multiple shift registers are cascaded, the same situation arises, but signal delays are so small that propagation delays and setup and hold times in the devices ensure that the cascaded shift register clocks in the old output state from the earlier shift register before that output changes, and no problem occurs.

There are several ways around this problem. First, confirm that this is the problem using an oscilloscope while transmitting a regular data stream from the micro. Then you should be able to decide on a good way to solve it.

 

[martin69]

Hi Kris,

Thanks for your answer
Every LED works indeed as a shift register for the data line, which is why I want to feed the output of the last LED of the first panel to the first one of the second one.
As for the clock line, I'm also using the clock output by the last LED.
All RS485 transceivers are set with a fixed direction. Each bus should be pretty much independent :
uC -- first LED of the first panel
last LED of the first panel - first LED of the second panel
last LED of the second panel - first LED of the third panel

In the case of a phase problem between data and clock, if incorrect data is clocked, I suppose I should still get "some" data transmitted to the panel ? As in gibberish, making all the LED flash randomly. The strange thing is that nothing actually happens : no LED lights up, as if neither data nor clock are being transmitted

I'll try to get hold of an oscilloscope good enough to analyze if there is a phase difference. If this is indeed the problem, is there an easy way to solve it ?

Edit : Actually, I think the conversion does introduce a drift between clock and data - The first panel works correctly, but when I tried to raise significantly the amount of FPS (from 25 to 50), I was starting to have strange things happening, like the wrong LED lighting up with the right color, quite randomly. If I already get a slight drift between data and clock after the first TTL-485-TTL conversion, how can I get everyone back aligned ?

Thanks !

Martin

 

[KrisBlueNZ]

As for the clock line, I'm also using the clock output by the last LED.

I'm not sure what you mean here. All of the shift registers in the first panel are clocked from the same signal, right? So the signal you're feeding into the MAX485 for the clock output to the next panel is taken from the clock input on the last shift register, but it's the same signal as the clock for all the shift registers on that board, right?

All RS485 transceivers are set with a fixed direction. Each bus should be pretty much independent:
uC -- first LED of the first panel
last LED of the first panel - first LED of the second panel
last LED of the second panel - first LED of the third panel

Right. You mean the serial data output from the last shift register on the first panel is sent (via RS-485 and back) to the data input on the first shift register on the second panel, right?
What ICs are you using for the shift registers? And how many are you using on each panel?

In the case of a phase problem between data and clock, if incorrect data is clocked, I suppose I should still get "some" data transmitted to the panel ? As in gibberish, making all the LED flash randomly. The strange thing is that nothing actually happens : no LED lights up, as if neither data nor clock are being transmitted

Yes, I would expect random corruption of the data. Have you checked that the MAX485 output from the data signal driver on the first board is actually changing? If you're taking the MAX485's input from the wrong place in the circuit, that would explain why the next board always sees a fixed state on the data signal.

I'll try to get hold of an oscilloscope good enough to analyze if there is a phase difference. If this is indeed the problem, is there an easy way to solve it ?

I think adding a D flip-flop in between the serial output of the last shift register and the MAX485 data driver, clocked on the FALLING edge of the clock signal (assuming the shift registers are clocked on the rising edge) should have the right effect.

Edit : Actually, I think the conversion does introduce a drift between clock and data - The first panel works correctly, but when I tried to raise significantly the amount of FPS (from 25 to 50), I was starting to have strange things happening, like the wrong LED lighting up with the right color, quite randomly. If I already get a slight drift between data and clock after the first TTL-485-TTL conversion, how can I get everyone back aligned?

The "drift" consists of delays in both the clock and data signals that will vary over a small range; you just need to make sure that the time between the data being set up and the active edge of the clock is long enough to cover the maximum skew caused by the worst-case difference between the delays.

How are you driving the SPI signals? Does your micro have a dedicated SPI peripheral or are you bit-banging it? What's the micro?

 

[martin69]

The clock line I'm transmitting is just the one coming out of the last LED - but yes, it is the same clock line as the one going in the first LED

The shift registers I use are the ones integrated in my LED modules : WS2801
This is their datasheet
http://www.adafruit.com/datasheets/WS2801.pdf
The clock frequency I'm using is pretty low, only 1 MHz
I have 128 LEDs on each panel (3 panels, so 384 in total), so that means 128 shift registers


The microcontroller I'm using is a Teensy 3.0, it has a dedicated SPI output, and is supposedly adequate for this kind of application. Actually, when I was using SPI only, I had next to no problem forwarding up to two panels (some small random flashes sometimes), and it became pretty bad with the ground loop only when I added a third panel inside the loop.

Yesterday night, I tried something else in order to find out where my problem came from : instead of the panels, which require both clock and data, I tried RS485'ing a more simple system.
I tried controlling a DMX equipment (stroboscope) using my microcontroller. DMX is based on RS485, so it is essentially the same thing : 3 wire based, A, B and GND plug. No clock/data delay problem, only a single information is transmitted

If I have the following configuration : TTL coming out of the microcon -> RS485 with the transmission max485 -> DMX equipment, it works perfectly well (I'm sending a fast - slow - fast - stop sequence to the strobe to debug).
However, if I do : TTL coming out of the microcon -> RS485 with the transmission max485 -> TTL with the reception max485 -> back to RS485 with the transmission max485 -> DMX equipment, no such luck.
Something still seems to be transmitted, as the "signal received" LED on the dmx equipment sometimes randomly flashes up, and goes so far to actually make the strobo flash randomly on some rare occasions. However, it's definitely not what I intended to transmit.

 

[KrisBlueNZ]

Sorry for not reading your first post carefully!

Regarding your DMX testing, I don't know why it didn't work. DMX is a unidirectional serial data stream, and converting from RS-485 to logic levels and back should not cause a problem. Can you post a schematic diagram of the circuit you used? Include the details of the powering and earthing connections.

I've read the WS2801 data sheet - thanks for the link. I see what you mean about taking the clock from the last LED in the chain.

My previous suggestion of adding a D flip-flop in the data line, clocked on the falling clock edge, would require an extra clock pulse, which wouldn't work properly with the WS2801's cascading arrangement. I think you might need to delay the clock signal slightly, by inserting a small R-C delay between the clock output of the last WS2801 and the MAX485 that drives the clock signal to the next panel.

How have you arranged the powering and grounding for the panels? I assume you have a separate power supply for each panel, because of their high power consumption? I suggest you keep the power supplies separate and isolated from each other, connect each one directly to its panel, and then connect the 0V rails of the panels to the 0V rail of the control board using separate connections. This is like a star earth arrangement.

I suspect your problems may be because of how you're arranging the power supply and earthing. This might also be the reason you had trouble with your DMX experiment. Can you describe this in detail?

 

[martin69]

Indeed, the DMX experiment is quite of a mystery, and when something's strange and doesn't work as expected, I usually think it's a problem related to the ground...

I made a quick schematic of the DMX testing using Fritzing, so it's got kind of a breadboard look, but it's essentially what I did.

Each panel has its own separate 12V 200W power source. The MAX485 on the panels are powered with these sources, with a 5V LM7805 voltage regulator in between (+ the capacitors recommended to stabilize it further).

While testing with the DMX, I connected the grounds between the microcontroller, the 5V power source for the first MAX485, and the 12V power source for the MAX485 on the panel - as such, everyone should share the same ground

The microcontroller is powered by my laptop computer, so there is no earthing. The panel power supply has a connection to earth
The DMX equipment, the panel and the 5V power supply were all connected to the same power strip.

Tonight, I'm going to test running all of my Max485 powered with the same power source, in order to check if the power source on the panel might be the cause

 

[KrisBlueNZ]

Thanks for the diagram. That's very helpful. The grounding arrangement looks fine to me.

I notice that on the MAX485 at the left side of the top breadboard, pin 3, the transmit enable input, is not connected to anything. This is a high-impedance input and it may pick up noise if it's not driven.

If fixing that doesn't improve things, you could try terminating the RS-485 pair at the receiver (the same MAX485) with a 120 ohm resistor across pins 6 and 7. If that doesn't work, I don't know what else to suggest.