We’ve seen a lot of hacks with the nRF24l01+ 2.4 GHz radio modules. The tiny chips pack a lot of bang for the buck. Since the radios can switch frequencies relatively quickly, [Shubham Paul] decided to take advantage of this feature to make a rudimentary frequency-hopping communications channel.
The code is actually incredibly simple. Both the transmitter and receiver simply scan up and down over the defined channels. Because the clock speeds of any given pair of Arduinos are likely to be slightly different, it’s not a surprise that the radios eventually drift out of sync. Right now, as a quickie solution, [Shubham] is using a serial-port resynchronization: both are connected to the same computer, and he just tells them to get on the same channel. That’s not a horribly satisfying workaround. (But it’s a great start!)
Keeping two radios that are continually swapping channels in sync is no easy task, but it could possibly be made easier by taking advantage of the nRF’s acknowledge mode. If the delay between a sent acknowledge message and a received one were constant, these events (one on TX and one on RX) could be used to re-sync the two hopping cycles. All of this would probably require more temporal resolution than you’re going to get out of a microprocessor running Arduino code, but should be possible using hardware timers. But this is pure speculation. We briefly looked around and couldn’t find any working demos.
So Hackaday, how would you remotely sync two nRF24s on the cheap? Or is this a crazy idea? It might help to make transmissions more reliable in the face of 2.4 GHz band interference. Has anyone implemented their own frequency hopping scheme for the nRF24l01+?
[ProtoG] sent us in this video (also below) where he demonstrates the use of machinist’s dial-gauge indicator arms as helping hands. I’ll admit that I got so jealous that I ordered a pair. I wouldn’t say that I need more tools to hold things in place, but I certainly want them. The rapid coarse placement combined with fine adjustment looks so sweet. Using them as scope-probe holders is brilliant.
Our own helping hands, purchased for $5 from a surplus shop, have seen nearly twenty years of use now. About ten years ago, I heat-shrinked and plasti-dipped the jaws, and since then they do less damage to cable insulation. The clips kept coming loose, but that was fixed with a little epoxy. I never used the magnifying glass, and by removing it I bought some more sliding room for the jaws, which was an easy win. The base has a “non-slip” coating of Shoe-Goo that keeps it in place on the desk. Cork might be classier.
For bigger holding, there’s always the desk vise, though I’ll admit that I mostly use it for holding PCBs while soldering, and that a better solution for that particular task wouldn’t hurt. [Mike Szczys] tells me that the Stickvise seen here is a handy thing to have on the bench. It started on Hackaday.io and we still carry it in the store.
For grabbing the fiddly little things, nothing beats a pair of hemostats and a range of tweezers. Hemostats in the desk vise make a great ad hoc holder. Good sharp tweezers pay for themselves with the first removed splinter, or placing SMT parts.
So, Hackaday, what do you use for holding things? What do you hold your PCBs with while soldering? What do you use to hold down SMD parts? What’s your third hand, or twenty-third? Continue reading “Ask Hackaday: Helping Hands”
My buddy Harold recently landed a new job at a great technology company. It came at a perfect time for him, having just been laid off from the corporate behemoth where he’d toiled away as an anonymous cog for 19 years. But the day before he was to start, the new company’s HR folks sent him some last-minute documents to sign. One was a broad and vaguely worded non-compete agreement which essentially said he was barred from working in any related industry for a year after leaving the company.
Harold was tempted not to sign, but eventually relented because one needs to put food on the table. Thankfully he’s now thriving at the new company, but his experience got me thinking about all the complications hackers face with the day jobs that so many of us need to maintain. Non-competes and non-disclosures are bad enough, but there’s one agreement that can really foul things up for a hacker: the Intellectual Property Agreement.
Continue reading “Ask Hackaday: How Should Hackers Handle IP Agreements?”
I have a love/hate relationship with the crocodile clip. Nothing is so quick to lash together a few half-baked prototype boards on your desk, but nothing ends up in such a tangle so quickly, either. I love the range of pretty colors that crocodiles come in, as well as the easy ability to just clip on to the side of a PCB, or any old loose wire. But they come loose, they can have intermittent contacts, and we’re not even sure if there is such a thing as a current rating for them.
When [WarriorRocker] wrote in asking what we use instead of crocodile clips, he included a photo that sent a chill down my spine, from a review of some clips on Amazon. I’ve seen this one in real life. And what’s worse is the one with the loose wires that sometimes make contact with the spring-clip body and sometimes not.
After an hour-long debugging session about twelve years ago now, such an intermittent croc caused us to make a lifelong vow. All of our croco-clips have been disassembled, manually inspected, and many of them soldered together. When I buy new ones, I check them all before mixing them in with the known-goods. Even thinking about this now makes me want to pull back their little rubber booties just to make sure. Continue reading “Ask Hackaday: Bitten by the Crocodile Clip”
3D printers are the single best example of what Open Hardware can be. They’re useful for prototyping, building jigs for other tools, and Lulzbot has proven desktop 3D printers can be used in industrial production. We endorse 3D printing as a viable tool as a matter of course around here, but that doesn’t mean we think every house should have a 3D printer.
Back when Bre was on Colbert and manufacturing was the next thing to be ‘disrupted’, the value proposition of 3D printing was this: everyone would want a 3D printer at home because you could print plastic trinkets. Look, a low-poly Bulbasaur. I made a T-rex skull. The front page of /r/3Dprinting. Needless to say, the average consumer doesn’t need to spend hundreds of dollars to make their own plastic baubles when WalMart and Target exist.
The value proposition of a 3D printer is an open question, but now there is some evidence a 3D printer provides a return on its investment. In a paper published this week, [Joshua Pearce] and an undergraduate at Michigan Tech found a 3D printer pays for itself within six months and can see an almost 1,000% return on investment within five years. Read on as I investigate this dubious claim.
Continue reading “Ask Hackaday: Is Owning A 3D Printer Worth It?”
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?”
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=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?