Innovation is often brought about by pressure. You can do something a certain way and it is expensive, so cost pressures you to find a cheaper way. The expense can be time, material, monetary currency, complexity, reliability, lack of beauty. The expense does not even have to be real to pressure you towards innovation. It just has to be perceived.

Early on in my development of my current light installation I had to have a way to turn up and down the levels of light on Red Green and Blue LEDs. The light levels built into my RGB chip that I am using are 0-255 . There are only 256 levels. The problems are that there is nearly no difference between 254 and 255, the lowest levels are not visible, 0,1,2, and sometimes 3, cannot be seen, and the difference between 3,4,and 5 are pretty coarse and that the three colors have different properties. Some seem more linear at lower levels than others. The lowest visible level on each of them is different. Each time you want to adjust one of the levels you change the code and then load it up to the chip. Getting it to look smooth was not difficult, but at the start it was time consuming.

When using a bigger chip with more memory I used three lookup tables for the levels. This is a table that might start like this, [0,2,3,4,6,8,10,13,16, etc.] But for this piece I only had ATTiny 85 chips during the development. Others were becoming available again. The ATTiny has got “Tiny” in its name for a reason. At $1.59 its memory is limited.

Using the lookup tables I started to get “out of memory” type errors when trying to “compile” the program. Compiling is the process where what you have written gets translated into the code your computer, in this case the ATTiny can use. I had to come up with another way. The errors made no sense to me, my program did not use that much memory. But I am not a computer scientist, no degree, no deep expertise. “Live with it, find a new way”.

So, instead of using a lookup table I used multiplication and division of integers. But because numbers with decimal points use more storage, I would multiply by 106 and then divide by 100 then add 1 on the way up . So 30 stepped would step to the integer portion of 30*106/100 +1, or 32. 100 steps to 107 and as you get higher the steps get bigger. Coming down I multiply by a number less than a 100, say 94 and subtract the 1. This does not use that much less memory as far as I could figure, but it worked. Maybe there was something I did not know. I cannot know everything, sometimes I just let things be if they are working.

Well turns out I had tried to compile my software with the settings set for an ATTiny 25, not an ATTiny 85 and it has much less memory. However, the new method is much easier to tweak and keep track up so I have stuck with it. It produces numbers very similar to my lookup tables, mostly because my lookup tables were done by mostly approximating the formula in my head. The formula has a softer top or bright range and I like the way it looks. I ran a single strip of lights back and forth the old lookup table way and the new way. I like the new way. If I go back to a lookup table for some reason I will likely calculate the steps.

The chips I am talking about using in the next piece have four times as many steps. I am about to start working with them. But I think that the properties of LEDs will stay the same so the formulas will stay similar. Since the communication time with the new LEDs is also faster there should be less jitter and flicker. I am excited to see them. With more steps lookup tables become even less efficient and more difficult. The multiplication and division for indexing is much easier.