Author: tinkermax

Investigating MQTT persistence in an IOT protocol on the ESP8266

| tinkermax

One of the most important reasons that I considered using MQTT for my haptic wristband project was because of its ability to handle devices that are intermittently connected. IOT devices, even if nominally switched on, may at any given time be unavailable due to sleep modes (even although this direction did not prove as promising on the ESP8266 for my application as I’d initially hoped), or simply because the device has temporarily lost Wi-Fi connectivity.

MQTTInspector_sWhatever the cause of disruption, the MQTT architecture provides for the broker to store any important messages (i.e. those flagged with high qos or “quality of service”) to be later delivered to a client that had been previously subscribed, also with high qos, but is at that point in time disconnected.

For my project this is crucial. I have always envisaged my wristband to be an additional “priority” channel to cut through the barrier of noise created by the visual overload of our multiple screens, through the beeps and buzzes representing emails, meeting requests, tweets, texts, phone calls and missed calls – which are themselves competing for (hopefully) the majority of your attention directed at real people and real objects around you as you do your job and live your life!

Therefore, as a device that handles relatively few but very important notifications, a missed message is unacceptable.

Unfortunately, as I hinted at last week, I struggled to get this MQTT mechanism to work. The main problem I was having was that I was not sure where the fault lay – and even wondered if I was misunderstanding the way that MQTT should work. I began to suspect that the free MQTT broker that I was using did not support this more advanced behaviour. As it transpired, and thanks to some timely help from Carl at CloudMQTT support, the MQTT broker turned out to be fine – it was both the ESP8266 client and the MQTT test software that I was using that were dropping the ball.

After wading through many documents on the web, I also realised that this whole area of MQTT persistence is quite confusing and not well explained from the point of view of someone actually wanting to make use of it. So, in this post, I aim to first explain how persistence should work, and then afterwards provide all the details for someone to actually try it out for themselves. Along the way I also discover a couple of great new products. Continue reading →

Reducing ESP8266 Power Consumption using deep sleep

| tinkermax

[Update May 2016: for reducing power consumption of a NodeMCU board, see this post where I revisit the topic].

In my previous post, I mentioned that one of the reasons that I was excited about MQTT was because of its potential to allow power savings schemes on the ESP8266. The MQTT broker could asynchronously hold messages during the period that the ESP8266 was in a sleep cycle, to ensure that nothing is missed while dramatically reducing average power consumption.

This week I have hit a few obstacles, mainly due to the immaturity of current implementations of some of the latest MQTT qos (quality of service) features – at least that is what I suspect at this point. But more on that next week.

So, focusing on the ESP8266: my initial research had led me to believe that “deep sleep” mode was the way to go. Who can argue with using just 78μA during deep sleep?

To be able to implement deep sleep (without adding extra hardware to generate a wake-up signal), you need to link 2 pins on the ESP8266, as discussed here. Fortunately, the ESP-03 module has pads broken out on the PCB that you can join together. By linking these, you lose the ability to use GPIO16, but gain an automatic wake-up from deep sleep after the number of microseconds that you specify in the system_deep_sleep(time_in_us) call. You can understand better how this works by looking at the ESP-03 schematic.

To avoid any confusion, the pads to join are shown below:

ESP-03-rst1 Continue reading →

Investigating MQTT as an “IoT protocol” for the ESP8266 wristband

| tinkermax

I have recently had a rethink about how I will link my wristband to an alert source.

To demo my first prototype, I hosted a web page on the ESP8266 device itself. Selecting a button on the web page posted a value, which activated the chosen vibration pattern. This is a very convenient way to demo the concept, but, in the real world it has some significant drawbacks.

The first drawback is that the whole submit / refresh cycle of a web page is not particularly fast, which also probably means that the web server on the ESP8266 is having to do a relatively large amount of work. I therefore had originally planned to eliminate some of this overhead by following the approach in the ESP8266 IoT example of using http methods and json, which can be called from anything (e.g. from another pc/server by using the curl command).

But this does not solve a second issue, which is that the ESP8266 server has to be “always on”, waiting for a command from the remote web page. This is likely to make power savings measures (sleep cycles) difficult, which is less than ideal given that Wi-Fi is not as power efficient as Bluetooth – notwithstanding that Wi-Fi continues to evolve.

The third problem is the direction of the link. To communicate with the wristband requires that you initiate a connection. This is not a problem if you are on the same network (and also assuming you always know the ip address of the wristband). However, if the source of the alert is from outside the network, a firewall port will need to be opened and forwarded – something that will usually be out of the question on most corporate networks.

With this background, and inspired by Peter Scargill’s exploits, I decided to investigate MQTT. Potentially if offered to solve all three of my issues:

  • It is a lightweight protocol, optimized for resource-constrained devices (like the ESP8266) – refer to here and here.
  • Because it uses a broker in the middle, both the client and the (wristband) device talk to the broker, not to each other. This allows for an asynchronous communication scenario in which I could allow the wristband to, for example, check the broker for messages and then go to sleep for a second, yet be guaranteed not to have missed a message when it next checks at the end of that second. Such a duty-cycle could dramatically lower the overall power consumption.

MQTT-architecture

  • The broker architecture also solves the firewall problem by reversing the direction of the connections. Now the wristband will initiate the connection to the broker, which can thereafter communicate without the need for port forwarding.

Continue reading →

Designing the Wristband PCB… using DesignSpark and iTead Studio

| tinkermax

These days I use DesignSpark PCB for designing my PCBs. A few years ago, I judged it to be the best of the free software after trying Eagle, Kicad and others – and I like the way that RS is continuously developing it. Ultimately though, whatever CAD tool you choose, the most important thing is to become familiar with it.

I used DesignSpark to generate a PCB for my vibrating wristband from the schematic that I had already captured. I manually positioned the components, but let the auto-router route all the tracks. I had to move the components slightly over a few iterations to get the auto-router to be able to complete all the nets. PCB I have previously had two sets of PCBs made at ITEAD Studio, and been very happy with the results. Certainly their prices are good at $1 per 5cmx5cm board.

Just be aware of minimum sizes in your design. In the past I have specified silkscreen text and lines that were too small to be printed. It is very easy to lose touch of just how small things really are when you are looking at a full screen CAD view. ITead has posted guidelines here, but basically you should be fine if you don’t need to go below 0.2 mm.

batteryI designed the board with exactly the same dimensions as the Adafruit battery that I plan to use, since the board will sit on top of this battery (37mm x 30mm). The process for generating the correct files for an ITEAD Studio 2-layer board is quite simple, but you should follow the following steps once you have finished your design: Continue reading →

“Haptic Bracelet” published by Hackaday… and working on the next version

| tinkermax

It was fantastic to see my vibrating wristband appear on http://hackaday.com/2015/02/12/a-haptic-bracelet-for-physical-computing/

Brian Benchoff did a great job writing his article.

Meanwhile, I am working on my next prototype. The main goals are to:IMG_4268s

  1. Make the action of each vibration motor more specific. This will be done by eliminating the plastic backbone (which conducts vibrations). I will instead use a fabric band with compartments to keep components in the right place.
  2. Make everthing smaller by designing a pcb to hold all of the electronic components.
  3. Use the ESP-03 version of the ESP8266, as it is smaller and has more outputs that are broken out.
  4. Move beyond the web server / page demonstration to connect the device to a message source elsewhere on the web.

IMG_4272s

I have managed to get a newly arrived ESP-03 working on a breadboard, including properly latching the shift register during updates, as I mentioned I intended to do.IMG_4271s

With the previous ESP-01 version, I tried making an adapter to reuse the ESP8266, but it all went wrong when the solder flowed more than I intended. It then struck me that the modules are so cheap that it is not worth going to all the effort – just keep one permanently for breadboard prototyping.

IMG_4273s

I have been making extensive use of the SDK examples to work out what to do. But, when faced with a bunch of c modules and headers for the first time, it can be difficult to get an overview of how they interconnect and interrelate.

There must surely exist some good (and free) tools to generate these “call graphs“. After all, this capability is built into any compiler?

Continue reading →

Vibrating Wristband Alert

| tinkermax

Welcome to this first post on my blog. Over the years I have enjoyed following and using the work of many others across the Internet, so have decided to contribute my efforts to the community as well.

I have always had a passionate interest in electronics (refer to About), but these days it is very much a hobby. So, if you look around my site, you will notice placeholders for projects that I still plan to write up – sometime in between work and family life.

The Concept

I was motivated to develop a vibrating wristband communication device after reading “Enchanted Objects” by MIT Media Lab’s David Rose. In the book, he imagines a future based not around the “cold slab of glass” of our smartphone screen, but instead on “technology that can enhance our five senses and optimize our physical abilities – by accommodating and responding to the way we already operate in the world”.

IMG_3926s

As I planned my device, I drew up the following wish-list:

  1. The device should communicate with us in an immediate way that bypasses our usually overworked visual sense.
  2. The device should have multiple vibrating actuators to be able to deliver a richer message than can be achieved by using “Morse code” like on-off pulses to a single actuator.
  3. It should use Wi-Fi to connect directly to other devices over the internet. This is in contrast to almost any other similar device either available or being proposed. Of course, the use of Wi-Fi instead of BLE does mean a higher power consumption. But for this proof of concept, I wanted a device that was a “first class citizen”, not requiring tethering to a smartphone or other device. The power issue could be dealt with later, hopefully with sleep modes, advancing technology, etc.
  4. In keeping with the Internet of Things (IoT) ethos of ubiquity, the device needed to be low cost. This is particularly important for the wristband, because it is explicitly designed as a single function device, not to be all-in-one and consequently complex-to-use as seems to be the current trend.

The ESP8266

The technology required to make this possible (at least from a hobbyist perspective) only became available late last year, in the form of the ESP8266. This remarkable module is tiny, has built in Wi-Fi, a programmable CPU able to control GPIO pins, and costs only about 3 dollars (including free shipping from China!)

ESP8266

The drawback is that documentation is scarce – although this situation is gradually improving due to a few intrepid developers out there (refer links for details). It also does not run Linux like some other development boards, which means that you have a limited choice of development options (at least currently).

I initially started coding the wristband using Lua, which becomes possible by flashing the ESP8266 with the NodeMcu firmware, using ESPlorer. Although certainly an easy way to get started, in my case the results were flaky. I was constantly getting module resets, and wasn’t sure why. Memory also seemed to run out quite quickly. However, I may not have persevered enough, or the environment may have improved since then. So don’t let me put you off trying – here is a link to download my wristband_lua code.

As a result, with some trepidation, I moved onto using the Unofficial Development Kit by Mikhail Grigorev, which turned out be an excellent piece of work. It does require that you develop your code in C, which may not be to everyone’s taste. In my case, it is my preferred development language and so, quite a few hours later, I had ported across my wristband code into the “esphttpd” example provided in his SDK.

To my delight, this proved to be stable. Also, the serial bit-banging loops were running 250x times faster as measured on an oscilloscope – not essential for my application, but nonetheless satisfying.

The First Prototype

The main objective was to find out how the multiple vibrating actuators would actually feel when on your arm. Was this a feasible approach to communicate a variety of different messages?

Continue reading →