[Daniel Reetz] spent six years working as a Disney engineer during the day and on his book scanner, the archivist at night. Some time last year, [Daniel] decided enough is enough, got married, and retired from the book scanner business. There’s a bit more to it than that, but before leaving he decided to dump, not just the design, but the entire rationale behind the design into a twenty-two thousand word document.
One of his big theses in this document, is his perceived failure of the open hardware movement. The licenses aren’t adequate, as they are based on copyright law that only applies to software. This makes it impossible to enforce in practice, which is why he released the entire design as public domain. He also feels that open hardware shares design, but not rationale. In his mind this is useless when encouraging improvement, and we tend to agree. In the end rationale is the useful thing, or the source code, behind a design that truly matters. So, putting his money time where his mouth is, he wrote down the rationale behind his scanner.
The rationale contains a lot of interesting things. At a first glance the book scanner almost seems a simple design, not the culmination of so much work. Though, once we began to read through his document, we began to understand why he made the choices he did. There’s so much to getting a good scan without destroying the book. For example, one needs a light that doesn’t lose any color information. It doesn’t have to be perfect, as the software can correct the white balance. However, it can’t lean too far away from the natural spectrum, it can’t be too bright, and it can’t be uneven, and it can’t be prohibitively expensive. A lot of thought went into the tent light design.
[Daniel]’s book scanners are immensely popular, and are being used all over the world. He’s certainly made an impact, and the community that formed around his project continues to grow without him. He made some interesting points, and if anything wrote a really good build and design log for the rest of us to learn from.
[Dave] builds custom wooden orreries, which are mechanical models of the solar system. It’s no surprise then that he’s interested in the Antikythera Mechanism—a small geared device discovered off the coast of the Greece in 1900 that is believed to be the first analog computer and one of the oldest known geared systems, built partly to predict the positions of celestial bodies in the solar system as it was understood in ancient Greece.
[Dave] decided to build a wooden version of the Antikythera Mechanism as a proof of concept that it can be done in wood rather than the brass of the original. He also sought to incorporate all the modern theories of the device’s gear train. The entire system is made out of 6mm birch plywood that [Dave] cut by hand on a scroll saw. That’s right — no CNC or lasers here. This has as much to do with replicating the craftsmanship of the original as it does with practicality. Besides, the pitch of the gear teeth is too small to be effectively cut with a laser.
There are no motors, either. The gears are centrally connected to nested brass tubing and the mechanism is actuated with a hand crank. The six pages of forum discussion are worth combing through just to see the pictures of [Dave]’s progress and all of those meticulously hand-cut gears.
It took [Dave] the better part of two years to complete this work of art, and you can see it in motion after the break. With the first version complete, he has begun Mk. II which will feature all of the spiral dials and pointers of the original. If you’re interested in exploring the Antikythera Mechanism further, here is Hackaday’s own in-depth look at it.
I recently had the chance to visit Belgrade and take part in the Hackaday | Belgrade conference. Whenever I travel, I like to make some extra field trips to explore the area. This Serbian trip included a tour of electronics manufacturing, some excellent museums, and a startup that is weaving FPGAs into servers and PCIe cards.
Blood doping is so last decade! The modern cyclist has a motor and power supply hidden inside the bike’s frame.
We were first tipped off to the subject in this article in the New York Times. A Belgian cyclocross rider, Femke Van den Driessche, was caught with a motor hidden in her bike.
While we don’t condone sports cheating, we think that hiding a motor inside a standard bike is pretty cool. But it’s even more fun to think of how to catch the cheats. The Italian and French press have fixated on the idea of using thermal cameras to detect the heat. (Skip to 7:50 in the franceTVsport clip.) We suspect it’s because their reporters recently bought Flir cameras and are trying to justify the expense.
The UCI, cycling’s regulatory body, doesn’t like thermal. They instead use magnetic pulses and listen for the characteristic ringing of a motor coil inside the frame. Other possibilities include X-ray and ultrasonic testing. What do you think? How would you detect a motor inside a bike frame or gearset?
A camera slider is an accessory that can really make a shot. But when your business is photography rather than building camera accessories, quick-and-dirty solutions often have to suffice. Thus the genesis of this camera slider controller.
The photographer in question in [Paulo Renato], and while his passion may be photography, he seems to have a flair for motorized dollies and sliders. This controller is a variable-speed, reversible, PIC-based design that drives an eBay gearmotor. The circuit lives on a scrap of perfboard, and it along with batteries and a buck converter are stuffed into the case-modded remains of an old KVM switch. Push buttons salvaged from another bit of e-waste act as limit switches, and a little code provides the magic. We like the hacked nature of the controller, but we wonder about the wisdom of using the former KVM’s USB ports to connect the controller to the drivetrain; it’s all fun and games until you plug a real USB device into it. In sum, though, a nice build with nice results. Check out his other videos for more on the mechanicals.
[Hans Peter] had reached the moment of popping the question. Going down on one knee and proposing to his girlfriend, the full romantic works.
He’s a brave man, [Hans]. For instead of heading for the jeweller’s and laying down his savings on something with a diamond the size of a quail’s egg he decided that his ring should contain something very much of him. So he decided to 3D print a ring and embed a slowly pulsing LED in it. He does mention that this ring is a temporary solution, so perhaps his soon-to-be-Mrs will receive something sparkly and expensive in due course.
To fit his LED and flasher in such a small space he used a PIC10F320 microcontroller that comes in a SOT-23-6 package. This was chosen because it has a handy PWM output to pulse the LED rather than flash it. This he assembled dead-bug style with an 0603 LED, and a couple of hearing aid batteries to power the unit. He has some concerns about how long the hearing aid batteries will power the device, so as he wrote he had better hurry and get on his knees. (He informs us in his tip email that she said yes.)
Benchmarks often get criticized for their inability to perfectly model the real-world situations that we’d like them to. So take what follows in the limited scope that it’s intended, and don’t read too much into it. [Joonas Pihlajamaa]’s experiments with toggling a hardware pin as fast as possible on different single-board computers can still show us something.
The take-home result won’t surprise anyone who’s worked with a single-board computer: the higher-level interfaces are simply slow compared to direct memory-mapped GPIO access. But really slow. We’re talking around 5 kHz from Python or any of the file-based interfaces to the pins versus 3 MHz for direct access. Worse, as you’d expect when a non-realtime operating system is in the middle, there are glitches on the order of ten milliseconds with all the file-based methods.
This test only tells us so much, though, and it’s not really taking advantage of the BeagleBone Black’s ace in the hole, the PRUs — onboard hardware processors that bring real-time IO capabilities to the system. We’d like to see a re-write of the code to take advantage of libpruio, for instance. A 20 MHz square wave is a piece of cake with the PRUs.
Of course, it’s not interacting, which is probably in the spirit of the benchmark as written. But if raw hardware speed on a BeagleBone is the goal, it’s likely that the PRUs are going to feature prominently in the solution.