It used to be that we’d write the pixel’s DMX address in firmware, then compile and program each PIC. It worked well but got tedious.
Several thousand pixels later, we’ve got field-programmable source code up and running.
Short version: the PIC listens for an alternate (non-zero, dimmer data always is zero) start code in the DMX stream. That start code is followed by a special packet of data which contains, among other things, the new start address plus a checksum. The chances of this particular packet occurring naturally in your lighting rig are one the order of 1 in 2^80. That’s a 1 followed by 24 zeros. At the time of this writing, this number is slightly higher than the new US national debt.
‘Programming’ packets can be sent at any time.
The new address is, of course, stored in the processor’s permanent memory.
The address is also displayed by the pixel on power-up. The red LED flashes once (.2 S duration) for each ‘hundred’ in the pixel’s address or once (.6 S duration) if there are no hundreds.
Likewise for green / tens and blue / ones.
Channel 1 = long | long | short
Channel 12 = long | short | short short
Channel 304 = short short short | long | short short short short
So now, all pixels can be factory programmed with the same firmware. This saves us a tremendous amount of time.
Firmware works for point source, ‘mini’ and ‘classic’ pixels and is totally backwards-compatible with anything we’ve ever shipped. It will also work in 3-channel mode on the through-hole DIY pixels. Haven’t had time to mess with the 5-channel version.
Contact us for a .hex file if you want to re-burn your own pixels. Or send ’em back and we’ll be happy to re-flash them with this new code. Programmers are $46 and will be available soon in the online store.
Watch it work in the clip below. Click the arrows in the bottom right corner of the video frame for a full-screen version.
Boring technical bits:
A normal DMX packet looks something like this on a ‘scope:
BREAK 0 X X X X X X X
Where 0 is the start code, which is then followed by between 1 and 512 8-bit channel values.
Our pixel programming packets have 11 bytes and look like this:
BREAK P I X E L S HH LL CHECK 0xFF
‘P’ is the upper-case ASCII character having a hex value of 0x50. ‘I’ is 0x49, etc. HH is the high byte of the new address. LL is the low byte of the new address. CHECK is the 8-bit sum of the high and low address bytes, overflow ignored.
Programming packets which don’t precisely match this format are rejected.
The pixel firmware doesn’t currently error-check the new address, so values between 513 and 65535 are technically valid. They’ll just never light up in any production lighting rig. However, the programmer firmware is range limited to [1 510]. What good would it do to park a 3-channel pixel at 512?