Close
0%
0%

BARCO NX-4 GROUP REVERSING ADVENTURE

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...

Update: Row scanning working.

Known/working:

  • Building and loading via JTAG new firmware into the main FPGA. This firmware is starting from scratch, we don't understand much yet about the default Barco firmware, although we've dumped it.
  • We understand the majority of how the board works and can display pixels (now on all rows), and communicate via the IN and OUT connectors (various protocols partially done, UART finished and working)
  • Scanning out pixels to the main LEDs  (and the 3 self-test LEDs on the back) 

Unknown

  • Don't know anything so far about the native Barco data format for driving the tiles without reflashing them first; this is going to be difficult without having a working Barco rig (controllers and head end) or insider info. 
  • Don't really know what the CPLD does internally, there's some communications between the Spartan and the CPLD that are captured but not figured out. It may not matter too much.

Unimplemented

  • Daisychaining tiles (e.g. via LVDS)
  • Temporarily (until powercycle) reprogramming a tile is easy enough with a JTAG interface, but a small amount more work is required to write a permanent image to the parallel flash onboard.
  • A variety of housekeeping stuff; fan control, understanding the dot-correction calibration eeproms, and so on.


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.


... Read more »

svf - 667.94 kB - 11/26/2017 at 12:27

Download

Simple_NX4_11_25.svf

Same as "Simple_NX4_11_25.bit" in SVF format; works for me (richaplin); can boot a tile into r,g,b all row display. Although built from same src this SVF file is not quite the same as the one Spacecoaster posted. Give it a shot.

svf - 667.94 kB - 11/26/2017 at 05:15

Download

Simple_NX4_11_25.bit

Same program as posted by SpaceCoaster on github "simple_nx4_8eab499.svf" but as a .bit file, compiled independently by rich aplin, confirm it works the same for me as him - I can power up my tile, load this .bit, and get all rows showing sequential r,g,b

bit - 165.34 kB - 11/26/2017 at 05:05

Download

simple_nx4_8eab499.svf

SVF for programming simple_nx4. Displays vertical BRG stripes.

svf - 665.18 kB - 11/24/2017 at 21:39

Download

NX-4_CPLD_Startup_1.sr

A sigrok / PulseView compatible logic readout of the first data burst present on the CPLD-FPGA communication pins as the module starts up.

sr - 4.48 kB - 11/24/2017 at 19:32

Download

View all 16 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

  • IT'S ALLLIIIVEEEE!

    kevtris03/30/2018 at 04:06 7 comments

    Well I managed to snag an NX-4 control box off ebay for 100 bucks last week!  It was a total pig in a poke (kind of like the LED tiles were) but it seems to work, at least enough to drive the displays!  I have it showing test patterns and stuff now using it.

    The wiring is now figured out for the cables, and it works like this:

    (8 pin "out" connector -> 9 pin "in" connector)

    1 - > 1  (+24V)

    2 -> 6 (GND)

    3 -> 7 (out data to display positive)

    4 -> 3 (out clock to display negative)

    5 -> 5 (in data from display positive)

    6 -> 2 (out data to display negative)

    7 -> 8 (out clock to display positive)

    8 -> 4 (in data from display negative)

    It appears the cable from the NX control box to the tile, and the cable between tiles is the same.  I guess this would make sense.

    Inside the NX control box proper is a huge 24V, 15A(!) power supply.  It has an IEC receptacle on it, but unfortunately it is only for 240V operation.  It will not run on 120V.  The supply is extremely high quality and has a very small for this power level planar transformer inside and a PIC micro.  It also has I^2C for some reason.     I cannot use the existing supply so I am just hooking my bench supply up for now and running a single tile.

    A quick scoping reveals the clock going to the display is 50MHz which is a bit higher than I was expecting but not too far out of the ordinary I guess.   I initially didn't twist my pairs because I was lazy, and it resulted in it not working very well at all.

    Holding the wires together with my finger seemed to make it work a lot better and I started to get actual data on the display!  Interesting how the word "up" was showing up in green at the bottom there.

    Finally, after doing it right and twisting the pairs, it seemed to be working properly.

    There's a two position dip switch on the board with the text "sw this way for normal operation" with an arrow.  If both of the switches are in the down position, it will display a moving white grid pattern that marches down and to the right one row/column every 300ms or so.  I assume this is so you can tell if you have arranged the tiles properly in the array and have not turned one or more of them.

    If one switch is up and the other is down, you get the "soft back up" message with the marching row/column behind it.  I am not sure what this means but it is probably documented in the manual. 

    Clicking both up in the "normal" position, results in all LEDs glowing a dim grey, I suspect for LED testing or similar.  On this panel all LEDs appear to light and with absolutely uniform brightness. 

    There's a ton of LEDs on the control PCB and they all flash various patterns.  I am not sure what they mean but there's four LEDs near the connector to the indicator LEDs for the box which indicate status.  One flashes yellow about once a second (sometimes it will flash twice in a pattern) and the other flashes orange 3-4x a second.

    Hardware on the control board is pretty brute force.  There's an ARM CPU, Stratix GX FPGA (with 8 serdes, two per HDMI connector to link the control boxes together as shown in the docs), 6 128Kbyte 15ns SRAMs, a maxii CPLD, and a bunch of power supplies.


    On the bottom is a 4mbyte parallel flash ROM and a MAX232 RS232 transceiver.  There is also a mini USB connected to the ARM, but I have not plugged anything into it yet.  There are 3 big honking 9A 30V polyswitches to limit current to each string of three LED panels as well.

    That's about it for now, I just got this box today and had to do a quick play around to see if I could get it to light up one of the LED panels, and it did!   I hope it isn't too tough to hook this up to an FPGA and do some heavy duty reverse engineering of their protocol now.

    Finally, a crappy pic of the board inside the box.

  • A Slight Disaster and More Info

    kevtris12/05/2017 at 11:12 4 comments

    I decided to try and feed the display so more LFSR goodness, and I managed to get the link light to stay lit, and the fan kept spinning.   Buoyed by this success, I kept at it and could keep the LED/fan on longer.   Each time the FPGA was reset, the LEDs would flash on briefly with a different pattern too.

    But, after awhile the status LED started doing a double flash.   This means I blew away the main application firmware somehow.  Whoops.   Checking the rental install PDF, this means that the board is running on backup firmware.  I will eventually desolder the flash on this board anyways for testing, and I will replace it with two .5mm FFC connectors to hook it up to my tester.

    In the mean time, I will remove the flash from another board, bend pin 10 (/WE) up and reinstall, then solder /WE to 3.3V to prevent the flash getting blown away with subsequent poking.  I should've done this from the start, but these things happen.

    I was doing a bunch of poking around the barco website, and their "director toolset" is available for download.  Inside the install file, I found all the various firmware images for what looks like every (or nearly so) LED product they make and have made.  There's no registration or other requirements it seems and the installer is there for download.

    https://www.barco.com/en/product/director-toolset

    I used winzip to unpack the installer without running it.

    In the installer it lives at:  /install/install/installerdata/disk1/instdata/resource1.zip

    in resource1.zip: /$IA_PROJECT_DIR$/directortoolset_2.08-win.zip

    in the above zip: /flashfiles/

    whew!

    Inside was the firmware/software for these tiles.   The FPGA bitstream and the microblaze code are separate files.  There's a couple versions of each for the NX4 stuff.   These appear to have a bit more metadata in them but otherwise look similar to the stuff found in the parallel flash.

    The interesting files are named:

    Nx firmware_ctrl 4.0.0.hwr    (434K)

    Nx firmware_mod 4.0.0.hwr (166K)

    Nx program 4.0.0.swr           (129K)

    Nx program_backup 2.0.0.swr (57K)

    Nx program_mod 4.1.0.swr  (75K)

    The documentation pdf that is on the director toolset link is also kind of interesting;  it explains things like calibrating the display using a camera, manually, etc. as well as the kinds of diagnostic information available.   These displays are also capable of gap compensation where it dims the pixels on the inside vs. the outside to make gaps less noticeable.. neat.

  • I^2C for Fun and Profit

    kevtris12/03/2017 at 01:22 2 comments

    After some messing around, I managed to capture the entire I^2C sequence on startup, and now have a complete log of what happens on the bus.

    Looks like it initializes everything and then reads a bunch of the data out of the EEPROM on the LED board which isn't too surprising.  Every 2 seconds, it reads the two temperature sensors.    I will have a link below to the entire data log in human readable format.  Here's some highlights, though, with my notes:

    At the start, there's a bunch of small 1-4 byte reads out of the two EEPROMs, most likely reading version/model information.

    START
    DEVADD: 50 WRITE ACK
    SUBADD: 0F ACK 10 ACK

    START
    DEVADD: 50 READ  ACK
    SUBADD: 32 ACK 32 ACK 32 ACK 32 NACK

    STOP

    START
    DEVADD: 50 WRITE ACK
    SUBADD: 0F ACK 14 ACK

    START
    DEVADD: 50 READ  ACK
    SUBADD: 00 ACK 12 NACK

    STOP

    START
    DEVADD: 51 WRITE ACK
    SUBADD: 01 ACK 00 ACK

    START
    DEVADD: 51 READ  ACK
    SUBADD: 32 ACK 32 ACK 32 ACK 32 NACK

    STOP

    START
    DEVADD: 51 WRITE ACK
    SUBADD: 01 ACK 04 ACK

    START
    DEVADD: 51 READ  ACK
    SUBADD: 00 ACK 05 NACK

    STOP

    If you know about I^2C, the above should be self-explainatory.  If not, here's how a typical EEPROM read works:  First, the start condition tells the chip a transmission is happening;  then it sends the device address (50h is the control board's EEPROM, 51h is the display board's).   The direction of the following command is sent (read or write) then the sub-address.

    For the first transmission the address 0F10h is sent.   To read from a location in the EEPROM, you first tell the chip you're going to write and specify an address, then repeat the start condition with read.   This is kinda hacky IMO but it is how it works.

    After this, the EEPROM will spit out 1 or more bytes.  Your code has to ACK each byte except the last;  at which point you NACK to tell the chip you're done with it, and finally end with a stop condition.

    So right off the bat, they are reading locations 0F10h-0F13h from the control board EEPROM, then they read from 0F14h-0F15h.  

    They then read from the EEPROM on the LED board in a similar manner, except it's reading addresses 0100-0103h and then 0104h-0105h.

    There's some more transfers from the two EEPROMs and then they initialize the light sensor:

    START
    DEVADD: 39 WRITE ACK
    SUBADD: 80 ACK 03 ACK

    STOP

    START
    DEVADD: 39 WRITE ACK
    SUBADD: 81 ACK 00 ACK

    STOP


    Going by the datasheet for the TSL2560CL ( https://www.digikey.com/product-detail/en/ams/TSL2560CL/TSL2560CLTR-ND/3095174 )

    Device address 39h is the sensor, then they write 03h to register 00h  which turns the chip on.  Register 00h is the configuration register.

    Next, they write 00h to register 01h.  This is the "timing register".  It sets the gain to 1x, and sets integration time to 13.7ms (the longest integration time available).

    After this, the two temperature sensors are initialized:

    START
    DEVADD: 49 WRITE ACK
    SUBADD: 01 ACK 00 ACK

    STOP

    START
    DEVADD: 49 WRITE ACK
    SUBADD: 05 ACK 00 ACK

    STOP

    START
    DEVADD: 49 WRITE ACK
    SUBADD: 02 ACK 4B ACK 00 ACK

    STOP

    START
    DEVADD: 49 WRITE ACK
    SUBADD: 03 ACK 55 ACK 00 ACK

    STOP

    START
    DEVADD: 48 WRITE ACK
    SUBADD: 01 ACK 00 ACK

    STOP

    START
    DEVADD: 48 WRITE ACK
    SUBADD: 05 ACK 00 ACK

    STOP

    START
    DEVADD: 48 WRITE ACK
    SUBADD: 02 ACK 4B ACK 00 ACK

    STOP

    START
    DEVADD: 48 WRITE ACK
    SUBADD: 03 ACK 55 ACK 00 ACK

    STOP

    Device addresses 48h and 49h are the two temperature sensors.   Both are programmed identically.   The meaning of the writes is:

    01h 00h:   Write 00h to register 01h-  this is the configuration register.   This selects temperature sensor 0 (the internal temperature sensor), clears the error queue, and turns the chip on.

    05h 00h:  Write 00h to register 05h-  this is the secondary configuration register.  It's simply zeroed out since this chip does not have the "conversion start" pin.

    02h 4bh 00h:  Writes 4b00h to register 02h- this sets the lower hysteresis trip point for overtemp. ...

    Read more »

  • The Adventure Begins

    kevtris12/02/2017 at 10:01 0 comments

    Well, I have one of the modules connected up to my general purpose FPGA reverse engineering / ROM emulation rig.  There's no ROM emulation yet but I can feed it arbitrary data and receive data from the display.

    For testing, I sent it LFSR data (41 bit LFSR) at various speeds from 100KHz to 10MHz or so and so far nothing happened.  This isn't too surprising I guess.  It most likely has some kind of complex packet structure to turn the display on and configure it.

    I also hooked the FPGA's programming pin up that reconfigures it so I can reboot the board without having to power it down and up again.   This lets me catch anything that happens on startup.      While I was soldering wires, I connected the I^2C bus to my board as well.

    I will record the entire I^2C startup sequence (it's long and takes a few seconds) along with the data that comes back out of the chip on startup.   There's 4mbytes of RAM which should be plenty for this application.

    Eventually I want to replace the RAM/ROM on the board with an adapter for this emulator board and probe memory as it runs.

    One interesting thing is if you reset the board, some random rows of LEDs will flash on and off quickly as the CPLD is sent the control signals.  This doesn't happen from poweron, just if you reset the FPGA.

    The data coming back from the display seems to be boring and so far not too interesting.  It's the same data that it spits out of the output jack.   It is a 10 bit repeating pattern: 1111111111111111_0001110101_0001110101_0001110101.    If the data is interpreted such that the initial 0 is a start bit, the data becomes 0011_1010 with an extra "1" stop bit.  This is ASCII for the backslash (\) character.  I guess the data format might be basically RS-232 like in nature but synchronous instead of asynchronous.

    Changing the input clock over the entire 10KHz to 10MHz range resulted in the same exact synchronous data stream coming out.  Maybe the display is looking for text/data strings?  That'd be pretty interesting if so (and I suspect they will be present in the parallel flash).   It most likely is packetized format, and there will be commands to turn it on, check the calibration, read the temp sensors, etc.  As it is, the I^2C is not accessed again after startup so it is obviously sitting and waiting for commands before it starts doing stuff (tm).  If it is packetized it probably is checking for a hash/checksum too and it will not accept the data unless this is present.

    Here's a quick dump from signaltap.   GPIN10 and GPIN11 are the differential output from the display's input connector, GPIN12 and GPIN14 is the I^2C.  There was a gap in the I^2C data so I moved the time slider to the point where a new I^2C transaction starts.  The differential return data idles with GPIN11 high and GPIN10 low (the 111111 part above).  The data logging was triggered on the rising edge of the clock I am feeding the board so it just looks high all the time (GPOUT2 and 3 is the clock,  GPOUT 0 and 1 is the data).

  • First Impressions

    kevtris11/30/2017 at 11:15 5 comments

    I received some of the displays today and decided to poke around with them a little bit.

    There is quite a bit of activity on start up.   The I^2C bus is read for a few seconds,  the fan starts and stops, and various other things happen.

    Watching the data bus to the RAM/flash, they are constantly hitting the RAM.   At startup, you can see what I suspect is the I^2C data being written into RAM, presumably for the dot correction.

    I hooked some wires up to the back side of the control PCB and brought them out and did a little messing around.   It looks like pins 3/8 on the input connector is the clock.  Feeding it a 1MHz differential clock results in a similar clock emerging out of the output connector (pins 4/7).   When the clock is provided, a repeating synchronous data pattern is present on pins 3 and 6 of the output connector.

    If the clock is provided on startup, the output pins on the input port (pins 4/5) spit out a pretty hefty string of data shortly after power is applied.  I am not sure what data is coming out, but it definitely is something.   There doesn't seem to be a repeating pattern looking on the scope but I am unsure what it is.

    Whatever data is fed into the Din pins (5 and 8) of the output connector seems to simply be passed through to the Dout pins (4/5) on the input connector when it's sitting there during normal operation.

    The passthrough appears to be combinatorial since I can feed nearly anything in and it comes out exactly the same.  The data is not sampled on the clock or anything (i.e. I can feed it a higher frequency clock and it simply passes it through).

    During the startup, it switches the outputs between passthrough and internal state (during the data it sends synchronous with the input clock) then it switches back to passthrough.

    The output clock appears to shut off (on the output connector) when the internal state is being dumped, then it starts up again afterwards when it's in passthrough mode.

    It seems that the FPGA basically passes clock/data through unless it wants to talk to the host.  I guess this makes sense. 

    I was thinking the next step might be to make a small breakout board to replace the SRAM/flash on here and connect it to my ROM emulator device to start substituting data and seeing what addresses are being read/written (as well as being able to dump the RAM contents).   This would also let me watch the bus to see what the CPU inside is doing.

    The access speed seems to be pretty fast, 25 or 50ns, so I might have to swap out the 40MHz oscillator with a 10MHz one or similar to slow it down enough so that my ROM emulator (a RAM + FPGA basically) can keep up.  We'll see.

  • Data is Beautiful

    modder_mike11/25/2017 at 06:20 7 comments

    After @kevtris posted the image of the font hidden in the image file, I thought it might be fun to poke around in there some more and see what could be seen.  I started by mapping out the following data areas (defined as "long" stretches of bytes other than 0xFF):

    0x000000-0x000003: FF FF FF FF (4 bytes)
    0x000004-0x029503: FPGA boot bitstream (169216 bytes)
    0x030002-0x03D407: Something (54278 bytes)
    0x040000-0x0400BB: Something (188 bytes)
    0x09006C-0x0A3513: Something (79016 bytes)
    0x0B0000-0x0B004B: Something (76 bytes)
    0x0D6AFC-0x113513: Something (248344 bytes)
    0x120000-0x1200D7: Something (216 bytes)
    0x1400B8-0x141B05: Something (6734 bytes)
    0x142B00-0x144605: Something (6918 bytes)
    0x145600-0x147105: Something (6918 bytes)
    0x150000-0x1500A7: Something (168 bytes)

    There are three large blocks of data, and in each area can be found a copy of the font that @kevtris documented.  Presumably these are firmware images.

    The font was found with bit spatial analysis (a term I'm using because I don't know the proper term for this) using yy-chr.  That got me thinking, what else might we figure out by looking at the dumped image visually?  So I mangled the data a bit and came out with the following grayscale representation:


    Interesting.  If we know the first band at the top is the FPGA's boot bitstream... then the band in the middle sure looks like another one - but upside down.  The data seems to back this up - starting at 0xFFFFF and continuing backward to 0xD6AFC, there seems to be another 169220 bytes of bitstream there.  I ran a diff between the two bitstreams, and though they look similar, about half of the bytes are different - and since most of the bitstream is zeros, that means there are a whole lot of differences.  But they are both undoubtedly the same type of data:

    With that chunk removed from the 248K of continuous data noted above, we end up with 79124 bytes - much closer in size to the other two similar-looking sections.  Given this, the presence of the font in all three places, as well as a set of strings in all three, it seems that the flash contains two bitstreams, three firmwares, and some small chunks of other data interspersed here and there.  Neat!

    [Edit] Addendum.  The reversed bitstream is a documented feature of Spartan-3E.  It is part of its MultiBoot function.  On first powerup, the FPGA loads a bitstream starting either at the bottom of its address range and reading up, or from the top of its address range and reading down, depending on the configuration of the bitstream header.  Then once this is loaded, by toggling the FPGA's MultiBoot Trigger signal, the FPGA is instructed to reconfigure itself from the opposite end of the memory in reverse order.  Except as you see here, the second image is at 0x0FFFFF, which is not the end of the flash address space, so the programmer seems to have done something interesting with the memory architecture.  It is possible that the flash configurator (iMPACT or similar) was configured for a 1M flash, and the programmer appended additional data after the end of the MultiBoot bitstream, because I can't otherwise figure out how to get iMPACT to override the start address for the second image...

    The dual bitstream function is often used as a safety feature for field-upgradeable systems.  One of the two is protected, and the other is allowed to be written by user software.  If the upgrade goes poorly, there is always a known-good bitstream to bring up the FPGA so that it can be attempted again, and you don't have to go find the JTAG cable.  Another neat feature that Barco may have taken advantage of.

  • Some words on CPLD startup

    modder_mike11/24/2017 at 19:34 1 comment

    I took some logic analyzer plots of the startup sequence of the unknown FPGA-CPLD communication pins.  I don't know what any of it means yet, but maybe it will be of use to someone.

    This plot is taken in timing analysis at 1us/sample, just to show what the whole first two seconds of startup looks like.  There is movement up to about 600ms, then basically nothing as the module goes into 'no incoming signal, just sit here and blink' mode

    I have zoomed in on most of the transitions, and there's not really a lot going on at most of them, with the notable exception of the two little spikes around the second division.  There's actually quite a lot going on around there.  The next two plots were taken in timing analysis at 2ns/sample to adequately capture the clock rate.

    Here's the tail end of the first data blip.  Pins 2, 3 and 5 have relatively constant transitions with occasional rapid bursts.  Pin 6 displays serial data, as theorized in another thread this is likely SOUT data from one of the LED strings.  Pin 8 has a fairly regular clock, but this is interesting - during this startup time, the clock measures around 27MHz, but it jumps to 40MHz when the module goes idle.  What the point of this would be, I don't know.

    The second blip looks similar but the data on Pin 6 is different, the FPGA must be asking the drivers a different question.

    I have posted a Sigrok/PulseView-compatible dump of the first data burst to the Files section.  It is missing the data for PIN41 which was lost when my analyzer crashed before the dump finished, but PIN41 doesn't do anything during this time anyway.  Hopefully someone can make some sense of this.

  • Simple NX4 Test Program

    SpaceCoaster11/24/2017 at 18:30 13 comments

    I have a simple NX4 test program which displays a BRG pattern on the tile. I will update the program as we discover more secrets. Dot Correction implementation is next on the list.

    https://github.com/derekmulcahy/simple_nx4

  • Initial thoughts

    kevtris11/23/2017 at 04:30 1 comment

    Well I got on the bandwagon and bought 70 of these modules.  I hope they all or mostly all work.  Anyways, I have been poking through the ROM images posted, and I found a font inside of the parallel flash.  It lives around 83180h or so (I will check for more than 1 copy of it... the install PDF claims there's backup firmware in the flash in one of the troubleshooting sections).   The font looks like this:

    I used yy-chr to grab it.  Interesting that it's 6 pixels high, I guess this is so they can fit 6 lines of it on one of the modules. 

    Was poking through the EEPROM_panel file too, and it seems to be calibration data and possibly pixel order data too.  There's several distinct sections of data.     The EEPROM_control file is kind of weird, there's obviously data in here but it doesn't seem to be calibration data, I am not sure what would be living in here.   I guess it could be a local copy of adjusted calibration data maybe?

    My current working theory is on bootup, the controller will fetch the panel's calibration and control data out of the EEPROM_panel chip and load it into the SRAM (after some kind of processing and possible calibration with the light sensor/LEDs).  I guess over time the panel could recalibrate itself too.   The SRAM most likely holds the frame buffer as well, and during scanout it reads the pixel data and calibration data and does the fixup.

    Reading literature for other similar LED walls, they do a 3*3 matrix multiply for every single pixel to effect the calibration.  I am not sure if this does it, but I wouldn't be surprised if it does.   It might be interesting to creatively corrupt the RAM contents as it runs to see if anything happens.

    Because there is a font in the ROM, this thing most likely has some kind of diagnostics it can perform.

  • OpenNX4 source + binaries posted!

    Richard Aplin11/15/2017 at 07:00 14 comments

    A big chunk of NX4 Xilinx code (with precompiled binaries and python code to talk to the tile over UART) just posted: https://github.com/raplin/OpenNX4 

    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. 

    Goal

    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.

View all 23 project logs

Enjoy this project?

Share

Discussions

bruce.gettel wrote 11/09/2017 at 00:11 point

All - I'm not one of you experts, but I am fascinated with all things blinkenlights, and I bought 20 of these panels even though I've no idea what to do with them.  I also currently work for a Barco VAR and might have access to things that aren't all that easy for others to get.  For instance, I just downloaded the last released of firmware that Barco issued for the NX4.  

If anyone needs this or has requests for other stuff that I *might* be able to get, please ask away or contact me at bruce.gettel at gmail.

BG

  Are you sure? yes | no

Richard Aplin wrote 11/07/2017 at 23:18 point

BTW if you like now might be a good time to order an Orange Pi if you want to play along with my fiddlings (to be posted RSN);  I was planning to do some host-specific things like implement a dual-I2S receiver mode which should run at around 100mbps (plus also use the hardware H264 decode etc) and set up a "plug'n'play'display" bootable SD image. Anyway, there are a bunch of them (on aliexpress, or some vendors on amazon if you want them faster); specifically I suggest the "Orange Pi One" (if you can wait for shipping https://www.aliexpress.com/store/product/Orange-Pi-One-ubuntu-linux-and-android-mini-PC-Beyond-and-Compatible-with-Raspberry-Pi-2/1553371_32603308880.html) ; if you want wifi use a USB dongle (e.g. a decent 802.11a with useful antennas). Other OPis models (there are many) can work but there are pros and cons too long to go into here. Like any component I suggest you buy two for the usual reasons.  I really _really_ enjoy working with them as host platforms for stuff. 

  Are you sure? yes | no

SpaceCoaster wrote 11/06/2017 at 23:21 point

I checked the rotation speed of the fan using an optical tachometer. With the original firmware it starts at 5800 rpm and then turns off. If I create firmware which just pulls the FPGA pin 39, lt19333_enable low to start the fan then the speed of the fan is 4100 rpm. Some magic in the original firmware must happen to control the fan speed and somehow to make it run faster!

  Are you sure? yes | no

modder_mike wrote 11/07/2017 at 01:37 point

If you look at the voltage driving the fan, you'll find it might be something like 7.5V... I believe pin 122 on the FPGA modifies the output voltage of the LT1933.

  Are you sure? yes | no

SpaceCoaster wrote 11/07/2017 at 02:07 point

That works! Driving the panel with 12V and setting pin 122 high produces 11.1V on the fan and a speed of about 6200 rpm. Toggling pin 122 at around 1kHz and I get a speed of 5800 rpm. The fan is quiet at 4100 rpm and even quieter when off!

So pin 122 is one for the docs, fan_boost?

  Are you sure? yes | no

modder_mike wrote 11/07/2017 at 02:28 point

I called it "FAN_ADJUST"... we're not really boosting the voltage, the nominal voltage is 12 and we're really adjusting it down.  On another note, the reason you're getting 11.1V is because LT1933 can't make 12V from 12V, it needs about 14.5V minimum.  I use 16-20V, but 24V should be fine too if you have it.

I see a very faint ~40kHz spike on pin 122, I wonder if that's the nominal control frequency... I can't prove it, because all the stock bitstream seems to do without signal input is 0% or 100% duty cycle.  It has to be fast enough that the smoothing capacitor at the LT1933 feedback input sees an essentially DC voltage - keep in mind we're using PWM to drive an analog feedback circuit.

  Are you sure? yes | no

Ian Hanschen wrote 11/04/2017 at 19:48 point

Would it still be worthwhile to lift the FPGA? I damaged the LEDs getting the plastic off my first board (too excited I guess) - I was planning to reflow them since the pads look ok, but I'd be almost ok with that panel being sacrificial.

  Are you sure? yes | no

modder_mike wrote 11/04/2017 at 22:51 point

Well, that would tell us whether any of the remaining unidentified FPGA pins go anywhere, which would be nice.  I'd enjoy seeing it, if you really want to sacrifice a control board.

  Are you sure? yes | no

Ian Hanschen wrote 11/03/2017 at 15:01 point

Is anyone going to the Hackaday SuperConference?

  Are you sure? yes | no

modder_mike wrote 11/03/2017 at 17:36 point

nope :(

  Are you sure? yes | no

David Kuder wrote 11/01/2017 at 18:38 point

Is TE 206482-2 the right part number?  I couldn't find it at TE or distributors, 206485-1 however looks like the right part.

  Are you sure? yes | no

Chankster wrote 11/01/2017 at 19:38 point

I updated the parts list and can confirm these works (per the picture below).

206485-1 - CPC PLUG ASSEMBLY SIZE 11-9
206434-1 - CPC PLUG ASSEMBLY SIZE 11-8

  Are you sure? yes | no

modder_mike wrote 11/01/2017 at 21:17 point

The parts in the parts list were the connectors on the board, they shouldn't have been replaced with the plugs - they're two different parts :)

  Are you sure? yes | no

Chankster wrote 11/01/2017 at 21:33 point

I clarified the mating part numbers.

  Are you sure? yes | no

Richard Aplin wrote 11/02/2017 at 00:12 point

Thanks! Damn those things cost more each than we paid for the NX4 :-)

  Are you sure? yes | no

modder_mike wrote 11/02/2017 at 03:07 point

I guess I should clarify a little more.  206433-2 and 206486-2 are the empty housing part numbers, without the PC pins installed.  1776889-1 and 1776890-1 are the part numbers with PC pins preinstalled, but it's difficult to find info on those parts.

  Are you sure? yes | no

David Kuder wrote 11/01/2017 at 21:42 point

Thanks, yes I meant 206485-1 as the mating connector for the 9 pin.

  Are you sure? yes | no

Chankster wrote 11/01/2017 at 13:39 point

I can confirm that the TE circular connectors fit perfectly.

  Are you sure? yes | no

Ian Hanschen wrote 11/01/2017 at 19:32 point

Awesome!

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 15:37 point

Watching the constant use of the flash (the FPGA is using flash pins that aren't shared with SRAM), I wonder if it has an onboard microblaze or other soft processor and it's executing a poll loop, constantly reading the instructions from flash.

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 16:36 point

How often?  I saw that there was activity on the I2C bus every so often as well, it could just be logging temperature data or something.

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 19:22 point

In my case it's constant - at least this is what I get from putting things in the 'read pin state' mode for JTAG. The address pins wiggle so I'm not sure it's logging temperature.

  Are you sure? yes | no

modder_mike wrote 11/01/2017 at 01:55 point

Are you sure?  The Chip Enable for the flash (FPGA pin 104) on my board is solid high (not enabled), whereas the Chip Enable for the SRAM (FPGA pin 31) is constantly moving.

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 03:37 point

Finally got JTAG wired up, enumerates ok! (using 2.8 for vcc)

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 02:34 point

BTW I would remind everyone that I have a dead board (dead FPGA; just sucks power and gets hot) and I'm not sure what the cause was.  At the time I had a JLink connected (and working) and was using the 3v3 on the JTAG connector as my VREF (which runs the client-side of the level shifter in the jlink). The Xilinx also has series resistors on the JTAG port (there's a small resistor pack on the bottom of the board) which is recommended for running the jtag at 3v3 by Xilinx so i'd think it would be ok. However, my board worked for an hour or something, and then everything suddenly went south; the fpga turned into a heater and essentially is now essentially shorting its power rails.  Note that this also may have been a separate rogue loose wire zapping the board, and not the jtag at all, i.e. I fat-fingered something... but given that new FPGAs are $20 a pop on digikey, I thought I'd mention it.   What I can say is that if you nab 2v8 off the fpga and use that as your JTAG VCC then there's no problem (been hooked up for days to board #2, works fine).  Honestly I kinda expected 3v3 JTAG to be ok and it probably is, but I have a cautionary tale on my desk. :-)

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 05:27 point

Have you decided whether to pull the chip off yet?  I'd like to know how many of the pins I wasn't able to immediately trace are actually used somewhere on the board, which would be pretty simple if we could see under the FPGA :)

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 05:31 point

heh ok lemmie fire up the hot air one sec. thanks for your hard work on the other pinouts..

Update: I tried for a while. It wasn't coming off. I used a rectangular nozzle on my hot air that wasn't quite the right size, I could have tried longer or with different air settings but I got bored.

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 05:39 point

You're welcome :) By the way, I see your note in the UCF you posted, "Missing: Fan control on/off"... we actually aren't, the LT1933 generates the 12V for the fan, so pin 39 is actually the fan control (though I'm not yet ready to say there's not another control pin to set speed, TBD after seeing your results).  

Coincidentally, fan control and a blinking red status LED are as far as I've made it on my own HDL adventure so far...

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 19:24 point

Have you tried those solder alloys that stay molten for much longer, like chip-quik? They make desoldering these sorts of chips easy. http://www.chipquik.com/store/index.php?cPath=200

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 01:31 point

A mike you have jtag- cool yeah I'll massage things into a working state and post to the github. Not sure if I have access - I'm "raplin"

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 15:55 point

I've added you.

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 01:29 point

Yeah can anyone with a bit more time than me beep out the pins from the flash (and ideally sram too) to the Xilinx? Lots of kiddie halloween going on here.   I'm thinking that handy firmware for this would be a multi-mode receiver where the panel will display pixels sent as any of:  SPI, WS2812, UART or I2C, if we get carried away could have images stored in the flash (programmable over the interface) and then send "image select" messages, with intensity etc. Maybe play animated GIFs?  Lots of fun things to do anyway.  I implemented a framebuffer a a BRAM and that looks fine; still haven't figured out how to change the led scanline yet tho; stuck on outputting to the first 1/6. It should be easy (e.g. a 3 pin mux select) but they did put a CPLD on the display board so maybe they made it all fancy...
I'll post some stuff to github when I have a sec. I think the free webpack xilinx ISE will program these.  I used a JLINK and an FT2232 based board (w/level shifter) both successfully, I just got a Digilent JTAG device that is supported by ISE...  "End users" should be able to just jtag the unit once with something cheap (FT2232 most likely) and then send other stuff over the data link.   

Ian you look like an FPGA pro; last time I did anything on FPGAs was the Game Genie back in the 90's, that was all Altera and Actel and 486 PCs and dos tools :-)

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 02:16 point

Re: pinout of flash and SRAM - I already beeped it out and posted it, check the project logs :)

By the way and for what it's worth to anyone else interested in working on this - I'm using a Bus Pirate with OpenOCD to poke at it.  I'll post a tutorial when I actually get something working.

  Are you sure? yes | no

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

oh thankyou! I'd install the xilinx webpack version if you don't have it

  Are you sure? yes | no

Ian Hanschen wrote 10/30/2017 at 03:50 point

TopJTAG Probe is a fine tool, thanks for the heads up!

  Are you sure? yes | no

Richard Aplin wrote 10/30/2017 at 05:34 point

I've been scheming to make something like that for SWD as well, I was pleased to see it but there's a ton you can do with the concept. So nice to sample the pins of a device you're RE'ing with just 2/4 debug connections

  Are you sure? yes | no

Ian Hanschen wrote 10/27/2017 at 15:39 point

Thanks for posting the pinout - could one of you try to dump the flash and (or) eeprom on the back of the led board? I'm curious what they contain. So far, thoughts are calibration info, gamma correction ramps, ...? Also curious why it has a whole megabyte of sram. Maybe it generates the ramps and stores them there.

  Are you sure? yes | no

modder_mike wrote 10/28/2017 at 22:14 point

Half megabyte actually (256K x 16), but yeah.  There are only 3500 individual LED dice, so that's a lot of storage per subpixel.

As for dumping the memories, I'll work on it, but I'm not sure whether Richard or I will be able to get there first... the EEPROMs will be easy, but the flash will require one of us to write some HDL to read it out to a serial port or something because there's too many pins to do it any other convenient way, and he's got the leg up on me with regard to build environment :)

  Are you sure? yes | no

Ian Hanschen wrote 10/29/2017 at 23:07 point

I had a little time this weekend, I tried to send differential signals for clock, load and data (from an lfsr) to the 3 lvds pairs. The orange "have a connection" light went on, but I wasn't able to 'fuzz' it in any interesting way. The third pair below looks to be an output (oops) - I can read a voltage off of it. So really all I got done this weekend was figuring out P and N from the FPGA datasheet.

    INPUT_CONN_PIN_5 IO_L01P_0 (P) 112 
    INPUT_CONN_PIN_4 IO_L01N_0 (N) 113

    INPUT_CONN_PIN_7 IO_L02P_0 (P) 116
    INPUT_CONN_PIN_2 IO_L02N_0 (N) 117

    INPUT_CONN_PIN_8 IP_L03P_0 (P) 119
    INPUT_CONN_PIN_3 IP_L03N_0 (N) 120

Quartus is my mainstay, I'm still learning Xilinx ISE - if Richard doesn't beat me to dumping the flash, I'll try and get that done.

  Are you sure? yes | no

modder_mike wrote 10/30/2017 at 00:10 point

Yeah, I was going to include the pin names in the pinout project log, but the length of the names screwed with the layout of the table so I scrapped them, sorry about that.

I just a half hour ago got OpenOCD talking to the board, but I don't have any useful HDL written and probably won't have time until next weekend... so we'll see who gets to it first :)

  Are you sure? yes | no

Richard Aplin wrote 10/27/2017 at 00:24 point

Fairly obvious but worth pointing out that these things have 6 (optionally differential pair) inputs so should be straightforward to support all sorts of pixel input formats; SPI, I2C, UART.. even WS2812B emulation :-)  Enough flash and ram to support all sorts of things; perhaps even enough gates for a simple soft cpu? So much fun.

  Are you sure? yes | no

modder_mike wrote 10/27/2017 at 08:15 point

Hey, on your UCF.  You and I seem to have opposite LED_XLAT and LED_MODE assignments.  I went and traced the signal all the way back to the LED drivers and I think I've got it right, but then I don't understand how your HDL works...?

  Are you sure? yes | no

Richard Aplin wrote 10/27/2017 at 08:30 point

aaahaahahaaaaa.... that explains a lot of the last few hours of random flashing! :-) Thanks!   I was fuzzing stuff last night, working over it properly this evening and yes was having weird results... yes that works much better now :-)

  Are you sure? yes | no

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

Github repo here, feel free to push: https://github.com/ianhan/barconx4

  Are you sure? yes | no

Ian Hanschen wrote 10/26/2017 at 13:56 point

Moved the last progress update from summary to a log, please fix if I screwed anything up :)

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 12:44 point

Yes! 5:33am and we have leds lighting up!

[ Note: this is the 'easy' way - this is making the panel work by reprogramming the FPGA on it (temporarily; every time you reapply power the FPGA reboots with factory code from the EEPROM chip on the board) - critically this doesn't include any understanding of the regular Barco pixel bitstream, this is reprogramming the thing very hackily to make light come out..  A better solution will be to figure out the data format Barco use, but right now I have nothing that generates that data... ]

 I totally overlooked the part of the TLC5941 sheet that says you have to wiggle BLANK every 4096 GClks else you get nothing.  Anyway.. light is now coming out of the LED array and also the separate LED_CAL_SIN leds on the back.  Plenty of figuring out left to be done but safe to say it's looking like it'll be fine. 


I'll post something useful (xilinx bitstream, video, etc) asap but here's some somewhat useful Xilinx Spartan pinouts:  

NOTE these pinouts ("Pxx") refer to the main Xilinx pin assignments; the CPLD is a simpler chip on the LED front panel PCB that (I currently assume) is a fairly simple mux-with-bells-on.

// Preliminary/incomplete Spartan 3E pin usage for NX-4 tile. Definitely not fully correct; but LEDs light up

NET "led_l_sin[1]" LOC = P2; //m101 test point

NET "led_l_sin[2]" LOC = P3;
NET "led_l_sin[3]" LOC = P4;
NET "led_l_sin[4]" LOC = P5;
//rest of the LED_L_SIN or LED_R_SIN are not fully confirmed ; may be wrong, but probably close...

NET "led_l_sin[5]" LOC = P7; 
NET "led_l_sin[6]" LOC = P8; //not fully confirmed may be wrong
NET "led_r_sin[1]" LOC = P14; //not fully confirmed may be wrong
NET "led_r_sin[2]" LOC = P15; //not fully confirmed may be wrong
NET "led_r_sin[3]" LOC = P16; //not fully confirmed may be wrong
NET "led_r_sin[4]" LOC = P17; //not fully confirmed may be wrong
NET "led_r_sin[5]" LOC = P20; //not confirmed may be wrong
NET "led_r_sin[6]" LOC = P21; //not confirmed may be wrong
NET "led_sclk" LOC = P139;   //right
NET "led_mode" LOC = P32; //m104 test point on PCB  right
NET "led_xlat" LOC = P33; //m103 test point  right
NET "led_blank" LOC = P34; //m105 tp   right - note you have to drive this actively to get light..
NET "led_xerr" LOC=P10;   //not confirmed but likely
NET "led_cal_sin" LOC=P22; //serial in to a one-off driver that runs diagnostic leds 

//Now the comms pins to the small CPLD on the LED driver board

// we don't know what these do yet, but the CPLD handles row muxing plus more

NET "led_unk_cpld_p8" LOC=P123;
NET "led_unk_cpld_p5" LOC=P126;
NET "led_unk_cpld_p6" LOC=P24; //m102 test point
NET "led_unk_cpld_p44" LOC=P23;
NET "led_unk_cpld_p43" LOC=P132;
NET "led_unk_cpld_p42" LOC=P142;
NET "led_unk_cpld_p41" LOC=P143;
    

// i2c not checked but probably right
NET "i2c_scl" LOC=P25;
NET "i2c_sda" LOC=P26;

//definitely good...

NET "led_gsclk" LOC = P140;
NET "clock" LOC = P56;   //40mhz xtal on board
NET "clock" IOSTANDARD = LVCMOS25;

NET "led_status" LOC = P60; //yellow
NET "led_status2" LOC = P62; //red

//this is a pin on the NX4 input data connector; testing here...
NET "reset" LOC = P116;

  Are you sure? yes | no

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

I've added a github repo, feel free to push code to it: https://github.com/ianhan/barconx4

  Are you sure? yes | no

modder_mike wrote 10/26/2017 at 18:23 point

Well done sir, 0 to blinky in just a few days :)

One small correction, I don't believe Spartan-3E can boot from an I2C EEPROM, so I am guessing that the firmware is actually on the Spansion flash.  There's about 16 times too much space on the flash for a XC3S250E bitstream, so they're either using multiboot (there was mention in the manual about main and backup firmware), or there's some additional user data on the flash, or both.

One of my next tasks, after finishing extracting the component pinouts, will be to dump all the memories and see what we're working with.  I don't think anyone's managed to reverse-engineer a Xilinx bitstream yet, have they?  That'd make it pretty simple :)

  Are you sure? yes | no

Richard Aplin wrote 10/26/2017 at 20:59 point

The FPGA can't boot off a serial eeprom? That sounds odd - or maybe only SPI not I2C?  Anyway... I'm guessing the flash (which uses a hell of a lot of pins, being parallel) contains dot correction for the drivers (6 bits per R/G/B) as well as the Xilinx bitstream; because the rows are muxed you'd have to reload dot correction data every scanline, which would account for it being in parallel flash. (..but they could have copied it into the framebuffer SRAM on boot from a serial flash).. one guesses they may also support some other sorts of separate per-pixel adjustable coefficient.  Either way it's got a lot of junk in the trunk; the joy of not working down to a budget :-)    Having SRAM and flash (and a reasonable amount of I/O on the IN/OUT ports) makes a really nice fpga hacker platform 

  Are you sure? yes | no

modder_mike wrote 10/27/2017 at 00:01 point

Actually, looking over the datasheet again, it probably won't boot from a SPI EEPROM either.  The allowable options are:

- Master Serial from a Xilinx Platform Flash PROM

- Serial Peripheral Interface (SPI) from an industry-standard SPI serial Flash

- Byte Peripheral Interface (BPI) Up or Down from an industry-standard x8 or x8/x16 parallel NOR Flash

- Slave Serial, typically downloaded from a processor

- Slave Parallel, typically downloaded from a processor

- Boundary Scan (JTAG), typically downloaded from a processor or system tester

I'm guessing they're using the third option on this board.  We can be sure by probing the memory interface selection pins on the FPGA, which I'll try to do tonight.

Dot correction data, interesting.  That seems like it would be more appropriate to store on the panel EEPROM though - that way, if panel and controller were separated at the factory or on RMA, the panel's correction data could be loaded by a new controller and no additional calibration would be required.  A 512K EEPROM would be plenty large to record dot correction data for 1200 LEDs.  Flash being as slow as it is, I wouldn't expect it to contain runtime data; whether the data is in flash or EEPROM, it would normally be loaded to SRAM at boot.

  Are you sure? yes | no

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 

NET "clock" IOSTANDARD = LVCMOS25;

# 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

Similar Projects

Does this project spark your interest?

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