[Jaromir Sukuba] has an awesome BrainF*ck interpreter project going. He’s handling the entire language in less than 1 kB of code. Sounds like a great entry in the 1 kB Challenge. The only problem is the user interface. The original design used a 4 line character based LCD. The HD44780 controller in these LCDs have their own character table ROM, which takes up more than 1 kB of space alone.
[Jaromir] could have submitted the BrainF*ck interpreter without the LCD, and probably would have done well in the contest. That wasn’t quite enough for him though. He knew he could get character based output going within the rules of the contest. The solution was a bit of creative compression.
Rather than a pixel-by-pixel representation of the characters, [Jaromir] created a palette of 16 single byte vectors of commonly used patterns. Characters are created by combining these vectors. Each character is 4 x 8 pixels, so 4 vectors are used per character. The hard part was picking commonly used bit patterns for the vectors.
The first iteration was quite promising – the text was generally readable, but a few characters were pretty bad. [Jaromir] kept at it, reducing and optimizing his vector pallet twice more. The final design is pretty darn good. Each character uses 16 bits of storage (four 4-bit vector lookup values). The vector pallet itself uses 16 bytes. That means 64 characters only eat up 144 Bytes of flash.
This is exactly the kind of hack we were hoping to see in the 1 kB challenge. A bit of creative thinking finds a way around a seemingly impossible barrier. The best part of all is that [Jaromir] has documented his work, so now anyone can use it in the 1 kB challenge and beyond.
If you have a cool project in mind, there is still plenty of time to enter the 1 kB Challenge! Deadline is January 5, so check it out and fire up your assemblers!
[CNLohr] needs no introduction around these parts. He’s pulled off a few really epic hacks. Recently, he’s set his sights on writing a simple, easy to extend library to work with the HTC Vive VR controller equipment, and in particular the Watchman controller.
There’s been a lot of previous work on the device, so [Charles] wasn’t starting from scratch, and he live-streamed his work, allowing others to play along. In the process, two engineers who actually worked on the hardware in question, [Alan Yates] and [Ben Jackson], stopped by and gave some oblique hints and “warmer-cooler” guidance. A much-condensed version is up on YouTube (and embedded below). In the links, you’ll find code and the live streams in their original glory, if you want to see what went down blow by blow. Code and more docs are in this Gist.
Continue reading “[CNLohr] Reverses Vive, Valve Engineers Play Along”
I have a confession to make. I enjoy the challenge of squeezing software into a tiny space or trying to cut a few more cycles out of a loop. It is like an intricate puzzle. Today, of course, there isn’t nearly as much call for that as there used to be. Today even a “small” microcontroller has a ton of memory and resources.
Even so, there’s still a few cases where you need to squeeze those last few bytes out of memory. Maybe you are trying to maximize memory available for some purpose. Maybe you are anticipating mass production and you are using the smallest microcontroller you can find. Or maybe you’re doing the 1 kB Challenge and just want some advice.
One way to find techniques to maximize resources is to look at what people did “in the old days.” Digital Equipment computers once had a special character set called Squoze (or sometimes DEC Radix-50). This technique can be useful when you need to get a lot of strings into memory. The good news is that you can reliably get 3 characters into 2 bytes (or, as DEC did, 6 characters into 4 bytes). The bad news is that you have to pick a limited character set that you can use. However, that’s not always a big problem.
Continue reading “Squoze Your Data”
[Sven337]’s rebuild of a cheap and terrible baby monitor isn’t super visual, but it has so much more going on than it first seems. It’s also a how-to for streaming audio via UDP over WiFi with a pair of ESP8266 units, and includes a frank sharing of things that went wrong in the process and how they were addressed. [Sven337] even experimented with a couple of different methods for real-time compression of the transmitted audio data, for no other reason than the sake of doing things as well as they can reasonably be done without adding parts or spending extra money.
The original baby monitor had audio and video but was utterly useless for a number of reasons (French). The range and quality were terrible, and the audio was full of static and interference that was just as loud as anything the microphone actually picked up from the room. The user is left with two choices: either have white noise constantly coming through the receiver, or be unable to hear your child because you turned the volume down to get rid of the constant static. Our favorite part is the VOX “feature”: if the baby is quiet, it turns off the receiver’s screen; it has no effect whatsoever on the audio! As icing on the cake, the analog 2.4GHz transmitter interferes with the household WiFi when it transmits – which is all the time, because it’s always-on.
Small wonder [Sven337] decided to go the DIY route. Instead of getting dumped in the trash, the unit got rebuilt almost from the ground-up.
Continue reading “Baby Monitor Rebuild is also ESP8266 Audio Streaming How-To”
In an effort listen to his music on shuffle without the need to touch the volume knob [Mike] build his own automatic volume leveling hardware. He knows what you’re thinking right now: there’s software to do that for you. But building the feature in hardware is a great stepping off point for a project.
He started the prototype using LabVIEW along with a Mobile Studio development board and a Bus Pirate. This project will be a mix of digital and analog components and it’s a bit easier starting off the exploration with these tools rather than jumping right into the AVR code.
The circuit will sample the incoming audio, modify it accordingly, and output the result. The output side is where the Bus Pirate really shines. He’s using some MCP42010 digital potentiometer chips to make the necessary changes to the levels. They communicate via SPI and it’s nice to have the Bus Pirate’s terminal to issue commands without the need to reflash a microcontroller.
[Mike] made a video showing an audio waveform with and without the hardware leveling. Sound quality is still great, and each clip is played at a reasonably comfortable listening level. We’ve embedded that demonstration after the break.
Continue reading “Microcontroller based audio volume level compressor”
Low bandwidth speech compression is a desirable concept for amateur radio enthusiasts. Unfortunately there isn’t a great open-source option out there, but that’s changing with the low-bitrate speech compression package called Codec2. It manages to transmit and decode at 2550 bits per second with results comparable to proprietary solutions like MELP and very near the initial goal of 2400 bit/s. [David Rowe], who spearheads the project, has been simulating communications using a Linux box and has posted audio snippets at the first link above for comparison. They’re looking for feedback and testing so if you interested give them a helping hand.
A team from Johns Hopkins University has discovered a way to eavesdrop on encrypted voice streams. Voice data like the kind used by Skype for its VoIP service sends encrypted packets of varying sizes for different sounds. The team learned that by simply measureing the size of the packets, they could determine what was being said with a high rate of accuracy. VoIP providers often use a variable bit rate to use bandwidth more efficiently, but it is this compression that makes audio streams vulnerable to eavesdropping.
The team’s software is still in its early stages of development, yet incapable of parsing entire conversations. It is capable, though, of finding pre-determined keywords and inferring common phrases bases on the words it detects. It also has a higher rate of accuracy in identifying long complicated words than short ones. The team’s goal was not to eavesdrop, but to expose the vulnerability; team member [Charles Wright] notes, “we hope we have caught this threat before it becomes too serious.”
[via Schneier on Security]