Reading through the recent comments on my ColorNode project, it is clear that I wasn’t clear enough with how I used the hardware from a software perspective. Most of the software is based on the RF12 examples from JeeLabs. I took the RF12 Demo example and used/modified that for serial console control on both the controller and the string nodes. It implemented a nice menu system and I expanded that to send the different ColorNode commands as defined by my command packet structure. During development, I used that with a JeeNode attached to my laptop via a serial-to-USB converter as the controller and running the controller software. This also allowed me to print different debug info to the serial console so I knew if different nodes were receiving my commands or not. I eventually implemented an automatic pattern/sequence loop on the controller to cycle through different effects, as can be seen in the video. Other users may want to keep the controller connected to a PC and send it serial commands to sequence according to some other software sequencers, which could enable synchronizing the lights to music. I didn’t get there this year but maybe next year.
As far as libraries and the Arduino IDE is concerned, I slightly modified both the G35 library and the RF12 library and did all my development with Arduino version 22. When you are ready to download, select one of the ’328 boards @ 16MHz such as the Arduino Pro. For the G35 library, I used the digitalWriteFast.h macro to enable microsecond-accurate delays for the string protocol. Unfortunately, I couldn’t figure out how to make that work without hard-coding the ColorNode output pin into the G35 code, so it isn’t very universal for compatibility with other Arduino (or Arduino-compatible) boards unless you always use digital pin 19 or change it to match your configuration. The plus side is that, with the accurate delays, I get absolutely zero glitches – no stuck/flickering bulbs or wrong colors or random bulbs lighting. For the RF12 library, I have been using the rf12_easySend() function since it auto-retries. It is intended to be used with ACKs so it knows to re-send the packet until it receives an ACK from the destination or gives up after 8 retries. My nodes are programmed to not ACK when they are commanded via a broadcast message (node ID 255 – see examples below) so I hacked the timeouts and retries to be 10ms and 10, respectively, to very quickly re-send the packets and stop after 10 times. Originally, this was 1000ms and 8, but I found that the radio could be used much faster and if one or more strings didn’t receive the packet the first time, they all would after 10 retries over 100ms. This meant that all strings were synchronized to 1/10 of a second at worst case. If you are addressing one node at a time, the destination node will send an ACK when the command packet is received. The controller code will only retry 10 times if it never gets an ACK, otherwise it will stop once the ACK is received.
Here are some serial command examples:
If you are connected to a node via serial and enter “3,0,12,15,0,0,204,0,10 l” into the serial monitor (without the “”) this equates to Fade,start at bulb zero, end at bulb 12, red value 15 (max), green value zero, blue value zero, go to max intensity (0xCC in hex or 204 in decimal),use option 0 – fade in, step up the intensity once every 10ms. So, in other words, bulbs 0 through 12 would fade in from black to bright red in about 2 seconds. The l at the end basically indicates that it is the light command, versus entering just an o which turns off everything. No other parameters are necessary for the off command.
If you are connected to a node/JeeNode programmed as a controller and enter “4,25,49,15,15,15,100,1,100,255 l” this equates to Chase, use bulbs 25, through 49, red max, green max, blue max (results in white), half-intensity, use option 1 – chase down, step through the bulbs every 100ms, send the command to all bulbs (255 = broadcast). So, in other words, the lights will be a dim white and chase down from bulb 49 to bulb 25 in 100ms steps (total time would be about 2.5 seconds) and all nodes listening to the controller would run this command. The l and o commands are the same as in the node software, except you can choose which node (or all) to turn off using the o command – “255 o” would turn all strings off, “5 o” would only turn off string 5. If you want to address one node in particular, you would replace 255 with your node #. I don’t have a way right now to command anything other than all nodes or only one node. However, the commands are sent so fast that if the code was written to send a command to one node and then immediately after send it to another node, they would only be off by max 200ms (assuming it took 10 retries for node 1 and another 10 retries for node 2). If node one ACKed after the first packet and the second node did the same, then they would be synchronous within ~20ms.
One last note about the command structure – since I force retries when addressing the broadcast node (255 = all listening nodes), I have it setup to ignore any subsequent command packet that is exactly the same as the previous. I did this since the strings would sometimes get glitchy if the same light command was issued over an over again which would be the case if one node successfully heard all 10 retries. The downside of this is if you want to run the same white chase down command over and over again, it would only work the first time. The nodes would see that the new packet is the same as before and assume that it is due to retries and ignore it. In this case, you would want to issue an off command at the end of the sequence before sending the same command. This limitation only exists when sending commands wirelessly via the controller. If you program the same chase down sequence into the node software and have it loop, you can send the command to choose that particular Program (mode 1) number, then it can chase over and over again. I like using the pre-programmed sequences on the nodes better since you have much more control over individual bulb timings which allows you to make much more complex patterns than what can be accomplished via the command modes (Fade, Chase, Random, etc.). You are just kinda stuck with the programs on the nodes once they are programmed, sealed up in the box, and the strings hung up.
Attached is a .zip file with the code I used this past December for the video. It includes the Node software, Controller software, and modified libraries. I am glad that so many people are using the ColorNode hardware/software platform to control the GE Color Effects lights. Keep the comments and questions coming – I’ll try to address them as I can. Please post links to project pages or any videos of the lights in action so others can see what cool things people are doing with these lights. Thanks!
Code file: ColorNode Xmas 2011