A project researching the capabilities and use of the newly available ESP8266 low-cost WiFi module.
This project was created on 08/27/2014 and last updated 7 days ago.
I am still awaiting the arrival of the modules I ordered from AliExpress. I have a tracking number, but it doesn't seem valid yet. It is great reading up on the progress others who have received their modules are making! Peter has been active in the comments and has successfully sent TCP data.
I will provide another update when I receive the modules and being work on the library. I was originally going to write the library for the MSP430 microcontrollers, but it looks like many people who have received their modules are using the Arduino. I might create the library for the Arduino first so that I can get the most amount of people debugging the library. I will eventually port the library to both platforms.
So looking around on this German forum post about the ESP8266
I saw that somebody translated the Chinese AT command pdf (into German which google than translated into English for me). The translation this person posted had much more information about the chip than I had seen before! I had assumed that the Nurdspace page everybody is probably already very familiar with
was translated from the same document and was all the information we had so I didn't bother taking a look at the actual document in Chinese. It seemed like it would be just BARELY enough to get a good library going, however a lot of information was missing like possible return values and the returned data format. It wouldn't have been impossible to figure this stuff out after getting the chip, but it would have taken longer just poking around.
Read on to see the translated document and what to expect from the List Access Points Command.Read more »
I just placed an order for two ESP8266 Modules from AliExpress for $9.50 including free shipping. The processing time is 7 days and the expected shipping time is over 2 weeks. I will be posting the currently available documentation and the translations people have posted soon. I will also create a new GitHub repository to start commiting preliminary code based off of the documentation.
the product is listed here. Seems three people have gotten it to function.
@SA0987, if the blue light is coming on and staying on, there's something wrong. Do you have CH_PD connected to VCC? It might also be the available supply current from your serial cables: the module apparently needs 100-300 mA, which appears to be a problem for people using Arduinos.
If you got yours from Electrodragon, it's probably already v0.91.
I now have it working on both a Nano and Uno R3. 0.91 appears to have 115200 for speed, needs reset (next to TX) to be high at all times, and a 5->3.3 V divider.
There are other issues also (not sure why they have not been mentioned). for RX/TX to work. I have to program the device, then disconnect the USB cable. Make it self powered (Nano need a separate 3.3. Could not use its 3.3) and the demo works. I added a delay since I encountered some issues opening serial ports and sending commands before the device was ready. I got two of the three modules to work with the same sketch on both R3 and Nano.
a) add voltage divider TX -> ESP RX
b) serial port 115200 on .91
c) add a delay
d) take the reset high at all times (see dragon link above)
and I get
OK, Connected to WiFi.
> GET / HTTP/1.0
on my router ----
1 10.0.57.100 18:FE:34:99:20:77
2 10.0.57.101 18:FE:34:99:20:5F
Has anyone who has it working measured the power? Specs seem impressive but keen to find out the
wake -> connect -> send data (say 1KB) -> receive data (1KB) -> sleep
Power consumption and time if anyones making progress here..
Holidaying in the UK for a few more weeks so not sure if my modules have turned up yet, also still waiting the proper translated chip documentation and SDK from expressif.com which was promised for last week
I started there, too, but I don't have the UartSBee so I tried cutting their code down to just using HW Serial too see if I could monitor the communication with the Serial Monitor. Not much luv for me so I set out to explore some other options which I put up on my site at http://hobbies.boguerat.com/?p=321. Essentially, I just attached the ESP8266 to an UNO with an empty sketch then started sending over commands with the Arduino IDE Serial Monitor. The 3.3v/Gnd/RX/TX were all mapped directly to the corrsponding pins on both. I managed to get connect to the AP and get a TCP server running. I was able to communicate via PuTTy for a few seconds before the TCP connection stopped. Then it just kinda died out on me. Will try again tomorrow.
ArsenioDev, perhaps you have one of the revision 2 modules. If so, make sure that the CH_PD pin (that's the pin next to TXD, which is labelled NC in the diagram you are following) is held high by being connected to +3.3V (via a resistor). Otherwise the module will be in a mode which will not respond to AT commands. R2 modules have two LEDS on them, one of which will be lit when the device is powered. There's a photo on my blog (http://robinsonia.com/wp/?p=360) if you want to check. R2 boards also use a baud rate of 115200, not 57600.
I'm actually having success now. I can reliably establish a TCP connection and send data back and forth. It works rather well, with some limitations. It helps that I came across some slightly better documentation here: https://drive.google.com/folderview?id=0BwK3EhAfht8uWTdBdG55NEFCakE&usp=sharing, sourced from this esp8266.com forum post: http://www.esp8266.com/viewtopic.php?f=5&t=48&p=341&hilit=command+set#p341 which lists a few more AT commands and some more illuminating explanations.
AT+CIPMODE=1 or 0 (1 is default) sets the data receiving mode of the socket. If it's 0, received data is simply sent to the serial port. If it's 1, data gets "+IPD,c,n," prepended to it, where c is the channel number and n is the number of bytes received. c is omitted if you are in single-channel mode. If you have multiple connections going in, this mode is logical. If you have only one, it may be simpler to use the transparent mode (0). But: see AT+CIPSEND below, because this is affected by AT+CIPMODE!
The usual documentation about this is a bit pants. Here's how it works. When you issue an AT+CIPSEND command, you normally tell it the channel you want to send it over (the chip can keep four IP connections going at once) and the number of bytes you want to send (call it n). The module then responds with a ">" character. It will then take the next n bytes you give it and send them over the TCP link. Then it responds with "SEND OK" and returns to normal, waiting for your next command. There are three variants of the AT+CIPSEND command, however:
AT+CIPSEND=channel,length is used if you have multiple connections open (AT+CIPMUX=1)
AT+CIPSEND=length is used for a single channel (if you have previously issued AT+CIPMUX=0 to tell it that you will only use one connection at a time)
AT+CIPSEND can be used without any parameters if you are using a single channel and transparent data mode (AT+CIPMODE=0). Note that there is no channel or length specified in this variant. After you issue the command, it will simply send every byte you throw at it directly to the receiving socket. This includes AT+ commands. Note that I have as yet found no way of exiting this mode other than resetting the module.
Also note that if you are in transparent data mode (AT+CIPMODE=0) and you try to use the variant of AT+CIPSEND which uses a length value, it won't just fail or ignore it, it will actually reboot the module.
Lesser known AT commands not in other documentation:
AT+GMR retrieves the firmware ID of the module. There are at least two versions in the wild.
AT+CIPSTO=60 Sets the socket timeout period to 60 seconds
AT+CIPSTO? gets the current timeout value
You might want to change this value because if the server closes the socket, and your timeout value is too high, there appears to be nothing you can do from the client end other than do a hardware reset. I'm thinking it's probably going to be necessary to tie the CH_PD line of the module to an output from the arduino, as I'm bound to want to reset from software at some point.
It's good to make some progress. I'm going to look at the using the module as a server next.
I've received a couple of these from electrodragon. Having spent half a day playing with them, these are my findings so far:
1) the 3.3V available from an arduino can't provide enough current to run the wifi module. It won't even respond to commands without a separate power supply. Powering it from one of these (http://www.dx.com/p/lm2596-sdc-dc-to-dc-debugging-power-module-w-0-4-3-digit-voltmeter-deep-blue-310730) works fine.
2) As jacksonliam said, you must connect the CH_PD pin to +3.3V. Don't be put off by the suggestion in the diagrams on Nurdspace.com that the four pins in the middle of the connector are not connected to anything. CH_PD is the pin next to the TXD pin.
3) The AT commands mostly work. AT+CWLAP briskly returns a list of visible access points. AT+CWJAP connects to my home router (or claims to). Beyond that, things get flaky. Actually setting up a TCP connection to a running server does not seem to work. Nor does sending UDP. both allow me to get to the point of sending data, but then simply respond 'busy' to any further command or data until the device is rebooted (by unplugging it from the power supply). I'm not convinced that the device is ever genuinely connected to my router: the router doesn't show it in the list of active clients.
I'm frustrated. It seems so close to being functional, but feels like the firmware is missing some useful commands and diagnostic information. Or maybe it's the documentation. Perhaps if my Chinese was better...
I only got this far too, but I think mine was because of the lack of current. I saw "busy..." when I typed the 'start connection' command in wrong. I set mine in single connection mode.
I think the command is the requires the length of data you'll send, followed by a comma and then the data.
Can you post the output of the chip's response to AT+CWLAP before and after you issue the AT+CWJAP? I am most interested in the mode character. If you connect to your access point and power cycle the device and you send AT+CWLAP again, does the mode character stay the same?
If you want, feel free to change the names of some of the APs for privacy.
I've got it successfully sending data, albeit hooked up to an FPGA that can definitely deliver enough current. I left CH_PD floating, but my logic analyzer seems to think it's high anyway.
Does your module report the expected IP address if you issue the AT+CIFSR command? Does it respond to pings? Have you tried it in single connection mode (what I used)?
I've got the newer firmware running at 115200 baud, and the chip's sending data with both CR and LF so I assume it expects both as well. There is no mode parameter in my CWLAP responses.
Bafelgum, I'm working at 115200 baud. It seems to be a version 2 board (CH_PD and IO pins are connected). I do send CR and LF after each command, not just CR.
This morning, it works. Here's what I get (output is sanitised to remove wifi identifiers). Firstly, after AT+RST:
ets Jan 8 2013,rst cause:4, boot mode:(3,2)
load 0x40100000, len 24236, room 16
ho 0 tail 12 room 4
load 0x3ffe8000, len 3008, room 12
load 0x3ffe8bc0, len 4816, room 4
After powering off the device (but no other commands):
So it thinks it is connected. The mode character (if that's what it is) does not change. The router shows the device as "Unknown-18-fe-34-..., MAC Address 18:fe:34:99:20:5c, IP address 192.168.1.90). AT+CIFSR reports 192.168.1.90. I can then set up a connection and both send and receive data (I'm running a simple tcp server at the other end, from which I send the "aaaaa" data).
Goodness knows why it works today but didn't work the day before yesterday...
There is still a problem if the connection gets dropped, as there seems to be no way to reset the wifi module without powering it down. It gets itself into a state where it responds 'busy' to each character it receives, and nothing can be done. That's the next hurdle.
I got mine today from electodragon in the EU http://www.electrodragon.com/w/Wi07c I ordered it on the day I tipped HAD about this chip.
Its their 'new' version (LED on the very right edge of the board), of which mine runs at 115200 baud and requires both NL and CR after every AT command.
This version looks to have GPIO0, GPIO2, the RESET pin and CH_PD broken out, not sure if this will be the same for the aliexpress modules. CH_PD had to be tied to VCC for the module to boot.
When CH_PD is low its in 'firmware upgrade mode', though no details are given of how that works.
It spits out this when I run AT+RST
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
load 0x40100000, len 24236, room 16
ho 0 tail 12 room 4
load 0x3ffe8000, len 3008, room 12
load 0x3ffe8bc0, len 4816, room 4
Something made me laugh, "AT?" replies "no this fun".
It needs about 250-300ma at 3v3 to do fun stuff, I don't think I have anything that can provide that (all my stuff is 150ma max) I'll have to make up a makeshift battery holder with tinfoil and tape.
some info on the GPIO functions is shown here, but not translateable as it is in a picture
I found all the characters from the picture in the documents, and translated them with google translate.
At first it translated something to "on power-up state" but then it changed to Power Status, so I left both in.
A Proper english (not google) translation of the ESP8266 chip specification is here
I got this by asking the company espressif.com directly. I have also requested a copy of the english technical documentation, they have asked me to sign an NDA (WTF) but that OK I will do that as I would like to try and integrate the chip on my project on a later revision, I'm sure the silly NDA restriction will only last until the chinese translations are widespread then I can add it to my public document library. The people at espressif.com seem to speak genuinely good english so I am expecting some decent english documentation in a few weeks when it has been produced
my hackaday project: http://hackaday.io/project/1915-Data-Collection-Terminal
An obvious note here, the modules are NOT the same as the chip, the modules look to be third party products by the look of it which adds an SPI flash chip and its own serial to Wifi AT command set so expect to see a lot more cheap wifi modules around the $5 mark
The ESP8266 chip iself looks to be SPI controlled and has 3 channels to control SPI slaves plus serial and some GPIO. I thought it was an ARM SOC as it mentioned a thumb instruction set (somewhere), but I am no expert on these things.
Excellent find! I'll add it to the links later. I have also been in talks with espressif to try to get the English documentation. How extensive is he NDA? I wonder what the ramifications of publishing a library based off the documentation would be.
For clarification the properly translated document I posted was just the specs, they never mentioned NDA for that and its widely available in chinese so I posted it, they want the NDS for the technical documentation (the meat of the system: programming, registers, pcb antenna design stuff etc)
I am still waiting a reply on the NDA I haven't received/signed anything yet, but they did say that the translation wont be ready for about 10 days
The NDA will restrict publishing the material directly but shouldnt restrict creating a fully open source interface - similar to how the raspberry pi hardware used to be, we diddnt know all the details but had enough to make everything work
Also a small mistake on my part, its 1 SPI slave channel and 3 enables
SDIO 2.0, SPI, UART
32-pin QFN package
Integrated RF switch, balun, 24dBm PA, DCXO, and PMU
Integrated RISC processor, on-chip memory and external memory interfaces
Integrated MAC/baseband processors
Quality of Service management
I2S interface for high fidelity audio applications
On-chip low-dropout linear regulators for all internal supplies
Proprietary spurious-free clock generation architecture
Integrated WEP, TKIP, AES, and WAPI engines
Wi-Fi Direct (P2P), soft-AP
Integrated TCP/IP protocol stack
Integrated TR switch, balun, LNA, power amplifier and matching network
Integrated PLLs, regulators, DCXO and power management units
+19.5dBm output power in 802.11b mode
Power down leakage current of <10uA
Integrated low power 32-bit CPU could be used as application processor
SDIO 1.1/2.0, SPI, UART
STBC, 1×1 MIMO, 2×1 MIMO
A-MPDU & A-MSDU aggregation & 0.4ms guard interval
Wake up and transmit packets in < 2ms
Standby power consumption of < 1.0mW (DTIM3)
at least in theory in our hands are: toolchain, documentation, example code
is the serial flash memory mapped or is its content copied to RAM at boot?
is there internal flash memory in the chip?
can the firmware be upgraded OTA? (fragments in the "SDK" tell yes)
how to obtain missing documentation? e.g. configuration of peripherals
where to find "xtensa xplorer"
what jtag probe is suitable to debug this chip?
with enough serial flash memory (assuming it's memory mapped) is there a way to run openWRT?
And guessing from the compiler Name xt-xcc - this is probably Xtensa (former Tensilica now Cadance) CPU Core
Having a look at the Linkerfile (of the IOT SDK) - probably reveals the following specs:
dport0_0_seg : org = 0x3FF00000, len = 0x10
dram0_0_seg : org = 0x3FFE8000, len = 0x14000
iram1_0_seg : org = 0x40100000, len = 0x8000
irom0_0_seg : org = 0x40240000, len = 0x32000
I don't have experience with wifi modules, but I have written libraries for Ethernet modules. From the AT commands in the documentation, it looks very similar to what I have worked with before. I'm going to write the AT command library for the MSP430, but if I get time I will port it to AVR and PIC if there is interest.
From the comments it looks like there is some strong interest to get custom code running on the processor. I don't have experience with the architecture it uses, but it should be interesting to get working.
Sorry, I got a bit confused by the SDK but now I see that with the AT commands given it should not be too hard to get that ported to the arduino (cheap and easy) platform as well. Could be interesting to port it to the fubarino and I don't see why it should be a problem, when it really is a serial module.
I'm not sure if I would want to reprogram the units but it sounds interesting, too.