Close

Simple NX4 Test Program

A project log for BARCO NX-4 GROUP REVERSING ADVENTURE

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

spacecoasterSpaceCoaster 11/24/2017 at 18:3013 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

Discussions

Richard Aplin wrote 11/26/2017 at 11:34 point

Yay row scanning. The reason I couldn't figure it out by fuzzing the pins is embarassing; my project has a zillion warnings, which I largely ignored, and one of the warnings was helpfully pointing out that due to a typo I left cpld_p2 permanently dangling (undriven) no matter what I thought I was doing to it.  That'll learn me.. or maybe not. Anyway, yay, rows. Thanks!

Oh minor thing; I saw some stuff where the NX4 was being promoted for 3D use (with active shutter glasses), so that would possibly require a bit of extra sram & link bandwidth... If anyone cared about 3D, which it appears they don't.  :-)

  Are you sure? yes | no

SpaceCoaster wrote 11/26/2017 at 13:55 point

Playing ISE warning whack-a-mole sometimes is worthwhile. Looking forward to watching low res movies.

  Are you sure? yes | no

Richard Aplin wrote 11/26/2017 at 05:14 point

I confirm Spacecoaster's picture; even if tile has been powered down for few seconds, I can apply power, load this and I get all rows lighing r,g,b as shown.  Yay!  I recompiled from github; I uploaded my builds as both .bit and .svf...  I note that my SVF and his are different; try the one I made.  

  Are you sure? yes | no

SpaceCoaster wrote 11/25/2017 at 02:08 point

@modder_mike I am not doing dot correction, maybe your panel defaults to almost off for all the pixels. Your SOUT capture would have a lot of low values in the section for DC.

  Are you sure? yes | no

modder_mike wrote 11/24/2017 at 20:05 point

Neat!  But, I tried to compile and program it, and I don't get any display, just a blinking yellow light.  Can you post a SVF to make sure my environment is not to blame?

  Are you sure? yes | no

SpaceCoaster wrote 11/24/2017 at 21:42 point

@modder_mike   simple_nx4_8eab499.svf uploaded to files. I am not sure if I created it correctly. I am a SVF newbie.

  Are you sure? yes | no

modder_mike wrote 11/25/2017 at 01:42 point

Hmm.  Dim red light, blinking yellow light and no display.  But I discovered accidentally that if I unplug and re-plug the data connection to the panel, some (but not all) of the pixels light to varying brightness.  In 1x6 blocks, in presumably the correct color, just not all uniformly.  Weird.

We will have to wait and see if anyone else has this issue.

  Are you sure? yes | no

SpaceCoaster wrote 11/26/2017 at 15:32 point

@modder_mike Give it another go with the latest GitHub source as I have just added dot-correction. If you build it then the odds are pretty good that it will be a correct build. If it doesn't work then upload your bit file and I will try it.

  Are you sure? yes | no

modder_mike wrote 11/26/2017 at 17:07 point

Aha, this time it works.  Awesome :)

[Edit] I note that the red light is fully red now, where before when it wasn't working it was off or dim.  I wonder what that means?

  Are you sure? yes | no

SpaceCoaster wrote 11/29/2017 at 04:55 point

@modder_mike the red light is tied to the inverted led_xerr line. That line has a pull-up as it is a wired-or from all the TLC5941 chips. It blinks a bit on mine. 

  Are you sure? yes | no

modder_mike wrote 11/29/2017 at 05:07 point

Hmm.  So, then, an "off" light would have meant that the LED driver(s) were constantly throwing a LED Open or Thermal Flag error?  That's concerning.  Also, why do you think you see yours blink?  It seems like neither of those errors should be thrown on a working panel at low output power.

  Are you sure? yes | no

SpaceCoaster wrote 11/29/2017 at 05:15 point

I looked at it with a logic analyzer and the led_xerr signal is being pulled up and down at times which match when we do data transfer. Perhaps some other status is being encoded on it. Did you say that led_xerr is going via the CPLD? I just replaced the LED panel as I broke an LED when disassembling my first panel. Now the red led is visually steady. I will check it with the LA in the morning.

In toplevel.v

assign status_red = !led_xerr; // XERR is active low

  Are you sure? yes | no

modder_mike wrote 11/29/2017 at 06:12 point

Yeah, I should have read the HDL before I asked... but I'm lazy :)

XERR doesn't go to the CPLD, it's open drain and I seem to recall they're all just tied together to the same FPGA pin... the same data can be shifted out on SOUT in case the FPGA needs to figure out which specific driver is having problems.  According to the TLC5941 datasheet, the only two errors which activate XERR are LED Open and Thermal Flag, so seeing either one is strange.

  Are you sure? yes | no