It can be difficult to resist the impulse buy. You see something interesting, the price is right, and even though you know you should do your research first, you end up putting it in your cart anyway. That’s how [Tobias Girstmair] ended up being the not-so proud owner of a LEDBERG RGB LED strip from IKEA, and what eventually pushed him to replace wimpy original controller with an ESP8266.
So what was the problem with the original controller? If you can believe it, it was incapable of producing white light. When IKEA says an LED is multi-color, they apparently mean it’s only multi-color. A quick check of the reviews online seem to indicate that the white version is sold as a different SKU that apparently looks the same externally and has confused more than a few purchasers.
Rather than having to pick one or the other, [Tobias] decided he would replace the original controller with an ESP-03, hoping that would give him granular enough control over the LEDs to coax a suitably white light out of them. He didn’t want to completely start from scratch, so one of the first decisions he made was to reuse the existing PCB and MOSFETs. Some handy test points on the PCB allowed him to hook the digital pins of the ESP right to the red, blue, and green LED channels.
Then it was just a matter of coming up with the software. To keep things simple, [Tobias] decided to create a “dumb” controller that simply sets the LED color and intensity according to commands it receives over a simplified UDP protocol. Anything beyond that, such as randomized colors or special effects, is done with scripts that run on his computer and fire off the appropriate UDP commands. This also means he can manually control his newly upgraded LEDBERG strips from basically anything that can generate UDP packets, such as an application on his Android phone.
In this beautiful and well-documented reverse engineering feat of strength, [Eric Cohen] reverse-engineered a 1971 Singer calculator to gain control of the fabulous Nixie tubes inside. Where a lesser hacker would have simply pulled the tubes out and put them in a more modern housing, [Eric] kept it all intact.
Not even content to gut the box and toss some modern brains inside, he snooped out the calculator’s internal wiring, interfaced a Raspberry Pi to it, and overrode the calculator’s (860 Hz) bus system. With the Pi on the inside, controlling the Nixie tubes, he did what any of us would do: set up a UDP server and write an Android app for his phone to push ASCII data over to the former calculator. When it’s not running in its default clock mode, naturally.
All of this is extraordinarily well documented both on his website, in a slide presentation (PDF), and in video (embedded below). Our hats are tipped to the amazing attention to detail and fantastic documentation.
Now where is that Singer EC1117 calculator from 1971 that we’ve been saving for just such an occasion?
While we don’t think this qualifies as a “fail”, it’s certainly not a triumph. But that’s what happens when you notice something funny and start to investigate: if you’re lucky, it ends with “Eureka!”, but most of the time it’s just “oh”. Still, it’s good to record the “ohs”.
Gökberk [gkbrk] Yaltıraklı was staying in a hotel long enough that he got bored and started snooping around the network, like you do. Breaking out Wireshark, he noticed a lot of UDP traffic on a nonstandard port, so he thought he’d have a look.
[Danman] was looking for a way to get the HDMI output from a camera to a PC so it could be streamed over the Internet. This is a task usually done with HDMI capture cards, either PCI or even more expensive USB 3.0 HDMI capture boxes. In his searches, [danman] sumbled across an HDMI extender that transmitted HDMI signals over standard Ethernet. Surely there must be a way to capture this data and turn it back.
The extender boxes [danman] found at everyone’s favorite chinese reseller were simple – just an Ethernet port, HDMI jack, and a power connector – and cheap – just $70 USD. After connecting the two boxes to his network and setting up his camera, [danman] listened in to the packets being set with Wireshark. The basic protocol was easy enough to grok, but thanks to the Chinese engineers and an IP header that was the wrong length, [danman] had to listen to the raw socket.
Once everything was figured out, [danman] was able to recover raw frames from the HDMI extenders, recover the audio, and stream everything to his PC with VLC. All the code is available, and if you’re looking for a way to stream HDMI to multiple locations on a network, you won’t find a better solution that’s this cheap.
[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.
The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.
The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.
[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.
[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.
There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?
Even though the ESP8266 WiFi chipsets are really cheap (and can be somewhat challenging to work with), they still pack a lot of processing power. For instance, [Mr.jb.swe] took one of these modules and made a stand-alone live VU meter with WS2812B LED strip. The VU runs entirely on the ESP chip, without any additional microcontroller. It’s an example we think a lot of projects could follow to do away with unused horsepower (extra microcontrollers) sometimes used to avoid programming directly on the ESP. The stuff you can do with these modules is wild… did you see this WiFi signal strength mapping project?
The ESP chipset acts as a UDP client which receives packets from a WinAmp plugin that [Mr.jb.swe] wrote. The plugin continuously calculates the dB of whatever track is playing and streams it over WiFi to his ESP8266. He also mentions that the ADC of the ESP chipset could be used to sample audio as well, although that pretty much eliminates the need for WiFi.
The whole setup is very responsive even though the processor is parsing UDP messages, driving the WS2812 strip, and driving a small OLED display for debug—and it doesn’t even use a separate microcontroller. [Mr.jb.swe] also posted snippets of his code to get you started on your own project. Check out the videos after the break to see it in action.
Thought GNU Radio was just for radio? Think again. [Chris] has been hard at work turning the signal generation and analysis of the best tool for software defined radio into a networking device for speakers and a microphone.
The setup uses GNU Radio to generate a carrier signal whose frequency is modulated with a data stream. With this modulated signal piped over a laptop’s speakers, [Chris] is able to send UDP packets across his desk using nothing but sound.
[Chris] had recently used a similar technique to transmit data via audio with GNU Radio, but this latest build is a vast improvement; this is now a duplex networking, meaning two computers can transmit and receive at the same time.
In the end, [Chris] created a strange, obsolete device called a “modem”. It’s not exactly fast; sending ‘Hello World’ takes quite a bit of time, as you can see in the video below.