It’s all available here on his GitHub if you want to have a look. The transmission protocol is simplicity itself. It sends a two-byte header to detect the start of the message, and then it sends three bytes of data. The receiver turns this into MIDI and control-voltage output. Simple and useful.
We also admire the non-overkill (as well as the enviable battery life) of using straightforward radio transmitters rather than giving in and using WiFi.
We’ve covered some of Michael/[acidbourbon]’s hacks before, and the one that we think of the most, when we’re down in the basement drilling out holes in a PCB, is his semi-automatic drill press hack. Keep on hacking!
It’s no secret that we love the ESP8266 chip, and the community of hackers that have contributed to making it useful. We often joke about this or that new WiFi-enabler being an ESP8266 killer, but so far none have stepped up. Here we go again!
Espressif has released a chip that’s going to be an ESP8266 killer, and no, it’s not the ESP32. The ESP8285 went into mass production in March, and should start to appear in the usual outlets fairly soon.
What makes it an ESP8266 killer? It’s an ESP8266, but with the flash memory onboard. Nothing more, but also nothing less. What does this mean? Tiny, tiny designs are possible. And, if the street price ends up being right, there’s no reason you wouldn’t opt for built-in flash. (Unless you were planning on doing some ROM hacking.)
[David] created a great looking e-ink WiFi display project that works a little like a network-connected picture frame with a few improvements over other similar projects. With the help of an ESP8266 it boots up, grabs an 800×600 image over the network, updates the screen, then goes back to sleep. Thanks to some reverse engineering, he was able to make his own firmware for the onboard controller to handle the low-level driving of the display. Since e-ink displays require no power to hold an image and the rest of the unit spends most of the time either asleep or off, power use is extremely low. [David] hopes to go months without needing to recharge the internal lithium-polymer battery.
We previously featured another WiFi-connected e-ink display project that was in fact also the inspiration for this version. [David] uses a 4.3″ 800×600 GDE043A e-ink display and wrote his own firmware for the STM32F103ZE ARM CortexM3 SoC used as a display controller, a process that required some reverse engineering but was aided by the manufacturer providing a closed-source driver for him to use. [David] writes that some reverse-engineering work for this display had already been done, but he had such a hard time getting a clear understanding from it that he reverse engineered the firmware anyway and used the documents mainly for validation and guidance.
As a result, [David] was able to make use of the low-level driver electronics already present on the board instead of having to make and interface his own. E-ink displays have some unusual driving requirements which include generating relatively high positive and negative voltages, and rapidly switching them when updating the display. Taking advantage of the board’s existing low-level driver electronics was a big benefit.
The ESP8266 rounds out the project by taking care of periodically booting things up, connecting to the wireless network and downloading an image, feeding the image data to the STM32 to update the display, then disconnecting power from all non-essential electronics and going back to sleep. We especially like how the unit automatically creates a WiFi access point to allow easy (re)configuring.
There’s one more nice touch. [David] goes the extra mile with server software (in the form of PHP scripts) to design screens for the display with data like weather forecasts, stock prices, and exchange rates. Check it out in the project’s github repository.
[danman] has been playing around with various HDMI video streaming options, and he’s hit on a great low-cost solution. A $40 “HDMI extender” turns out to actually be an HDMI-to-RTP converter under the hood.
He’d done work previously on a similar extender that turned out to use a quirky method to send the video, which he naturally reversed and made to do his bidding. But non-standard formats are a pain. So when he was given a newer version of the same device, and started peeking into the packets with Wireshark, he was pleasantly surprised to find that the output was just MPEG-encoded video over RTP. No hacking necessary.
Until now, streaming video over an IP network from an arbitrary HDMI output has been tricky, [danman] has been more than a little obsessed with getting it working on the cheap. In addition to the previous version of this extender, he also managed to get a stream out of a rooted Android set-top box. That costs a bit more, but can also record at the same time, should you need to.
None of this solves the HDMI HDCP encryption problem, though. You’re on your own for that one.
(Those of you Wireshark wizards out there will note that we just swiped the headline image from the previous version of the project. There were no good images for this one. Sorry about that.)
There’s nothing to be ashamed of. It’s a problem we all have. You change your code a lot — you can’t help it, you just need to tweak one last little bit. And then you have to go downstairs, fetch your ESP8266 module, plug it in to your computer, flash the new firmware in, and then run back down and re-install your wine-cellar temperature monitor. If only there were a way to continuously update your ESP8266 over the air, pulling new code down from your GitHub repository, automatically running your test suite on it, and then pushing it off to the ESP.
OK, it’s ridiculous overkill, but [Daniel] strung together a bunch of open-source continuous integration tools and made them work with the ESP8266. A simple PHP script connects the ESP to the rest of the web infrastructure.
[Daniel] says the word “security” in the same way that gin aficionados whisper “vermouth” over their Martinis. Which is to say, there is none. But for a home solution, or if you want to play around with continuous development, it’s a good start.
And this is a cool project because it makes use of the ESP8266 OTA (over-the-air) programming library to push the code across. And we do hate having to run around the house to update firmware.
So check it out if you want to push code to your ESP8266s without physically going to fetch them, or if you want to integrate your web development with your home deployment.
Artists see the same world that the rest of us do. They just see it from a little bit off to the left. Where you see picking an ESSID for your router as being a hassle, or an opportunity to insult your neighbors, [Dmitry], alias [::vtol::] sees a poetry-delivery mechanism.
Based on ESP8266 units, each “poet” has a battery and a switch. Turn it on and it changes its SSID once every ten seconds, feeding everyone who’s listening the next line of a poem. You can’t connect to the network, but you can occasionally hit refresh on your WiFi scanner and read along.
Since they’re so cheap to build, [::vtol::] sees them almost as if they were poetry-throwies. You could easily afford to leave a few around the city, guerilla-style, broadcasting your (slow) message one SSID at a time. We love the video clips (inlined below) of him riding the subway with the device on.
In this installment of Minimal MQTT, I’m going to cover two loose ends: one on the sensor node side, and one on the MQTT server side. Specifically, I’ll tackle the NodeMCU’s sleep mode to reduce power and step you through bridging MQTT servers to get your data securely out of your home server and into “the cloud”, which is really just other people’s servers.
If you’re just stepping into this series now, you should really check out the other three posts, where I set up a server, then build up some sensor nodes, and then flesh-out a few ways to control everything from your phone or the web. That’s the coolest material, anyway. This last installment just refines what we’ve built on. Let’s go!