1
\$\begingroup\$

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

Does anyone have a hint regarding this ?

\$\endgroup\$
1
\$\begingroup\$

Martin,

I'm by no means an expert at RS485, but I have run into some of the same problems you've had with independent power supplies on multi-drop RS485 networks.

Most frequently, in spite of claiming fail-safe operation, they don't play nice with ground loops/DC offsets. For me, in the past, the most direct route is to use fail-safe biasing on the two lines. E.g. Fail-safe biasing network for RS485 lines.

By the way: Most of my learning has come from others here as well as some pretty good application notes from Texas Instruments (PDF), Maxim (HTML), and Analog Devices (PDF).

Hope to hear if this gets you in business.

Josh

\$\endgroup\$
0
\$\begingroup\$

If I understand you correctly, you're running clock and data over seperate, parallel, RS485 transmission lines? And, you're daisy-chaining both clock and data through your display panels? If my understanding above is correct, then I'd suggest you have a look at the timing of your clock and data signals at each display panel. My suspicion is that after the first TTL-485-TTL conversion, the clock-to-data timing is drifting. RS485 is inherently multi-drop, so I'd suggest that rather than daisy-chaining the signals you try paralleling all of the receivers up on each transmission pair.

\$\endgroup\$
  • \$\begingroup\$ Yes, I'm daisy chaining clock and data over parallel RS485 transmission lines, separate for each panel. By paralleling all of the receivers, what do you mean exactly ? Each LED acts as a shift register for my data, so I need to to route the output of the last LED to the first one of the following panel, which is why I don't think I can create a multi drop setup \$\endgroup\$ – Martin Oct 13 '13 at 12:44
  • \$\begingroup\$ @Martin - depending on how fast you're clocking your data stream, you might be better off going to a more conventional communications architecture: a single asynchronous RS485 transmission, multidropped to your 3 slave devices, each of which contains a microcontroller that is addressed by the host controller via a serial communications protocol. \$\endgroup\$ – markt Oct 13 '13 at 20:50
  • \$\begingroup\$ Also, again depending on your comms speed, are you sure your RS485 transceivers are rated to operate at that speed? \$\endgroup\$ – markt Oct 13 '13 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.