Skip to content

Archive for May, 2017


Word Clock – revisited

Back in 2014 I built a word clock that consisted of a strip of 111 Neopixels (WS2812B), controlled by an Arduino.

I got all fancy with it, wrote a custom application for the Mac for all the settings and changed the time base more than just a few times. Everything from picking up the GPS RF transmission here, to a direct GPS module, and even a RTC (DS3231).

It has been running fairly well until the last few weeks when the “Twelve” word started to exhibit some odd colours and wouldn’t completely shut off. Of course then I noticed other things like the printed paper mask I was using for the words had started to fade a bit, allowing the square boxes to shine through. Lastly the colours didn’t look all that vibrant any more.

I tried a couple of bandaid fixes for it and Carol suggested I needed to redesign it.

Redesign – Rip apart

I think I spent the better part of a week going through all the permutations of controls when it finally dawned on me that I needed to come up with a new face design. I took the foam board, paper and ripped it all apart so the only part remaining was the backplane with the Neopixels on it.

IMG 1080

The next thing was to write a quick Arduino test routine to make sure the LED’s are all working. Oddly enough, even though the Twelve word was failing for the last couple of pixels, my test routine proved there was nothing wrong with those pixels…mmmm Odd…

New Cell Design

Guess who has a couple of 3D printers? I kind of balked at first because it’s not just a design small enough to print in one afternoon. It had to be done in pieces, the pieces put together somehow, and so on. Oddly enough as I used Tinkercad to design what I wanted, it started to go together easier.

Each of the words, like the original would be a box on their own. I thought about how to put the cells together to make the grid and realized the easiest way was to use some of those M3 screws I have.

IMG 1081

I did a row at a time, screwed end to end, then fit them between the side frame rails. More screws and I just kept printing and assembling.

For the “lens”, I printed two layers of white PLA. I tried thinner and thicker layers but two seemed to work the best. I also tested some transparent PLA but you could see the Neopixels behind the lens so that wasn’t going to do. The white diffused the LED’s perfectly.

IMG 1082

Eventually I got the whole display done and then had to work on the electronic control.

Clock Electronics

To control the Neopixels all that is required is an Arduino. But then I was back to a RTC, GPS or RF signal catcher and I really wanted something, ah, different.

I remembered I installed my own NTP time server on my OS X Mac Mini so…why not use it. I didn’t want to use an Ardunio with Wifi or ethernet, so I decided on an ESPduino D1. The ESPduino is nothing more than an Esp8266 with a CH340G uart connection. I have a couple of them in my parts bin thus if I blow one up, I have a spare.

I found a few sketches that showed how to do NTP, and then I came across a sketch that did it with an 8 digit seven segment display. I have the same display and wired it up for testing just to make sure it worked. It worked quite nicely with my ESPduino D1.

I used the sketch as a starting point for my word clock because my logic and control is significantly different. About an hour later I had a working clock.

IMG 1085

Clock Box

The original box was still in good condition and I used it again. Even managed to reuse the matte from the original in 2014.

IMG 1086

I was going to use a dc-dc buck converter to drop 12V down to 5V but decided to make it even more simple and just use an iPhone charger to supply the 5V everything was going to run off.

Plugged it all in, connected to the access point, set it to use my wireless network and it sprang to life…

IMG 1092

The Tweaks

The original clock had bluetooth for adjustments, colours, brightness, light levels for auto dim and so on. Honestly in the three years it’s been running, I never adjusted any of that. Instead I kept the new build simple with one of the original tweaks left in. The auto brightness.

There’s an LDR mounted in the top of the frame. When the light level in the room drops below a specific level, the clock brightness drops to it’s night time setting. That’s it. Simple.

I printed a ESPDuino D1 mounting plate I found on Thingiverse, stuck it to the back of the foam board, plugged in a USB cable from the iPhone charger and away it went.

IMG 1093

Six connections to the ESPduino and it’s wired.

For the Twelve issue, when I went back through the original sketch I wrote, I missed the number of Neopixels in the strip. By one. My math is better now…


Ole Mega Ain’t What She Used To Be

The Arduino Mega2560 has been around a long time, at least in the world of micro controllers. Since 2009 so it’s not the new kid on the block by any means. In that time we’ve moved through to R3, revision 3, and it has been a robust hard working reliable platform.

Right up to the point that someone with the IQ of a stump decided to dump the ATMEGA 16U2 and incorporate the cheaper CH340G USB to serial mangler. In most cases, this piece of digital cruft will work. But there is no comparison if you lift the hood or try kicking the tires.


It’s decidedly easy to spot the CH340G, at this point. Course if the same low life decides to change the packaging it’s going to be a little tougher. In the photo, and probably what you’ll see more of than anything else is the one on the left with the CH340. It’s a 16 pin DIP package.


I feel the CH340 has but one goal in life. It pollutes Arduino boards, and it converts from USB to Serial and back.

On the other end of the spectrum, the ATMEGA16U2 is a microcontroller that firmware can be programmed into. Thus you can change the firmware and your computer will think it’s connected to a mouse, joystick, or keyboard. This is impossible to do with a CH340G.

An Arduino MEGA with a ATMEGA16U2 is plug and play for the most part. Most computers will recognize it in a few seconds after you plug it in.

The CH340G on the other hand, requires a driver to be downloaded and installed. Because of its brain dead nature, no computer is equipped to communicate with it unless that driver is there.

From what I can see, there is little price difference between the two but the ATMEGA16U2 is far superior. It might take a little more time to program the 16U2 to be a UART, so perhaps they are more intent on saving time than a users sanity.

The Sheep In The Closet

If you’re thinking, big deal, doesn’t matter to me, it might, depending on what you want to do with the MEGA.

For example, let’s say you want to do some blinky lights, Neopixels, TFT/LCD display, or some sensors. No big deal, it’ll work just fine because the 2560 chip is doing all the work. The 340G is just the way you program the 2560.

On the other hand, let’s shove a RAMPS board on it, upload some MARLIN firmware to it and then connect to it and run our 3D printer. At a high baud rate. Where a LOT of printers like to live. Specifically 250,000 baud. Don’t be surprised if you see messages from PrintRun like this:

Attempted to write invalid text to console, which could be due to an invalid baudrate
Attempted to write invalid text to console, which could be due to an invalid baudrate
Attempted to write invalid text to console, which could be due to an invalid baudrate

Say WHAT? You might not see that with Repetier Host, because it tends to filter out stuff it doesn’t understand so you don’t get junk in the monitor. But you can still see some “resends” because it didn’t understand the last thing it received.

The issue truly is the baud rate. According to the “data sheet” for the CH340H:

CH340 supports common baud rates: 50, 75, 100, 110, 134.5, 150, 300, 600, 900, 1200, 1800, 2400, 3600, 4800, 9600, 14400, 19200, 28800, 33600, 38400, 56000, 57600, 76800, 115200, 128000, 153600, 230400, 460800, 921600, 1500000, 2000000 baud.

Notice there is no “250,000” baud rate in that list? The closest is 230,400.

So many have tried to just code in the 230,400 and use it. And found themselves with errors that just don’t make sense…dropping to 115K baud doesn’t help much either. Marlin’s default with RAMPS is 250K.

I have tried different baud rates and met with poor results so I leave it at 250,000 and it works best on a ATMEGA16U2.

The reason for the 250K was the ATMEGA16U I suspect. The divider of the UART of the AVR (ATMEGA16U2) used in the Arduino can create 250000 without an error, while 230400 has a 3.5% error in clock. Even if 250000 is itself a non-standard baud rate, it just works.

CH340’s Arrggh.


The biggest problem is places like Amazon and eBay. Type in Arduino MEGA2560 R3 and you’ll find correct images of an R3 board but a wrong description, images showing a CH340G but all the ad text describing the ATMEGA 16U2, and any combination thereof.

Asking the seller if it’s really a ATMEGA 16U2, I’ve found out (the hard way) is pointless. The mass majority have no clue as to the technical specifications of what they sell. Some will tell you what you want to hear and send you the wrong thing any way.

I don’t think it’s a case of bait and switch, it’s more just a case of blissful ignorance.

So you’re left with getting someone to take responsibility for what they sell. Or trying to find someone who actually knows what they sell. Either way, it’s a path that shouldn’t have be ventured down. Sadly, it’s turning out to be a path all to common.