The Linux Throwie: A Non-Spacefaring Satellite

Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.

A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.

Where we left off, I had a solar cell that could charge a battery, and provide regulated 12v and 5v output. For it to be a functional device, there are three high level problems to solve:

  1. It must be possible to set up the device without direct physical access
  2. You must be able to remotely turn it on and off as needed.
  3. It needs to be accessible from the Internet.

The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?

As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.

Continue reading “The Linux Throwie: A Non-Spacefaring Satellite”

Of Roach Killer and Rust Remover: Sam Zeloof’s Garage-Made Chips

A normal life in hacking, if there is such a thing, seems to follow a predictable trajectory, at least in terms of the physical space it occupies. We generally start small, working on a few simple projects on the kitchen table, or if we start young enough, perhaps on a desk in our childhood bedroom. Time passes, our skills increase, and with them the need for space. Soon we’re claiming an unused room or a corner of the basement. Skills build on skills, gear accumulates, and before you know it, the garage is no longer a place for cars but a place for pushing back the darkness of our own ignorance and expanding our horizons into parts unknown.

It appears that Sam Zeloof’s annexation of the family garage occurred fairly early in life, and to a level that’s hard to comprehend. Sam seems to have caught the hacking bug early, and by the time high school rolled around, he was building out a remarkably well-equipped semiconductor fabrication lab at home. Sam has been posting his progress regularly on his own blog and on Twitter, and he dropped by the 2018 Superconference to give everyone a lesson on semiconductor physics and how he became the first hobbyist to produce an integrated circuit using lithographic processes.

Continue reading “Of Roach Killer and Rust Remover: Sam Zeloof’s Garage-Made Chips”

Fail Of The Week: When the Epoxy-Coated Chip Is Conductive

Every once in a while, you’ll find some weirdness that will send your head spinning. Most of the time you’ll chalk it up to a bad solder joint, some bad code, or just your own failings. This time it’s different. This is a story of weirdness that’s due entirely to a pin that shouldn’t be there. This is a package for an integrated circuit that has a pin zero.

The story begins with [Erich] building a few development boards for the Freescale Kinetis K20 FPGA. This is a USB-enabled microcontroller, and by all accounts, a worthwhile effort. So far, so good. The problem with the prototype boards was soon apparent. On some of the boards, the external 32 kHz oscillator was not starting. Resoldering the oscillator or microcontroller sometimes solved the problem, but not always. This is troubling, because that means the issue isn’t code, and it’s not the PCB. This is going to take a deep dive and a good inspection microscope.

One of [Erich]’s friends, [Christian B] somehow found the problem. When the Freescale K40 is manufactured, the die is carefully laid in a chip carrier and coated with epoxy, putting it in a small QFN package. The problem is, there’s an extra connection sticking out of one corner of this chip. This is just an artifact of the chip carrier, but if you leave exposed metal connected to ground, something is eventually going to go wrong.

The best guess [Erich] has is that this additional connection is from the manufacturing and packaging process, with the exposed metal pad in this application being bridged to an adjacent pad. Now, if there’s one failure to [Erich]’s design, it’s that the trace comes out of the pin on the adjacent pad at 90 degrees; this isn’t a best practice, but most of the time you can get away with it. This time, though, somebody got burned.

We don’t know how [Christian] ever found this issue. When you look at a tiny QFN package, you don’t expect there to be an extra pin attached to ground that can be easily bridged with a bit of solder paste. It’s either a lot of luck or skill to find this problem, but it’s a great example of the weird things you have to look out for.

Hackaday Links: November 18, 2018

The greatest bit of consumer electronics is shipping and the reviews are out: Amazon’s Alexa-enabled microwave is a capable microwave, but befuddling to the voice-controlled-everything neophyte. Voice controlled everything is the last hope we have for technological innovation; it’s the last gasp of the consumer electronics industry. This is Amazon’s first thing with a built-in voice assistant, and while this is a marginally capable microwave at only 700 Watts — fine for a college dorm, but it’s generally worth shelling out a bit more cash for a 1000 Watt unit — the controls are befuddling. The first iteration is always hard, and we’re looking forward to the Amazon Alexa-enabled toaster, toothbrush, vacuum cleaner, and Bezos shrine.

Need a laser cutter, like crowdfunding campaigns, and know literally nothing about laser cutters? Have we got something for you. The Etcher Laser crowdfunding campaign has been pinging my email non-stop, and they’ve got something remarkable: a diode laser cutter engraver for $500. It comes in a neat-looking enclosure, so it’s sure to raise a lot of money.

A while back [Paulusjacobus] released an Arduino-based CNC controller for K40 laser cutters. There were a few suggestions to upgrade this to the STM32, so now this CNC controller is running on a Blue Pill. Yes, it’s great and there’s more floating points and such and such, so now this project is a Kickstarter project. Need a CNC controller based on the STM32? Boom, you’re done. It’s also named the ‘Super Gerbil’, which is an awesome name for something that is effectively a GRBL controller. Naming things is the hardest problem in computer science, after all.

The Gigatron computer is a ‘home computer’ without a microprocessor or microcontroller. How does it do this? A metric butt-load of ROM and look-up tables. This is cool and all, but now the Gigatron logo is huge. we’re talking 18 μm by 24 μm. This was done by etching a silicon test wafer with electron beam lithography.

FPGA Testbenches Made Easier

You finally finish writing the Verilog for that amazing new DSP function that will revolutionize human society and make you rich. Does it work? Your first instinct, of course, is to blow it into your FPGA of choice and see if it works. If it does, that was a great idea. If it doesn’t, it was a terrible idea because — typically — it is hard to look inside the FPGA. That’s why you’ll typical simulate your logic on a desktop computer before you commit it to the FPGA. But that means you have to delay gratification long enough to write a testbench — a piece of hardware description language (HDL) code that exercises the function you wrote. In this post I’ll show you a small piece of software that can read your Verilog module and automatically create most of a testbench for you. The code originally came from GitHub, but I wanted to make some changes to it, so I forked it and I’ll tell you about the changes I made. This isn’t specific to a particular FPGA. Any Verilog project can use the tool to generate a simple starter testbench.

Writing a testbench isn’t that hard. You usually use the same language you wrote the original code in but since it won’t reside in silicon, you can do things in the simulator that you can’t get away with in code that you’ll synthesize. However, it is a bit painful to have to always write more or less the same code, especially if you have a lot of modules you want to test. But it is a good idea to test small modules before linking them together and then test them linked together, too. With this little Python script, it is very easy to generate a simple testbench and then further elaborate it. It isn’t life-changing, but it does save some time. If you want to try this out, you’ll need something to run the Python script on, of course. You also need a Verilog simulator or you can use EDA Playground to try all this out in your browser.

Continue reading “FPGA Testbenches Made Easier”

An In-Depth Look at Dexter, the Robotic Arm

Dexter, a really great robot arm project, just won top honors in the 2018 Hackaday Prize, and walked away with $50,000 toward continuing their project. As a hat tip to Hackaday and the community, Haddington Dynamics, the company behind Dexter, agreed to open-source their newest version of Dexter as well. As James Newton said when accepting the trophy during the award ceremony, “because of your faith in us, because of this award, we have been moved to open-source the next generation of Dexter.” Some very clever work went into producing Dexter, and we can’t wait to see what further refinements have been made!

Dexter isn’t the only robotic arm in town, by any means. But in terms of hobbyist-level robotics, it’s by far the most complete robot arm that we’ve seen, and it includes a couple of design features that make both its positional accuracy and overall usability stand out above the rest. This is a robot arm with many of the bells and whistles of a hundred-thousand dollar robot, but on a couple-thousand dollar budget. Continue reading “An In-Depth Look at Dexter, the Robotic Arm”

3D Printering: Blender Tips For Printable Objects

3D models drawn in Blender work great in a computer animated virtual world but don’t always when brought into a slicer for 3D printing. Slicers require something which makes sense in the real world. And the real world is far less forgiving, as I’ve found out with my own projects which use 3D printed parts.

Our [Brian Benchoff] already talked about making parts in Blender with his two-part series (here and here) so consider this the next step. These are the techniques I’ve come up with for preparing parts for 3D printing before handing them off to a slicer program. Note that the same may apply to other mesh-type modeling programs too, but as Blender is the only one I’ve used, please share your experiences with other programs in the comments below.

I’ll be using the latest version of Blender at this time, version 2.79b. My printer is the Crealty CR-10 and my slicer is Cura 3.1.0. Some of these steps may vary depending on your slicer or if you’re using a printing service. For example, Shapeways has instructions for people creating STLs from Blender for uploading to them.

Continue reading “3D Printering: Blender Tips For Printable Objects”