It’s no secret that we here at the Hackaday are suckers for cool display. LEDs, OLEDs, incandescent, nixie or neon, you name it and we want to see it flash. So it fills us with joy to discover a new way to build large, daisy-chainable 16-segment digits, and even more excited to learn how easy they are to fab and assemble.
A cousin of the familiar 7 segment display, the 16 segment gives so many more possibilities (128% more possibilities to be exact) for digit display. To be specific, those extra segments unlock the ability to display upper and lowercase latin characters as well as scads of punctuation.
But where the character set is complex, the assembly is anything but thanks to a great design from [Kolibri] called klais-16. They’re available fully assembled if you want to jump straight to code, but thanks to thorough documentation (seriously, check this out) assembly is a snap.
Each module is composed a very boring PCBA base layer which should be inexpensive from the usual sources, even when ordering one fully assembled. A stackup of three more PCBs are used for spacing and diffusion with plans for die-cut or injection mold layers if a larger production run ends up happening. Board dimensions for each character are 100 mm x 66.66 mm (about 4″ x 2.5″). Put together, each module can stand on its own or be easily daisy-chained together to make a longer single display.
Addressing all those bits with an elaborate, ugly control scheme would be a drag but fortunately the firmware for the onboard STM8 microcontroller exposes a nice boring serial interface which can be used without configuration to display strings. There’s even an example Windows Batch script!
CircuitPython reached a major milestone last week as it welcomed its 100th board into the fold: the wristwatch form factored badge designed for the 10th annual Open Source Hardware Summit, which takes place March 13th in New York City. Although CircuitPython — an open source derivative of MicroPython — was born at Adafruit, more than half of the boards on this list were produced outside of the company. That just goes to show the strength of the community in support of the snake.
The OSHW 2020 badge joins a litany of familiar boards happy to drop you into a Python interpreter. Among them there’s the Adafruit Feather ecosystem, the ItsyBitsy, specialized boards like the Edge Badge that was in some goodie bags at Supercon, and the CircuitPlayground — that Swiss army knife of sensors which now comes in a Bluetooth version. The first 100 boards were rounded out in strong fashion with [Joey Castillo]’s OpenBook e-reader and the Teensy 4.0. Continue reading “CircuitPython Slithers Into 100th Board — The OHS 2020 Badge”→
Here at Hackaday, we love knobs and buttons. So what could be better than one button? How about 16! No deep philosophy about the true nature of Making here; [infovore], [tehn], and [shellfritsch] put together a very slick, very adaptable bank of 16 analog faders for controlling music synthesis. If you don’t recognize those names it might help to mention that [tehn] is one of the folks behind monome, a company built on their iconic grid controller. Monome now produces a variety of lovingly crafted music creation tools.
Over the years we’ve written about some of the many clones and DIY versions of the monome grid controller, so it’s exciting to see an open source hardware release by the creators themselves!
The unambiguously named 16n follows in the footsteps of the monome grid in the sense that it’s not really for something specific. The grid is a musical instrument insofar as it can be connected to a computer (or a modular synth, etc) and used as a control input for another tool that creates sound. Likewise, the 16n is designed to be easily integrated into a music creation workflow. It can speak a variety of interfaces, like purely analog control voltage (it has one jack per fader), or i2c to connect to certain other monome devices like Ansible and Teletype. Under the hood, the 16n is actually a Teensy, so it’s fluent in MIDI over USB and nearly anything else you can imagine.
Hardware and software are certainly different beasts. Software is really just information, and the storing, modification, duplication, and transmission of information is essentially free. Hardware is expensive, or so we think, because it’s made out of physical stuff which is costly to ship or copy. So when we talk about open-source software (OSS) or open-source hardware (OSHW), we’re talking about different things — OSS is itself the end product, while OSHW is just the information to fabricate the end product, or have it fabricated.
The fabrication step makes OSHW essentially different from OSS, at least for now, but I think there’s something even more fundamentally different between the current state of OSHW and OSS: the pull request and the community. The success or failure of an OSS project depends on the community of people developing it, and for smaller projects that can hinge on the ease of a motivated individual digging in and contributing. This is the main virtue of OSS in my opinion: open-source software is most interesting when people are reading and writing that source.
With pure information, it’s essentially free to copy, modify, and push your changes upstream so that others can benefit. The open hardware world is just finding its feet in this respect, but that’s changing as we speak, and I have great hopes. Costs of fabrication are falling all around, open and useful tools are being actively developed to facilitate interchange of the design information. I think there are lessons that OSHW can learn from the OSS community’s pull-request culture, and that will help push the hardware hacker’s art forward.
What would it take to get you to build someone else’s OSHW project, improve on it, and contribute back? That’s a question worth a thoughtful deep dive.
Today at the Open Hardware Summit in Portland, Alicia Gibb and Michael Weinberg of the Open Source Hardware Association (OSHWA) launched the Open Source Hardware Certification program. It’s live, and you can certify your own hardware as Open Hardware right now.
What Is Open Source Hardware?
Open Source Hardware can’t be defined without first discussing open source software. At its very core, open source software is just a copyright hack, enabled by a worldwide universal computer network. The rise of open source software is tied to the increasing ease of distributing said software, either through BBSes, Usenet, and the web. Likewise, Open Source Hardware is tied to the ease of distributing, modifying, and building hardware.
In the 1980s, there were no services that could deliver a custom circuit board to anywhere on the planet for a dollar per square inch. When open software began, CNC machines were expensive tools, now you can build a very good machine for just a week’s wages. We are currently living at the dawn of Open Source Hardware, enabled by the creation of Open Source design tools that have themselves been used to create physical tools. Inexpensive 3D printers, open source oscilloscopes, circuit board plotters, and the entire hackerspace movement are as revolutionary as the Internet. These devices and the Internet are the foundations for Open Hardware and software, respectively. The objections to why hardware is incompatible with Open Source no longer apply and small-scale manufacturing techniques are only going to get better.
We posted about a 3D printer fire a while back. An attendee of the Midwest RepRap Fest had left his printer alone only to find its immolated remains on his return. In the spirit of open source, naturally, he shared his experience with the rest of us. It occurred to me that hackers are never powerless and there are active things to be done and avenues to explore.
There are really fantastic commercial fire extinguishing systems out there. One implementation, which is commonly deployed in cabinets and machining centers, is a plastic tube pressurized with an extinguishing agent by a connected tank. When a fire breaks out the tube melts at the hottest locations, automatically spraying the area with a suppressant. Variations of this involve a metal nozzle filled with a wax or plastic blended to melt at a certain temperature, much like the overhead fire sprinklers.
This system is also used inside engine compartments with success. For example, this item on amazon, is nothing but a pressurized plastic tube with a gauge on one end. Since the inside of an engine compartment can be treated as an enclosed space, very little fire suppressant is needed to extinguish an unexpected flame. It is important to note that this system works in a high temperature environment like an engine compartment, which bodes well for enclosed build envelopes on 3D printers.
Another option is to construct a suppressant mine. A Japanese and a Thai company have both come out with a throwable fire extinguisher. In the Japanese device, the outside of the extinguisher is a breakable glass vial which shatters upon impact; releasing the agent. The Thai device looks like a volley ball, and releases the agent upon the application of heat. This device seems like a better candidate for 3D printing or home projects. Imagine a small rectangular pack with adhesive on one side that sits near the possible fire points of the printer, such as under the bed or above the nozzle. In the event of a fire, the casing will melt and the system will automatically deploy a spray of extinguishing agent.
Most of the chemicals used in these constructions are benign and readily available. High pressure tubing and waxes can all be purchased and the desired melt points can be aligned with their datasheets by need. Plastic sheets are not hard to procure. These offer a nice solution due to their entirely passive nature. They don’t need power to operate and rely entirely on the properties of the materials they are constructed out of.
There are other options in active systems. Hackaday readers suggested things such as flame sensors for adding automatic cut-offs in case of a fire. Thermal fuses can also be considered in some cases. There are other tricks too, which are less kosher but will work nonetheless. For example, placing a critical wire, fuse, or component in the likely path of a fire so that it is destroyed first, stopping the operation of the device quickly. These avenues should be explored. At minimum there should be at least one project that uses a Raspberry Pi and an Arduino to tweet that fire suppression failed and the house is on fire.
Some of the big questions to ask are on the legal and ethical side. If someone started selling kits for a DIY fire suppression system and a fire ends up destroying someone’s property despite the device, who is responsible? Is it even safe to post instructions? What if a kit prematurely sets off and injures someone. I imagine a big part of the cost of these professional systems is some sort of liability insurance and certification. Still, putting a six hundred dollar fire suppression system on a six hundred dollar printer seems silly, and something is better than nothing.
Lastly, the comments directed a ton of flak towards the certification systems. There should be no reason that open source projects can’t produce their own specification for safety. An open source specification without an agency naturally couldn’t provide a legal defense against property damage, but a thought-out test program would provide piece of mind. For example, in the case of 3D printers, one could have a set of basic fail-safe tests. One example would be bringing the printer up to temperature and rapidly disconnecting the thermistor, does the printer erupt into fire? No? Good, it meets the spec. I wouldn’t mind knowing that the latest version of Marlin was tested on the popular boards and still met the community specification for fire safety.
As far as I can tell, there’s been very little work in open sourcing safety systems or in providing a testing framework for ensuring open hardware meets basic safety conditions. Many of you have experience with these systems. Some of you have gone through the entirely un-enjoyable process of getting a UL certification. What does Hackaday think?