A few weeks ago an incredible video of an engine exploding started making the rounds on Facebook. This particular engine was thankfully in a dyno room, rather than sitting a couple of feet away from a driver on a track. We’ve all seen engine carnage videos before, but this one stands out. This diesel engine literally rips itself apart, with the top half of the engine flipping and landing on one side of the room while the bottom half sits still spinning on the dyno frame.
Building performance engines is part science, part engineering, and part hacking. While F1 racing teams have millions of dollars of test and measurement equipment at their disposal, smaller shops have to operate on a much lower budget. In this case, the company makes their modifications, then tests things out in the dyno room. Usually, the tests work out fine. Sometimes though, things end spectacularly, as you can see with this diesel engine.
The engine in question belongs to Firepunk diesel, a racing team. It started life as a 6.7 liter Cummins diesel: the same engine you can find in Dodge Ram pickup trucks. This little engine wasn’t content to chug around town, though. The Firepunk team builds performance engines — drag racing and tractor pulling performance in this case. Little more than the engine block itself was original on this engine. Let’s take a deeper look.
NYC beaches are where tropical beaches addicted to meth go to die. So says [Vije Miller] in his write-up for his Arduino sand matrix printer. It’s a clever idea, five servo-operated cardboard plungers that indent a pattern of dots in the sand as the device is pulled forward, resulting in something not unlike a dot matrix printer that can write messages in the sand.
He’s submitted it to us as a Fail Of The Week, because it doesn’t do a very good job of writing in the sand, and it’s burned out a servo. But we feel this isn’t entirely fair, because whether or not it has delivered the goods it’s still an excellent build. Cardboard isn’t a material we see much of here at Hackaday, but in this case he’s mastered it in a complex mechanism that while it may have proved a little too flexible for the job in hand is nevertheless a rather impressive piece of work.
You can see a brief video below the break showing it in action. He tells us his motivation has waned on this project, and expresses the hope that others will take up the baton and produce a more viable machine.
If you are a regular at creating printed circuit boards, it is likely that somewhere in your shop there will be a discard pile of boards on which you placed a component in the wrong orientation such that it would not work. It’s easily done, and don’t be shy to admit it if it’s happened to you.
[Bill] was making his own ARM developer board, taking inspiration from the ARM Pro Mini. He produced his PCB design and sent it off to the board house, and in due course received and reflow soldered a batch of beautiful dev boards. On power-up though, something was wrong! No USB device detected on his computer, a disaster. A lot of studying board and schematic led to the discovery that his push-button switches had been placed at 90 degrees to the orientation it should have had, leaving them in a permanently “on” position.
The PCB bug makes this is a Fail Of The Week post, but he transformed into a win with some experimentation with the switch outline in KiCAD before finding a way to mount the switches on the pads at 45 degrees, covering three of the pads. Well done, and well done for admitting the error.
[Editor’s note: been there, done that. One way to prevent the error is to only connect to diagonally opposite pins of the tact switch, so the rotation doesn’t matter.]
Having earlier asked others to come clean with their PCB mistakes, it’s probably appropriate to admit that Hackaday scribes are just as fallible as [Bill] when it comes to PCB layouts. Somewhere there may still be a board on this bench with a QFN microcontroller bodged on at 90 degrees to its original orientation, with cut tracks and tiny wire runs.
Whether you are a seasoned PCB pro or a wet-behind-the-ears rookie, our Creating a PCB In Everything series should be of interest.
Museum exhibits are difficult to make, and they’re always breaking down; especially the interactive ones. This is a combination of budget, building a one-off, and the incredibly harsh abuse they take from children.
My first exhibit is an interactive laser show that turns waveforms from music into laser patterns, and different types of music have very different patterns. I knew from talking to the museum staff that industrial buttons were a necessity, but it turns out that industrial buttons are made under the assumption that tiny creatures won’t be constantly mashing, twisting, and (ew ew ew) licking the buttons. After a while, the buttons (and poor knob) were trashed.
The button face has been removed, and the knob is spinning freely.
Buttons at toddler level are in a vulnerable position.
The second exhibit is also interactive, but in this case it’s just a simple button that turns on a thing for a while, then shuts it off. You can read more about the Periodic Table of Motion on the project page. Here I thought; let’s use capacitive touch, put the sensor behind two layers of acrylic for protection, and then there won’t be any moving parts to break. I built a bunch of units, tested it for weeks, then installed it. Instant failure despite my diligence.
Something is different about the installation from my test environment. It might be the second layer of acrylic contributing. Maybe it’s the power supply and a strange ground issue. Maybe the room’s fluorescent lights are creating an electromagnetic field that is interrupting the sensor, or the carpet is causing static buildup that is somehow causing the midichlorians to reverse polarity and discharge through the base plate of prefabulated aluminite. In some of the cells, the button doesn’t work. In other cells it is extremely sensitive. In one column of the table (columns share a common piece of acrylic among 5 cells), a single touch will trigger all 5.
The circuit is an ATtiny with a 2.2M resistor between two pins, one of which connects via a short wire to a soldered connection to a piece of copper tape on the underside of an acrylic piece. The ATtiny is using the capsense library, which has features for automatic recalibration. Because of the way it is installed, I can’t reprogram them to adjust their sensitivity while inside the enclosure, so tweaking them post-install is not an option. I thought I could isolate the problem and use an existing capacitive touch sensor breakout of the AT42QT1010 hooked up to just power, but it had the exact same issue, meaning it’s either the power supply, the enclosure, or the room.
Side-by-side tests of copper tape+Arduino and AT42QT1010 had similar problems.
There are three paths I can go down now:
Find the problem and solve it
Switch to a photoresistor
Petition Hackaday for a better solution
Finding the problem and solving it will be a long and difficult path, especially since the museum environment is somehow and inexplicably different from the test environment. The photoresistor option has promise; when the user puts their hand over the paper button the light level changes. Some early testing indicates that it is easy to detect instantaneous change, and a trailing average and adjusting threshold make it robust enough for changing lighting conditions throughout the day. Further, it’s a simple change to the code, and the existing circuit board will accommodate the adjustment.
As for the third option…
What have you done for child-compatible touch interfaces that are robust enough to handle uncertain environments and harsh abuse? What buttons, knobs, and other interactive elements have you used?
Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.
Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.
For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.
We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.
