Stick a Pin in It

I’ve been working on a side project that uses some of the WS2812 based LED strips, just like the “NeoPixel” strips from Adafruit. Unfortunately, I began having problems with the strips in that they suddenly stopped responding to any control signals being sent to them. My suspicion was either a broken solder point or a dead pixel. Since they function by buffering the data and then sending it along to the next pixel in the line they have that old style Christmas lights problem of all lights after a broken light will not function.

As they were already installed in what was to be their final setup, this brought about the issue of getting access to the control signal at various points without tearing it all apart and removing the waterproof epoxy coating that covers the strip. I had set the problem aside for a while but then happened to walk by some sewing supplies in my house and noted a pin cushion… but I wasn’t seeing pins. I was seeing logic probes.

It seemed too simple to work, but I grabbed a pin and some alligator clip wires, and tried using the pin to inject control signals at various points along the strips… and it worked! Not only did it work through the waterproofing epoxy but in the wires between segments of LED strips as well. I could easily press the pin through the wire insulator, make a connection, and never really risk creating an exposed wire.

In the end, it turned out that the very first LED in the run at somehow fried its control chip. The was easily confirmed by using the pin to connect the data pad just after that pixel to the control signal and, sure enough, the rest of the strip lit up. So, quickly swapping that segment of LEDs fixed the problem and I was up and running again.

While the original idea was somewhat specific to these type of LED strips, I was quite impressed with how well it worked on regular hookup wires. I will definitely be using this trick for troubleshooting in the future. Sometimes you don’t need expensive tools, just some sewing supplies 🙂

PCB Fail

Ever since first trying KiCad and OSH Park I have been a little hooked on being able to throw together a custom PC, have it professionally manufactured, and shipped to me within a couple weeks. We’ve used KiCad and OSH Park on all of our prototypes here at Maniacal Labs but Dan and I use them constantly for our own projects as well. It’s quick and cheap, but I recently discovered the hard way not to go too quickly.

I was designing a PCB for a custom LED strip controller for a costume piece I’m working on. Nothing overly complicated, just an ATMega1284p, a button, rotary encoder, OLED screen, and a few capacitors and resistors. I had already breadboard the entire circuit and was confident it would work, so I decided to throw together the PCB and get it ordered.

Since I already had a design for an ATMega1284p breakout board I had design and used, I started with that, removed the parts I didn’t need and added in the button, encoder and screen. But re-using this design was also where I went a little wrong. KiCad has a feature called a “net name” where you can just drop a little tag on a component pin, name it, and all other tags with the same name will be connected automatically in the PCB routing. It’s a really great way to de-clutter your schematic.

However, my original breakout board design had a net named “RST” which was for the ATMega RESET pin, that gets hooked up to the FTDI & ICSP headers and pulled to VCC through a 10k ohm resistor. The problem came when I added in a schematic component for my OLED screen (a great one from Adafruit) which has a pin labeled “RST”. I needed this pin, so when I created its net name I, of course, named the net for that pin “RST”. A quick look at the design seemed enough to convince me that everything looked okay. So, after only about 25 minutes work, I sent the design to OSH Park to be fabricated.

Fast forward to yesterday. I got the boards back, solder everything on, power it up (the chip was already flashed), and… nothing. No screen display, no serial output. I tried flashing the firmware again only to find that my computer could not communicate with the chip. So, I did what I should have done in the first place. Went back to the PCB designs and used the “highlight net” tool to see what was hooked up wrong.


I quickly realized that RST on the OLED screen was connected to ATMega RESET pin. You can see the offending net brighter than the rest. The OLED RST pin is supposed to be only hooked up to PD7 on the ATMega so it can be reset from firmware. Without having a schematic for the OLED it’s hard to say, but my suspicion is that the OLED RST pin is pulled to ground internally to default to a reset state and expects to be pulled high by the micro-controller. Therefore it was was holding the ATMega RESET pin low and preventing it from booting.

Fortunately, the fix was simple enough. Scrape away the offending PCB trace (as seen in the screenshot) and solder in a wire from the ATMega pin PD7 to the OLED itself. You can see my fix in the top image.

So, lesson learned. Always, always, double and triple check your schematic and PCB nets before sending a design off to be fabricated. Better yet, don’t design a board in less than 30 minutes and then order immediately if it happens to be 1am. Wait until the morning. You might notice a mistake or two 😉

I’m in the middle of designing a new Maniacal Labs product (more on that in another post) and have been working with a library intended for the ATMega328 but need it working on an ATTiny4313. If you ever feel cramped for flash space while working on an Arduino project, try out the ATTiny series of chips and you will quickly feel like 32KB of flash is downright massive! The ATTiny4313 is a decently capable chip, with only 5 less I/O pins than the ATMega328 but a somewhat less proportional 4KB of flash. Right away, this library was going to be trouble since a bare minimum sketch compiled down to 4667 bytes. Practically nothing for a ‘328 but more than 500 bytes more than the ‘4313 could handle and that was without actually doing anything!

Much of the problem comes from that fact that the Arduino platform enables easy programming by abstracting the complicated stuff behind single methods. It may look like less code but is, in reality, more code than is needed for many tasks. For example, the blink example from the Arduino IDE:

    void setup() {                
      pinMode(13, OUTPUT);     

    void loop() {
      digitalWrite(13, HIGH);  
      digitalWrite(13, LOW);   

This compiles to 1076 bytes. Now let’s do it the “hard” way:

    void setup() {
      //Digital 13 is PB5, set as output
      DDRB |= _BV(PINB5);  

    void loop() {
      //set the pin HIGH
      PORTB |= _BV(PINB5); 
      //set the pin LOW  
      PORTB &= ~_BV(PINB5);    

This compiles to 674 bytes, a 37% decrease!! On a chip like the ‘4313 those 402 extra bytes comprise nearly 10% of the total flash available! To further understand what all the DDRB and PORTB stuff is about, take a look at Arduino’s article about direct port manipulation. If you want to up your Arduino/AVR game, it’s some great stuff to learn.

So, I’m sure you’re asking why there’s such a huge difference. It’s simple really… take a look in the Arduino core file wiring_digital.c and you will find that digitalWrite() is really this:

void digitalWrite(uint8_t pin, uint8_t val)
    uint8_t timer = digitalPinToTimer(pin);
    uint8_t bit = digitalPinToBitMask(pin);
    uint8_t port = digitalPinToPort(pin);
    volatile uint8_t *out;

    if (port == NOT_A_PIN) return;

    // If the pin that support PWM output, we need to turn it off
    // before doing a digital write.
    if (timer != NOT_ON_TIMER) turnOffPWM(timer);

    out = portOutputRegister(port);

    uint8_t oldSREG = SREG;

    if (val == LOW) {
        *out &= ~bit;
    } else {
        *out |= bit;

    SREG = oldSREG;

Wow, lots of magic going on there, right? A large part of what’s happening is converting an easy to remember pin number (like D13) into the actual port register and register bit. The rest is mostly code to protect you from yourself, like disabling interrupts and PWM output. Much of the time, this should be of little concern but the bright people who wrote the Arduino core included it to ensure as little barrier as possible. That’s wonderful when getting started but, as you can see, wastes a lot of program flash.

So next time you find yourself running out of program flash, think about digging in a bit, looking at some datasheets, and learning to do things the hard way.

The PrismaChron (not its first name, more on that in another post) has been in the works for quite a long time. Longer even than the Binary Epoch Clock. We’ve spent that time truly fine-tuning every little aspect of it in an effort to make it a fantastic little kit that we can be proud of. Being a clock that displays its time as color, getting it just right was very important to us and that meant getting the LED diffusion perfect.

Now, some might ask why we didn’t just use diffused LEDs. This was an option, but RGB LEDs are strangely difficult to source at a reasonable cost, especially of the diffused variety. Also, we wanted to give our customers to option of displaying the clock with the light from the LEDs reflecting off another surface, like a wall. This would require non-diffused LEDs, for maximum brightness.

But with clear LEDs, the colors don’t really mix together and they are far, far too bright to look at. I was seeing spots for days before finally making diffusers for the LEDs. So, to solve this problem of having a removable diffuser, we turned to some fun tech that we’ve been experimenting with… our 3D printer.

Our Replicator 2 made prototyping new diffusers from the comfort of Maniacal Labs HQ amazingly easy. But that doesn’t mean it did not take many, many tries to get it just right. The image below shows just some of the diffusers I tried before settling on the current version (shown installed on the PrismaChron on the left).

PrismaChron Diffusers

We started with clear, or “Natural”, PLA filament and tried a variety of shapes, thicknesses and infills1. Our initial thought was to go with a nice domed shape so it would look like a really large LED, but because 3D printers lay down the material in thin layers (around 0.1-0.3mm) the areas where these layers met caused more of a refracting effecting than a diffusing one. It looked better for sure, but you could still see the individual colors. We then moved to a completely flat surface in varying thickness, only to find that even up to as much as 3mm thick, the clear2 PLA was still far too translucent to properly diffuse the colors together.

This led us to realize we would need to go with a plastic that was much more opaque and simply rely on the fact that the LEDs are extremely bright to shine through. So we ordered some pure white PLA and printed off some of the designs we had tried with the clear. The domes were absolutely too thick to let a reasonable amount of light through, so we went back to the flat design.

Finally, we found that about 1mm thick, with 100% infill and a slight bevel around the top edge worked great. Also, by printing them upside-down, the top surface (which now contacts the build plate) is completely smooth instead of slightly textured, like the last layer to print always is. This design also worked out great because, despite the 100% infill, it uses a minimum of material and can be printed at 0.3mm layer thickness (the lowest on our printer) for extremely fast prints. It was actually possible to make the clear dome versions look good but only when printed at 0.1mm layer thickness and that made it take over 15 minutes just to print one! Our final version can be printed in under four minutes and we can print a large batch of 30 in under an hour.

We’re very excited to be using this awesome technology for a (hopefully) shipping product. Even for such a small, simple component, it would have cost many thousands of dollars to produce with traditional manufacturing methods.

So, if you would like your very own PrismaChron, please visit our Tindie Fundraiser page and pre-order now to help us reach our funding goal and make this kit a reality. We even have a fully assembled option!

1 Infill is how much the printer actually fills in the “solid” parts of of object. To save material this is often set to something low, like 10%, making it still structurally sound but without wasting material. Normally this is inconsequential because most plastics used are completely opaque.

2 It’s only mostly clear and in reality has about an 20% level of opacity.

Last month, Dan and I went to the Open Source All the Things event in the Research Triangle Park and had the pleasure of meeting Jason Hibbets of both Red Hat Software and Jason gave us a lot of great advice but also asked to considering contributing to – which we, of course, couldn’t turn down!

So, if you’d like a little behind the scenes look at the beginnings of Maniacal Labs, head on over to and check out our article!

Between the three of us, we have expertise in the fields of software, electrical, and mechanical engineering. And we all have day jobs in very much closed and proprietary industries. We would not be where we are today without the wonderful open source community and maker movement. One of the most visible qualities of these communities is their willingness to help beginners and experts alike. We’re not exactly beginners, but we’re certainly not experts. A few searches on the great community uncovered a great deal of the process and pitfalls we went through while designing our first product. We were, are, and will continue to be learning along the way…