Touch Sensitive Cement with Just a Dash of Neon

For quite some time now we’ve seen people casting their own countertops and other surfaces out of cement. It’s a combination of mold-making and surface finishing that produces a smooth and durable surface at quite a low cost, if you don’t factor in damage done to your back when lifting the thing for installation.

This offering is a little bit different. [Elliott Spelman] built his own touch sensitive cement table top. When you place your grubby hands on the polished surface, a loop of neon lighting is switched on. This is thanks to a 4:1 mix of quick setting cement and iron oxide powder. Bare copper wire was laid around the edges of the surface to be encased by the cement for making connections later.

There were some sad moments when [Elliott] was removing the cast surface from the mold. He ended up cracking it and suggests others be liberal with their use of both wax on the mold before casting, and patience in removing the cement afterward. We might also suggest a strengthening agent like fiber reinforcement. The edges and surface can be sanded to the finish desired and in this case, attaching table legs was easy since the wooden underside of the mold remains on the bottom of the cement.

The neon lighting adds a retro touch to this build. It’s sad to see this technology dying away, so a resurgence of artisanal neon is great in our book. [Elliott] found a Bay Area arts collective called the Crucible which does a lot of art glass education to help him make two hoops of glass tube and fill them with the appropriate gasses. A capacitive touch sensor (once Atmel, now Microchip part) AT42QT2120 (datasheet) monitors the wire coming from the slab and switches the power supply for the tubes using a combination of relay board and Arduino Uno.

We find the prospect of positional sensing in doped cement fascinating. Anyone have ideas for adapting this technique so that a more long and narrow slab could have positional awareness within, say, a few inches? Let us know in the comments.

Continue reading “Touch Sensitive Cement with Just a Dash of Neon”

Interview: Nacer Chahat Designs Antennas for Mars CubeSats

You have a shoe box sized computer that you want to use in a Mars fly by. How do you communicate with it? The answer is a very clever set of antennas. I got to sit down with Nacer Chahat, one of the engineers on the Jet Propulsion Laboratory team responsible for antenna design on Mars Cube One (MarCO). Two of these CubeSats that will soon be used to help a lander reach Mars. We talked about the work that went into MarCO, the deployable radar antenna he’s worked on for the RainCube project, and the early progress on OMERA, the One Meter Reflectarray.

This is a fascinating discussion of dealing with a multitude of engineering challenges including lack of available space for the antenna components, and power and weight limitations. Check out the video interview to see how the people at JPL fit it all into this, and other tiny satellites, then join us below for more details.

Continue reading “Interview: Nacer Chahat Designs Antennas for Mars CubeSats”

SPI On Embedded Linux

Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?

The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.

The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.

Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.

Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.

Continue reading “SPI On Embedded Linux” Passes 200,000 Registered Users just welcomed the 200,000th registered user! We are the world’s largest repository of open hardware projects and is proving its worth as the world’s most vibrant technology community. This is where you go to get inspiration for your next project, to get help fleshing out your product ideas, to build your engineering dream team, and to tell the tales of the workbench whether that be success, failure, or anything in between.

Over the past six months, as we’ve grown from the 150k member milestone to this one, our movement has enjoyed ever-increasing interaction among this amazing group of people. Thank you for spending so much time here and making a great place for everyone!

Hack Chat Bring Experts from Many Fields

bunnie03-01It’s always great when you can watch a conference talk or interview online. But if you weren’t there in person the opportunity for meaningful interaction has already passed. With this in mind, we’ve been inviting experts from numerous fields to host discussions live in the Hack Chat room.

This is a great way to further our goal of forming a global virtual hackerspace. It’s common to have talks and workshops at a hackerspace, where you can not only learn from and ask questions of the person leading the event, but meet others who share your interests. This has happened time and again with recent guests including Bunnie Huang who talked about making and breaking hardware, a group of Adafruit engineers who discussed their work extending the MicroPython libraries, Sprite_tm who covered the continuing development of ESP32 support, and many more.

This Friday at Noon PST Hackaday’s own Jenny List will be leading the Hack Chat on RF Product design. See you there!

Amazing Projects

It’s pretty amazing to see a guide on building a smartphone for $50 in parts. If that exists anywhere, it’s probably on — and it’s actually pushing about 80,000 views so far! Arsenijs is a regular around these parts and his ZeroPhone — a 2G communications device based on the Raspberry Pi Zero — is a project that he’s been updating as his prototype-to-production journey progresses. It has a big team behind it and we can’t wait to see where this one goes.

zerophone-thumbWorking on your own is still a great way to learn and we see all kinds of examples of that. Just4Fun is learning the dark arts that went into early personal computing with a $4 project to build a Z80 system on a breadboard.

We revel in the joy of seeing great hardware art come to life. FlipFrame is a great example; it’s a digital picture frame project that goes far beyond that simple description. It rotates the entire screen to fit the layout of the image while showing off all of the hardware that makes this possible rather than hiding it away inside a case.

In addition to our registered users milestone, we’re just about to pass our 20,000th published project. There are so many projects to celebrate and draw inspiration from, and that collection grows every day!

The Rise of Build Contests

This winter we’ve seen a ton of interest in the build contests hosted on Of course, nothing can compare to the reach of the Hackaday Prize, our worldwide engineering initiative that challenges people to Build Something That Matters. The 2016 winners were announced in November; even so, people have been tripping over themselves to get a project built for the numerous contests we’ve hosted since then.

enlightenpiOf note is the 1 kB Challenge — a contest dreamed up by our own Adam Fabio which challenged entrants to build an embedded project whose compiled code was 1 kB or less. It was a joy to dive into the entries for this and it will certainly return again.

Running right now is the revival of my favorite build contest: the Hackaday Sci-Fi Contest. Bring your favorite Sci-Fi tech to life — it just needs to be recognizable from a book, movie, or TV show and include some type of electronics.

Meet Your Friends in Real Life

Some of my closest friends in life were first met online. But eventually, you just want to hang out in the same room. This is becoming more and more common with In November we celebrated our second Hackaday SuperConferece where hundreds of people who love hardware creation gathered in Los Angeles for two days of amazing talks, workshops, and hands-on hacking challenges. This is a good one to add to your calendar but tickets do sell out so consider some other options.

We have regular meetups in LA and New York. If you are ever traveling there, make sure to look up the schedule and see if it can be part of your trip. Perhaps the most interesting was World Create Day. In 2016, we had 80 groups across the world plan meetups on the same day so that the Hackaday community could hang out in real life. We’re not ready to share the details quite yet, but you should plan for that to happen again this year. Something to look forward to!

Robot Leaps Uncanny Valley on Backward Knees

We’ve covered a ton of Boston Dynamics robots but this is the second one in a row that has shown a departure from what a lot of people’s notion of an ‘advanced’ robot should look like. It’s a cellphone camera clip of a video played at a conference, but at least it isn’t vertical video — kudos to [juvertson]. At about 3:40 seconds into the video you get a good look “Handle” at a four-limbed robot with backwards joints and wheel.

This design makes a lot of sense and it’s good to see Boston Dynamics thinking about unique robot kinematics alongside the realities of motion. The result is something that appears neither human nor animal — it’s definitely not natural. Despite the presenter’s assertion that this will be nightmare-inducing, we think it’s the opposite, since it doesn’t tweak that string in your brain that cries “predator”.

Obviously this is what we’d call a self-balancer. But two-wheels-plus-rigid-frame it is not. The articulated lower limbs allow it to shift its mass over the wheels. The upper limbs play their part in balancing, at one point acting in the same way a figure skater’s arms would during a spin. And its dexterity in hopping over an obstacle is only made better by [juvertson’s] commentary. This is a really good balance between purely wheeled and purely humanoid designs and a nice addition to the evolution of robotics.

Continue reading “Robot Leaps Uncanny Valley on Backward Knees”

Jamming WiFi by Jumping on the ACK

As we fill our airwaves with more and more wirelessly connected devices the question of what could disrupt this systems becomes more and more important. Here’s a particularly interesting example because the proof of concept shows that you don’t need specialized hardware to pull it off. [Bastian Bloessl] found an interesting tweak to previous research that allows an Atheros WiFi card to jam WiFi by obscuring ACK frames.

The WiFi protocol specifies an Acknowledgement Frame (ACK) which is sent by the receiving device after error correction has been performed. It basically says: “yep, I got that data frame and it checks out”. This error correcting process turns out to be the key to [Bastian’s] technique as it provides time for the attack hardware to decide if it’s going to jam the ACK or not.

The jamming technique presented by [Mathy Vanhoef] at the end 2014 outlined both constant and selective jamming. The selective part involved listening for data packets and analyzing them to determine if they are headed to a MAC the attacker wishes to jam. The problem is that by the time your commodity hardware has decoded that address it’s too late to jam the packet. [Bastian] isn’t trying to jam the data frame, he’s jamming the ACK that the receiver sends back. Without that acknowledgement, the sender will not transmit any new data frames as it assumes there is a problem on the receiving end.

Ask Hackaday: Are Unlockable Features Good for the User?

There are numerous examples of hardware which has latent features waiting to be unlocked by software. Most recently, we saw a Casio calculator which has the same features as its bigger sibling hidden within the firmware, only to be exposed by a buffer overflow bug (or the lead from a pencil if you prefer a hardware hack).

More famously, oscilloscopes have been notorious for having crippled features. The Rigol DS1052E was hugely popular on hacker benches because of it’s very approachable price tag. The model shipped with 50 MHz bandwidth but it was discovered that a simple hack turned it into the DS1102E 100 MHz scope. Tektronix has gotten in on this action as well, shipping modules like I2C, CAN, and LIN analyzation on the scope but requiring a hardware key to unlock (these were discovered to have a horribly insecure unlock method). Similar feature barriers are found on Rigol’s new reigning entry-level scope, the DS1054Z, which ships with protocol analyzation modules (among others) that are enabled only for the first 70 hours of scope operation, requiring an additional payment to unlock them. Most scope manufacturers are in on the game, and of course this is not limited to our tools. WiFi routers are another great example of hardware hosting firmware-unlockable features.

So, the question on my mind which I’d like to ask all of the Hackaday community is this: are unlockable features good for us, the people who use these tools? Let’s take a look at some of the background of these practices and then jump into a discussion in the comments.

Continue reading “Ask Hackaday: Are Unlockable Features Good for the User?”