Milisecond start tree

 Previous   Continue   Next 

Table of Contents

Technology is changing, technology is changing the world...
At our client's tuning party (greetings) a participant using a fast camera in SlowMotion mode at 200 frames per second captured the moment of switching the start Christmas tree from the last orange to green. It was a double, seven‑point tree, i.e. it has three orange, green, red lights for each lane separately, plus four pre‑stage and stage lights.
The footage showed that with heavy slow‑down you can see that the green lights do not light up simultaneously – they are separated by one or two frames, i.e. thousandths of a second. After analysis we concluded that this has no real influence on the measurement process, because the human eye cannot register such a tiny difference without modern equipment… but a slight dissatisfaction remained, so we took up the challenge.
As a result of reviewing the firmware, Windows software and hardware we achieved several optimizations:

• First we tackled the transmission speed of commands between the tree and the computer. We increased it 24‑fold, up to 230 kbps, but at that speed there were concerns about stability and noise immunity in field conditions – finally we kept it lower, giving a 12‑fold speed‑up in transmission.
• Next were the firmware commands themselves. Although they were already minimalistic, they were largely responsible for the visual difference – because the left and right parts of the tree received separate commands. The difference would not be visible without beloved Windows… The UART interface is built so that when you send bytes one after another, it can transmit the first byte, take a coffee break, check the net, handle other processes, fiddle with the disk and only then send the second byte. Effect: the right green lights up faster than the left. After a few calculations we managed to compress the command for the left tree, the command for the right tree and the control data into a single byte. Thanks to these tricks the command became indivisible and reaches the tree’s firmware at the same moment for left and right sides (2× faster).
• The problem was subdued but a certain dissatisfaction remained… the programmer knows that the command reaching the tree’s microprocessor is processed sequentially for each light (point). Each such command lasts about 3.5 microseconds, plus a conditional instruction. Can something be done about it? As it turns out, yes. Good old assembly comes to the rescue. I wrote a simple and effective equivalent of the light‑turn‑on instruction that lasts… only 0.19 microseconds – 17× faster.

To sum up, faster transmission, shorter command, faster firmware and an atomic (uninterruptible) operation: 12 × 2 × 17 = 408 times faster, without changing the driver. Final tests at 960 frames per second recording show no difference in switching (the programmer knows there is some, however), we are waiting for faster cameras to become available (: