Everything you do bears some risk of getting you hurt or killed. That’s just the way life is. Some people drown in the bath, and others get kilovolt AC across their heart. Knowing the dangers — how drastic and how likely the are — is the first step toward mitigating them. (We’re not saying that you shouldn’t bathe or play with high voltages.)
This third chapter of an e-book on electronics is a good read. It goes through the physiology of getting shocked (DC is more likely to freeze your muscles, but AC is more likely to fibrillate your heart) and the various scenarios that you should be looking out for. There’s a section on safe practices, and safe circuit design. It’s the basics, but it’s also stuff that we probably should have known when we started messing around with electrons in bulk.
Continue reading “The Importance of Electrical Safety”
Sometimes you use a Raspberry Pi when you really could have gotten by with an Arudino. Sometimes you use an Arduino when maybe an ATtiny45 would have been better. And sometimes, like [Bill]’s motorcycle tail light project, you use exactly the right tool for the job: a 555 timer.
One of the keys of motorcycle safety is visibility. People are often looking for other cars and often “miss” seeing motorcyclists for this reason. Headlight and tail light modulators (circuits that flash your lights continuously) are popular for this reason. Bill decided to roll out his own rather than buy a pre-made tail light flasher so he grabbed a trusty 555 timer and started soldering. His circuit flashes the tail light a specific number of times and then leaves it on (as long as one of the brake levers is depressed) which will definitely help alert other drivers to his presence.
[Bill] mentions that he likes the 555 timer because it’s simple and bulletproof, which is exactly what you’d need on something that will be attached to a motorcycle a be responsible for alerting drivers before they slam into you from behind.
We’d tend to agree with this assessment of the 555; we’ve featured entire 555 circuit contests before. His project also has all of the tools you’ll need to build your own, including the files to have your own PCB made. If you’d like inspiration for ways to improve motorcycle safety in other ways, though, we can suggest a pretty good starting point as well.
We get a lot of press releases at Hackaday, but this one was horrific enough that we thought it was worth sharing. Apparently, some kids are accidentally eating lithium coin cell batteries. When this happens with bigger cells, usually greater than 20 millimeters (CR2032, CR2025, and CR2016) really bad things happen. Like burning esophaguses, and even death.
The National Capital Poison Center has done some research on this, and found that 14% of batteries swallowed over the past two years came from flameless candles like the ones above. We know some of our readers also deal with batteries in open trays, which are apparently pretty dangerous for children.
The National Capital Poison Center’s website has an entire page dedicated to battery safety, which is probably worth a read if you deal with batteries and small children on a regular basis. Should an incident occur, there’s even a hotline to call for assistance.
So, please, don’t swallow batteries, or let children put them in their mouths. After the break, a Canadian PSA song about not putting things in your mouth.
Continue reading “PSA: Don’t Let Kids Eat Lithium Batteries”
Within the past two months we’ve covered two separate incidents of 3D printing-related fires. One was caused by an ill-advised attempt to smooth a print with acetone heated over an open flame, while the other was investigated by fire officials and found to have been caused by overuse of hairspray to stick prints to the printer bed. The former was potentially lethal but ended with no more than a good scare and a winning clip for “Hacking’s Funniest Home Videos”; the latter tragically claimed the life of a 17-year old lad with a lot of promise.
In light of these incidents, we here at Hackaday thought it would be a good idea to review some of the basics of fire safety as they relate to the home shop. Nowhere was this need made clearer than in the comments section on the post covering the fatal fire. There was fierce debate about the cause of the fire and the potential negative effect it might have on the 3D-printing community, with comments ranging from measured and thoughtful to appallingly callous. But it was a comment by a user named [Scuffles] that sealed the deal:
“My moment of reflection is that it’s well past time I invest in a fire extinguisher for my workstation. Cause right now my fire plan pretty much consists of shouting obscenities at the blaze and hoping it goes out on its own.”
Let’s try to come up with a better plan for [Scuffles] and for everyone else. We’ll cover the basics: avoidance, detection, control, and escape.
Continue reading “Hack Safely: Fire Safety in the Home Shop”
Three things have happened in the last month that have made me think about the safety of self-driving cars a lot more. The US Department of Transportation (DOT) has issued its guidance on the safety of semi-autonomous and autonomous cars. At the same time, [Geohot]’s hacker self-driving car company bailed out of the business, citing regulatory hassles. And finally, Tesla’s Autopilot has killed its second passenger, this time in China.
At a time when [Elon Musk], [President Obama], and Google are all touting self-driving cars to be the solution to human error behind the wheel, it’s more than a little bold to be arguing the opposite case in public, but the numbers just don’t add up. Self-driving cars are probably not as safe as a good sober driver yet, but there just isn’t the required amount of data available to say this with much confidence. However, one certainly cannot say that they’re demonstrably safer.
Continue reading “Self-Driving Cars Are Not (Yet) Safe”
A while back I tried to make a case for good safety disciple as a habit that, when proactively pursued, can actually increase the quality of your work as a side effect. In those comments and in other comments since then I’ve noticed that some people really hate safety gear. Now some of them hated them for a philosophical reason, “Ma granpap didn’t need ’em, an’ I don’t neither”, or ,”Safety gear be contributin’ to the wuss’ness of the modern personage an’ the decline o’ society.” However, others really just found them terribly uncomfortable and restricting.
In this regard I can help a little. I’ve spent thousands of terrible long hours in safety gear working in the chemical industry. I was also fortunate to have a company who frequently searched for the best safety equipment as part of their regular program. I got to try out a lot.
Continue reading “Path To Craftsmanship: Don’t Buy Awful Safety Gear”
We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.
[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?
When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.
So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.