A Smartwatch You Can Easily Build Yourself

January 1, 2019 by 16 Comments

The concept of a smartwatch was thrown around for a long time before the technology truly came to fruition. Through the pursuit of miniaturisation, modern smartwatches are sleek, compact, and remarkably capable for their size. Companies such as Apple and Samsung throw serious money into research and development, but that doesn’t mean you can’t create something of your own. [Electronoobs] has done just that, with this Arduino-based smartwatch build.

The brain of the watch is that hacker staple, the venerable ATmega328, most well known for its use in the Arduino Uno and Nano platforms. An FTDI module is used for USB communication, making programming the board a snap. Bluetooth communication is handled by another pre-built module, and a smartphone app called Notiduino handles passing notifications over to the watch.

This is a build that doesn’t do anything crazy or difficult to understand, but simply combines useful parts in a very neat and tidy way. The watch is impressively thin and compact for a DIY build, and has a host of useful functions without going overboard.

We’ve seen other DIY builds in this space, too – such as this ESP8266-based smartwatch. Video after the break.

Continue reading “A Smartwatch You Can Easily Build Yourself” →

Drone over a wheat field

Ask Hackaday: How Would You Detect A Marauding Drone?

January 1, 2019 by 117 Comments

The last few days have seen drone stories in the news, as London’s Gatwick airport remained closed for a couple of days amid a spate of drone reports. The police remained baffled, arrested a couple who turned out to be blameless, and finally admitted that there was a possibility the drone could not have existed at all. It emerged that a problem with the investigation lay in there being no means to detect a drone beyond the eyesight of people on the ground, and as we have explored in these pages already, eyewitness reports are not always trustworthy.

Not much use against a small and mostly plastic multirotor. Sixflashphoto [CC BY-SA 4.0]
Not much use against a small and mostly plastic multirotor. Sixflashphoto [CC BY-SA 4.0]

Radar Can’t See Them

It seems odd at first sight, that a 21st century airport lacks the ability to spot a drone in the air above it, but a few calls to friends of Hackaday in the business made it clear that drones are extremely difficult to spot using the radar systems on a typical airport. A system designed to track huge metal airliners at significant altitude is not suitable for watching tiny mostly-plastic machines viewed side-on at the low altitudes. We’re told at best an intermittent trace appears, but for the majority of drones there is simply no trace on a radar screen.

We’re sure that some large players in the world of defence radar are queueing up to offer multi-million-dollar systems to airports worldwide, panicked into big spending by the Gatwick story, but idle hackerspace chat on the matter makes us ask the question: Just how difficult would it be to detect a drone in flight over an airport? A quick Google search reveals multiple products purporting to be drone detectors, but wouldn’t airports such as Gatwick already be using them if they were any good? The Hackaday readership never fail to impress us with their ingenuity, so how would you do it?

Can You Hear What You Can’t See?

It’s easy to pose that question as a Hackaday scribe, so to get the ball rolling here’s my first thought on how I’d do it. I always hear a multirotor and look up to see it, so I’d take the approach of listening for the distinctive sound of multirotor propellers. Could the auditory signature of high-RPM brushless motors be detected amidst the roar of sound near airports?

I’m imagining a network of Rasberry Pi boards each with a microphone attached, doing some real-time audio spectrum analysis to spot the likely frequency signature of the drone. Of course it’s easy to just say that as a hardware person with a background in the publishing business, so would a software specialist take that tack too? Or would you go for a radar approach, or perhaps even an infra-red one? Could you sense the heat signature of a multirotor, as their parts become quite hot in flight?

Whatever you think might work as a drone detection system, give it a spin in the comments. We’d suggest that people have the confidence to build something, and maybe even enter it in the Hackaday Prize when the time comes around. Come on, what have you got to lose!

Open Source Company Gives Us A Peek At Financial Innards

January 1, 2019 by 13 Comments

Here at Hackaday we are willing to bet that in a universe free of all monetary constraints, many of our readers would leave their day jobs in order to pursue their hardware hobbies full time. Obviously this is only practical for a lucky minority of people (for a wide variety of reasons) but we’re willing to bet that a significant stumbling block is figuring how to do it in the first place. You quit your job, but then what? If more information about starting and sustaining small hardware business’ was available more people would take the plunge to start one. There are software companies with salary transparency but this is only part of the picture and we can’t think of many hardware companies that offer the same. What we really want is to get an image of the entire business end to end; from suppliers to COGS to salary. And we want to see it for hardware.

Years ago the first and second Hackaday Prizes captured an entrant named FarmBot whose goal was to build open source robotic farming equipment to make it easier for anyone to grow their own food. A few successful Kickstarters and years later they’ve been shipped multiple versions of the Genesis and Genesis XL robotic farming system and have a sustainable business! And now they’ve decided to open source their business operations too. Suffice to say, this provides quite an uncommon view into the guts of what makes a small open source hardware business tick. Let’s take a closer look!

There is a wealth of information exposed in the company documentation; it’s as though they took their internal wiki and made it public, which we suppose is exactly what happened. The most interesting part for our readers might be the statistics page that tracks costs and quantities for their products. This is where the magic lives. You can use to it see that so far they’ve sold 124 Genesis XL machines at an average selling price of $3,834.34 for $475,458.30 of revenue (it cost $187,200 to build their run of 200 machines). You can also see that each machine has 1,415 parts and takes about 25 hours to assemble. This page is where the true guts of the business live.

Everything else is here too. Here’s where you can learn about what vendors FarmBot uses use logistics, or power, or web infrastructure monitoring. And this is the page with the infamous salary calculation formulas if you want to guess what you’d make as an employee. Then there’s a bunch of boring but important stuff. Fulfillment processes live here, and the consumables they use to support that fulfillment are listed here (with costs!).

One reason we enjoy open source so much is that it affords a wonderful opportunity for people to learn instead of keeping the important parts of a product or process perpetually under wraps. We’re hoping that documentation like this becomes more prevalent and foster an explosion of small hardware companies to follow it.

Excuse Me, I Have To Feed The Computer

January 1, 2019 by 13 Comments

It is a staple of science fiction to see a brain in a jar or other container, maybe used as some sort of computer device. You are probably imagining a brain-powered supercomputer with a room full of humans with electrodes in their heads, or maybe some other primate. The reality though is it might be just a small dish full of single-celled amoeba.

Researchers from China and Japan have successfully made a lowly amoeba solve the traveling salesman problem for 8 cities. We’ll be honest. We don’t totally understand the value to it over traditional methods, but it does prove that you can compute with organic matter. This isn’t just any amoeba, though. It is a particular kind, Physarum polycephalum, that has an unusual property — it can shapeshift, at least to a limited degree. The tiny creature is just like us in that it tries to get things it likes and avoid things it doesn’t like. It likes food, but it doesn’t like light.

Provide food, and the tiny creature will spread out. Shine light on it, and it will retract. That’s the property used to solve the thorny problem, but before we look at how that works it helps to understand the problem it is trying to solve.

Continue reading “Excuse Me, I Have To Feed The Computer” →

Artificial Limbs And Intelligence

December 31, 2018 by 1 Comment

Prosthetic arms can range from inarticulate pirate-style hooks to motorized five-digit hands. Control of any of them is difficult and carries a steep learning curve, rarely does their operation measure up to a human arm. Enhancements such as freely rotating wrist might be convenient, but progress in the field has a long way to go. Prosthetics with machine learning hold the promise of a huge step to making them easier to use, and work from Imperial College London and the University of Göttingen has made great progress.

The video below explains itself with a time-trial where a man must move clips from a horizontal bar to a nearby vertical bar. The task requires a pincer grasp and release on the handles, and rotation from the wrist. The old hardware does not perform the two operations simultaneously which seems clunky in comparison to the fluid motion of the learning model. User input to the arm is through electromyography (EMG), so it does not require brain surgery or even skin penetration.

We look forward to seeing this type of control emerging integrated with homemade prosthetics, but we do not expect them to be easy.

Continue reading “Artificial Limbs And Intelligence” →

A DIY Interface for Subaru Select Monitor 1

Hacking A 20 Year Old Subaru

December 31, 2018 by 45 Comments

While cars are slowing becoming completely computer-controlled, road vehicles have been relying on computers since the 1970’s. The first automotive use of computers was in engine control units (ECUs) which came along as fuel injection systems started to replace carburetors.

[P1kachu]’s 1997 Subaru Impreza STi, like most cars of this vintage, uses an ECU and provides a diagnostic connector for external communications. [P1kachu]’s Subaru hacking project includes building a diagnostic interface device, dumping the ECU’s firmware, and reverse engineering the binary to understand and disable the speed limiter. If this looks familiar, it’s because we just covered the infotainment hacks in this car on Saturday. But he added information about the communications protocols is definitely worth another look.

This era of Subaru uses a non-standard diagnostics protocol called SSM1, which is essentially a 5 volt TTL serial line running at 1953 bits per second. The custom interface consists of a Teensy and a 3.3V to 5V level shifter. Once connected, commands can be sent directly to the ECU. Fortunately, the protocol has been quite well documented in the past. By issuing the “Read data from ECU address” command repeatedly, the full firmware can be dumped.

[P1kachu] goes on to locate the various engine tuning maps and discover the inner workings of the speed limiter. With cars getting more computerized, it’s nice to see folks are still able to tune their rides, even if it means using Teensys instead of wrenches.

35C3: Safe And Secure Drivers In High-Level Languages

December 31, 2018 by 12 Comments

Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.

With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.

At last year’s 34c3, [Paul] already demonstrated the basics of writing such a user-space network driver for Linux, which serves now as reference implementation for his students. We won’t see Bash or JavaScript here, but we will see a brief summary of what it generally means to develop user-space drivers in C#, Swift, OCaml, or Haskell, along a more detailed insight from [Sebastian Voit] and [Simon Ellmann] about Go and Rust. A collection of each language’s implementation can be found on GitHub.

Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages” →