A Cloned Bluetooth Tracker Meets Its Maker

January 14, 2019 by Tom Nardi 30 Comments

The holidays bring us many things. Family and friends are a given, as is the grand meal in which we invariably overindulge. It’s a chance for decades old songs and movies to somehow manage to bubble back up to the surface, and occasionally a little goodwill even slips in here or there. But perhaps above all, the holidays are a time for every retailer to stock themselves to the rafters with stuff. Do you need it? No. Do they want it? No. But it’s there on display anyway, and you’re almost certainly going to buy it.

Which is precisely how I came to purchase a two pack of Bluetooth Low Energy (BLE) “trackers” for the princely sum of $10 USD. I didn’t expect much out of them for $5 each, but as this seemed an exceptionally low price for such technology in a brick and mortar store, I couldn’t resist. Plus there was something familiar about the look of the tracker that I couldn’t quite put my finger on while I was still in the store.

That vague feeling of recollection sent me digging through my parts bin as soon as I got home, convinced that I had seen something among the detritus that reminded me of my latest prize. Sure enough, I found a “Cube” Bluetooth tracker which, ironically, I had received as a Christmas gift some years ago. Putting them side by side, it was clear that the design of these “itek” trackers took more than a little inspiration from the better known (and five times as expensive) product.

The Cube was a bit thicker, but otherwise the shape, size, and even button placement on the itek was nearly identical. Reading through their respective manuals, the capabilities also seemed in perfect parity, down to being able to use the button on the device as a remote camera control for your smartphone. Which got me thinking: just how similar would these two devices be internally? Clearly they looked and functioned the same, but would they be built the same as well? They would have to cut costs somewhere.

Determined to find out how a company can put out what for all the world looks like a mirror image of a competitor’s device while undercutting them by such a large margin, I cracked both trackers open to get a bit more familiar with what makes them tick. What I found on closer inspection of these two similar gadgets is perhaps best summarized by that age old cautionary adage: “Don’t judge a book by its cover.”

Continue reading “A Cloned Bluetooth Tracker Meets Its Maker” →

Years Don’t Dim The Shine Of These Curious Gadgets

January 13, 2019 by Donald Papp 4 Comments

[Maarten Tromp] recently took the time to document some of the unusual and creative electronic projects he received as gifts over the years. These gadgets were created in the early 2000’s and still work flawlessly today. Two of our favorites are shown here: Hardware Tetris Unit (shown in the image above) and Heap of Electronic Parts.

The “Heap of Electronic Parts” makes sounds when in sunlight.

Heap of Electronic Parts was a kind of hardware puzzle and certainly lives up to its name. It’s a bunch of parts soldered in a mystifying way to the backs of four old EPROMs — the chips with the little window through which UV is used to erase the contents. Assured that the unit really did have a function, [Maarten] eventually figured out that when placed in sunlight, the device ticks, buzzes, and squeals. [Jeroen] had figured out that the EPROMs could act like tiny solar cells when placed in sunlight, and together the four generate just enough power to drive an oscillator connected to a piezo speaker. It still chirps happily away, even today.

Hardware Tetris plays in a terminal window.

Hardware Tetris Unit was a black box intended to be plugged into a serial port. With a terminal opened using the correct serial port settings, a fully-functional Tetris game using ASCII-art graphics could be played. It was even self-powered from the serial port pins.

Inside Hardware Tetris is an AVR microcontroller with some level shifters, and the source code and schematics are available for download. 14 years later, computers no longer have hardware serial ports but [Maarten] says a USB-to-serial converter worked just fine and the device still functions perfectly.

There are a couple more devices documented on [Maarten]’s gifts page, including a Zork-inspired mini text adventure and a hardware board that does some trippy demos on an old Nokia color LCD. [Maarten]’s friend [Jeroen Domburg] (aka Sprite_tm) had a hand in creating most of the gadgets, and he’s someone whose brilliant work we have had the good fortune to feature many times in the past.

Is Baking A Raspberry Pi The Recipe For Magic Smoke?

January 10, 2019 by Tom Nardi 35 Comments

No, Hackaday hasn’t become a baking blog. We’re just here to give you a bit of advice: if [MickMake] ever offers you one of his fresh-baked Pis, proceed with caution. While we have no doubt that there will be some interesting smells wafting out of his kitchen, these aren’t the tasty pies you’re looking for. There’s no delicious home-baked treat when that timer dings, just a handful of Raspberry Pis that have had an exceptionally hard day.

To properly explain the odd sight of some Raspberry Pis laid out on a cookie sheet, we need to take a step back. [MickMake] originally set out to see how everyone’s favorite Linux SBC would handle the harsh Australian heat, and thought that setting them up on his car’s dashboard would be a suitable torture test. But as luck would have it, a storm rolled in while he was making the video which brought temperatures down to a “cool” 30 C (86 F); basically jacket weather at the bottom of the world. So naturally, he decided to put them in his oven instead.

Placed on an insulating sheet and with a thermocouple between them to get an accurate idea of the temperature they were experiencing, an original Pi, a Pi 2, and a pair of Pi 3s were sent on the ride of their lives. In addition to monitoring them over the network, he also added a “heartbeat” LED to each Pi so he’d be able to tell at a glance if any of them had given up the ghost. As if these poor little Pis didn’t have it bad enough already, [MickMake] decided to take things a step farther and run sysbench on them while they took their trip through Hades.

The Pis are actually rated for temperatures up to 85C, and all the participants of the experiment hit that point without any issues. At 87.3 C (~190 F) the original Pi dropped off the network, but its LED was seen bravely blinking on. At 105.7 C (~222 F) it finally breathed its last, followed by the pair of Pi 3s tapping out at 112 C (233 F). The Pi 2 fought on, but it fell right at the 119 C (246 F) mark.

But what about when they cooled off? Somewhat surprisingly, [MickMake] successfully powered all four back up and was unable to find any damage to the Pis, either physically or operationally. Even the SD cards survived, and the Pis popped right back onto the network and were ready for another round of Silicon Chef. Not bad considering they were subjected to temperatures three times higher than the official limit.

Testing electronics in your home oven might seem a bit suspect, and admittedly we’d probably turn down a slice of the next few frozen pizza’s [MickMake] runs through it, but it’s not really so far removed from how proper reliability testing is performed.

Continue reading “Is Baking A Raspberry Pi The Recipe For Magic Smoke?” →

Vintage Programmer Gets Modern Chip Adapter

January 8, 2019 by Tom Nardi 8 Comments

While trying to revive a Donkey Kong Jr arcade board, [Jelmer Bruijn] found himself in the market for an EPROM programmer and became the proud owner of a 1990’s era Dataman S4. Despite its age, it’s a fairly nice tool which allows you to read and write a laundry list of different EPROM types, all without being tied to a computer. The only catch is that a few types of chips need an adapter to work in the Dataman S4, some of which are unsurprisingly no longer available.

After some above and beyond support from the current crew at Dataman set him on the right track, [Jelmer] decided to try his hand at reverse engineering how the old adapters worked so he could build his own. His ultimate goal was to read 40 pin EPROMs on the 32 pin Dataman S4, but in the end he says the information he gathered should be applicable for building other adapters if you ever find yourself in need of such things.

As you might expect, there’s a bit more to the project than a simple pin adapter. [Jelmer] assumed some kind of shift register or latching arrangement would be required to make up for the shortage of pins on the Dataman S4’s ZIF socket. It was just a matter of figuring out how it all went together.

Luckily, [Jelmer] found that the programmer would happily attempt to perform operations on a 16 bit EPROM even though no adapter was physically present. This gave him a chance to probe around with a logic analyzer to figure out what it was trying to accomplish. The trick turned out to be splitting the 16 bit bus into two 8 bit buses which are requested sequentially.

With careful observation, close studying of 16 bit chip datasheets, and much brow furrowing, he was eventually able to come up a design that used five 74xx573 latches and put a schematic together in Eagle. There were a few kinks to iron out when the boards finally arrived, but ultimately the design worked on the first try. [Jelmer] says the same technique should work for 42 pin EPROMs, but as Dataman still actually sell adapters for those he decided not to supply schematics for it.

[Jelmer] tells us that he was inspired to send this success story our way after reading how our very own [Elliot Williams] took the long away around to erase a couple UV EPROMs recently While this isn’t the first time we’ve seen somebody have to hack support for 16 bit EPROMs into their programmer, it’s good to see that the manufacturer at least had the customer’s back in this case.

Being An SPI Slave Can Be Trickier Than It Appears

January 8, 2019 by Kerry Scharfglass 10 Comments

Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.

The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.

But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.

Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.

Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption

January 3, 2019 by Sean Boyce 7 Comments

When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.

I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.

About seven weeks ago, support for the libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.

However, my preferred automated build tool for NodeMCU wasn’t available on the ESP32 yet. Compiling the firmware was required – this turned out to be a surprisingly user-friendly experience, so I thought I’d share it with you. If I had known it would be so quick, this chip wouldn’t have sat on my desk unused quite so long! Continue reading “Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption” →

Fail Of The Week: EPROMs, Rats’ Nests, Tanning Lamps, And Cardboard On Fire

January 2, 2019 by Elliot Williams 87 Comments

It all started when I bought a late-1990s synthesizer that needed a firmware upgrade. One could simply pull the ROM chip, ship it off to Yamaha for a free replacement, and swap in the new one — in 2003. Lacking a time machine, a sensible option is to buy a pre-programmed aftermarket EPROM on eBay for $10, and if you just want a single pre-flashed EPROM that’s probably the right way to go. But I wanted an adventure.

Spoiler alert: I did manage to flash a few EPROMs and the RM1X is happily running OS 1.13 and pumping out the jams. That’s not the adventure. The adventure is trying to erase UV-erasable EPROMS.

And that’s how I ended up with a small cardboard fire and a scorched tanning lamp, and why I bought a $5 LED, and why I left EPROMs out in the sun for four days. And why, in the end, I gave up and ordered a $15 EPROM eraser from China. Along the way, I learned a ton about old-school UV-erasable EPROMs, and now I have a stack of obsolete silicon that’s looking for a new project like a hammer looks for a nail — just as soon as that UV eraser arrives in the mail.

Continue reading “Fail Of The Week: EPROMs, Rats’ Nests, Tanning Lamps, And Cardboard On Fire” →