I have the first Internet Window prototype built up. I used a laser cutter to cut a frame out of 3/16 inch thick cast acrylic. This frame is just intended to hold everything together enough that it's a single unit instead of a mess of wires. I also had to solder the power cables down.
The final version will have a frame that can be wall-mounted easily. It will also have a smaller interface board that has the correct connectors for the power cables that come with the panels. In the meantime, I will continue to document this project on Hackaday.io.
I'm starting to document a project I've been working on for the last year. This is an evolution of the seven-segment display project. Now with more LEDs.
The 12-bit Internet Window is a low resolution, high brightness, wifi-enabled display. It's main components are:
- Four 64x32 pixel RGB LED matrix panels
- A Particle Photon
- A custom interface board
- Mounting hardware
- Power supply
The interface board uses a CPLD to bridge SPI data from the Particle Photon microcontroller and the 6-wide parallel shift register interface required by the panel. This allows the microcontroller to use hardware timers and DMA to keep the display refreshed with minimal CPU overhead.
This project is largely enabled by Adafruit and their wonderful tutorials. I referenced their tutorials frequently during my design.
I'm in the process of putting together a few kits of all the necessary hardware. For now, I'm sharing them with firmware engineers willing to contribute to the open-source libraries and examples.
The first units of USB Power Armor Type-A are now available in the Reclaimer Labs store. I'm hand assembling these units to get them out quickly.
USB Power Armor allows you to charge your devices at full speed while blocking data communication. This prevents the spread of malware, such as BadUSB. To learn more about how USB Power Armor works, check out this blog post.
Highlighting the security risks of using USB to charge mobile devices, BadUSB – a class of exploits that can lead to malware infections – was recently in the news. With the adoption of USB-C, concerns are only going to increase. New devices, including the new Apple Macbook and Chromebook Pixel, only have USB-C ports, which means the only way to charge your device is through a data port that could open your computer to attack. This vulnerability is especially a concern if you want to use untrusted USB chargers, like you might find in coffee shops and airports.
One way to stop these attacks is to use a device that physically disconnects the USB data lines, while leaving the power and ground lines connected. This approach has a major disadvantage because devices and chargers use the data lines to negotiate power requirements, usually via the USB Battery Charging specification. Without that negotiation, the device can’t determine what capabilities the charger has. Instead of being able to draw 7.5 W or more, the device can only safely draw 0.5 W, which means it could take 15 times longer to charge your phone with this technique.
Fortunately, there is a way to block the USB data signals and still allow the device and charger to negotiate the correct amount of power. The key is that the power negotiation occurs much more slowly than the data flow: 100 Hz instead of 1 MHz. A capacitor across either of the data lines limits the bandwidth so that the charging negotiation can occur, but traditional USB data transfers are blocked. In fact, the USB specification has a maximum allowed capacitance between a data line and ground for this reason.
Because the difference in speed from USB Battery Charging to even USB Low Speed is so large, there is plenty of room for error. Anything over 75 pF is outside the official USB spec for data. The data lines have a typical series resistance of 33 Ohms which means a 33 nF capacitor will create an RC filter with a time constant of approximately 1 μs. A time constant of up to 100 μs is acceptable for passing USB Battery Charging signals, and under 0.1 μs is needed for USB Low Spped, so a variety of capacitance values will work.
To test my ideas, I ran an experiment. I tried three USB cable configurations and, with each configuration, measured how much power my phone drew and whether or not my desktop recognized the device. I tried the original cable as a control. Then I soldered a 22 nF capacitor between D- and GND. Finally, I cut the D- line entirely. The results are below.
- Intact cable: 9.1 W - Good connection to desktop
- Capacitor installed: 7.4 W - "USB Device Unrecognized"
- D- line cut - 2.4 W: "USB Device Unrecognized"
These results are in line with my expectations. The difference between having the intact cable and having the capacitor installed could result from a difference in battery load. I suspect my phone drew more current than it should have in the third test. It seemed to draw 500 mA instead of 100 mA, which is all that is allowed by the spec. Still, with the D- line connected, it drew significantly less power.
I've designed a small device that incorporates these capacitors, along with some test and debug features, into a small board with a plug on one end and a receptacle on the other. It’s called USB Power Armor. I plan to build prototypes and do further testing this coming week. Here's a preview.
Update: The first units of USB Power Armor Type-A are available for sale now. Click here to get yours.
One of the fastest ways to get started with our seven-segment display is to use an Arduino. One Arduino can drive many digits. Up to 10 has been tested. 30 or more is practical with the standard interconnects, and hundreds are possible with multiple power drops.
You will need to connect the Arduino to one of your digits. This digit must be on the end of the chain. It will drive the rest of the digits as explained in the firmware section. To connect your Arduino, you have two options:
Use jumper wires
Connect each of the relevant lines between the on-board header and the Arduino. You'll need seven wires. To use the example code, wire up your Arduino according to the following table.
Solder to the on-board pads.
The pads are a bit tight in Rev 3, but they work with the Arduino Uno form factor. You'll need some 0.1 inch male header in right-angle thru-hole, such as Samtec's TSW-120-22-F-S-RA . I recommend putting the header in the Arduino, then soldering the header to the board. Once it's soldered, you can remove the Arduino and replace it at will. See the pictures below.
The examples firmware projects are still being developed. Eventually, they will be turned into a firmware library for very fast integration. If you know of an existing library for seven-segment displays, especially for Arduino, please leave a comment.
Each digit takes in data via shift registers. This allows daisy-chaining multiple digits together without the use of additional pins on your Arduino. Adafruit has a great introduction and tutorial for connecting shift registers to an Arduino. The Reclaimer Labs seven-segment display uses the same interface.
To achieve faster speeds and drive more digits, you can use the hardware SPI controller. Although the shift register interface is different than SPI, they are similar enough to be compatible. The most important difference is to ignore the SPI chip select (CS) pin and connect latch enable (LE) to a separate pin. Once all the relevant data has been transmitted, the LE pin must be manually pulled high then low. Using the SPI hardware on your microcontroller can free up the CPU, especially if you have Direct Memory Access (DMA) controllers on-board.
Most of the firmware examples include a font library. You can use this by indexing into the array and shifting out that byte. The index is the value you wish to display. font_inverted has values for upside-down digits; font is for upside-up. For example, to display a "3" on an inverted digit, you would send the byte font_inverted. To turn on the decimal point, simply set the upper-most bit of the byte. In this example, you would send the byte (font_inverted | (1<<7)).
This post should be enough to get you started using the seven-segments displays with an Arduino. Feel free to leave a comment or send us an email if you have any questions.
Preproduction (Rev 3) units of the 6-inch tall seven-segment display are available for sale at the Reclaimer Labs store. All boards are fully assembled and tested. Each segment comes with a laser-cut cardboard waveguide and interconnect. These are early units, so not all the bugs have been worked out. As I update the design to the production design (Rev 4), I will post specifics. In the meantime, you can get started on your projects with these preview units. Enjoy.
It's been a while since I updated this blog. That's because I've been working on Rev 3 of the seven segment display. This is the preproduction version. It is an important step on the way to ramping up to mass production. Over the next few weeks I will be testing and evaluating these units and building demos for the Kickstarter video. Stay tuned.
Today I will describe how I built my prototype countdown clock, which counts down to the next SpaceX launch. It automatically updates itself using the Network Time Protocol (NTP) and a script running on my home server. This project will demonstrate how to use the panels and will provide a glimpse into the firmware libraries that are under development.
The hardware consists of the ten Rev 2 prototype displays, one Spark Core, and a breadboard power supply. I’ve connected the digits in pairs to make a colon for every other segment. I used the interconnects along the bottom only. It is important not to connect both top and bottom, which would connect the output of the downstream panels to the input of the panels upstream and cause the display to latch up.
The firmware is experimental, to put it kindly. I threw it together in a weekend, so it’s messy, but I will have time to rework the firmware into a nice library for Spark and Arduino while I wait for the Rev 3 panels. In the meantime, feel free to look at the firmware on Github.
The basic flow of the firmware is to constantly check for the time to advance by a second. It then recalculates the number of seconds until the target time will arrive, does calculations to get the minutes, hours, and days, and then updates the display. Please note that I used the Sparkfun Real Time Clock (RTC) library for Spark, which means that times are not in Unix time but are offset by 2208988800 seconds. This difference confused me for a while. The firmware also includes a function to update the target time. This function can be called at any point by a script on the Internet. I used a string instead of a number because the biggest number I could use was a signed integer, and I wanted to be sure I could represent more distant times if necessary.
The software is even less stable than the firmware. I used Python because I’m familiar with the language and because there are libraries to do everything I needed. The script downloads the front page of spacexstats.com and then parses it to find the first time, which I assume is the next scheduled launch time. I used Beautiful Soup to do the parsing after referring to a few examples in the documentation. I also found a library to talk to the Spark Cores. To run the script, users will have to install these libraries. Once I had the script, I set up a cron job that runs the script once per minute.
There is much room for improvement in this design, but it was very fun building a working prototype so quickly. Please leave suggestions in the comments or make pull requests on Github.
Reclaimer Labs now has a logo. I'm still working out the details of its spacing relative to the name, but it's coming together. Thanks to Two Thousand for putting this together. You can check out her other work here.
I finished building and testing all 10 Rev 2 prototype segments. Here's a video of a quick test of driving all of them from an Arduino. I also figured out the code to use SPI to drive the data and clock lines. I've since ported that code to a Spark Core. Next up is writing the code to countdown to SpaceX DISCOVR launch tomorrow.
I was having trouble soldering the Rev 2 boards reliably. The major problem involved the slots for the LEDs. For these prototype boards, I needed to stick to a standard PCB fabrication process, which meant that I couldn't get non-plated slots. Unfortunately, plated slots make it very easy to short out the LEDs. To test for a short, I used my multimeter on the diode setting. If the LED lit up, there was no short; if the buzzer beeped, I needed to rework the soldering. Fixing three or four LEDs per board was very time consuming, and it took me 90 minutes to solder the first two boards together. I needed a better solution to cover the plated slots.
At this point, the nail polish came in. I used it as a sort of temporary solder mask. It stinks a bit when the soldering iron hits it, but it's not much worse than the solder itself. Out of the next eight boards, I experienced two shorted LEDs, and that improvement made the process much faster. I'm not convinced nail polish is the best solution, so if you have other suggestions, please leave a comment.
Tonight I spent some time thinking about the pinout for the connectors. One of the major issues with Rev 1 was that the pinout was incompatible with the boards when they were touching each other. The lesson I learned from that mistake was to be very careful when using the mirror command on connector components in the schematic editor (the mirror command is usually more trouble than it's worth). I also learned that it's a good idea to have a supply of Arduinos on hand.
I've since fixed and tested the new pinout on the Rev 2 boards. The boards interconnect perfectly and have no issues with shorting power and ground. As a precaution, I added PTCs, a resettable fuse on the VLED line. With the design ready to work for normal usage, I wanted to focus on user error. A user will connect to one of the two "IN" connectors on the board. So far, I've only used individual jumper wires. However, it's possible that a user could use something like a ribbon cable with a matching pitch. I wanted to find out what would happen if the user flipped the cable around and installed it backwards.
First, I looked at the schematic. Normally, swapping power and ground would be a problem. However, in this case, swapping VLED and GND connects ground to the anodes of the LEDs. Next, I checked the "Absolute Maximum Ratings" section of the TLC5917 datasheet. The limits seemed tight, especially when applying negative voltages to the pins. This situation would arise if 12 V were applied to ground and 5 V were applied to the pins, such as CLK and SDI. The chip would think it was getting -7 V on some of its pins.
After thinking about the various ways to arrange the pinout, I was unable to come up with a solution that would stay inside the maximum ratings when the connector was reversed. The last thing I needed to do was test the pinout. Swapping my individual jumper wires around, I plugged it in and expected magic smoke to come out. I was pleasantly surprised when nothing popped. The only component that was getting hot was the 22R resistor bank on the Arduino, located near the USB connector. Fortunately, the resistor bank was able to survive a few minutes of punishment. I then swapped everything around, and the system functioned normally.
I'm satisfied with the current pinout. The system withstood a reversed connector long enough for the user to realize something was wrong. Hopefully, the instinct to disconnect the power when things don't go as expected will win out. Ultimately, it's expensive, if not impossible, to design for every contingency. I did test a few other pinouts and had far worse results. I hope my new Arduinos will arrive soon.
Connectors are almost always a driving cost in electronics designs, and my board is no exception. In terms of the bill of materials (BoM), the connectors are responsible for half the cost. For this reason, I spent more time looking for a good deal on the connectors than on any other item on the BoM.
First, I wanted to make sure I had selected a good connector. I knew I wanted to be able to chain up multiple digits, but I also wanted a smooth edge on the outside. Additionally, I wanted the ability to rotate any digit in the chain by 180 degrees and still be able to link digits together. That specification required a connector that did not hang over the edge. I decided to go with a female connector for both input and output connectors and to use long-tailed, unshrouded male header pins as the interconnect. A 0.100-inch pitch would make my selection compatible with many existing connectors and prototyping systems, which would be valuable for any hobbyists that buy the product. A surface mount option would make the board easy to assemble.
With specs in mind, I needed to see if the connector I wanted existed and what options were available. My go-to source for connectors is Samtec. In my experience, they are the definitive source for connectors. Their website is relatively easy to browse, with a huge selection and great documentation. Their major advantage is that they will ship overnight samples of anything you want for free. I started browsing in the .100-inch pitch connector section and found the SSM series. This connector comes with a right angle, surface mount option. It also mates with the TSW series, which can include a long tail for the interconnect.
Samtec's connectors are excellent quality, but they are expensive. In small quantities, each connector was $1.22, and I needed four per board. For small runs, it's very convenient to avoid worrying about sourcing connectors. For this product, I needed something cheaper, or the final product would be too expensive to sell at retail. Because the price breaks at Samtec did little to improve the cost, I had to look elsewhere. Unfortunately, distributors like Digikey and Mouser weren't much help. I even used my early access at parts.io, but there were not many options. Finally, I resorted to Google. I searched for "surface mount header" and clicked on any link that looked like the product. There were a few manufacturers and distributors listed. Sometimes distributors have links to datasheets, which I can use to find new manufacturers to look at. Some of the manufacturers required me to fill out a form to request a quote by email. After a few of them got back to me, I had a new, lower price and a much higher minimum order quantity (MOQ): $0.55 each with a MOQ of 2,700 connectors.
The minimum quantity of connectors will drive the minimum quantity of boards I can make cost effectively. The price of the connectors will also have a large effect on the price of the completed board. I'll discuss more details about costs and pricing in future posts.
In my previous post, I went over how I selected the Lite-On LTST-C230TBKT blue LED. Today I'll discuss the process I used to check that this LED was a good selection.
The first thing I did was go to Octopart to see what prices and availability were like outside of Digikey. There, it looked like Digikey had the best price and the most in stock, but Mouser had 10,000, and a few other places also had these LEDs.
Second, I wanted to see what other color options existed in the same form factor and with similar electrical characteristics. Down at the bottom of the Digikey product page is a link to view the product in the online catalog.
There, I saw a bunch of color options, which looked promising. From that page, there is a link to view results as a parametric search. There were some non-reverse mount LEDs and multiple packages. After selecting only reverse mount, cut tape, and in-stock parts, there were nine options left (about one in each color). I could have red, amber, yellow, green, or blue LEDs. They all had the same current rating, so the current set resistor connected to the LED driver IC wouldn’t need to change. Because they all had the same package dimensions (which presumably meant that the land patterns for the PCB were the same), I could use the same PCB for any color.
Next, I wanted to see the options for buying reels of these LEDs. Digikey has a nice little "Alternate Package" box with a link to the reel packaging. At 11,000 LEDs, they would cost just under $0.07 each. If I built more than 500 boards and ordered more than 15,000 LEDs, that price would drop down closer to $0.06. That price was not bad and was a lot cheaper than other options I'd seen.
Finally, I wanted to check the datasheet. LEDs are simple, but I like to know that the manufacturer cares enough to test the product and publish the results. For this project, some of the exact details don't matter, but it's nice to know the product is well characterized. It's reassuring to have the spatial distribution of the light produced, for example, even if I don't need that data at this point. More importantly, the datasheet has land patterns and hole cutouts for the PCB and also has exact dimensions of the product and its packaging. The PCB information would make it easy to lay out the board. The dimensions of the reel would be useful for a contract manufacturer or assembly house so they know what they're getting and can set up their pick-and-place machines.
After I considered these features, this LED looked good. In my next post, I plan to go over my selection of the connector.
In this post, I'll go over the LEDs I selected for the seven-segment display.
While designing these initial prototypes, I have been keeping in mind that the design needs to be straightforward to manufacture. I've also been considering the overall system design, especially the mechanical assembly of the final clock. The LED selection had a lot to do with that. Digikey has 19,037 options for discrete LEDs. Here's how I narrowed it down to one.
Let me start by mentioning that RGB LEDs, like the Neopixel, are cool. However, they are overkill for this product. They are also expensive and less available than single color LEDs.
The first way I narrowed the search was selecting only reverse mount, surface mount (SMD) LEDs, which Digikey calls "Surface Mount, Bottom Entry." This choice was important to the system design in two ways. Firstly, keeping all parts on the same side of the board is much cheaper for assembly. Double-sided boards require two trips through a pick-and-place machine and the reflow oven. Depending on the process, adhesives have to be used on the first side. This procedure adds complexity and cost to the final product. Secondly, reverse mount LEDs allow for a smooth front surface to mount both the diffusers and wave guide material. I want that part of the design to be very flexible and easy so users can make their own guides.
The second way I narrowed the search was selecting only blue LEDs. The brought the results down to 34. I wanted a blue clock, but I chose blue for another reason. Blue is a difficult LED color (difficult enough to win researchers a Noble Prize). Blue LEDs require the highest voltages, which means that, if blue LEDs work, lower-voltage LEDs, such as green and red, should also work. I'm also interested in a manufacturer that has a family of similar LEDs that differ only in color. Because of that feature, if I want to make variants of the segments with different colors, I can use the same boards and just swap out the LED part.
After further narrowing the search to cut tape packaging and in-stock items, there were only six results. Cut tape is important because I want small quantities for prototyping but reels for manufacturing. I have assumed that, if cut tape was available, I can also get the product in reels, but I will double check my final selection later.
At this point, any of the LEDs would work for prototypes. The next two columns I looked at were unit price and quantity available. If I make 500 boards with 22 LEDs per board, I'll need 11,000 LEDs. Digikey now lets you sort by price at a quantity. At production quantities, the Lite-On LTST-C230TBKT blue LED stood out as less than half the cost of the second least expensive option. It also had the highest quantity available, at over 51,000 in Digikey stock.
In my next post, I'll go over my process for double checking my LED selection.
This blog documents the process of taking a prototype into low-level production. I'll start by going over the design of the full digit prototype. Below is the schematic, which is intentionally simple. Let's go into some of the design's details.
LED Driver IC
When I started doing research for this project, I thought the LED driver IC would be a challenging part to find. As it turns out, there are many constant current (CC) LED driver ICs on the market with a wide variety of interfaces. I wanted a constant current LED driver with direct current instead of PWM because I wanted to dim the segments while avoiding ghosting issues. You can sometimes see this effect of PWM-based dimming if you glance back and forth across an LED source.
Instead of needing two chips, such as a shift register and a current source, the TLC5917 does it all and more. It works out of the box as a shift register with direct current drivers. The current is set with a single resistor. Additionally, the TLC5917 has special commands to dim the display based on a fraction of the set current. Beyond that, it can detect shorts and opens, and shifts out the results. If the microcontroller could also read in shift register data, it could do an incredible amount of diagnostics for less than $1 per board.
That's enough for now. In future posts, I plan to go over how I selected the LEDs and the connectors.
Today I'd like to go over the optical stackup I'm using for the full digit. The materials from top to bottom are
- Standard copy paper
- Two pieces of 1/8-inch-thick acrylic opaque white, laser cut to form segments
- One piece of 1/8-inch-thick 40% transparent white acrylic, laser cut to a size of 6.0 inches x 4.2 inches
- A PCB with reverse mount LEDs for a smooth top
The Rev 2 boards in for the full digit recently arrived. I soldered up two of them and connected them together for a quick test. The major bug fix was in the connector pinout. Now the boards can butt up against each other like they were supposed to. I'm running this test using a Spark Core and a breadboard power supply from Adafruit. The colon is two decimal points. The digit on the right is upside down.
I'm starting this blog to document the process of taking an open-source hardware project from concept to product. I'll be diving deep into matters that include design for manufacture, component selection, supply chain management, pricing, assembly, marketing, sales, and logistics. In my professional career, I've worked on many projects up through the production stage. However, these projects were hardware tools for my company’s internal use. This blog will follow the first project I am making available to the general public.
My personal goals for this project are threefold:
- Have a cool clock at the end.
- Learn about Internet-connected modules, such as the Spark Core.
- Gain experience with the process of taking a hardware project to market.
I can't guarantee I will make a successful product. Regardless, I intend to post updates on my progress here as I go through each of the challenges related to this project. Whether or not there is a successful product at the end, I know I will learn a great deal about the process. My hope is that you can learn with me.