If you’re a resident of Seattle, I highly recommend you check out the Bubble events group. One of their regular events over the summer is something called “Nocturnal Push” where you can get decked out in your best glow gear and cruise the Alki Beach strip on your bike, longboard, or whatever.
That’s why I made this:
So I’m no stranger to persistance of vision LED displays. One of the first projects posted to my blog was my POV toy about this time last year. I also made the “Ice Breaker” which operates on the same principle. Persistence of vision is a very simple concept. By moving an array of LEDs quickly and blinking them in a specific pattern, you can utilize the slow response of your retinae to produce what appears to be a stationary image.
In fact, one of the first micro controller projects I ever attempted was a persistence of vision display system for a bike wheel back in 2009. I had just finished my first class on embedded design and I saw a video of Monkey Electric’s wheel lights. Knowing nothing about AVRs, I decided to attempt to make what they made using a raw 8051 with an external ROM and RAM chip all in assembly because that’s what we used in the class and I didn’t know any better.
Working with my friend Collin, we produced this:
We code named it “Green Moon” and didn’t make it much farther than what you see here. Those are paint stirrers if you’re curious.
But I digress.
So I’ve done persistence of vision displays before; there’s really nothing new there. The challenge this time was to make it small enough to fit on a 72mm longboard wheel, and to make it cheap enough so that I could mass produce it and sell it to folks in the area.
So boiling it down: I needed a consumer-ready stick of LEDs that I could control with a micro controller with a sensor that can detect wheel speed all for as cheap as possible.
Unfortunately, I didn’t quite accomplish all of these goals, and since I haven’t touched this project for over a month, I decided to officially put it to rest for the time being. I didn’t want to deprive you guys of a blog post though, so read on to find out how it works and see if you can improve it!
One of the benefits of doing a display on a longboard as opposed to a bike is that during regular use, a longboard wheel rotates many more times per second than a bike wheel. This means that it’s much easier to attain a high enough refresh rate to achieve persistence of vision. Instead of using the four arrays of LEDs like in the MonkeyElectric display which effectively refresh the image four times per rotation, I would only need one array of LEDs to refresh it once per rotation.
I wanted my display resolution to be much higher than the 8 pixel display of the Ice Breaker, but my micro controller of choice (the ATTiny24) didn’t have enough pins to spare, so I couldn’t do the one to one LED mapping that I had used before.
This means that I had to multiplex the LEDs. This presents a problem with a persistence of vision display though because when you think about it, the display itself is already “multiplexing”. It’s core function involves it only showing a single row of light at a time.
With the array multiplexed, each single row of the image involves flashing light from multiple banks of LEDs quickly in sequence. I was worried for a while that my micro controller wouldn’t be fast enough to flash all three banks of LEDs in sequence before moving on to the next row of the image. There’s also the problem of image distortion resulting from the array moving too far while a single bank is turned on.
This turned out to not be a problem as the micro controller was plenty fast. I shouldn’t have been surprised because this is exactly how the POV toy I took apart worked.
In the interest of keeping costs down, I picked the cheapest LED I could find. Pricier, more efficient LEDs would create a brighter display, but I figured that it was a sacrifice worth making as this thing was only meant to be used at night.
The other main component of my circuit was a sensor to determine the wheel speed. In order to display a steady image on the wheel, the micro controller would need to know approximately how fast the wheel was turning so it could blink the LEDs at the right times.
There are a number of ways to gather this kind of data such as electrical contacts and optical sensors. I’ve even seen a rotating POV display that uses a electronic compass to determine the rate of rotation based on the changing direction of magnetic north. I thought at first that I could use an accelerometer to detect that change in the direction of gravity, but I reasoned that the regular vibrations associated with riding a longboard on pavement would far overpower the acceleration due to gravity making an accelerometer useless.
I settled on using a 90$$^\circ$$ IR reflection sensor:
This sensor consists of an IR LED and an IR phototransistor. When the light from the LED reflects off a surface (in this case the ground) and into the phototransistor, the transistor turns on passing a signal to the micro controller which triggers an interrupt. Once per rotation, this sensor would be pointing down towards the ground and not only give the wheel speed information to the micro controller, but also orientation information for images that must be displayed upright.
After a few tries with this design, I had to give up on it. The amount of light reflected off the ground varies heavily depending on what kind of surface you happen to be rolling over. IR acts similar to visible light in many ways, so a white concrete sidewalk will reflect much more light than black pavement. I found that no amount of fiddling with the power output of the IR LED or the sensitivity of the phototransistor could make this design work consistently on any dark surfaces.
I then had the idea of using the longboard deck itself as the reflective surface. This would offer a surface at a constant distance with a controlled level of reflectivity. Unfortunately, on the longboard my friend lent me, the wheels were too far from the body of the board and there wasn’t enough IR reflecting back. I even tried adding some retro-reflective safety tape:
Which despite being really cool stuff, didn’t help too much. Even if I had gotten it to work, it depended too much on longboard geometry which isn’t very consistent between decks (some longboards have wheels that extend past the edge of the deck), so it would be less viable as a commercial product.
My next design placed the reflector inside the wheel. Longboard wheels are designed with the bearings built into the body of the wheel. This means that the wheel’s axle doesn’t rotate at all. By affixing a reflector to the axle I would have a steady measurement point that my circuit would pass once per cycle.
The reflector itself was hard to come by. My prototype used a piece of cardboard cut to shape and glued to the axle nut:
Presumably, a commercial version would come with a piece of shaped plastic that could be threaded to screw into the end of the axle bolt or shaped to fit around the nut. This was mildly off-putting as there would be costs associated with getting plastic custom formed, but it started to look like the only option that would work.
Opposing this reflector was another IR reflection sensor except this one was a surface mount model placed on the bottom of the board:
I messed up the footprint a little when printing the PCB, so it was a little ugly soldering it in…
With some minor tweaking of the IR LED and sensor, I found this method to be nearly flawless. What’s even cooler is that the orientation of the image displayed can be altered by moving the reflector around.
The main problem with this design is that again, it depends too much on board geometry. I thought going into this project that all longboard wheels are the same. I found out later that they vary quite a bit as this graphic from MuirSkate.com demonstrates:
I was thinking at first that I might be able to accommodate different wheels using different reflector shapes, but even among these categories, the wheels vary a bit, so anything designed for a specific offset wheel might not fit on another offset wheel. Furthermore, I don’t even know that I’d be able to get sideset wheels to work at all.
This is the problem that eventually killed this project, however the current design does work perfectly fine with my Freeline skates which have wheels that very closely resemble 72mm centerset longboard wheels in size and shape. While it’s a working design, it’s not a commercially viable one.
The device has one button. Deal with it.
My major concern when I started designing the PCB was keeping the device balanced. I was worried that any minor weight imbalance would cause the wheel to vibrate annoying the rider at best and tearing the PCB from the wheel at worst.
Because of this, I placed the battery (the heaviest component) directly in the center of the board:
The battery was too large to place on the top of the board as it would get in the way of the LEDs, so I had to place it on the back. This ended up being a problem for a number of reasons. The battery protruded so far from the PCB that it would hit the axle before the board could lie flush against the wheel (which might not have been a problem with a sideset wheel).
Also, at the time I was thinking that the board would need to be mounted relatively permanently either with small screws into the wheel or with some kind of semi-permanent adhesive. Putting the battery on the back would make it impossible to replace without removing the PCB.
I opted instead to put the battery on the top:
This unfortunately required me to move the row of LEDs slightly off center, but it turned out to have a negligible impact on the displayed image.
This set the wheel completely off balance, so I looked around online for some type of cheap counterweight. I remembered buying lead weights for my pinewood derby car when I was a kid, so I looked for those. Apparently kids these day aren’t badass enough to deal with the dangers of lead poisoning, so they moved down to tungsten. Tungsten is another dense metal, and tungsten spheres marketed for pinewood derby racers can be obtained very cheaply off Amazon:
They have a diameter of 4.5mm and weigh in somewhere near 1g (my scale is only so precise though Wolfram Alpha places it pretty close to that). The battery itself only weighs 3g, so a clever placement of a tungsten sphere near the edge of the board should be able to balance it.
I drilled a hole near the opposing edge and glued one of the spheres into it. I didn’t get the balance perfect, but it’s pretty close. I think it could be made perfect with minor adjustments.
The one new aspect of this project is how it’s turned on. Shopping around for power switches, I found a lot of them to be really expensive. It’s actually pretty hard to find even a crappy slide switch that’s under 50 cents. To reduce the cost of the power switch, I opted to not have one all together.
Instead, my device simply goes to sleep. In sleep mode, the ATTiny24 draws just 2uA which means that it can stay like that with a CR2032 battery for about 13.6 years before the battery dies. This might as well be the same thing as turning it off entirely.
I designed the firmware with a timer that is reset every time the button is pressed or the IR sensor picks up the reflector. When this timer runs down to zero (about two minutes), the micro controller turns off the LED array and IR sensor and goes to sleep. It can only be woken up by pushing the button again.
Unfortunately, despite all of this, the battery life of the unit isn’t very good when it’s awake. Because of the shape of my reflector and the distance to it from my board (which is separated from the wheel by a thick piece of foam tape), the IR LED still has to be fairly bright. This means that when the unit is idling (not displaying an image), it’s drawing 13mA of current.
This number could be greatly reduced by changing the shape of the reflector to reduce the distance from the sensor (something I would do if the reflector was precisely molded from plastic).
It could also be potentially reduced by polling the IR sensor once every millisecond or so instead of leaving it on continuously. This could cause a problem though because the firmware wouldn’t know the precise moment the reflector came into range, it would only know the first time it was polled. This lack of precision could cause the image to flutter similar to how it did in Icebreaker 1.0. Care would have to be taken to make sure the polling rate was fast enough
The patterns are all generated using a python script on my computer. This script takes in a 2 color PNG file and outputs an array of LED values along with an image simulating what the result will look like:
I found out after the fact that when mounted on the right wheel of my front skate and rolling forward, the image is mirrored. Also, the placement of the reflector causes the image to be rotated 180 degrees. To counter this, I flipped and rotated my PNG before sending it to the Python script so it would come out right.
A commercially viable device would need to have a method in the firmware for displaying the images in reverse in case the device was mounted on a left wheel and thus spun “backwards”. Perhaps the mode could be changed by holding down the interface button. I didn’t bother including this feature in my prototype.
I found that my device could hold just 4 patterns. Each pattern was made of a 160 element array of 1-byte values (each radial row of image was 15 bits $$\approx$$ 2 bytes). With the overhead from the compiler, that worked out to about 188 bytes of micro controller program memory per pattern. While my ATTiny24 only had enough room for 4 patterns in addition to the core firmware, its 8k counterpart could use its additional 6,000 bytes for patterns and store an estimated 35 total.
It would be nice to allow the end user to design the patterns, but the human interface parts required to pull that off would increase the cost of the unit substantially. I put this device in the same category as the blinky light things they sell at the circus. It’s kind of neat, and it’s really cheap.
The firmware for displaying these patterns is incredibly similar to the firmware of the Ice Breaker. Simply put, there’s a timer that measures how long a single rotation takes and then a function splits that time up into 80 equal increments. Every time 1/80th of the cycle elapses, the firmware displays the next row of the image. Assuming the speed of the wheel doesn’t vary too much between each cycle, this method should produce a fairly stable image.
When the wheel has stopped rotating for a second or so, the firmware stops trying to display the image and instead illuminates a single LED that represents which image it’s currently trying to display. This makes it easy for the user to select their desired image without having to spin the wheel to find out which one they’ve selected. The image is changed by pushing the button.
I took the display for a spin outside and tried to get some footage of it working. POV displays never play nice with cameras, so if you can imagine, it looks a lot better in person.
So again, I didn’t quite achieve what I set out to do, but it’s still a pretty neat gadget, and I really like how I got the power management to work. The simplicity of a single on button and an auto-shutoff is a really nice feature that I’d like to work into some future designs.
It was also a lot of fun designing a product where one of the ultimate goals was absolute cheapness. I was much more willing to take risks that potentially sacrificed the quality of the device and explore some new techniques (such as multiplexing) that I usually try to avoid.
The per unit BOM cost for components from Digikey purchased in the quantities required to make 50 units came out to $3.22. The tungsten spheres add another $.22 if I got them from Amazon. Considering the PCB is only 2.5 square inches, I imagine the PCB and assembly wouldn’t be much more than a few dollars if purchased in large enough quantities. All together, I think this kind of device could retail for a price somewhere around $6-10. Perhaps a set of four would get a discount.
I might pick up the idea of a wheel-mounted persistence of vision toy at some point in the future. I had an idea for combining the image scanning capabilities of the POV toy I reverse engineered with something wheel-mounted that might make for a fun project.
Project files can be found here: Longboard Wheel DIsplay v1.1