Ever since seeing a cool dot matrix NYC subway timetable on the background of a YouTube cooking video, I dreamt of having my one for myself. Obviously with a timetable for our household's usual routes here in Wellington.

Fast-forward a couple of years, and that is how I found myself jumping into the wonderful, complex, humbling world of Arduinos. I recently finished building a prototype and it, miraculously, works. It also ain't ideal, and I'll have to rethink parts of the build if it'll ever become a useful thing that improves our lives. 

But I learned a lot from the process of building this thing. So much so that I now have a gazzilion ideas of other stuff I want to put together to automate things around the house. Anyways, here are some of my key takeaways of this build.

Serial communication & message encoding

To my surprise, this ended up being as much of a software project as it was a hardware build. I spent the bulk of the time tinkering with the how the board and the computer exchange messages. Those of us who came up as web devs never really had to worry about packets. 

The truth is: GET/POST requests are a breeze compared to sending and receiving bytes thanks to a bunch of abstractions that we take for granted. We don't roll our own HTTP protocol for servers, right?

But I digress.

It was really cool creating my own little message encoding to enable communication between the program in the microcontroller and the little Go service I wrote to download and parse data from the MetLink API (see above about breeze).

Reliable messages, I learned, are much more than just their content.

At a minimum, what is sent over the wire requires starting and ending markers (I went with the bytes representing < and > wrappers). Adding a header with the content length was also beneficial (I reserved 3 bytes right before the content body for this), as it can help the receiving end to validate the correct number of bytes for the body were parsed.

And because of this video, I also made sure to include a version number header to future-proof this bad boy. With this, I can set a expected standard for a message and encode and decode accordingly. And, more importantly, it can be used to immediately stop execution when the expected version isn't met.

Voltage, current, resistance

I haven't had to think about Ohm's Law in about 20 years. It's the simplest of equations Voltage = Current * Resistance, and super important if you don't wanna fry your little electronics by overloading them with current, or want them to run properly.

In a way, this issue strikes me as scaling deployed services. You want to have just enough power to run efficirently, not too little, not too much.

In my case, the Arduino is perfectly happy with the 5V USB connector and it can also power other components with up to 5V. But voltage isn't everything. Most times a resistor is needed between the board and the device so that the current is regulated to the ideal range, one that will suffice the device's power needs but won't overheat and destroy it entirely. And it's so damn hard telling resistors apart.

The single power source is more than enough for now, but it is something that I really need to think about when it comes to the display option (more on my display choices below). There is a chance I'll need to add an external source to supply the screen with a bit more power than the Arduino can.

And there are so many nuances like this in an electronics build, so you gotta read each component datasheet — which is a learning experience on its own.

Not the perfect solution for the problem

There's just too much friction with the prototype in its current state.

The first problem is that it needs to be plugged to a computer at all times because I'm powering the board and exchanging messages via the USB port. That limits the placement of the display and that makes it a lot less useful when we need to keep tabs on our bus while trying to get ready in the morning.

That is compounded by the super small size of the LCD display I prototyped with, which means you need to be relatively close to it to read the timetable. Unless one of us is right by the few spots where I can keep a computer and the display rig realtively undisturbed — and, let me tell you, they aren't usually where one hangs around during the morning rush — it is easier to pull up the MetLink app on our phones to check.

The size problem could be solved with a bigger screen, and that's the "vision" for the build anyways: a 32x8 dot matrix display. But the placement is a more complicated issue to resolve. This is something that I hadn't anticipated, but it makes me wonder if I should pair it with a RaspberryPi, go with Pi-only build, or pivot to a different type of board with native wireless capabilities, such as an ESP32.

Tweezers

Just get tweezers. Best money I ever spent was a set of 3 precision anti-static tweezers.