Our OoberLights Prototype Boards are Lighting Up!

| Comments

I’m super excited. Super duper excited! We’ve been working on the OoberLights project for quite some time. The first time I blogged about it was in May of last year, but I know we’d already spent several months hashing out the idea before then. The screenshots of the board that I used in that blog post were using the tiny WS2812 LEDs. They didn’t even exist when we started designing the board, so we were definitely already a good way into the project by May.

I don’t recall what was slowing us down. We had a few quiet months in there, but by the end of 2019, we were just about ready to pull the trigger and order the first batch of boards. Then Chinese New Year slowed us down, then COVID-19 hit. We started uploading files to PCBWay to get our quote on February 26. We went back and forth a few times answering their questions, and we finally got to pay for our order on March 5.

The boards arrived on Friday, April 23. On Sunday night, we got on a video call and started testing the first board.

What’s involved in testing the OoberLights boards

Our designer was worried that something would go wrong in his power supply circuits. Our board is designed to take a 5-volt input via USB, then it needs to supply 3.3 volts to the ESP8266 and 3.9 volts to the WS28212 LEDs. We’re also set up to take lithium-ion voltage input on an optional battery connector.

If his math was wrong, or he accidentally chose the wrong part, one of those voltages could have been out of spec, and it would be a HUGE bummer if we plugged in power and all the LEDs immediately burned out. Even if the power supplies were bad, it would be nice if we could just bypass them with external hardware. That way we could still test the ESP8266 and WS2812 LEDs and get some code written!

Our awesome hardware designer cut about a dozen of the power traces in the design and left solder pads for me to bridge, and the board is littered with test points for taking measurements. That way we could connect things up one section at a time.

He did a good job. All the power components were in spec, and nothing burned out!

This is where things got a little rocky

We were able to power the board via battery or USB, but the USB interface wasn’t working. Every time I plugged it into my computer, the Linux kernel was constantly attempting to reset the port and complaining about bad cables.

1
2
3
4

[6952390.844066] usb 3-2-port1: attempt power cycle
[6952392.091827] usb 3-2-port1: Cannot enable. Maybe the USB cable is bad?
[6952393.036179] usb 3-2-port1: Cannot enable. Maybe the USB cable is bad?
[6952393.036442] usb 3-2-port1: unable to enumerate USB device

The USB chip is small. The components that connect to it are tiny. We decided this was a good point to take a break. Our awesome designer was tasked with deliberating over the schematics, and I was tasked with digging out my FTDI board and manually flashing the ESP8266 using the programming pins we have exposed on the board.

It took a day or two before I could find where my FTDI board was hiding, find a spare mini USB cable, and get some code running on this thing. When I finally did, the news was good. Everything was working!

The truth is that I couldn’t have been more pleased with where we were at that point. The microcontroller worked. WiFi worked. The LEDs were way brighter than they need to be. The only thing that wasn’t working was the USB interface.

Even if I wound up being completely incapable of manually fixing the USB problem with my soldering iron, it wouldn’t be a big deal at all. I could have ordered up some FTDI boards, soldered them to our programming header, and happily sent any of these 10 boards to developers and testers.

We got the USB port working!

I’m glad I sat on this for a day or two. The initial suggestions involved hairy tasks. Things like disconnecting one leg on that tiny chip and connecting it directly to one of the other chips that happens to be the tiniest thing on the board, or adding minuscule capacitors in difficult places.

I’m not smart enough to understand how many new ideas actually came up, or which plans were just slight modifications of previous plans. At one point, though, our amazing designer said something I could understand. He told me to try bypassing the resistor labeled R9.

Connect a wire from one end of a tiny component to another! He was speaking my language! I can do this!

I plugged the test board into my computer and kept an eye on dmesg output. It was repeating the same error messages over and over again. Then I touched both sides of the resistor with the ends of a Dupont breadboard wire. Dupont connectors have rather thin but quite rigid conductors at the ends, so this was the best instrument I had on hand for the job.

1
2
3
4
5
6

[7100125.189710] usb 1-9: new full-speed USB device number 61 using xhci_hcd
[7100125.489721] usb 1-9: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63
[7100125.489723] usb 1-9: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[7100125.489724] usb 1-9: Product: USB2.0-Serial
[7100125.497488] ch341 1-9:1.0: ch341-uart converter detected
[7100125.508561] usb 1-9: ch341-uart converter now attached to ttyUSB0

As soon as I looked up, I saw the message that a USB serial device was connected!

After three or four attempts, I even somehow managed to hold the Dupont cable in place while flashing the ESP8266. Everything was working!

Soldering a tiny bodge wire was fiddly, and it took me at least 4 different attempts. I would get the wire in place, it would look fine, but it wouldn’t work. I’d push down on the second solder point with my thumbnail, and it would immediately connect. Three or four more attempts, and I got it working.

One of the prototypes isn’t currently in the building, so I can’t bypass the resistor on that one. I have bypassed the resistor and flashed my test firmware on the remaining eight prototype units that I have on hand. I couldn’t get the USB serial interface to work on only one of those boards, but I was able to manually flash the firmware and see the blinkenlights, so the board isn’t a total loss.

I’ve done a bad job keeping track of things. I know for certain that on one of these boards, I accidentally touched a tiny component near the resistor with the soldering iron. Was that the board that isn’t working correctly? I have no idea!

What’s next for the OoberLights project?!

On the hardware side, we have a few fixes ready to go, and we’ve already come up with a handful of important upgrades. I don’t want to tell you too much about the upgrades. If they don’t work out, I would feel bad about crushing your dreams!

We’ve only just barely begun writing software. Everything we have running on there so far is just one sort of test pattern or another.

The OoberLights board is going to be Butter, What?!’s first product. What is it going to take to get this open-source product to market?

First of all, we need to be able to sell at least several hundred OoberLights boards. We need to have a reasonably large batch produced to get the per-unit pricing down to an acceptable level.

We have some pretty good estimates on what an order of 100, 200, or 300 boards will cost. We still have to design brackets and face plates for ATX case mounting. Designing is easy, and we can do the 3D printing and CNC work to fulfill early orders, but we will have to get quotes on having this stuff done in larger quantities.

This brings us to the software.

Minimum viable product?

I hate using these three words, but they keep knocking around in my head.

When the idea for the OoberLights board was much less uber than it is today, all it had was a single ring of LEDs. The LEDs weren’t even RGB! The software was going to be so simple. Progress bars, clock-like widgets, and maybe up to four LEDs spinning round and round at different speeds.

Writing the code to do that over a serial port would be a cakewalk. It would require almost zero planning and an evening or two at the keyboard.

Now we have WiFi, colors, brightness levels, and a whole lot more pixels. The more I think about it, the more complicated it gets. I want all of the potential complexity to be handled by the software on the OoberLights. Everything should be simple for the end user.

NOTE: This is where a video of the spinner and progress bars should go. I haven’t written any code for that yet!

I could write three long blog posts about the things I want the OoberLights to be able to do, and why those things are more complicated than they seem.

For now, I think we need to focus on building that minimum viable product. We need spinners, progress bars, and clocks. That’s it. If we have that, we have something cool for someone to put in their case or on their desk.

All the cooler stuff can be added over time.

The sooner I can put these up for sale, the sooner I can order a big batch of boards. When I order a big batch, I can get OoberLights boards into more developers’ hands. I don’t believe for a minute that if I build these, developers will come, but we are going to quickly run out of hardware with only 9 working prototypes!

Some test code is available on GitLab

The test code is rudimentary and slapdash. Once we got to the point where we were able to flash code to the ESP8266, I was in a rush to see if the LEDs would actually light up! I grabbed the Arduino IDE, loaded one of the Neopixel library’s test sketches, made some tweaks, and pushed it over to the OoberLights board.

That was a success, and I’ve been building on top of that ever since. Once I got three test patterns loaded, I was trying to test the power usage at various brightness levels. Needing to flash a new build just to change the test pattern or brightness was a pain, so I wound up borrowing my home automation’s very basic web server code.

The web server can be problematic. Some of our test patterns take several seconds before ever returning to the main loop, which tends to make web calls time out. It does the job for now, but it is annoying!

I’m hopeful that we can use the Arduino IDE for all our development. That makes the OoberLights easily hackable by the widest possible audience, and I’m excited about that. I’m certain we could squeeze more out of the hardware if we use the ESP8266 SDK instead, but the CPU on the ESP8266 is overkill for our needs, so I’m not worried about giving up some performance, storage, or memory if it makes development easier for the masses!

Conclusion

I’m going to say we have nine fully functional prototypes. We’ll be getting those into the hands of developers and testers soon. We have some ideas for upgrades on the second prototype. I’ve asked our designer to hold off on making those changes until after we hear back from our testers.

What do you think of the OoberLights? Are we making something cool? Are we on the right track? Do you need something like this in your FreeNAS server? Let us know in the comments, or stop by the Butter, What?! Discord server to chat with us about it!

Comments