After three years of online publications, HardwareX may have solidified itself as an academic journal for open-source hardware. We originally wrote about HardwareX back in 2016. At the time, HardwareX hadn’t even published its first issue and only begun soliciting manuscripts. Now after three years of publishing, six issues as of October 2019 (with the seventh scheduled for April 2020), and an impact factor of 4.33, it’s fair to say that Elsevier’s push into open-access publications is on a path to success.
To give you a bit of background, HardwareX aims to promote the reproducibility of scientific work by giving researchers an avenue to publish all the hardware and software hacks that often get buried in traditional manuscripts. The format of HardwareX articles is a bit different than most academic journals. HardwareX articles look more like project pages similar to Hackaday.io. (Maybe we inspired them a bit? Who knows.)
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.
An animation of a commercial fires suppression system, fire trace’s, operation. Firetrace‘s website has more.
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.
BlazeCut Automatic Fire Suppression System 6′ TV200FA, Automotive Extinguisher Installed under Car Hood.
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.
The Thai invention is a volleyball that melts upon contact with flame and releases a pressurized extinguishing agent.
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?
Electronic conference badges have been around for at least a decade now, and they all have the same faults. They’re really only meant to be used for a few days, conference organizers and attendees expect the badge to be cheap, and because of the nature of a conference badge, the code just works, and documentation is sparse. Surely there’s a better way.
Enter the Hackable Electronic Badge. Ever since Parallax started building electronic conference badges for DEF CON, they’ve gotten a lot of requests to build badges for other conventions. Producing tens of thousands of badges makes Parallax the go-to people for your conference badge needs, but the requests for badges are always constrained by schedules that are too short, price expectations that are too low, and volumes that are unknown.
There’s a market out there for electronic conference badges, and this is Parallax’s solution to a recurring problem. They’re building a badge for all conferences, and a platform that can be (relatively) easily modified while still retaining all its core functionality.
