ESP8266 tests

IntroDSC_3532_r

If you remember the time when radio modules like the nrf24l01 dropped under $5 you are going to like this. Now there are WiFi modules at that price point and there are going to be massive changes in the IoT.

The ESP8266 is a low power WiFi module built around the ESP chip of course and some flash memory. It’s made some waves around the Internet recently and everyone is excited about it, i would say even more than when TI launched its cc3000 WiFi which promised a low price point for WiFi. There are plenty of other WiFi modules out there, but nothing except router based modules made any significant excitement.

Like the cc3000, these modules contain WiFi PHY and a processor to leverage the task of a small micro around it. This is done to shorten the time to market and ease the RF qualifications of the final design. But for hobby level, it means that the module does most of the heavy stuff for you, without worrying what is inside. You can probably make your Internet connected temp sensor with a 1k microcontroller but you can even skip it by playing with the newly released SDK.

WiFi, the universal connection

Why does the WiFi matter? Well, it is the most universal thing to connect your stuff to the internet. With other radios you normally have to result to a gateway or something similar that does the link between your simple radio and the internet. That would have not been a problem if anyone defined some standard that everyone agreed to, instead of having every manufacturer trying to promote their own. And no, there was no way out of this.

Bigger batteries

It’s no surprise that the new devices consume more power compared to other radio modules like the NRF24L01, as it can operate at higher data rates and higher power. While this might be an advantage with larger coverage and higher throughput, it’s not the best if your application is a low power sensor. Still, a pair of AA(A) batteries might be able to feed your internet powered temperature sensor for a year, about what you can get from a coin cell with lower power RF modules. It’s actually not the RX/TX power per se that causes battery drain, but the longer response time required to establish a connection and upload a small amount of data to a server half way around the world, which can reach to 100ms or more. Compared to that, in a dedicated system,  a sensor with a dedicated gateway will get a response as fast as 1ms and is required to upload less data. One solution can be to use the battery powered WiFi modules with a local server to minimize response time.

Quick testDSC_3504

My ego box is a quick candidate to become wireless, but as I wanted to keep the original intact, I made a new temporary one. My greatest concern was to establish if the HW, with default firmware(less important), is capable of running stable for a long time. The build puts together an Xmega header board with an IL9341 2.2” QVGA LCD and, of course, the ESP8266 module.

As there is no great deal of official documentation for the chip, I could not establish a correct way to check whether the chip is still connected to the WiFi correctly or not. After a lot of experimenting I found that checking the IP is the only way. This is also the best way to test if the connection to the WiFi was successful, as the module replies with “OK” even if trying to connect to an nonexistent network.

The software loop is quite simple (sorry, no code yet): every 30 seconds, if the IP is available, get the visits counter of my website, otherwise attempt to connect to the WiFi. The time since power up is measured in h:m:s, along with successful readouts of the counter. Further, the number of WiFi reconnects (how many times it lost connection) and the number of connection attempts (except the first) is counted to provide an outlook on the stability. A dedicated TP LINK 841ND router is used to provide WiFi access, because I wanted to test things without altering my normal internet connection.

 Results

First results show good stability of the module and code. In multiple experiments the module is capable of reconnecting to the WiFi in case of connection loss caused by router shutdown. Saturating the WiFi with file transfer between two devices does not seem to bother the ESP module.

Now, the endurance test is started, stay tuned for more results.

Update 1: 1 week in the device went without any re-connection. Note that the router was set to manual IP for the ESP.

Update 2: Somewhere in the 9th day there was a re connection to the WiFi, which took 2 attempts.DSC_3561

Update 3: Another re-connection some time during the second week. It also looks like I am converting the number as signed, hence the negative number of successful attempts to get the website counter after 32767. I should also have used a 32bit counter, but that is for the second revision.

Update 4: the device worked for 859 hours before being shut down for the holidays. It is safe to assume the ESP can be trusted to need infrequent resets, should it be used for a permanently operated device. 

859_h

 Build pictures

DSC_3509DSC_3516DSC_3518DSC_3526

Be Sociable, Share!
1,820 views since Nov 2016

2 comments to ESP8266 tests

  • Sam

    Howdy Bob,

    Thanks for the insight! I’m wondering if you found any of the data transmission between the uP and the computer to be difficult. I’m looking to connect my xmega to run data straight to a URL based data visualizer (to show some ADC data from the uP) and was questioning the ESP8266’s ability to do this.

    I’m a pretty new engineer experimenting with this, so any feedback or help is greatly appreciated!!

    Sam

  • […] is a quick and dirty solution, i scavenged of the build of the ESP8266 test rig which uses the XMEGA header board. It’s using a IL9341 driven 2.2″ 320×240 LCD […]

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

*