modder_mikeI 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 Connector | Output Connector |
| 1 - +VIN | 1 - +VIN |
| 2 - Input Pair 1N | 2 - GND |
| 3 - Input Pair 2N | 3 - Output Pair 2P |
| 4 - Output Pair N | 4 - Output Pair 1N |
| 5 - Output Pair P | 5 - Input Pair P |
| 6 - GND | 6 - Output Pair 2N |
| 7 - Input Pair 1P | 7 - Output Pair 1P |
| 8 - Input Pair 2P | 8 - Input Pair N |
| 9 - ? No discernible 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.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Thanks Mike. I am adding the results in these posts to the "Project Details" above. I just found out yesterday that there's going to be a hackaday workshop this coming Wednesday at the superconference, where folks are going to be trying their hand at reversing these panels - we might be about to get a lot of help. I killed an FPGA by not figuring out that pins 4 and 5 on the input connector were likely output. I did try driving 2/7 and 3/8 with clock and LFSR data, did not work. May try it again.
Are you sure? yes | no
Oh, neat! It will be particularly interesting to see if any progress can be made on reverse engineering the existing bitstream or data protocol. As much as I appreciate the work that is being done with new HDL, the panels would be most useful if we could figure out how to drive them without reprogramming.
Are you sure? yes | no
I agree - I'd rather get their professional scanout than my attempt to match it. I've updated the details with the pin/pair information - please check my work - I'll leave the clock/data theory until it's been tested.
Are you sure? yes | no
that is true, it would be great to know what the 'real 'protocol is. I expect the tiles have a way to access their own flash for upgrading the xilinx code.. Ironically knowing the real protocol will require an FPGA upstream to generate it, whereas if you spin your own you can make up something to fit your chosen driver (e.g. SPI @80mhz over two LVDS pairs which only requires an LVDS transeiver on say a Raspberry Pi or Orange Pi, driving an arbitrary number of tiles). I'll write some project log blurb about this actually..
Are you sure? yes | no