Wifi with ESP8266 - Part 2

Following my first foray into ESP8266 world, I wanted to flash new firmwares and try alternative ones...

As far as I know, the most advanced one is the Lua-based Nodemcu, so let's give it a try.

Trying Nodemcu

Flashing

The main website for nodemcu is very confusing because it succint, not technical and seems to be based on a devkit.

Fortunately, I found the following pages, which are easy to follow:

So, I hooked GPIO0 to GND and off we went...

First problem...

Having disconnected the GPIO0 and rebooted the module, the serial console was all black. It seems that speed was now down to 9600 bauds... fair enough.

First steps with the LUA console

I don't really know LUA. Fortunately, the API is documented and there are examples available on the main website.

> print(node.info())
0       9       5       10311147        1261768 512     0       40000000

OK Version is 0.9.5 as expected. Other values are chipid(10311147), flashid(1261768), flashsize(512KB) and flashspeed(40000000). Don't know how important they are in our case.

> print(wifi.sta.getip())
192.168.1.20    255.255.255.0   192.168.1.1

Cool... changing firmware didn't reset the Wifi configuration! :-)

Second problem...

Depite the display of the IP address... the module didn't seem connected! :-(

Well, after a lot of investigation, I discovered that UDP usually works, ping doesn't (it might not be implemented, I don't know), and for TCP... it depends.

As first, I thought it was related to a ARP (MAC address) bug described in some forums because I too could't communicate with a machine on the same LAN. But it turned out that even with remote sites (all routed through the same gateway), sometimes it worked but most of the time it ended up in timeout. It looked like the ACK (last part of the TCP handshake) wasn't accepted by the module.

I probably tried every firmware available, including the development ones, to no avail.

Pity, this looked liked a potentially interesting product. And by the way, if official website is not informative, the Github project page has all the links.

ESPlorer

On a positive node, during this exploration of nodemcu, I discovered a Java software which facilitate the use of the module. It is called ESPlorer and can deal with the "AT mode", Nodemcu and (in theory at least) Micropython.

Micropython

Next...

Following the instructions from the Micropython Github's page, I installed esp-open-sdk in order to compile the firmware. Unfortunately this doesn't seem to work anymore. I always ended-up with errors related to implicit declaration of function 'PIN_PULLDWN_DIS'. It seems that these macros have been removed in the Expressif SDK 1.1. Great!

Since I only wanted to give a quick try, I was trying to avoid having to waste too much time on compiling this firmware! Fortunately, the good folks at Adafruit have a compiled version ready to download.

But, sadly enough, once configured I found the same problem I had with nodemcu... I can connect to some external website but there is still this weird issue with any local website. Worse, this makes Micropython crash!

I think MicroPython has a lot of potential but it is still very much work in progress.

Note : In the meantime, I "ordered" a WiPy during their Kickstarter fundraising. It is not based on the ESP8266 but on the CC3200 which is not in the same league in terms of performance, support and price.

Back to AT Firmware

Unable to solve the TCP connection kerfuffle, I decided to flash an AT firmware, thinking that using nodemcu may have broken something.

These are referenced on http://www.electrodragon.com/w/ESP8266_Firmware#AT_Firmware and http://bbs.espressif.com/viewforum.php?f=5.

Version 0.9.5.2 didn't seem to recognise the Wifi network at all any more but the 0.9.5 booted:

AT+GMR
00200.9.5(b1)
compiled @ Dec 25 2014 21:40:28
AI-THINKER Dec 25 2014

That said, once again UDP connexions were fine but TCP ones were also a bit dodgy (same as with nodemcu and micropython). They used to work fine! Same for ping which was no longer possible.

This was all very confusing...

Arduino

Starting with Arduino 1.6.4, there is support for ESP8266. And it is very easy to setup : http://makezine.com/2015/04/01/installing-building-arduino-sketch-5-microcontroller/.

Trouble is, when looking for information, there are loads of info about "ESP8266 + Arduino board" (linked by Serial) which is not the setup used here (ESP8266 used as sole MCU programmed by the Arduino IDE tool-chain).

Also without any kind of "assistance" (keep in mind that the Arduino boards use a dedicated MCU just to help with the USB connection and the flashing process) it is not as straightforward as flashing an Arduino: you need to play with GPIO0 and Reset. That said, thanks to this I understood the concept of devkit mentionned by nodemcu. More about it later.

Back to square one

Not being able to run anything because of this strange bug, I decided to see if the module was beyond repair (cf what happend with my HM-12).

For this, I managed to track down the original firmware contained in a file called ESP8266_flasher_V00170901_00_Cloud Update Ready.zip. And... Miracle! the client/server fonctions were back...

So just to make sure, I thought:

In short, the only firmware which seem to work on my (all?) ESP-201 seems the one reporting "00170901". Sadly enough, this one is not massively stable nor really useful in standalone.

Next time ?

Looking for additional info, I discovered that the nodemcu's devkit exists in 2 (released) versions:

I don't exactly know how different they are otherwise. They both have USB connection, voltage regulator and 2 buttons to help with flashing : FLASH & RESET.

So I decided to order one v1.0 from ebay ~ US$11 (inc. P&P). Should arrive within 3-4 weeks.

In the meanting, I'll try to explore deeper the possibilities of both nodemcu and arduino on ESP8266 without using network connections.

A suivre...

    Lacrosse, Digispark, Raspberry Pi, Roundup

    Quite happy with the results from the current setup, I decided to complete my collection of sensors with a WSTX3-TH to put on the front balcony.

    WSTX3-TH

    As a free bonus, since I moved to the final version (from prototype breadboard to a PCB one with all the necessary pins properly grounded), I seem to receive the signal from a neighbouring sensor as well. With 3 temperature readings from outdoors, I think I'm covered for the winter!

    Code is available on github :https://github.com/guillier/la_crosse_sensors

    Schematic is quite simple:

    Schematic

    Time to move on (and to concentrate on the main programme, maybe?)

    New RF 433Mhz receiver

    Following my post about the receiver for La Crosse sensors, I started to doubt about the quality of the reception.

    On my left: XY-MK-5V

    XY-MK-5V + FS1000A

    As I said before, I found this one on ebay for 1 € (inc. postage)!

    But it is not specially noted for its quality of reception and output signal is very noisy.

    On my right: RXB6

    RXB6

    I decided to break the piggy (hum!) and ordered a RXB6 module which has a far better reputation. Cost from China is $5 (inc. pp). Obviously it took 3 weeks to arrive but finally, I was able to try it on the Arduino.

    Surprise! It didn't work at all. Nothing, no signal on the PIN 13.

    After a while, and really thinking I got a duff one, I hooked it on the Digispark and... miracle!

    Performances

    But if I had some readings, it occured to me that something must be wrong as TX sensors are quite chatty (a repeted signal every minute or so) and I had only 20 values for a whole evening.

    Something was definitely amiss. OK pulseIn is not necessarily the best method ever but since the microcontroller is not doing anything else, this should not be a problem.

    While decoding, I ignore the LOW part of the signal (the 1000μS gap) but still...

    After a lot of trial and error, I finally understood where the lock was: A tiny little bug!

    The Bug

    The first loop validate the preamble by checking the value is 10d (00001010b) but the variable was defined by int so depending on the preceding bits it could have held a different (higher) value despite a correct preamble.

    To correct this behaviour I could either do a AND 255 with the value but I simply defined by variable by 8-bit byte type.

    I also changed the boundary timings to be less restrictive.

    Pin 13

    Reading about different receivers, it seems that the RXB familly (at least) doesn't cope well with pull-ups. Since the pin 13 of the Arduino has a LED, this might be the reason why it didn't work when I first tried it. It works fine on any other pin...

    Additional items

    Adding an external antenna to the RXB6 doesn't seem to make much difference but when hooked on the digispark, a decoupling capacitor (100nF) seems mandatory for the RF receiver!

    And the winner is...

    RXB6 module is definitely better, especially with the outdoor sensor, but it also uses twice as much power (6.7mA vs 3.8mA). And the XY-MK-5V has an unbeatable value for money.

    Lacrosse TX2/TX3 Sensors and Digispark

    Digispark

    The Digispark is a Atmel Attiny85 based microcontroller development board similar to the Arduino line but cheaper and smaller. They had an extremely successful Kickstarter campaign 2 years ago and clones are available on ebay a few euros.

    Digispark

    They seem to now have their own ecosystem and can emulate a USB device. The USB is also used to programme the microcontroller, the same way it is done on Arduino.

    Wiki pages quickref and basics have some information about pins, differences from the Arduino and limitations.

    For reference, here is the schematic of digispark.

    Pins

    Here I need only two pins for the project : 1 for the RF receiver and the other one for the serial connection to to Raspberry Pi.

    I decided to go serial instead of I²C mainly because of the asynchronous nature of the signal and to avoid polling from the I²C master (Raspberry Pi in my case). Here the digispark will simply send its data as soon as it decodes something from the RF receiver.

    So PIN 0 will be the RF receiver IN while PIN 2 (default for Serial Debug) will be used for the Serial Communication. 38400 bit/s seems to be the recommended value. Fair enough.

    Code is available on github :https://github.com/guillier/la_crosse_sensors

    Raspberry Pi

    Serial communication

    In order to allow serial communication, the serial port has to be freed from any usage as a console. Once it is done (and the Raspberry rebooted), minicom can be used to check if everything is alright.

    minicom -b 38400 -o -D /dev/ttyAMA0

    Note that the port is /dev/ttyAMA0 while the one for the Z-Wave static controller is /dev/ttyACM0.

    Storing values

    Same as the values from the airpi sensors, these ones can be stored in RRD databases:

    rrdtool create temperature_device33.rrd --step 300 \
DS:temperature:GAUGE:600:0:U \
RRA:AVERAGE:0.9:1:24 \
RRA:AVERAGE:0.9:6:35064 \
RRA:MIN:0.9:288:1826 \
RRA:AVERAGE:0.9:288:1826 \
RRA:MAX:0.9:288:1826

    ⇇ « Page 3 / 4 » ⇉