John Dammeyer of Automation Artisans  posted several messages to a CAN (Controller Area Network) mailing list (CANLIST ) which go into great detail about the design of the rings and how CAN was used to automate them.
After a very exhausting 3 months with a few almost all-nighters here is
the result which I can now talk about.
Officially opened tonight by The Premier of British Columbia, Gordon
Campbell, the Olympic rings you see are 10m in diameter and are clearly
visible leaving YVR airport. Each ring has 150 LED based nodes using
1Mbps CAN buses to a Freescale 9S12 processor through five TKE WSC-10 CAN
bridges. The Freescale is told what to show via a USB interface through a
There are a total of 27,000 LEDs (9 of each RGBW) in the 750 Lights and
each ring has three 35m long subnets that hold 50 lights each. Every
Light is individually addressable, refreshed at a 25Hz rate and we did a
light show to demonstrate the capabilities.
Over the next few days I'll describe the successes and the problems and
how we solved some of them.
If I find any online video coverage or just even online video of the rings
I will post.
It's time to say thank you to some of the people involved in all this:
Although he no longer works at TI, at the time, Steve Corrigan helped in
determining if our Thick DeviceNet cable and trunks would work. One of
the subnet trunklines is almost 36m long. We used TI drivers for this
Bertil Bäck at TKE in Finland supplied the CAN Bridges used in the
project. We needed 5 and he had 4 in stock. He supplied the fifth one
which had been exposed to all sorts of EMC testing that no supplier in his
right mind would normally sell. It did eventually have problems but
worked and is still working. His support to help configure it for our
application which included running our test code on his own Freescale 9S12
eval board was instrumental in getting this project working.
To realize how impressive this WCS-10 Bridge is you have to realize that
every 40 mS I send a burst of 75 back to back 11 bit ID messages with 8
data bytes. The messages come from our 9S12 controller into the WCS-10
Bridge and immediately leave out 3 other CAN ports on the Bridge to the 3
ring trunklines with only a one message delay. All 75 messages took under
10mS which meant we had 30mS each cycle to query nodes for status and send
extra commands to the lights.
We have a temperature sensor in each light so after each 40mS poll we ask
a single light in each ring for status. After 6 seconds we draw a
coloured graphic of the ring cluster with node temperatures. We saw the
effect of the sun warming the lamps on the south west side more than the
North East side and the gradual cooling as the sun went down. Amazing 750
node temperature sensor array.
We also used two CAN4USB units from Steve Letkeman at Zanthic for
programming the CANOpen port of the WCS-10s and PBA Engineering used one
for testing and programming the Node IDs for each of the 750 lamps. While
that was going I also used a CANUSB from Lawicel for tracking and
verifying messages during debugging.
Dr. Jim Lacombe consulted on the Physics side of things with Airy Disk
calculations and determining optimum Lamp spacing to provide the
impression of a continuous line rather than discrete lights. The photo in
the link was taken much closer than the best position which is at a
traffic intersection a bit further back. The Premier saw the rings from
his aircraft the night before at 4 nautical miles distance and had the
light show then while we were testing. Apparently they were clearly and
distinctly ring like and visible from that far away.
Ian Mackay at Denman Software provided the Windows Show software based on
my Windows Testing software.
Coast Circuit Connections in Victoria did the board assembly. Over 27,000
through hole LEDs on 800 boards in a very short time.
Canadian Circuit and Dyco Circuts both worked over the Christmas break
between Christmas and New Years to provide PC boards for us. The time
frame was such that the boards were designed, prototyped and then put into
production in less than two weeks.
This scale of project is never just the work of one person. So thanks to
all who provided help.
Automation Artisans Inc.
Ph. 1 250 544 4950
We're finding that we will be doing the same thing. The TKE witch we are using has a CANOpen port that reports diagnostics which I only used once to set up bit rate and sample point etc. I wrote a small program that talked to a CAN4USB from Zanthic to do this. We're now going to connect to it permanently to get more up to date information. It runs at only 500 kbps but will be very useful.
We've had an interesting problem with the system that we're not entirely sure that we have solved. On occasions one of our trunk lines (sub nets) would lose communication and we had no idea why. Finally putting a scope on the bus showed that we were getting 12V noise on the CAN bus. That caused communication to fail. It was pretty messy and alas, I was so involved in trying to solve the problem that I forgot to take a scope picture. Something about it being 4C outside, windy and dark and late at night.
Anyway, we think it was a CAN Bus wire from the PC board inside one of the nodes contacting a sharply cut LED pin since some of the LEDs are fed by 12V. As the temperature shifted or from vibration, the noise became sporadic. We resorted to removing one node at a time until the signal cleaned up and looked like it was supposed to. Then we left that one out and connected nodes again. At one point the noise came back and we disconnected a second. Finally we had a working network less about 4 nodes. We installed replacements and I started the process of upgrading their node IDs.
At this point I'll embarrass myself.
Each node has a custom serial # and a node ID. Normally the new nodes are numbered '1' since that's an illegal node in the system (Node #0 is a global message to all nodes). In this case a couple of other unused node #'s were installed and so I accessed the number and verified I could talk to it. Next I told it that I wanted it changed from 145 to 78. The nodes not only have to be unique but also numbered consecutively so that we can race a block of lights around the Olympic ring.
So with the click of a button I neatly and in one single operation changed 50 nodes to all have the ID #78. Less than one second later I realized what I had just done. Most of these nodes were 45m in the air and it was 4C and dark and windy.
Fortunately we had a list of all 750 node serial #'s and what node ID had been assigned to that number; there would be 5 of each node # from 2 to 151. Slowly and methodically I'd search for a serial # starting on the list with the ones assigned 77. We worked our way through to #126 assigning the correct nodeID as we went along. It took a while since there were errors on the list where the serial numbers were recorded incorrectly. When we were done we had successfully renumbered 50 nodes in order.
It was 23:30 that night when we finally ran our test demo flashing sequences. By co-incidence, the Premier of the Province of British Columbia was just arriving from up north and at 4nm away (about 8km) had a clear view of the show. Apparently he was pleased.
Me. I had a couple of large glasses of Scotch and went to bed.
Now I find the number 78 showing up in all sorts of correspondence from co-workers. I'll never live it down.
I'm curious if others have had similar problems. For example. The nodes
draw a maximum of 4.175W on average. We needed to have 50 nodes per sub
net and cost was a factor so one of the criteria was that we wanted to use
one connector per node for power and CAN and it had to be weatherproof.
The calculated combined draw of the lamps worst case was 208.75W and the
Thick DeviceNet cable had rating of 8A maximum. That meant the worst case
lowest bus voltage had to be 26V. Ideally a 32V to 36V supply would
reduce the current and give us some headroom.
What we didn’t take into account was the power consumed by the resistance
in the cable.
Therefore if someone has done a system similar in size I'd really like to
Here are a couple of videos of the rings lights in action.
http://www.gov.bc.ca/premier/ Click on the [video] link
For people coming from other network topologies the CAN addressing model can be a bit confusing. Every ID that is sent on the bus needs to be unique to avoid duplicate IDs with different Data. So generally part of the ID has the source NodeID value embedded in it. Since no other module has the same NodeID all IDs are guaranteed to be unique.
That can change where there is a Master of course. Using a established protocol solves your problems. CANOpen or DeviceNet or NMEA2000 or J1939 or MilCAN etc. make it easier to create hardware because you don't have to think about all the network issues.
However, there are applications that the above network HLPs don't address well. My Olympic Rings was an example in point. I had 750 nodes to deal with. Each node is phsysically and firmware wise identical and interchangeable. At most I can have about 120 nodes on a single CAN bus.
My solution was to first design in the DS1822 temperature sensor and serial # chip from Dallas Semi. Now I could be guaranteed that in some way each node was unique. However, the serial number is larger than a 29 bit ID and so duplication on the lower 29 bits was possible.
Because the rings were mechanically built in 3 segments per ring I set it up to have 3 segments of 50 nodes each on the last 10m of a 35m long cable. Each cable was brought back to the control cabinet where they connected to a TKE CAN Bridge. The 5 CAN bridges connected to a 9S12 board with 5 CAN modules. So one Bridge per ring. One CAN network per ring. Total number of nodes per ring was 150 starting at node ID #2 and going up to node ID #151. Node ID #0 was reserved for global messages (higher priority too) and NodeID #1 was the default as programmed brand new node. It would be possible to have a full network of 150 nodes all with ID #1.
So I have 5 rings each with identical node IDs on 5 separate CAN buses. Each node has been programmed with one of those node #'s.
So the real question is what happens when I want to get information from a node. The application knows which ring so we're down to just one CAN bus. The NodeID # is embedded into the ID along with a Client/Server bit set to Client. The node replies to a query with the Client/Server bit set to Server. And there you have it. Unique IDs. No duplication.
If all the nodes had the same ID# I can send out a message to all nodes (#0) with the serial # of the device in the Data part along with a new node #. Only the node with a matching serial # will set it's node ID to the new value. The others ignore the message.
The key thing is to know the serial #. With the serial # and an unused nodeID I can also set a lamp to node 200 for example and then tell the lamp to turn on after sending a global message to turn all lamps off. Now I have one lamp on. I can look to see where it is and decide that way where the lamp is physically located and then assign the correct nodeID.
The above description is just one way of handling a massively large network. I welcome descriptions from others as to how they've done things.
We've lost a few CAN HVD245 transceivers on the ring lights but for the most part they have been very robust. The HVD232s have a lower voltage rating and it appears that Hot Plugging can kill them quite easily.
It hasn't been a problem on the Olympic Rings at YVR because there our power supply is lower than the maximum input voltage on the CAN lines. The dual Olympic Rings in Coal Harbour barge however run on 48V to 58V depending on whether the generator or hydrogen fuel cell are charging the batteries. Most of the time on that network we lose LM5574 switching regulators from transients that go way above the 70V limit on the devices.
Trouble with hot plugging occurs when the ground is the last pin to make contact. At that point the CAN lines become the lowest potential point and we exceed maximum voltage rating on any pin and the occasional HDV245 will die. We've learned the hard way not to hot plug on that system.
Our biggest failure rate has been with the HDV232 on a CAN to USB dongle. It's got only a 16V maximum on any pin rating and we need to test our lamps with a 24VDC supply since the regulator circuit is designed to not turn on below 18V. Hot plugging that puppy has killed the devices so all four of our dongles have had at least one HDV232 replaced.
In hind sight it would have been nice to use isolated CAN transceivers but availability and cost were issues. Steve C. can confirm that you can probably hot plug with a ground pin that is longer than the rest and makes contact first thereby preventing a differential from Power to CAN lines.
It's what you do whenever you plug something into a connector that already has voltage on the connector. For example, when you plug a lamp into the wall and the switch on the lamp is on, then you are hot plugging the lamp. Won't hurt the lamp. Pretty well 99.9% of any equipment you buy can be plugged into the wall while it's turned on since that simulates plugging it in when it's turned off.
But if you plug in an electronic device onto a DC (or AC) bus along with signal lines, and the ground is plugged in last there is a good likelihood that the device will try to power up using the signal lines as a ground reference which can cause all sorts of problems.
Ideally, you shut down power, then plug it in, then turn on power. For the YVR Olympic rings we often have a service guy go out with a bucket truck to replace the occasional lamp that dies from water slowly leaking in. Because of the guy wires, he may take as long as a half an hour to navigate the bucket up to the defective light. And often he's the only one on site. Turning off power then going up, plugging in a lamp, going down, turning on power and finding it didn't work is just too expensive so we hot plug.
What would be nice would be AMP CPC pins that are different lengths so we could make the ground pin longer than the rest. But alas, they don't make them.