COLORCLOCK

What time is it?

Amber o'clock-ish (?)

Feb 3

An Iterative Approach

I have decided on a multi-stage approach to development where each iteration has increased functionality to the previous. This diagram illustrates the top-level electronic design, with each iteration of implementation.

Top-Level Schematic

Notes

RGB PWM wires represent the red, green, and blue PWM outputs from the Arduino. The output from the Arduino will be stepped up to 12V to power the LEDs on the light display.
I2C serial wires include clock (SCL) and data (SDA) lines.
Time display is used by the artist during installation. Time display will be hidden from viewers.

Version Summary

V0 | Minimum viable product; one ColorClock with 24 hr cycle time

V1 | Includes interface and second ColorClock for participant interaction

V2 | Includes additional ColorClock to previous versions with 60 min cycle time

V3 | Includes additional ColorClock to previous versions with cycle time equivalent to length of event week

Jan 28

ColorClock Design is Shaping Up

It's been a productive weekend for ColorClock design. My collaborator / partner and I have decided on a form that we are happy with and are now looking into materials - and consequently design modifications to accommodate for standard sizing and availability of said materials.

Fabrication

Up until this point, the physical design of ColorClock has been undefined; I've focused on the software and less on the construction of the end product. I've been drawn to the idea of a circular light which is in line with the cyclical nature of time, and the form factor of a wall clock. We considered that this piece needs to be visible during the daytime in a sunny desert, so the light needs to be shaded in some way. After countless discussions, we were thrilled to settle on this simple lean-to type shade structure with the light visible from underneath. We also decided to include a bench under the structure so that viewers would be able to experience a reprieve from the sun while enjoying the view of the ColorClock.

Hardware

The current design of ColorClock calls for non-addressable RGB LEDs, since the light only needs to display one color at any given time. We are considering either constructing our own light fixture with RGB LED strips, individual LEDs, or using a pre-fabricated circular PCB with a LED matrix. As of yesterday morning, we were leaning more towards using a pre-fabricated board to reduce the complexity of assembly and it will probably just be prettier than something we make ourselves. But when considering the size of the light that we would like (~3 foot radius), buying something pre-fab might not be feasible. There's also the question of whether we want to use RGB LED strips, or to use individual LEDs, and embark on the challenge of soldering ~200 LEDs by hand 😅

Software

The bulk of the software design and architecture is complete; the time-to-color algorithm is working, and the gradual change from one color to the next is also functioning properly. I paused development in 2021 when my test circuit was not smoothly transitioning from one color to the next but we figured out that I was simply using the wrong output pins of the Arduino. The next software task is to take user input in the form of switches to allow the time to be set externally.

The current software design uses the assumption that the LEDs are non-addressable. The time-to-color algorithm outputs three values, red, green, and blue. But if I end up using addressable LEDs, I will have to add another layer of architecture to take the RGB values and send them to the board. I'll cross that bridge when/if I get there.

Though it's possible my LED programming design will have to be modified, for now I'm directing my attention to debounce logic for pushbutton input 🤓

Jan 10

A Tale of the Lost Serial Ports, and the Linux Environment that Could Have Been

WSL 2 cannot interface with the serial ports on my PC and it makes me sad. Because that means I can't use WSL for the one use case I reallllly want it for: programming an Arduino.

It's been about a year and a half since last looking at the code base for my ColorClock project and I finally have the mental capacity to continue work on this endeavor. In one of my previous posts I shared my excitement over using the Arduino Command Line Interface because it enabled me to code and upload my programs all in a single terminal window. But, I should mention that all of my Arduino development up until this point has been on a MacBook i.e. a UNIX environment.

This past weekend I tried to recreate this development environment on my newly remodeled Windows gaming tower. I was super excited about the prospect of getting to use Windows Subsystem for Linux (WSL) and no longer needing to use Cygwin or some other Linux emulator-like-thing.

It took me hours to just to get compiling again - between dealing with Git issues, installing the toolchain, tracking and installing library files, and relearning how to interact with Arduino CLI. My efforts felt worth something for a tiny while because I got it to compile on the command line 🥳 But then... the internet rained on my parade 😭

I read somewhere that WSL doesn't play nice with the serial ports, but I was not deterred. Surely SOMEONE has been able to get WSL to communicate through serial? I was determined to find a way.

I learned about a third party program, USBIPD that would allow WSL to see my serial ports. And this was confirmed! I performed the commands on the PowerShell side (e.g. bind, attach) and then I saw my Arduino on the WSL side using lsusb!! But when when it was time to run the upload command my console spits out a no communication error.

I felt defeated. Fine. Windows. YOU WIN.

It crossed my mind to use keep using my old development environment, but that was using my 10 year old Macbook - which I love, but I have a new computer and I want to use it!

I proceeded to use VS Code with the Arduino plugin, had trouble, got it to work with PlatformIO, which worked but created so much overhead I went back to the Arduino extension and FINALLY got it to work.

To be fair, I like VS Code. The more I learn about it the more I like it. The Vim plugin is actually quite good (I can use my own .vimrc file) and the Python debugger is pretty sweet.

Honestly, I'm just happy to be working on a fun project again.