This a project for a group of folks working to reverse engineer the Barco NX-4 LED panels.

Similar projects worth following
Community project for reverse engineering the LED tile we all got cheap! Feel free to join if you want to share progress and work together!

If you want to be approved for membership, write about your progress (or effort) in the comments.

SuperConference folks: Welcome! Hopefully what we have is useful to you, please add information here if you figure something out!

We are updating the project details with information as we go.

The story so far...

We can control the LED drivers to scan out a row in the 12 sections, but we haven't figured out how to ask the CPLD to switch to the next row (or why the CPLD owns row MUX).

Current "Request For Investigation":  Figure out what the FPGA sends to the CPLD on the front board to get it to scan through the six display rows. If someone has a working display a logic analyzer capture of the FPGA->CPLD lines (ideally from boot) would be great.


Setting up and sending pixels to the LED row drivers, and turning on pixels (and the 3 self-test LEDs on the back)

Communications through the IN and OUT connectors.

Not working/unknown:

Scanning more than the first of the multiplexed rows; the CPLD is in charge of stepping these it seems.

Panel LEDs

Contributors: @Richard Aplin, @modder_mike

The panel is divided into twelve segments of 16x6.  Each segment is driven by three Texas Instruments TLC5941 16-channel LED drivers.  Each driver controls one color of the tri-color LEDs.  The three drivers have their serial data cascaded, with the first controller in the cascade being Red, then Green, then Blue.  Anode voltage is switched to each of the six rows of LEDs in sequence via a transistor controlled by the CPLD.

The 96 LEDs in the segment are controlled by only 16 driver channels by multiplexing the rows' LED anode voltage (TLC5941 switches the cathode side).  Each of the 36 rows has a transistor between the panel's +4.5V input and the LED anodes.  All like-numbered rows' transistors are connected to a common control pin on the CPLD.  The CPLD cycles through them in sequence as instructed by the FPGA, synchronized with the incoming display data.

Take care when rewriting HDL for the FPGA.  Because the LEDs are expecting to be run at only 1/6 duty cycle, they may theoretically be damaged if they are not cycled as quickly by user HDL.  (For experimenting, consider using the calibration LEDs on the rear of the panel, which are not multiplexed.)

There are three I2C devices on the LED panel, an EEPROM, a temperature sensor and an ambient light sensor used for brightness calibration.

Most of the LED driver control pins are brought out to the data connector by way of two buffers.  The remaining signals (SOUT for each driver string) are fed to the CPLD.

Back Panel Connectors

Contributors: @Richard Aplin, @modder_mike, @Chankster@Ian Hanschen

Input connector (TE AMP 206486-2 -  mates with 206485-1)

PinFunctionFPGA PinFPGA LVDS PairFPGA Direction
1+VIN. Connected to a Linear LTC1778.
Recommend 14.5-24V.
Read more »

This is a garbage project snapshot of when I first got lights. Some random thing in this is enabling the LED drivers. For {reason} you need to run this after first powering on the tile. Let's figure out what it is!

x-zip-compressed - 990.10 kB - 11/15/2017 at 22:26



may have errors, was dumped with hacky rig

octet-stream - 64.00 kB - 11/11/2017 at 06:23



may have errors, was dumped with hacky rig

octet-stream - 64.00 kB - 11/11/2017 at 06:23



The 2MByte flash dumped. Not certain the address lines are correct but it looks reasonable. Of note; some strings at 0x110eb0, also some obvious 8bit->12bit lookup tables at 0x112000, 0x112400 . Note that this FPGA uses a bitstream that is 0x29500 bytes (1,353,728 bits) long, and there's a clear break in the flash contents at that point. See for details on the data format- page 249 lists the bitstream bootstrap sync word of "0xAA995566" which is present at offset 4 in the flash. Possibly this image is off by 4 bytes, or maybe that's just how it is.

octet-stream - 2.00 MB - 11/11/2017 at 05:23



EEPROM dump, control board, Mike's sample #1

octet-stream - 64.00 kB - 11/03/2017 at 02:54


View all 11 files

  • 1 × Xilinx XC3S250E FPGA, Spartan-3E, 250K gates, TQFP-144
  • 1 × Cypress CY7C1041D Static RAM, 4Mbit (256K x 16), TSOP-44
  • 1 × Xilinx XC9536XL CPLD, 800 gates, QFP-44
  • 37 × Texas Instruments TLC5941 LED driver, low-side, 16-channel, QFN-32 (5x5)
  • 2 × Texas Instruments SN74LVC16244A Buffer/driver, tri-state, 16 channel (4x4), TSSOP-48

View all 14 components

  • OpenNX4 source + binaries posted!

    Richard Aplin3 days ago 14 comments

    A big chunk of NX4 Xilinx code (with precompiled binaries and python code to talk to the tile over UART) just posted: 

    Currently the code supports taking to a host over UART (e.g. loading images onto the NX4) and python code is provided to make it do stuff. 

    It's currently in an 'advanced user' state, there remains one vital thing to figure out on the NX4; how to get the row scanning working (i.e. how to get the CPLD on the LED driver board to play ball). 

    Once we get that sorted out we're fairly far towards a working, daisy-chainable video tile, controllable by a variety of hosts (Ardunio, embedded linux, etc) using a variety of protocols and doing a variety of 'intelligent display' tricks. 


    We should be able to end up with something you can flash onto a tile in a minute or two with a cheap JTAG adapter, and accepts further firmware updates over the wire

    The blocker right now is the CPLD (not) doing row scan... 

    Here's a really, really bad photo where I'm moving the camera so you can see the scanned image (original inset).   The tile itself seems high quality; you can get excellent intensity gradients on it, and the 1/6 scan rate w/12-bit CC drivers is a luxury.

  • Protocol suggestions

    Richard Aplin11/06/2017 at 22:18 5 comments

    Hi there, 

    As someone who's interested in the "reimplement HDL" option for the tiles - I thought a suitable name might be "OpenNX4" (resisting the temptation to run the two n's together) and had a few thoughts/suggesions to throw out there.

    For the sake of this discussion, let's say an "end user" is someone who (at least initially) has one or more NX4 tiles and a Raspberry Pi and wants to use them as a video panel (daisychained, with the tiles in a plane or just placed artistically), with minimum extra hassle.

    Because the only limit of how many tiles you can daisychain is your power source, your frame rate and your wallet, let's look at how we can get the best frame-rate (=highest speed pixel interface).

    The tiles come with an IN and OUT port. The IN port has 2x in and 1x out LVDS pairs, and the OUT port has 2x OUT and 1x IN pairs. The pairs can be used as single-ended i/os as well of course.  

    As NX4 is FPGA driven it means almost any protocol can be implemented (although HDMI video is not reasonable). You really just want a lot of downstream performance; an upstream link back from the tiles can be arbitrarily slow.

    If we look at what protocols are available on typical hacker boards (OPi, RPi, Allwinner, or even Teensies):

    I2C up to about 1-2mbps, UART ~4mbps.. and..

    SPI (and/or I2S) ports at up to ~100Mbit/s

    (There is also SD - as 'make the tile a fake SD card' which is fiddly and takes too many wires in fast 4-bit SD mode)

    Another option is that some SBC's have a connector for an LCD display which is usually LVDS, and we could probably provide an interface to that too assuming there are enough pins (or we ignore some of them). 

    The current crop of cheap allwinner H3 boards are great, and some tricks are possible including running both I2S ports synchronously (=2 bits @ 80+Mhz); they're my fave platform right now, but much of this is doable on a Raspberry Pi too (possibly lower performance).

    Suggested configuration

    For the sake of discussion let's say you stick an Orange Pi right physically on the back of an NX4 tile, and that's your video processor; you can send it stuff over wifi or ethernet, generate trippy images, play video off SD, whatever. It runs some code that preprocesses and maps the pixels to the tiles, and blasts the result to the first (and subsequent daisychained) NX4 tiles. (You can probably power the Orange Pi off the 4v6 supply in the tile).  

    First tile in array receives single-ended

    So the NX4 is an SPI slave.  All our tiles boot up in "spi slave" mode until they hear otherwise.

    So from your OPi you run SPI MOSI and SCK over nice short terminated wires into the tile data input. Add MISO so you've got a data stream back (we could connect CS but could also design the protocol so it's not required). This will probably achieve in the ballpark of 30-80Mbps actual throughput.  

    Even higher performance option : I2S on Allwinner boards; instead of using SPI it's likely possible to use synchronous dual channel I2S; i.e. run PCM0_DOUT and PCM1_DOUT, PCM0_CLK (and PCM0_DIN for a return data channel) which might achieve ~100Mbps. 

    Daisychained are differential

    Ok so that's the first tile, what about daisychaining?  Note that we can use the first tile as a "single ended to differential converter" and have the OUT port sending LVDS signals downstream to all the other tiles; hence we gain the noise immunity, longer wire length and general better performance of LVDS for all the other tile data links, however many there are (limited only by your desired frame rate).  

    Advanced hacker bonus points would be so only one tile needs to be reflashed with different Xilinx code, and it accepts a single-ended input from the linux board and converts it to Barco format output for the other daisychained tiles...

    Bottom Line - performance

    Ok so if in practice we get say 30mbps data rate...

    Read more »

  • Some words on the I/O connectors

    modder_mike11/04/2017 at 04:47 4 comments

    I see Ian posted a preliminary pinout for the input and output connectors.  I have some additional information on that topic that I haven't posted yet, so now seems as good a time as any to get that out there.

    In a full NX-4 installation, three of these modules are cascaded via the 8- and 9-pin connectors on the rear.  That means that all signals necessary for operation of the next panel must be transmitted by the previous one.

    Here's a key piece of information that may have been glossed over.  FPGA pins 128 and 129 (IP_L06P_0/GCLK8 and IP_L06N_0/GCLK9) are dedicated input pins.  These happen to be mapped to output connector pins 5 and 8.  Therefore, we can say that the output connector contains two power pins, four output pins, and two input pins.  Because the panels are daisy-chained, we can also therefore say that the input connector contains two power pins, four input pins and two output pins.

    If you look closely at the layout of the board, there are resistors attached to pins 7 and 8 of the input connector.  If you poke around, there are also two similar resistors tied to pins 2 and 3 of the input connector and pins 5 and 8 of the output connector.  These appear to be pullup/pulldown or termination resistors for the input lines.  Therefore, I assert that the pin directions of the two connectors are:

    Input ConnectorOutput Connector
    1 - +VIN1 - +VIN
    2 - Input Pair 1N2 - GND
    3 - Input Pair 2N3 - Output Pair 2P
    4 - Output Pair N4 - Output Pair 1N
    5 - Output Pair P5 - Input Pair P
    6 - GND6 - Output Pair 2N
    7 - Input Pair 1P7 - Output Pair 1P
    8 - Input Pair 2P8 - Input Pair N
    9 - ? No discernable destination

    It would not be unreasonable to assume something like that the dual pairs are a high-speed differential channel for carrying pixel data and consisting of clock and data pairs, and the single pairs are a status bus traveling in the opposite direction for panel configuration and error messages (fan fail, overtemp, etc).  There is also a resistor between pins 5 and 8 on the output connector, and pins 3 and 8 on the input connector; based on the rest of my theory and symmetry of design, I'd guess that pins 3 and 8 were the Data bus for pixel data, and pins 2 and 7 would be the Clock.  Or I may be missing something and my theory is completely worthless - this is all unconfirmed, which is why I hadn't posted it yet :)

    One additional additional note on +VIN.  Although things start to respond at only 6V, the input has to be higher than that for everything to work properly.  The LT1933 switching regulator that runs the fan puts out 12V, and it needs maybe 2.5V of headroom to do the step-down.  So the nominal input VIN has to be at least about 14.5V.  That's a weird value, so I'd expect the real input to be somewhere in the 16-24V range.

  • Trimming down members

    Ian Hanschen11/03/2017 at 13:30 0 comments

    Dropping some of the members who haven't contributed - I'm sorry about that. I was eager to have folks join in so I was auto-approving, but please post in the comments if you have something to contribute (or are working on something - that's good enough), and we'll approve your join request. Otherwise, if you've purchased the panels and are waiting for the results, just follow. I want to make sure the folks doing the hard work get the credit.

  • I2C Devices and EEPROM Contents

    modder_mike11/03/2017 at 03:10 9 comments

    I've mapped all five I2C devices in the assembly to addresses now.  They are as follows:

    0b0111001x (0x39): LED Panel ambient light sensor
    0b1001000x (0x48): LED Panel temperature sensor
    0b1001001x (0x49): Control Board temperature sensor
    0b1010000x (0x50): LED Panel EEPROM
    0b1010001x (0x51): Control Board EEPROM

    The ambient light sensor's address corresponds to one option for a Taos part; it responds to a request for register 0x0A with 0x0A, which either means it's a Taos TSL2560 Rev. 10, or it's something completely different that just parrots back the data sent to it (I haven't dug any further into it yet).

    I have also dumped the two EEPROMs, and have posted them to the Files section.  They are structured differently, but both start with a preamble containing the part number, serial number and manufacture date.

    Now go forth and speculate wildly :)

  • Xilinx starter project on github

    Ian Hanschen11/01/2017 at 04:07 0 comments

    I've pushed a Xilinx ISE starter project configured for the NX-4 board with all of the known pins mapped and outputs defaulted to ground. It's on the GitHub repo.

  • Quick test bitstream for ya

    Richard Aplin10/31/2017 at 22:13 12 comments

    I've got a bit carried away in the weeds with adding bells and whistles to my xilinx stuff (and it's broken right now) but I uploaded a .bit and .svf (use whichever your jtag supports), which zips some pixels along the top row of each scan. It's just a very rough thing from last week so you can see some pixels light up.

    Programming this image won't affect your board; reset it and it's back to normal.

    Note that on this image I used pin 7 on the input connector (that's the male connector on the left of the back, the top-left pin) as a chip reset, so jumper it to GND to make stuff work. 

  • JTAG

    Richard Aplin10/30/2017 at 04:38 1 comment

    FYI JTAG connections you may wish to use 2.8v as marked for your JTAG interface bus voltage instead of the 3v3 provided on the jtag connector.  I honestly think 3v3's fine but... someone would have to disprove my experience by doing it and not having the $20 Xilinx blow up. 

    It looks like pretty much any JTAG interface is fine; there are a bunch of tools; OpenOCD has some JTAG support but I didn't see Spartan 3E programming in there (it looks a bit light on fpga support unless I was looking at the wrong thing). 
    You can use the Xilinx ISE tools and the "device programmer" part can generate a kinda "jtag recording" (SVF file I think?) which is so simple almost any JTAG programmer can replay it to program a device.

    I tend to use a lot of embedded linux (currently Orange Pi boards which are my default hardware platform now) so "xc3sprog" works fine with an FT2232-based JTAG interface.  

    If anyone wants a buying suggestion for a JTAG interface; If you want a quality tool the "TIAO tumba"  FT2232 board (relatively pricey at $30) has all the level shifting and jumper doodads you want and looks to be a perpetually handy thing to have around the house.

  • Control Board FPGA Pinout

    modder_mike10/27/2017 at 07:48 0 comments

    I might be missing a few connections yet which I'll correct as I come across them, but here is the pinout of the XC3S250E FPGA on the control board.  Note that the SRAM and the Flash share an interface bus.  Also note that the JTAG interface is 2.5V logic.

    PinFunction PinFunction
    1PROG_B (Pullup to +2.5V)73GND
    2LED_L1_SIN74SRAM_A16; FLASH_A15
    3LED_L2_SIN75SRAM_A15; FLASH_A14
    4LED_L3_SIN76SRAM_A14; FLASH_A13
    5LED_R1_SIN77SRAM_A13; FLASH_A12
    7LED_R2_SIN79VCCO_1 (+3.3V)
    8LED_R3_SIN80VCCINT (+1.2V)
    9VCCINT (+1.2V)81SRAM_A12; FLASH_A11
    13VCCO_3 (+3.3V)85SRAM_A10; FLASH_A9
    19GND91SRAM_A6; FLASH_A5
    25I2C_SCL97SRAM_A1; FLASH_A0
    26I2C_SDA98SRAM_A0; FLASH_DQ15/A-1
    28VCCO_3 (+3.3V)100VCCO_1 (+3.3V)
    30VCCAUX (+2.5V)102VCCAUX (+2.5V)
    42VCCO_2 (+3.3V)114
    43SRAM_BHE#115VCCINT (+1.2V)
    45VCCINT (+1.2V)117INPUT_CONN_PIN_2
    49VCCO_2 (+3.3V)121VCCO_0 (+2.5V)
    50SRAM_IO7; SRAM_IO15; FLASH_DQ7122
    64VCCO_2 (+3.3V)136
    65VCCAUX (+2.5V)137VCCAUX (+2.5V)
    66FLASH_A19138VCCO_0 (+2.5V)
    70SRAM_A17; FLASH_A16142CPLD_PIN_42
    72DONE (Pullup to +2.5V)144JTAG_TDI

  • Lights on

    Richard Aplin10/26/2017 at 21:24 0 comments

    Simple/ugly proof of concept from last night; no row-muxing yet but the lights come on..

View all 14 project logs

Enjoy this project?



Richard Aplin wrote 10/26/2017 at 04:11 point

Ohhhh I see that _is_ fancy.. they have a TI 16-channel 12-bit programmable CC driver per row pixel (with 1/6 scan)? Niiice.  I actually assumed it was a cheap 1-bit-per-pixel and you just scanned the shit out of it to do your intensity modulation.  Thanks a lot that's very helpful. I'd not pulled an led driver panel apart yet b/c it looked hard to do nondestructively.  Yes I was barking up the wrong tree there.. So nice to have a TI driver (that detects dead LEDs too)   No expense spared I see! 

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 04:36 point

Disassembling the panel isn't fun, but it's not awful.  You'll need to pry off the little plastic shades on the front to get at the screws underneath.  I did this with my fingernails, and a utility knife where they didn't want to move.  There are only two plastic pegs that stick into the panel PCB, and they otherwise clip around the packages of the LEDs with little bitty clips.  Working from one corner, I was able to slide my fingernail along the row to get one side up, then kind of pushed and wiggled it around until I was able to work them out from around the LEDs.  Repeat 15 times.

The Barco documentation says these parts aren't replaceable once they're removed.  Some of the clips do appear to have been lost to the effort, but most are left - if you work slowly and don't pull too hard you should be able to maneuver them off intact enough to stick back on.  And then there's always glue as a last ditch effort.

Be sure not to jam tools into the fronts of the LEDs, the lenses are silicone and are soft!

  Are you sure? yes | no

Ian Hanschen wrote 10/26/2017 at 03:29 point

I am in the middle of a work crunch - hoping to hop onto this this weekend but I may be working. Feel free to change this page as you see fit, as well as add new contributors. I've written several LED matrix cores over the years and plan to write one for this display - it's good to see so much progress already!

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 01:00 point

I have the xilinx running my code and generating test pixels and h/v clocks (and I can see at least the clocks etc with a scope, plus the diagnostic LED is useful to flash); no main pixels lighting up yet, but it's easy enough to get it running and I'm trying various fuzzing of the unknown pins...  

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 01:49 point

Try controlling the CAL driver (pin 15), I don't think there will be any CPLD switching nonsense required for that.  The CAL driver controls three LEDs pointing out the back of the LED panel housing under the control board, behind a little black plastic window.  The driver is TI TLC5941.

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 02:27 point

oh sweet. I've not pulled apart the front panel yet. Anyone got any pictures or other info on what's on there? I assume the i2c is just for eeprom  / sensing?

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 02:32 point

Here's my .ucf file for pins so far btw; [NOTE this is now outdated and errors were found, see more recent posts etc]

NET "led_l_sin[1]" LOC = P2;
NET "led_l_sin[2]" LOC = P3;
NET "led_l_sin[3]" LOC = P4;
NET "led_l_sin[4]" LOC = P5;
NET "led_l_sin[5]" LOC = P7;
NET "led_l_sin[6]" LOC = P8;
NET "led_r_sin[1]" LOC = P14;
NET "led_r_sin[2]" LOC = P15;
NET "led_r_sin[3]" LOC = P16;
NET "led_r_sin[4]" LOC = P17;
NET "led_r_sin[5]" LOC = P20;
NET "led_r_sin[6]" LOC = P21;
NET "led_sclk" LOC = P139;
NET "led_mode" LOC = P33;
NET "led_blank" LOC = P34;

//NET "led_unk_p6" LOC=P6; in only
NET "led_unk_p44" LOC=P44;
NET "led_unk_p43" LOC=P43;
//NET "led_unk_p42" LOC=P25; //!!!42;
//NET "led_unk_p41" LOC=P41; in only

NET "led_gsclk" LOC = P140;

# PlanAhead Generated physical constraints 

NET "clock" LOC = P56;

# PlanAhead Generated IO constraints 


# PlanAhead Generated physical constraints 

NET "led_status" LOC = P60;

--- The GSCLK and LED_SCLK are both run through a buffer on the board which implies they are right. The LED_R_S* outputs I partially beep-tested on my dead board and partially just guessed b/c they're clearly all in the bank0 i/o domain.
Assuming SCLK is 16*3 clocks per line, then a row strobe (GSCLK?) once per 48; I've tried both +ve and -ve polaity on GSCLK so far; there's some master enable I'm not finding.

The 1:6 row mux select; any ideas of the pins for this? Presumably 3 bits A0..2..

The main clk is 40mhz and right now I have good looking SCLK/GSCLK generated off that (a couple of mhz SCLK right now) and a bunch of 1's and 0's going out the LED_S* pins.   Nothing lighting up. Am fuzzing some of the other pins... 

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 02:37 point

I posted a few admittedly poor photos.  The I2C bus is connected to three components: an AD7416 temperature sensor (identical to the control board but NOT an ADC as you guessed, the 7416 has only a temp sensor), an AT24C512 serial EEPROM (again, the same as on the control board, I assume containing calibration data or other panel info), and an ambient light sensor that looks kind of similar to an AMS TSL2561 or TSL2563, though I cannot yet confirm.  The ambient light sensor looks at the output of the calibration LEDs in what I assume is an attempt to normalize brightness across panels.

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 02:49 point

Your logic on GSCLK is a bit flawed.  GSCLK is not really a clock, but more of a brightness control input.  The driver wants 6 or 12 bits of data per pixel on SIN (depending on mode), or 96/192 bits per driver, times 3 drivers.  You will need to use LED_XLAT to latch the data into the driver.  Take a look at the datasheet for TI TLC5941 for more information.

Note also that the maximum clock frequency for the driver is 30MHz, it looks like you're already dividing that down which is good because it may not run at the full 40MHz.

  Are you sure? yes | no

Richard Aplin wrote 10/25/2017 at 19:48 point

BTW I killed one of boards already (fpga dead) - I can hot-air the xilinx off if you want to see the board underneath it. 

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 00:41 point

That might be handy, if you don't mind.

  Are you sure? yes | no

Richard Aplin wrote 10/25/2017 at 19:26 point

Incidentally there is a nice windows tool (free trial) called "TopJtagProbe" which will connect to the NX4 FPGA (I used a J-Link) and you can monitor all the pins and wiggle their states (while fpga is running or stopped). It's extremely handy. I have successfully connected and programmed the FPGA via a J-Link under windows and also via an FT2232 interface (using urjtag on linux)

  Are you sure? yes | no

Richard Aplin wrote 10/25/2017 at 19:21 point

A bunch of pictures I took of the NX-4 are here; if anyone wants to copy+post elsewhere (here etc) go for it

  Are you sure? yes | no

Richard Aplin wrote 10/25/2017 at 19:20 point

Hey I've done some work on this too; my notes so far at

Just this and that you've traced the pinout from fpga->panel - handy! I've got the FPGA running my own bitstreams now.  I blew one up tho already - it may have been that my JTAG was at 3v3; I've switched to 2v8 now, seems fine

  Are you sure? yes | no

Jarrett wrote 10/25/2017 at 17:58 point

Needs more pictures :)

  Are you sure? yes | no

Ian Hanschen wrote 10/26/2017 at 14:08 point


  Are you sure? yes | no

Ian Hanschen wrote 10/24/2017 at 16:31 point

I've turned his project into a group project. Feel free to join and share your progress - we can reverse this thing faster if we work together.

  Are you sure? yes | no

modder_mike wrote 10/22/2017 at 17:20 point

If you'd like some help, I've made a fair amount of progress so far.  The unit probably runs on somewhere between 18 and 36V, applied on the lefthand connector on pins 1 (+) and 6 (-).  The LED panel runs on about 4.6V, with logic running at 3.3V, both produced on the control board.  I've mapped the board-to-panel data connector, and all of the LED driver signals are brought out to it - except that there are six times as many LEDs as driver channels, so each driver output must be multiplexed to several LEDs.  This is half of what the CPLD on the LED panel does; the other half of its function is to route the SOUT pins of the drivers.  There are 9 pins on the connector that go to the CPLD, and there are only 800 gates in the CPLD, which isn't a ton.  I'm hoping the CPLD does nothing more than signal routing with a parallel or simple shift-register interface, and thus that it can be easily reverse-engineered - but I haven't gotten quite that far yet :)

  Are you sure? yes | no

Ian Hanschen wrote 10/24/2017 at 02:45 point

I would love some help - my original plan (which has worked in the past) was to progarm the fpga with a design that spits out the pin numbers of each pin in async serial, on that pin...then probe around the board. It sounds like you took the time to trace it out - would you be ok with sharing that? :) I've added you to this project if you want to publish here, or you can email me - ianhan at gmail

  Are you sure? yes | no

modder_mike wrote 10/24/2017 at 03:43 point

Right now I've only got the power and data connections between the control board and LED board mapped, I don't have the control board FPGA mapped yet, that's my next task.  I'll post what I've got though.

  Are you sure? yes | no

Chankster wrote 10/22/2017 at 15:58 point

I'm sure you have your own pictures but here's some I took:

These seem to be a match for the connectors on the back:

206485-1 - 9 pin female

206434-1 - 8 pin male

  Are you sure? yes | no

Ian Hanschen wrote 10/24/2017 at 02:46 point

Great photos. I chased down the old (out of stock everywhere) connectors first, then found these as well. I think they are a match.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates