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.
Hackaday reader [nats.fr] wrote in with some code from a project that resizes a video stream on the fly using an FPGA. Doing this right means undoing whatever gamma correction has been applied to the original stream, resizing, and then re-applying the gamma. Making life simpler, [nats.fr] settled on a gamma of two, which means taking a bunch of square roots, which isn’t fast on an FPGA.
[nats]’s algorithm is pretty neat: it uses a first-stage lookup to figure out in which broad range the value lies, and then one step of Hero’s algorithm to refine from there. (We think this is equivalent to saying he does a piecewise linear interpolation, but we’re not 100% sure.) Anyway, it works decently.
Of course, when you start looking into the abyss that is special function calculation, you risk falling in. Wikipedia lists more methods of calculating square roots than we have fingers. One of them, CORDIC, avoids even using multiplication by resorting to clever bitshifts and a lookup table. Our go-to in these type of situations, Chebyshev polynomial approximation, didn’t even make the cut. (Although we suspect it would be a contender in the gamma=1.8 or gamma=2.2 cases, especially if combined with range-reduction in a first stage like [nats.fr] does.)
So what’s the best/fastest approximation for sqrt(x) for 16-bit integers on an FPGA? [nats.fr] is using a Spartan 6, so you can use a multiplier, but division is probably best avoided. What about arbitrary, possibly fractional, roots?
(Bipolar Junction) Transistors versus MOSFETs: both have their obvious niches. FETs are great for relatively high power applications because they have such a low on-resistance, but transistors are often easier to drive from low voltage microcontrollers because all they require is a current. It’s uncanny, though, how often we find ourselves in the middle between these extremes. What we’d really love is a part that has the virtues of both.
The ask in today’s Ask Hackaday is for your favorite part that fills a particular gap: a MOSFET device that’s able to move a handful of amps of low-voltage current without losing too much to heat, that is still drivable from a 3.3 V microcontroller, with bonus points for PWM ability at a frequency above human hearing. Imagine driving a moderately robust small DC robot motor forwards with a microcontroller, all running on a LiPo — a simple application that doesn’t need a full motor driver IC, but requires a high-efficiency, moderate current, and low-voltage-logic compatible transistor. If you’ve been here and done that, what did you use?
There have been virtual worlds long before our computers could render anything but potatoes with anime faces. Bulletin boards, mailing lists, and forums dominated and then fell, for the most part, to social media. In a way even the personal home page has gone to the wayside. (remember geocities?)
The internet has gone through many phases of development. We’ve experimented with lots of concepts and when they fail or go out of style, there are ghost towns of information left untouched.
Imagine this, you have a friend who grew up in Shenzhen, China. The place from whence all your really cool electronics come these days. They speak Chinese in a way only someone born there can, and given that you know them through a shared interest in hardware hacking you can assume they know their way round those famous electronics marts of their home town.
Now, imagine that in a rash move, your friend has offered to pick up a few bits for you on their next trip home. A whole city-sized electronic candy store opens up in front of you, but what do you ask for them to seek out?
Before you continue, consider this. Why has Shenzhen become the powerhouse of electronic manufacturing (and everything else) that it is? Economists will give you pages of fascinating background, but if you want a simple answer it is that those electronics are produced for export, and that its citizens are only too happy to export them to you. Therefore if you want to get your hands on electronics from Shenzhen you do not need a friend who is a native of the city, all you need is a web browser and a PayPal account.
We have all become used to seeking out the cool stuff and eagerly waiting for a padded envelope from China Post a week or two later, so there are very few items that are worth putting a friend to the extra task of finding. At which point you realize that it is the candy store rather than the candy itself which is so alluring, and you ask your friend for a video walkthrough with commentary of their travels through the electronics marts. Oh, and maybe a Chinese Raspberry Pi with red solder resist, just for the collection.
If you had a friend about to board a plane to Shenzhen, what would you ask them to find for you that you can’t just buy for yourself online? Remember, nothing that’ll land them with awkward questions at either airport, nor anything that’ll land them with a hefty customs bill. That’s a very good way to end a friendship.
Apex Minecraft hosting recently held a scholarship competition. The person who sent in the best essay would win a $2,000 scholarship. The winning essay starts, “Five years ago, at age 13, I built an entire computer from scratch. Assembled from basic components: wires, torches, repeaters, pistons, and blocks, it was capable of rendering images to a display, multiplying and dividing numbers, and even calculating square roots.” I had to read it twice before it clicked that he was talking about a computer built entirely in a fictional universe.
It’s no wonder that he’s now a freshman at college, pursuing a degree in computer engineering. After reading this, I started to reminisce. The first computer I ever had access to was my mother’s laptop. It had an install of QBASIC on it, and I remember using it to make a few text based games. Later on when we got our first family computer I remember spending hours getting no better at video game programming using QBASIC.
It went on and on. I remember doing AI for video games in DarkBasic. I remember doing physics and collisions. Eventually I found my way to html, then php, to make websites about games (which are too terrible to share with you). So when the time came to program robots I was absolutely fearless. It just seemed like such a natural extension of what I already knew that it never occurred to me to be thankful for the time I spent trying to make my own simple little games until much later.
In the end I am still occasionally making little forays into game programming when I want to learn a new language or get back up to speed. It never occurred to me that perhaps this was just the way I’ve always learned a language.
Later on in the winner’s essay he goes on to describe his minecraft community. They taught new players. They taught themselves. They hung out and became friends. The writer gained a sense of self as a user of computers, a teacher of skills, a good member of a community, and a solver of problems. Unlike some of his classmates he won’t go to college and have to learn if he’s good enough. He’ll already know. All it took was a silly block based game.
Did any of you have seemingly frivolous endeavors show up as a foundation for your life and learning far into the future? Tell in the comments below how this ended up shaping your career.
I have a good background working with high voltage, which for me means over 10,000 volts, but I have many gaps when it comes to the lower voltage realm in which RC control boards and H-bridges live. When working on my first real robot, a BB-8 droid, I stumbled when designing a board to convert varying polarities from an RC receiver board into positive voltages only for an Arduino.
Today’s question is, how do you convert a negative voltage into a positive one?
In the end I came up with something that works, but I’m sure there’s a more elegant solution, and perhaps an obvious one to those more skilled in this low voltage realm. What follows is my journey to come up with this board. What I have works, but it still nibbles at my brain and I’d love to see the Hackaday community’s skill and experience applied to this simple yet perplexing design challenge.
I have an RC receiver that I’ve taken from a toy truck. When it was in the truck, it controlled two DC motors: one for driving backwards and forwards, and the other for steering left and right. That means the motors are told to rotate either clockwise or counterclockwise as needed. To make a DC motor rotate in one direction you connect the two wires one way, and to make it rotate in the other direction you reverse the two wires, or you reverse the polarity. None of the output wires are common inside the RC receiver, something I discovered the hard way as you’ll see below.