Unbelievable.

The interest this project grown far beyond anything we ever imagined.

When we started out we had a few ideas about what we wanted to achieve.  We are pleased we’ve got over our own ‘line’, and are now able to ramp things up & make the technology available to everyone else.

In the process, we’ve been asked a thousand questions concerning ‘when’ and ‘how much?’

So here goes.

During 2009, we spent a lot of time (and money) researching and developing various design ideas. Where we are today is a long way down the track from the original classic pixels first released in 2005.  Our goal in 2009 was to find an affordable, reliable RGB node, suitable for large scale deployments. Getting a working design is only part of the challenge.  We’ve looked at various production options as well.

The difference in build quality between factories is significant!  Component choice is also important: inferior parts will run for a few days  or weeks, then completely or partially fail.

Sometimes cheap parts come at  a very high overall price.

Our testing will continue on some new products this year as well, but the new nodes that we have now, are performing well.

We’ve now invested a significant amount time and money ensuring our nodes will be reliable.  R&D is like that – lots and lots of sunk costs, destructive field testing, and often very little apparent result.

The nature of the Internet (and hardware hackers in general) almost certainly guarantees that someone else will find and start to sell an apparently similar product. There’s not much we can do to stop that.  And frankly, we’re not interested in trying.

Competing solely on price only leads to disappointment and frustration for all parties, and it’s not a game we’re interested in playing.

Know also that components which appear identical on a computer screen may behave in a radically different way in real life.

What we will offer – on absolutely everything that leaves the shop –  is a 100% money-back, no-questions-asked, we’ll-be-devastated-if-your-system-doesn’t-run-perfectly guarantee of support and service.  Each system will ship with a hearty helping of peace of mind.

That’s the value we’re adding to the process, and we think it’s significant.

To stay informed, just enter your name and email address in the top right corner of this page.  You’ll be the first on your block to receive  project updates.

We have got a number of other products now ready for release in 2010.  We’ve thought long and hard about how to proceed.  Our goal is to offer something useful to both the ‘DIY’ crowd and those seeking a complete turnkey solution.

Here’s What’s Planned for 2010:

A new website, dedicated solely to these products. This will include a support forum, online ordering, photo/video galleries and the more.  We will be distributing product initially from the USA and New Zealand. We’re working on wider distribution around the globe, but we can’t grow this too fast, if we want to survive!

LED Strings

We will be releasing the self contained strings for purchase end of Feb 2010.

We likely will be offering 200mm spaced nodes as well, at similar prices.  These strings will be 25 nodes long.

Led Wall Washers and Tubes

We have some very bright tubes and wall washers that we have almost finished testing.  More details will be released as they become available.

Thanks!

Again, to stay updated on the project, just enter your name and email address in the upper right corner of this page.

Questions?  Comments?  Want to reserve your bits right now?  Send a quick email to ‘john AT response-box.com.’  We’d love to hear from you.

Warmest regards,

JEC & mrpackethead

Down-under colleague mrpackethead designed this plug-in module for the Art-Net controller.  Sized to fit in the footprint of two existing logic chips, it generates 4 universes of DMX.  As boards size is limited, it contains outputs on .1″ pin headers only.  Each output is based on a discrete RS-485 driver chip and a high-speed optocoupler.

Yes, the optocouplers may not be needed.  But the extra layer of protection isn’t very expensive to include.

A few days ago, I spoke on the phone with a gentleman who installs large-scale Christmas light displays.  Apparently his client’s system was hit by lightning.  The better part of 40 controllers were destroyed, likely by current traveling up and down the data distribution network.

“I’ve never seen the inside of so many chips!  no only were the  485’s blown open but in many cases the PICs and the 74xxx chips  that go between the PICs and the optos were also blown open.  it  was amazing.

-Drew Hickman, Holiday Technologies, www.holidaytechnologies.com”.

Ouch.

'Daughterboard' for the Art-Net controller which generates 4 universes of DMX

They say that when calculating time required for a project, you should make your best estimate and double it.

Then add an order of magnitude.

So an hour becomes two days, a week becomes two months, etc.

This adage certainly holds here.

Not much new to mention today, so I’ve included a picture of the prototype controller.

It’s big – 8.12″ x 4.0″.  The end user wanted field-replaceable driver chips, so we picked some chunky DIP parts.  This board can drive 16 separate strings, and each string can contain 2048 nodes.

The original design had 2 x LM1117 SMD voltage regulators, one each for the +5 and +3v3 rails.  But heat dissipation was a problem – nearly 2 W – they were swapped out for  a TO-220 package + heat sink.  The ethernet controller (Wiznet W5100) is only available in a .3mm pitch, 80-TQFP package.  Getting all those leads soldered in only the proper place takes a steady, steady hand.

Rev2 boards are being manufactured right now, and ought to ship on Monday.

Onward!

… dropped off a well-worn package Thursday morning.  14 Kg of halfway-around-the-world happiness are now spread out on the workshop floor.

I’m now the proud owner of 1000 pieces of waterproof addressable RGB node:

A while back, I scanned blueprints of the house into the computer, and then imported them into the CAD program.  It appears that we need ~ 960 nodes to cover the rooflines, raingutters, windows and main entrance arch.

The controllers are coming along nicely as well.  I’ve currently got a single data output which can drive 300 nodes at a 25.5 Hz refresh rate.  With some optimizing, those numbers should reach 340 nodes (2 universes of DMX) and 44 Hz frame rate.

Then, it’s a simple matter of cloning the output drive code as many times as are needed, up to the limit of my firmware and the ethernet processor.  Supporting 2048 nodes (13 universes!) in a single string would be wonderful.

Monday afternoon I’m expecting a batch of controller circuit boards as well.  These boards will contain the ethernet controller.  We now have sample code which pulls data from the ethernet interface at 7+ megabits / second.

So the jump from ‘barely stable system at 10 Hz and 1 universe of Art-Net’ to ’screaming fast’ should be significant.  Switching from serial SPI mode (3 pins) to parallel data transfer mode (14 pins) makes a huge difference.

Onward!

This post is meant to answer some of the questions I’ve received in the ‘comments’ section, as well as through private email exchanges.  Specifically, “Great!  I now have $X hundred pixels.  How do I control them all?”

Having a background in theatre / live production / staging, I lean towards tools written by and for those people.

There are many choices for controlling large arrays of RGB nodes.  A nicely written tutorial on the subject is here.

A google search for ‘pixel mapping software’ will return many options. Price ranges from free to many thousands of dollars, depending on the number of outputs required. Software options include Colour-Tramp by Artistic License,  Chamsys MagiQ PC (free, multiplatform!), RadLite/PixelRange, Green Hippo’s Hippotozer software, and many more.  Also interesting is Landy Bible’s .Matrix program – sort of a poor man’s Catalyst server – which speaks Art-Net and is free from his site.

There’s also possibilities of building custom patches using MAX/MSP.  Finally, the fine folks over at kineme.org have done some neat work using Quartz Composer under Mac OS X, plus plugins for USB-DMX dongles and Art-Net.

Note that our (coming soon!) Art-Net interface will work with all of these commercial programs…

Co-developer has been working on the code needed for driving a string of TriPix.  Now that we’ve got Art-Net receive code and TriPix transmit code, all that’s left is to merge the two together.  Should have something stable by the end of the week.

The chip which handles the low-level ethernet routines is tiny.  It’s the size of a regular 44-TQFP package, but there’s 80 pins instead.  The pins sit on a fine, fine pitch – and I’m glad the robots at the assembly shop will be handling that part of the job.  Wouldn’t want to try soldering it by hand.  

On a side note, we currently use two shops for assembly.  One is in Asia.  They do fantastic work on high volume projects and the prices can’t be beat.  Usually takes 20-30 days to turn an assembly project around.  The other shop is here in town – about 15 minutes away.  Though their assembly costs are typically higher, it’s great to have partners who work in the same time zone, speak the same language, and can work really, really quickly.  They’ll regularly assembly our orders of 10-20 circuit boards – some fairly complex – in just 2 or 3 days.

It looks like the controller will be able to parse 2 consecutive universes of data (1024 channels), which roughly equates to 340 RGB nodes.

Demo video of  a handful of Tripix being driven:

Good news is that we’re now successfully receiving & parsing Art-Net packets.  Bad news is the code barfs with more than one universe at full speed (512 channels at 44 Hz) on the wire.

 Next task is to optimize some buffers and convert critical parts of the human-readable code into super-efficient machine language.  Hopefully this will dramatically increase the system throughput.

Estimates at this time is that our single controller will be able to support 5-6 universes of DMX over Art-Net at full speed.  Anyone need a crazy inexpensive Art-Net to DMX bridge?

Good times. More soon.

A challenge with point source pixels, classic pixels, Tripix and RGB emitters in general is that they require stacks and stacks of data to run properly and smoothly.  Unfortunately, a regular DMX universe contains 512 channels, which is only enough to drive 170 3-color pixels at 8 bits per color.

Last year, my personal rig required the better part of two universes.

This year, folks are running displays based our pixels and sized between 1K and 7K discretely controlled RGB emitters.  On the high end, that’s nearly 20,000 bytes of data for each ‘frame’ of a display scene.  Step that up to video playback speed (30 fps) and the datarate approaches 6 megabits per second, sustained.

Driving a rig that size with regular DMX gear costs a small fortune in cable and connectors alone.  And one of the biggest, baddest $40K lighting consoles in town, the GrandMA, tops out at about 16,000 channels.   

Enter Art-Net.

For the uninitiated, Art-Net is a totally open, freely-published, ethernet-based transport protocol for lighting control data.  It’s based on UDP packets and traverses regular (inexpensive!) ethernet switches and hubs with ease.  It can zip through the air over a wireless internet connection. Even the iPhone / iPod Touch can generate Art-Net packets.  Best of all, the potential bandwidth is massive.  

From the official spec:

A theoretical limit of 255 universes of DMX512 exists in this specification. However a simplistic data rate comparison (DMX runs at 250KBaud, 10BaseT at 10MBaud) suggests a maximum of 40 universes of DMX is the limit. Art-Net uses a simple delta transmission compression technique that will provide about 40 universes. If an installation of more than say 30 universes is contemplated, then it is necessary to use the unicast features of Art-Net II and 100BaseT or better physical layer. If this is done the number of universes limit becomes purely related to the network bandwidth.

Click here for a PDF copy of the Art-Net spec.

But how do you get data out of an ethernet cable and in to your lighting rig?  You need an ‘Art-Net to DMX Bridge.’  They typically contain an ethernet jack and between 1-8 XLR connectors (one per universe).  Lots of companies make them.  Though prices have come down a bit as the technology has matured, current pricing seems to be $200 – $250 per universe of DMX output.

For that reason, we’ve decided to design an Art-Net node that’s directly integrated with the existing Tripix controller.  We’ll bypass the discrete equipment (and cable, and connectors, and cost, and hassle) required for Art-Net–>DMX and DMX–>Tripix and drive the pixels directly.

It’s likely that the node will receive 2 universes (1024 channels) of data.  Thus, it will be trivially easy to drive ~ 340 RGB pixels from a single controller.

Even more attractive is that the network interface will only add about $16 to the parts list of the base controller.

Plus development time.

More soon!

This post attempts to gather all of the important Point Source Pixel information in one area.  Click on any picture below to enlarge.

For pictures, video clips and more, take a look in the ‘archives’ section and peruse older posts.

Introduction

The point source pixel system was designed in 2008 to be bright, easily chained and easy to use.  To that end, we settled on a system comprised of driver boards, a ribbon cable wiring harness, and small circuit boards containing the RGB LED and appropriate DMX reception hardware.

Each pixel includes a standard RS-485 receiver and a small microcontroller.  The receiver chip converts a balanced differential signal into a standard logic level that the processor can understand.  Each pixel requires three consecutive DMX channels: one each for red, green and blue.  Red is always the first channel, green the second and blue the third.

Of course, the start address of each pixel can be set to any number between [1 510].  Thus, 170 pixels can be discretely controlled by a single DMX universe.

Pinout / Wiring Data for DMX Splitter / Driver

A driver board has headers for  power  and DMX in/through.  It contains an RS485 receiver chip and 2 RS485 transmitter chips.  Since RS485 is meant to be used in shielded, twisted pair cables (rather than ribbon cable) we decided it made most sense to drive moderately short (10′  - 20′ long) cables.  If the ribbon cable is much longer, signal integrity of the high-speed DMX data is compromised.

Thus, up to 32 driver boards may be daisy chained together.  Each driver board has two outputs.  Each output can drive between 1 and 32 RGB pixels.

The system’s backplane is based on regular 10-conductor ribbon cable.  Since these are very light cable gauges, we use 4 conductors each for power and ground.  The remaining pair transmits the DMX data.

To build the backplane, we installed 10 conductor IDC female connectors at regular points along the ribbon cable.  Spacing between 6″ and 8″ seems to work well.

Point Source Pixels have a 10-pin male header, which conveniently attaches to the ribbon cable backplane.  Naturally, the header pinout matches that of the splitter / driver boards.

Sample part numbers from www.jameco.com:

• 10 pin male header #67821, $0.21 @ qty 10 (included on assembled circuit board)
• 10 pin female IDC socket #32492, $0.25 @ qty 10
• 10 conductor ribbon cable #643815, $15.18 / 100′

System Power

Each pixel has a built-in voltage regulator which converts Vin (usually 8-12V DC) to +5v required by the processor and LED.  Note that the RGB LED is driven from the processor’s pins.  This means that the board input voltage can vary somewhat, so long as it is high enough that the voltage regulator can function properly.  We’ve had spectacular success using switching power supplies designed for / removed from computers.  They output +12v DC at many, many amps, and for a very reasonable price.  Try www.weirdstuff.com if you don’t have anything lying around.  At full power, each pixel draws just over 60 mA at 5 volts.  A bit of Ohm’s law shows that

• .06 A * 5V = .3W
• 12V / .3W =  40 mA drawn from a +12v supply.

So choose a properly sized power supply for the job.

Wiring Diagram for Point Source Pixel

DMX Addressing

Naturally, for most effective operation each pixel requires a unique DMX address.

Since each board is too small to contain a DIP switch or display + pushbuttons, there are two ways a pixels DMX start address can be set.

1. In firmware at compile time.  Using a PIC programer and Microchip’s MPLAB, each pixel’s start address can be hard-coded into program memory.  This works well (we’ve done it thousands of times) but gets tedious after a while.  Also, a special programming harness is required to access the proper pins on the chip.
2. With an external programmer.  We designed the firmware to listen for a specific sequence of data, beginning with a ‘non-zero’ start code.  This start code / data sequence would never occur in a regular lighting system.  Think of it as a secret knock on the pixel’s back door.  When the proper data and checksum is received, the start address is stored in the processor’s permanent memory.  Changing addresses is easy and takes only a few seconds and can be done without any special computer programs.  See this link for a description and video clip of the field programming system.

That’s a decent overview of the system.  Questions?  What have we missed?  Send an email to john AT response-box.com.

Finally!

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

etc.

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.

Setting Pixel Addresses in the Field from Engineering Solutions Inc on Vimeo.”>

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 0×50. ‘I’ is 0×49, 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?