Espressif Releases ESP8266-Killer!

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.)

Continue reading “Espressif Releases ESP8266-Killer!”

An Improved WiFi Connected E-Ink Display

[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.

eink_back
Lithium-polymer charger (top left); Single-cell lithium-polymer battery (center); pullups and power cutoff for nonessential electronics (green board, lower right); ESP866 (lower left).

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.

eink_apThe 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.

Continuous Delivery For Your ESP8266

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 [squix] 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.

[squix] 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.

Hacking A Fluke Multimeter To Serve Readings Over WiFi

Your multimeter is probably your most useful instrument if you work regularly with electronics. It goes with you everywhere, and is your first port of call in most cases when you are presented with a piece of equipment. And when you think about it, it’s a pretty amazing instrument. Multimeter technology has advanced to the point at which even an inexpensive modern device has functions that would have required a hefty budget a few decades ago.

There is still one thing affordable multimeters remain unable to do: they can’t log their readings for analysis on a computer. They’re an instantaneous instrument, just as they always have been.

Lord of Hackaday [Sprite_TM] decided to hack his multimeter to serve its readings over Wi-Fi. Rather than start with a throwaway meter from the bargain bin, he did it with a Fluke. The meter he chose was a Fluke 15B+, the company’s budget offering for the Indian and Chinese markets, since he had one spare.

Opening up the 15B+, he was presented with its processor concealed under a blob of epoxy and thus unidentifiable. Armed with the knowledge that other similar Flukes contain Fortune Semiconductor parts, he investigated as many data sheets as he could find from the same company and finally identified it as an FS98O24 one-time-programmable microprocessor. Sadly this chip has no serial port, but he did find an I2C EEPROM which he correctly guessed held calibration settings. Removing this chip gave him a meter with slightly off calibration, but also gave him a serial port of sorts.

Further detective work allowed him to identify the baud rate, and supplying random commands delivered him some that returned data packets. Eventually he identified a packet containing the states of the LCD’s segments, from which he could derive its displayed value. Connecting an ESP8266 module with appropriate software left him with a Wi-Fi connected multimeter. There was a little more refinement to his hack, he created a power management board to activate the ESP when needed, and a neat hack to display its IP address on the screen.

Multimeter hacks have featured several times here at Hackaday. We’ve had another serial port hack, or how about a remote display for another Fluke on a Gameboy Advance?

Power Glove Takes Over Quadcopter Controls

Gerrit and I were scoping out the Intel booth at Bay Area Maker Faire and we ran into Nolan Moore who was showing of his work to mash together a Nintendo Power Glove with an AR Drone quadcopter. Not only did it work, but the booth had a netted cage which Nolan had all to himself to show off his work. Check the video clip below for that.

The control scheme is pretty sweet, hold your hand flat (palm toward the ground) to hover, make a fist and tilt it in any direction to affect pitch and roll, point a finger up or down to affect altitude, and point straight and twist your hand for yaw control. We were talking with Nolan about these controls it sounded sketchy, but the demo proves it’s quite responsive.

The guts of the Power Glove have been completely removed (that’s a fun project log to browse through too!) and two new boards designed and fabbed to replace them. He started off in Eagle but ended up switching to KiCAD before sending the designs out for fabrication. I really enjoy the footprints he made to use the stock buttons from the wrist portion of the glove.

A Teensy LC pulls everything together, reading from an IMU on the board installed over the back of the hand, as well as from the flex sensors to measure what your fingers are up to. It parses these gestures and passes appropriate commands to an ESP8266 module. The AR Drone 2.0 is WiFi controlled, letting the ESP8266 act as the controller.

Minimal MQTT: Power And Privacy

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!

Continue reading “Minimal MQTT: Power And Privacy”

Find The Source: WiFi Triangulation

[Michael] was playing with his ESP8266. Occasionally he would notice a WiFi access point come up with, what he described as, “a nasty name”. Perhaps curious about the kind of person who would have this sort of access point, or furious about the tarnishing of his formerly pure airspace, he decided to see if he could locate the router in question.

[Michael] built himself a warwalking machine. His ESP8266 went in along with a GPS module interfaced with a PIC micro controller. It was all housed in an off the shelf case with a keypad and OLED screen. He took his construction for a nice calming war walk around the neighborhood and came home with a nice pile of data to sort through. To save time, he placed the data in a SQL database and did the math using queries. After that it was a quick kludge to put together a website with the Google Maps API and some JavaScript to triangulate the computed results.

Sure enough, the person with the questionable WiFi access point shows up on the map.