Vintage Camera Flash Turned OLED Desk Clock

April 19, 2019 by 6 Comments

After covering a few of his builds at this point, we think it’s abundantly clear that [Igor Afanasyev] has a keen eye for turning random pieces of antiquated hardware into something that’s equal parts functional and gorgeous. He retains the aspects of the original which give it that unmistakable vintage look, while very slickly integrating modern components and features. His work is getting awfully close to becoming some kind of new art form, but we’re certainly not complaining.

His latest creation takes an old-school “Monopak” electronic flash module and turns it into a desk clock that somehow also manages to look like a vintage television set. The OLED displays glowing behind the original flash diffuser create an awesome visual effect which really sells the whole look; as if the display is some hitherto undiscovered nixie variant.

On the technical side of things, there’s really not much to this particular build. Utilizing two extremely common SSD1306 OLED displays in a 3D printed holder along with an Arduino to drive them, the electronics are quite simple. There’s a rotary encoder on the side to set the time, though it would have been nice to see an RTC module added into the mix for better accuracy. Or perhaps even switch over to the ESP8266 so the clock could update itself from the Internet. But on this build we get the impression [Igor] was more interested in playing with the aesthetics of the final piece than fiddling with the internals, which is hard to argue with when it looks this cool.

Noticing the flash had a sort of classic TV set feel to it, [Igor] took the time to 3D print some detail pieces which really complete the look. The feet on the bottom not only hold the clock at a comfortable viewing angle, but perfectly echo the retro-futuristic look of 50s and 60s consumer electronics. He even went through the trouble of printing a little antenna to fit into the top hot shoe, complete with a metal ring salvaged from a key-chain.

Late last year we were impressed with the effort [Igor] put into creating a retro Raspberry Pi terminal from a legitimate piece of 1970’s laboratory equipment, and more recently his modern take on the lowly cassette player got plenty of debate going. We can’t wait to see what he comes up with next.

Continue reading “Vintage Camera Flash Turned OLED Desk Clock” →

Radio Free Blockchain: Bitcoin From Space

April 2, 2019 by 31 Comments

Cryptocurrencies: love them, hate them, or be baffled by them, but don’t think you can escape them. That’s the way it seems these days at least, with news media filled with breathless stories about Bitcoin and the other cryptocurrencies, and everyone from Amazon to content creators on YouTube now accepting the digital currency for payments. And now, almost everyone on the planet is literally bathed in Bitcoin, or at least the distributed ledger that makes it work, thanks to a new network that streams the Bitcoin blockchain over a constellation of geosynchronous satellites.

Continue reading “Radio Free Blockchain: Bitcoin From Space” →

1 Trillion USD Refund! (PDF Enclosed)

March 6, 2019 by 5 Comments

Security researchers have found that it is possible to alter a digitally signed PDF without invalidating its signatures. To demonstrate it, they produced a fake document “refund order” of $1,000,000,000,000 dollars, with a valid signature from Amazon. This sparked my attention, since I was quite sure that they didn’t use some sort of quantum device to break the cryptography involved in the signing process. So what exactly is going on?

The researchers claim to found at least three different ways to, in their words:

… use an existing signed document (e.g., amazon.de invoice) and change the content of the document arbitrarily without invalidating the signatures. Thus, we can forge a document signed by invoicing@amazon.de to refund us one trillion dollars.

That’s not good news if you take into account that the main purpose of digitally signing a document is, well, prevent unauthorized changes in that document. The good news is that you can update your software to fix this flaws because of this research; the main PDF readers companies were given time to fix the issues. The bad news is that if you rely on the signature verification for any sensitive process, you likely want to go back and see if you were using vulnerable software previously and check that documents were correctly validated. I’m thinking about government institutions, banks, insurance companies and so on.

The implications are yet to be seen and probably won’t even be fully known.

There are three classes of attacks that work on different software. I’ll try to go into each one from what I could tell from reading the research.

Continue reading “1 Trillion USD Refund! (PDF Enclosed)” →

Multiple OLEDs? Save Pins By Sharing The I2C Clock

February 27, 2019 by 17 Comments

Inexpensive OLED displays with I2C interfaces abound, but there is a catch: they tend to be stuck on I2C address 0x3C. Some have a jumper or solder pads to select an alternate (usually 0x3D), but they lack any other method. Since an I2C bus expects every device to have a unique address, this limits the number of displays per bus to one (or two, at best.) That is all still true, but what [Larry Bank] discovered is a way to get multiple OLED displays working with considerably fewer microcontroller pins than usually needed.

While bit-banging I2C to host one display per bus on the same microcontroller, an idea occurred to him. The I2C start signal requires both clock (SCL) and data (SDA) to be brought low together, but what would happen if the displays shared a single clock line? To be clear, each OLED would — logically speaking — still be on its own I2C bus with its own data line, but they would share a clock signal. Would a shared clock cause attached devices to activate unintentionally?

A quick test consisting of four OLED displays (all with address 0x3C) showed that it was indeed possible to address each display with no interference if they shared a clock. Those four individually controlled displays needed only five I/O lines (four SDA, one shared SCL) instead of eight. The Multi_OLED library is available on GitHub, and in case it is useful for devices other than OLED displays, bit-banged I2C with support for shared clock lines is available separately.

There’s more to do with OLEDs than get clever with signals: check out these slick number-change animations, and that even looks to be a project that could benefit from a few saved GPIO pins, since it uses one small display per digit.

Anti-Lock Brakes For Bike Might Make Rides A Little Safer

February 17, 2019 by 59 Comments

Crashing one’s bike is a childhood rite of passage, one that can teach valuable lessons in applied physics. Assuming the kid is properly protected and the crash is fairly tame, scrapes and bruises are exchanged for the wisdom to avoid sand and gravel patches, and how to avoid a ballistic dismount by not applying the front brakes harder than or before the rear brakes.

But for many of us, those lessons were learned long ago using a body far more flexible than the version we’re currently in, and the stakes are higher for a bike ride that includes braking mistakes. To help with that, [Tom Stanton] has been working on anti-lock brakes for bicycles, and in the process he’s learned a lot about the physics and engineering of controlled deceleration.

It seems a simple concept – use a sensor to detect when a wheel is slipping due to decreased friction between the tire and the roadway, and release braking force repeatedly through an actuator to allow the driver or rider to maintain control while stopping. But that abstracts away a ton of detail, which [Tom] quickly got bogged down in. With a photosensor on the front wheel and a stepper motor to override brake lever inputs, he was able to modulate the braking force, but not with the responsiveness needed to maintain control. Several iterations later, [Tom] hit on the right combination of sensors, actuators, and algorithms to make a decent bike ABS system. The video below has all the details of the build and testing.

[Tom] admits bike ABS isn’t much of an innovation. We even covered an Arduino-instrumented bike that was to be an ABS testbed a few years back. But it’s still cool to see how much goes into anti-lock systems.

Continue reading “Anti-Lock Brakes For Bike Might Make Rides A Little Safer” →

Cool Tools: A Little Filesystem That Keeps Your Bits On Lock

January 24, 2019 by 52 Comments

Filesystems for computers are not the best bet for embedded systems. Even those who know this fragment of truth still fall into the trap and pay for it later on while surrounded by the rubble that once was a functioning project. Here’s how it happens.

The project starts small, with modest storage needs. It’s just a temperature logger and you want to store that data, so you stick on a little EEPROM. That works pretty well! But you need to store a little more data so the EEPROM gets paired with a small blob of NOR flash which is much larger but still pretty easy to work with. Device settings go to EEPROM, data logs go to NOR. That works for a time but then you remember that people on the Internet are all about the Internet of Things so it’s time to add WiFi. You start serving a few static pages with that surprisingly capable processor and bump into storage problems again so the NOR flash gets replaced with an SD card and now the logs go there too. Suddenly you’re dealing with multiple files and want access on a computer so a real filesystem is in order. FAT is easy, so the card grows a FAT filesystem. Everything is great, but you start to notice patches missing from the logs. Then the SD card gets totally corrupted. What’s going on? Let’s take a look at the problem, and how to reach embedded file nirvana.

Continue reading “Cool Tools: A Little Filesystem That Keeps Your Bits On Lock” →

Underclocking The ESP8266 Leads To WiFi Weirdness

January 4, 2019 by 39 Comments

Sometimes the best hacks come from the most basic of questions. In this case, [CNLohr] was wondering what would happen if he started to reduce the clock speed of the ESP8266’s Baseband PLL (BBPLL) while still trying to communicate with it. You know, as one does. The results ended up being fairly surprising, and while it’s not immediately clear if there’s a practical application for this particular trick, it’s certainly worth some additional research.

Code for stepping through clock speeds

The idea here is that the BBPLL is the reference clock for the entire system, including all of the peripherals. So underclocking it doesn’t just slow down code execution as you might expect, but it also slows down the chip’s interactions with the outside world. [CNLohr] demonstrates this concept in the video below, showing how the baud rate used to view the serial output from the ESP8266 needs to be adjusted to match the chip’s frequency or else you’ll only get garbage on the line.

But what happens to the WiFi? As [CNLohr] discovered, while the center frequency itself doesn’t change, the channel width gets narrower as the clock rate is lowered. When viewed on the waterfall display of a software defined radio (SDR), the transmission can be seen “compressing” in a step pattern as the clock rate is reduced. As one might expect, the 802.11 packets become indecipherable to a normal WiFi device running in monitor mode. The signal is still at the correct frequency, but the devices can no longer understand each other.

Now it was time for another of those basic questions. What would happen if you did the same thing to a second ESP8266? Much to his surprise, [CNLohr] discovered that the two devices could still communicate successfully as long as their BBPLL clock speed was the same. From an outsider’s perspective it looked like gibberish, but to the two ESPs which had been slowed by the same amount, everything worked as expected even though the 802.11 standards say it shouldn’t.

So what can you do with this? The most obvious application is a “stealth” WiFi connection between ESP8266s which wouldn’t show up to normal devices, a communications channel invisible to all but the most astute eavesdropper. [CNLohr] has made all the source code to pull this trick off public on GitHub, and it should be interesting to see what kind of applications (if any) hackers find for this standards-breaking behavior.

If your thing is devices being forced into operations they were never intended to by particularly twisted hackers, check out our recent coverage of the USB serial adapter turned SDR by [Ted Yapo].

Continue reading “Underclocking The ESP8266 Leads To WiFi Weirdness” →