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” →

35C3: A Deep Dive Into DOS Viruses And Pranks

December 31, 2018 by 29 Comments

Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.

So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.

We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.

Continue reading “35C3: A Deep Dive Into DOS Viruses And Pranks” →

The Art Of Vacuum Tube Fabrication

December 31, 2018 by 32 Comments

Vacuum tubes fueled a technological revolution. They made the amplification of signals a reality for transatlantic telephone cables (and transcontinental ones too), they performed logic for early computers, and they delivered that warm fuzzy sound for high fidelity audio. But they were labor intensive to produce, and fragile, so semiconductors came along and replaced tubes in almost every application. But of course tubes are still with us and some tube applications are still critical — you’ll find them used in high-power RF and there are even satellites that depend on klystrons. So there are still experts in tube fabrication around, and Charles Alexanian is one of them. His newly-published talk at the 2018 Hackaday Supercon (found below) is a whirlwind tour of what goes into building a vacuum tube.

The process of building your own vacuum tube isn’t hard, but it’s not a walk in the park. The difficulty comes in the sheer number of processes, and the tricks of the trade found at every step. Charles’ methaphor is that if you build one tube at a time each step is like learning to ride a bicycle again, but if you build many you get into the swing of it and things go a lot better. His talk is a brief overview of everything, but if you want to drill down he also wrote an excellent article that goes further in depth.

In the working components of each tube are the precision parts: the grid (or grids). For the tube to function well these must be accurately produced which can be done with photolithography, but Charles usually uses a winding process involving a lathe. After winding, the grid is stretched to straighten the nickel wire, then cut to length. Other components such as the plate are stamped using an arbor press and simple forms he fabricates for the purpose.

Tube sealing machine common in factories
Lathe setup used for 1-off tube sealing
Tube being tested for leaks

Two glass components are used, the dome itself, and feedthrough stems that have a wire for each lead passing through a glass disc. The components are spot welded to the inside portion of the feedthrough stem, then the glass is fused together, again using a lathe. It heads over to a pumping station to evacuate the air from the tube, and is finally tested for leaks using a handheld Tesla coil (see, we knew those weren’t just toys).

Charles proposed his Supercon appearance as a chance to fabricate tubes on-site. We loved the idea, but the amount of gear needed is somewhat prohibitive (annealing ovens, vacuum cabinets, torches for sealing, and the need for 220v, plus space for it all). That’s too bad since we were really hoping to see the Jolly Wrencher in Nixie-tube form — incidentally, Charles says Nixes are simple to make compared to amplifiers and switches. He also mentions that the majority of your time is spent “washing” parts to remove impurities. Fair enough, that part sounds boring, but we hope to endure it at some point in the future because vacuum tube fabrication demos feel very much like a Hackaday event!

Continue reading “The Art Of Vacuum Tube Fabrication” →