DIY Thermal Imaging Smartphone

April 26, 2016 by Elliot Williams 22 Comments

We wish we had [Karri Palovuori] for a professor! As an exciting project to get incoming freshmen stoked on electrical engineering, he designed a DIY thermal-imaging smartphone that they can build themselves. It’s all built to fit into a sleek wooden case that gives the project its name: KAPULA is Finnish for “a block of wood”.

It’s just incredible how far one can push easily-available modules these days. [Karri] mounts a FLIR Lepton thermal camera, an LPC1768 Cortex M3 ARM micro, a GSM phone module, and a whole bunch of other cool stuff on a DIY-friendly two-sided board. The design uses 10 mil (0.25mm) trace and space, which is totally achievable with home etching methods. Copper wire bits fill up the vias. Did we mention he’s making the students do all this themselves? How awesome is that?

[Karri] expects that the students will tweak the software side of things. With additional onboard goodies like an accelerometer, microphone, speaker, SIM card, and USB, it’s not likely that they’ll get bored with the platform. He has a stretch hope that someone will take the hardware and modify it. That’s ambitious for sure, but it’s so cool that someone could.

We’ve seen some sophisticated DIY cellphones before, but this one rises above by being easily DIYable and including awesome extra features. Order parts now, and start etching. You could be sending thermal-photo tweets inside of just a few days.

Sophi Kravitz Talks The Tech Behind Art

April 25, 2016 by Elliot Williams 6 Comments

Hackaday’s own mythical beast, Sophi Kravitz makes some amazing collaborative tech-art pieces. In this talk, she walks us through four of the art projects that she’s been working on lately, and gives us a glimpse behind the scenes into the technical side of what it takes to see an installation from idea, to prototype, and onto completion.

Watch Sophi’s talk from the Hackaday | Belgrade conference and then join us after the jump for a few more details.

Continue reading “Sophi Kravitz Talks The Tech Behind Art” →

Cyclists Use Tiny Motors To Cheat

April 25, 2016 by Elliot Williams 138 Comments

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?

This Teddy Bear Steals Your Ubuntu Secrets

April 22, 2016 by Elliot Williams 20 Comments

Ubuntu just came out with the new long-term support version of their desktop Linux operating system. It’s got a few newish features, including incorporating the “snap” package management format. One of the claims about “snaps” is that they’re more secure — being installed read-only and essentially self-contained makes them harder to hack across applications. In principle.

[mjg59] took issue with their claims of increased cross-application security. And rather than just moan, he patched together an exploit that’s disguised as a lovable teddy bear. The central flaw is something like twenty years old now; X11 has no sense of permissions and any X11 application can listen in on the keyboard and mouse at any time, regardless of which application the user thinks they’re providing input to. This makes writing keylogging and command-insertion trojans effortless, which is just what [mjg59] did. You can download a harmless version of the demo at [mjg59]’s GitHub.

This flaw in X11 is well-known. In some sense, there’s nothing new here. It’s only in light of Ubuntu’s claim of cross-application security that it’s interesting to bring this up again.

And the teddy bear in question? Xteddy dates back from when it was cool to display a static image in a window on a workstation computer. It’s like a warmer, cuddlier version of Xeyes. Except it just sits there. Or, in [mjg59]’s version, it records your keystrokes and uploads your passwords to shady underground characters or TLAs.

We discussed Snappy Core for IoT devices previously, and we think it’s a step in the right direction towards building a system where all the moving parts are only loosely connected to each other, which makes upgrading part of your system possible without upgrading (or downgrading) the whole thing. It probably does enhance security when coupled with a newer display manager like Mir or Wayland. But as [mjg59] pointed out, “snaps” alone don’t patch up X11’s security holes.

Embed With Elliot: Keeping It Integral

April 22, 2016 by Elliot Williams 66 Comments

If there’s one thing that a lot of small microcontrollers hate (and that includes the AVR-based Arduini), it’s floating-point numbers. And if there’s another thing they hate it’s division. For instance, dividing 72.3 by 12.9 on an Arduino UNO takes around 32 microseconds and 500 bytes, while dividing 72 by 13 takes 14 microseconds and 86 bytes. Multiplying 72 by 12 takes a bit under 2.2 microseconds. So roughly speaking, dividing floats is twice as slow as dividing (16-bit) integers, and dividing at all is five to seven times slower than multiplying.

There’s a whole lot of the time that you just don’t care about speed. For instance, if you’re doing a calculation that only runs infrequently, it doesn’t matter if you’re using floats or slow division routines. But if you ever find yourself in a tight loop that’s using floating-point math and/or doing division, and you need to get a bit more speed, I’ve got some tips for you.

Some of these tips (in particular the integer division tricks at the end) are arcane wizardry — only to be used when the situation really calls for it. But if you’re doing the same calculations repeatedly, you can often gain a lot just by giving the microcontroller numbers in the format it natively understands. Have a little sympathy for the poor little silicon beasties trapped inside!

Continue reading “Embed With Elliot: Keeping It Integral” →

All Prior Art

April 21, 2016 by Elliot Williams 31 Comments

Disclosed herein is a device for gauging medication dosage. The method may include displaying first, second and third navigation controls. A switch is connected in parallel to the relay contacts and is configured for providing a portion of the input power as supplemental load power to the output as a function of back EMF energy.

We’ve had patents on the mind lately, and have been reading a fair few of them. If you read patent language long enough, though, it all starts to turn into word-salad. But with his All Prior Art and All the Claims websites, [Alexander Reben] tosses this salad for real. He’s got computers parsing existing patents and randomly reassembling them.

Rather than hoping that his algorithm comes up with the next great idea, [Alexander] is hoping to nip the truly trivial ones in the bud. Because prior art — the sum of all pre-existing ideas — is enough to disqualify a patent, if an idea is so trivial that his algorithm could have come up with it, it’s sooner or later going to be off the table.

Most of the results are insane, of course. And it seems to be producing a patent at a rate of about one per 10-15 seconds, so we’re guessing that it’ll take quite a few years for these cyber-monkeys to come up with the works of Shakespeare. But with bogus and over-broad patents filtering through the system every day, it’s not implausible that some day it’ll prove useful.

[Via New Scientist, thanks Frank!]

BeagleBone Pin-Toggling Torture Test

April 21, 2016 by Elliot Williams 20 Comments

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.