Falcon Controllers and Null Pixels

I have, upon prodding from the beloved, gotten into the programmable LED pixel Christmas light game. We’ve put together a display driven by a Falcon F4V3 controller board.

I recently discovered the need to insert a couple of null pixels into the display (mostly because I wasn’t smart enough to buy any Falcon F-Amps before getting to this point) due to too-long data lines between elements.

The documentation for the controller was not particularly clear on the way to handle such null pixels. I saw that the ‘String Ports’ page on the controller management console had a ‘Null’ column in the configuration table. The documentation says this about the column:

Used to define the number of nodes which will not light up at the start of the string. These nodes will pass data to the next node but will not light up. This is useful when there is gap between display elements larger than your pixel spacing and you don’t want to cut/splice the string between the nodes to accommodate for this.

That description implied that these pixels would be invisible to the controller – that they would be treated as if they weren’t present. However, my experimentation with the setting implied otherwise: every time I increased the ‘Null’ setting, a pixel would fall off the end of the model.

My assumption was that a Null pixel was still consuming data from the strand (or, more precisely, that the controller was not inserting an extra pixel’s worth of data in the stream) but it was being set to ‘always off’. Further experimentation showed that was wrong: pixels added to the ‘Null’ column are invisible to the model. However, the number of pixels in the strand needs to account for Null pixels.

That is, if you set the ‘Null’ count for a strand to 5, you need to increase the ‘Pixel Count’ for the strand by 5 as well. Doing so adjusts the ‘End Channel’ for the strand up by a commensurate number of channels, but that doesn’t seem to reflect reality: I’ve added Null pixels that would (according to the controller interface) cause a channel conflict with another strand, but the model seems to work correctly.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.