Check it out, the Hackaday YouTube channel just passed 100,000 Subscribers! Thank you to everyone who has been following the great stream of videos on our channel. If you’re not yet following us, now’s the time!
Upstairs at the Marquis Cornwallis pub in central London, around 75 Hackadayers convened, ate well, drank well, and were generally merry. Nearly everyone in attendance brought a hack with them, which meant that there was a lot to see in addition to all that socializing to be done.
I spoke with a huge number of people who all said the same thing: that it was fantastic to put faces to the names of the writers, hackers, and other readers. As a writer, I finally got to meet in person some of the people who’ve produced some of my favorite hacks, in addition to most that were totally new to me. I can’t say how often I heard “Oh you’re the person behind that project. I loved that one.” A real sense of the Hackaday community was on display. Continue reading “Hackaday’s London Meetup Was A Corker”
Here at Hackaday, we are a team of technical writers who spend our days keeping abreast of the wonderful world of hardware as we write up the interesting things that cross our timelines and serve them up everyone to enjoy. That is however only part of the picture, the other half of the Hackaday family is you, our readers and our community. You are a wonderfully diverse group of people who do some fascinating things, and you are what gives us life.
From time to time, Hackaday makes it out on the road, we have events, we host meetups, and we spend time with you, the community of which we are a part. Of course, our world can be an annoyingly big place at times, so for a lot of us these meetups are too far away. As a Brit, for example, the upcoming Hackaday Superconference in Pasadena, California, is a somewhat unattainable dream without shelling out a significant chunk of the old hard-earned on travel.
In the very short term we must continue to disappoint many of our worldwide readers because we can’t have meetups all over the world and all at once. But we can at least provide succour to our British readers this month, with more than one opportunity to get to know Hackaday writers as we go out on the road.
In the first instance, I’m going to be in Hebden Bridge, Yorkshire this weekend. I’ll be giving a couple of talks, one on Friday at the Wuthering Bytes festival, and the other on Saturday at the Open Source Hardware Camp. I’ll be bringing along the remainder of my stock of Hackaday stickers left over from SHA Camp, and I’d love to see what you’ve been getting up to.
But worry not if you can’t make it to Yorkshire, for there is another chance for Brits to meet us this month. Our London Unconference on the 16th of September may have been a speedy sell-out, but because we have no wish to disappoint those of you who missed out on a ticket we’re also running a bring-a-hack meetup the night before. We’ve hired the Drawing Room at the Marquis Cornwallis, a pub not too far from Russell Square Tube station in London, so come and have a pint with us and show us what you’ve made. Get your skates on, it’s not much more than a couple of weeks away!
There are times when I feel the need to really make a mess. When I think of making messes with a degree of permanency, I think of fiberglass. I also really like the smell, reminds me of a simpler time in 8th grade shop class. But the whole process, including the mess, is worth it for the amazing shapes you can produce for speaker pods and custom enclosures.
Utilizing fiberglass for something like a custom speaker pod for a car is not difficult, but it does tend to be tedious when it comes to the finishing stages. If you have ever done bodywork on a car you know what kind of mess and effort I am talking about. In the video below, I make a simple speaker pod meant for mounting a speaker to the surface of something like a car door.
You can also use a combination of wood and fiberglass to make subwoofer cabinets that are molded to the area around them. You can even replace your entire door panel with a slick custom shaped one with built in speakers if you’re feeling adventuresome.
On my way to this year’s Hackaday SuperConference I saw an article on EE Times about someone taking the $22 Lattice iCEstick and turning it into a logic analyzer complete with a Python app to display the waveforms. This jumped out as pretty cool to me given that there really isn’t a ton of RAM on the stick, basically none that isn’t contained in the FPGA itself.
[Jenny List] has also written about the this application as created by [Kevin Hubbard] of Black Mesa Labs and [Al Williams] has a great set of posts about using this same $22 evaluation board doing ground up Verilog design using open source tools. Even if you don’t end up using the stick as a logic analyzer over the long haul, it’ll be very easy to find many other projects where you can recompile to invent a new purpose for it.
1 kilobyte. Today it sounds like an infinitesimally small number. Computers come with tens of gigabytes of ram, and multiple terabytes of storage space. You can buy a Linux computer with 1 gig of RAM and secondary storage as big as the SD card you throw at it. Even microcontrollers have stepped up their game, with megabytes of flash often available for program storage.
Rapidly growing memory and storage are a great testament to technology marching forward to the beat of Moore’s law. But, we should be careful not to forget the techniques of past hackers who didn’t have so much breathing room. Those were the days when code was written in assembly. Debugging was accomplished with an expensive ICE (an In Circuit Emulator… if you were working for a big company), or a few LEDs if you were hacking away in your basement.
To keep these skills and techniques in play, we’ve created The 1 kB Challenge, a contest where the only limit is what you can do with 1 kB of program memory. Many Hackaday contests are rather loose with constraints — anyone can enter and at least make the judging rounds. This time 1 kB is a hard limit. If your program doesn’t fit, you’re disqualified, and that is a challenge worth stepping up to.
That said, this is Hackaday, we want people to be creative and work around the rules. The important thing to remember is the spirit of the design constraints: this is about doing all you can with 1 kB of program space. Search out the old and wise tricks, like compressing your code and including a decompression program in your 1 kB. Crafty hacks to squeeze more into less is fine. Using the 1 kB as a bootloader to load more code from an SD card is not fine.
Any Hackaday contest needs some awesome prizes, and this one is no different.
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?