{{
ESP8266 UDP demo module
by Roger Williams / localroger 11-11-2014
Note this assumes the ESP8266 has already been put
in AT+CWMODE=1 (client) and AT+CWMUX=0 (single channel)
This was tested with a unit from Amazon seller flyfun
which communicates at 9600 baud. Note ths misspelled
ALREADY CONNECT message. This sends about 4 packets
per second waiting for the module to reply before each
new transaction. The module does reset once in awhile
but it remains connected so this only results in a
brief interruption. For units that work at faster baud
more delay may be necessary to prevent resetting.
Although this code detects and handles incoming packets
each single packet is sent to the serial 8 or 9 times,
quickly flooding the buffer if there is more than one
character. I don't know why it does this.
}}
CON
_clkmode = xtal1+pll16x
_xinfreq = 5_000_000
rxpin = 1
txpin = 0
vgapin = 8
led1_pin=17
led2_pin=18
led3_pin=19
led4_pin=20
obj
SER : "FULLDUPLEXSERIAL"
VGA : "VGA_TEXT"
dat
host_ip byte "192.168.1.64",0
host_port byte "48623",0
network byte "GTMFCAL",0
reply byte 0[80]
var
long initcnt
pub main | c
ser.start(rxpin, txpin, 0, 9600)
vga.start(vgapin)
dira[led1_pin..led4_pin]~~
waitcnt(cnt+clkfreq)
repeat
outa[led1_pin..led4_pin]~
initcnt++
\join_network
waitcnt(cnt + clkfreq*2)
pub join_network
echostr(string("AT+CWJAP?",13,10))
getresp(@reply,1)
byte[@reply + 7]~
if strcomp(@reply, string("+CWJAP:"))
\start_udp
else
echostr(string("AT+CWJAP=",34))
echostr(@network)
echostr(string(34,",",34,34,13,10))
'this might take awhile
getresp(@reply,20)
if strcomp(@reply,string("FAIL"))
abort
elseif strcomp(@reply,string("OK"))
start_udp
pub start_udp
outa[led2_pin]~~
echostr(string("AT+CIPSTART=",34,"UDP",34,",",34))
echostr(@host_ip)
echostr(string(34,","))
echostr(@host_port)
echostr(string(13,10))
getresp(@reply,2)
if strcomp(@reply,string("OK"))
start_process
elseif strcomp(@reply,string("ALREAY CONNECT"))
start_process
else
abort
pub start_process
outa[led3_pin]~~
repeat
outa[led4_pin]~
echostr(string("AT+CIPSEND=10",13,10))
echowait(">",1)
hex(cnt,8)
ser.tx(13)
ser.tx(10)
echowait(10,1) 'wait for LF
outa[led4_pin]~~
vga.out("(")
vga.dec(initcnt)
vga.out(")")
getresp(@reply,1)
if not strcomp(@reply,string("SEND OK"))
abort
' waitcnt(cnt+clkfreq/2)
'type string to module waiting for each char echo
'time out and fail if echo doesn't arrive
'
pub echostr(ptr) | i, l, c, q
l := strsize(ptr)
if l > 0
repeat i from 0 to l-1
c := byte[ptr + i]
ser.tx(c)
q := cnt
repeat
if echocheck == c
outa[led1_pin]~~
quit
if cnt - q > clkfreq / 4
outa[led1_pin]~
vga.out("?")
return
pub echocheck
result := ser.rxcheck
case result
13, -1:
'ignore
10:
vga.out(13)
other:
vga.out(result)
pub echowait(c,t) | i
i := cnt
repeat
if echocheck == c
return
if cnt - i > clkfreq * t
abort
'get response into the indicated buffer.
'time out and fail if it doesn't arrive.
'
pub getresp(ptr, t) | i, c, q
q := cnt
i := 0
byte[ptr] := 0
repeat
c := ser.rxcheck
if c < 0
if (cnt - q) > (clkfreq * t)
vga.dec(clkfreq * t)
return
else
case c
13:
'do nothing
10:
if i > 0
if not is_ipd(ptr)
vga.out(13)
return
else
i := 0
byte[ptr] := 0
other:
if i < 80
byte[ptr+i++] := c
byte[ptr+i] := 0
vga.out(c)
pub is_ipd(ptr) | c1, c2, nch
if byte[ptr] <> "+"
return
bytemove(@c1,ptr+1,4)
bytemove(@c2,string("IPD,"),4)
if c1 <> c2
return
'spontaneous data from host
'collect character count
ptr += 5
nch := 0
repeat while (c1 := byte[ptr++]) <> ":"
nch *= 10
nch += (c1 - 48)
vga.dec(nch)
'collect incoming characters
repeat nch
c2 := ser.rx
'collect OK
getresp(@reply, 1)
vga.str(@reply)
getresp(@reply, 1)
vga.str(@reply)
PUB hex(value, digits) | c
'' Print a hexadecimal number
value <<= (8 - digits) << 2
repeat digits
c := lookupz((value <-= 4) & $F : "0".."9", "A".."F")
ser.tx(c)
This seems to be fairly robust and is probably the killer app for the ESP8266; it still resets once in awhile but it doesn't matter because it quickly recovers and doesn't lose the wifi connection. This code deals with the "human" interface waiting for all responses with timeouts, which seems to keep the resetting down to a dull roar.
I see you are annoyed with the echo responses from the ESP8266, as I was. I found that in order to speed up the communication process it was best to turn off that functionality. The command to do that is "ATE0". Why it's not the same format as any of the other commands, I have no idea. Also, this is not a saved setting, so you must run it each time the device starts up.
I bought a few more modules - price has come down, now only $3.99. I only had one module to test but I have this idea of setting one up as a server, and several as clients, and getting them chatting to each other. Even if the "webpage" is just one line of text eg "Temp = x" , that is still very useful. Visions of swarms of little robots/quadcopters exchanging their GPS positions and flocking in order to take over the humans...
Nice work, Move forward
I have to wirte in this thread because i am a newibie and the my account keeps telling me to post on thread. But this may be very interesting for me in future because i want to design low cost home automation systems
thanks
Playing around with a module this morning. I am using a little max3232 board bought on ebay, a FT232 USB to D9 cable and a little variable switch mode supply that has a display for current and volts. The latter is because I wanted to see the current consumption as some have said it can be quite high briefly. It mostly is around 70mA.
Terminal program is Putty, and baud rate is 115200 as this module is an older version (newer ones are 9600 baud?)
So - AT+RST and it resets
AT+CWMODE=3
AT+CWLAP and it lists access points around my house.
Then I tried to connect, and I think this is where I have gone wrong, because all the commands this module likes need to be in capitals, so I had the caps lock on and when I typed
AT+CWJAP="SSID","password"
I typed the SSID in capitals, but the actual SSID of that router is a mix of upper and lower case.
Now the CWLAP command won't work. This is discussed more on this website http://www.esp8266.com/viewtopic.php?f=6&t=571
and the problem is that this module remembers the router it connected to in eeprom even after a reset. Further, it is not entirely clear whether it can be disconnected again. I think it has been set up so it keeps trying to reconnect a broken link so once it has been told about an access point, it really wants to stay friends with that access point
Try
AT+CWQAP
which is the quit command, and it responds, in rather charming Chinglish
"no, this fun"
The second try of this command came back with OK, but it is not entirely clear if it really did disconnect.
In any case, there are are a few blogs out there talking about how the CWAP command won't work if it is not connected. It hangs, or says it is busy, or returns an error.
Another test is CWJAP with "","" so that is a blank SSID and password but that doesn't seem to help either.
I suspect they have quite a few bugs which they are ironing out as we go.
So the next step is probably to update the firmware. I'm following the thread a couple above by ProcessingData. I'm on the steep part of the learning curve with Python, so what do I do with esptool.py? The link brings up the code in the web browser - do I need to save this somewhere?
And the link to the new firmware (electrodragon) appears to be broken now.
Any help with the firmware update process would be most appreciated.
Once that is working, I want to experiment more with not just how these modules work, but more importantly, how they fail. It seems that there need to be some delays between commands, and judging by the responses to manual commands, probably a certain number of retries with each command as well.
Addit:
AT+CWJAP="","" does work, but only after you then cycle the power.
So now once the access point has been totally reset
AT+CWLAP
is working again.
So now I have an IP address assigned to the module and I can ping it.
I think so far, any interface with the propeller is going to need the ability to power cycle the module.
More testing, can point the browser at this IP address - lots of text appears on the module terminal screen.
And also, power cycling the module and it is remembering the IP address and automatically reconnecting after only a couple of seconds.
I have been following the threads and developments on the ESP8266 too. There is an updated SDK that has some fixes and additions.
One of the problems found is that you need to get a connection first before doing other things as the SSID and Password is written away to the eeprom. It would be worth following or asking on the ESP8266 forum.
I have an ESP-01 with the extra 2 GPIO connections. I ordered an ESP-03 a few days ago as this brings out more GPIOs.
Meanwhile I am waiting for a pcb design I sent off last w/e that uses a PropPlug connections both ends to permit insertion in between the PropPlug and Prop. I use my PropPlug version that taps the 5V from the USB, and my dev board adds a 3V3 regulator for the ESP8266. Its designed for the ESP-01 because I sent it off before I decided to order the ESP-03.
It seems some have put a larger cap (470uF-1000uF) on the power supply and that stops the ESP from resetting at random. This is way too high for putting on the USB bus for power so perhaps a 47uF tantalum or maybe 100uF electrolytic. Remember tho that USB recommends 10uF max.
I don't know if anyone else has noted this, but I see there is an article in Dec2014 Silicon Chip on the ESP8266 modules.
The article has some good links and summary of the AT commands.
We are at the cutting edge here.
Ok, well for my problem the answer was to log off the current connection with a blank ssid and blank password. So that should be part of the disconnect sequence.
Are there any old MUD games online still (text based adventure games). I seem to recall that you needed to telnet to them. But the text that comes back ought to be much easier to parse than, say, html is. So it should be easier to get something going that is vaguely interesting without having to write some sort of html browser.
Am researching arduino telnet client code at the moment. OBC has some interesting posts over on PropellerPowered. Plus his nifty instructable. Need to open port 23 and then put in the IP address of the telnet server. Not sure what to do next though - in html you send GET but not sure what you do to a telnet server.
Am testing with just a terminal program like putty rather than adding in the propeller as it makes things simpler to debug.
This is fun!
We are at the cutting edge here.
Ok, well for my problem the answer was to log off the current connection with a blank ssid and blank password. So that should be part of the disconnect sequence.
Are there any old MUD games online still (text based adventure games). I seem to recall that you needed to telnet to them. But the text that comes back ought to be much easier to parse than, say, html is. So it should be easier to get something going that is vaguely interesting without having to write some sort of html browser.
Am researching arduino telnet client code at the moment. OBC has some interesting posts over on PropellerPowered. Plus his nifty instructable. Need to open port 23 and then put in the IP address of the telnet server. Not sure what to do next though - in html you send GET but not sure what you do to a telnet server.
Am testing with just a terminal program like putty rather than adding in the propeller as it makes things simpler to debug.
This is fun!
Telnet is pretty much just a serial connection over the Internet and the server usually displays a welcome message and then talk to whatever shell or app it's in. You are welcome to connect to Tachyon running on an IoT5500 at tachyonforth.com but use port 10001 for the connection as port 23 is frequently being used by hackbots.
Steep part of the learning curve here and lots of things that didn't work, but I finally got the signon screen for a multi user dungeon.
1) generally the module stays linked to the router. So you can turn it off for a few hours, come back, turn it on and it will be part of the network and it is ready to connect to something.
2) I don't think it remembers the AT+CIPMUX status. So to test this, AT+CIPMUX? and if it comes back with zero, then reset it to AT+CIPMUX=1
3) Closing a connection - AT+CIPCLOSE may or may not work, I'm not sure yet. What is more definite is to use the number that was used in CIPSTART, ie if you use 4, then close it with AT+CIPCLOSE=4. actually I'm still not sure about the whole closing thing yet. more tests to come. Ok, yes, if you want to close a connection AT+CIPCLOSE=4 and it should come back straight away with "unlink". If not, then there is a fault, and ?? better to reset the module, and put in CIPMUX and then CIPSTART again.
4) the login syntax is AT+CIPSTART= then number not in quotes, then "TCP" in quotes, then the ip address or dns in quotes, then the port number not in quotes. IE no quotes, quotes, quotes, no quotes. Mess one up and it gives a syntax error
5) The port number is not necessarily 23 for telnet, nor is it 80 for http.
6) The correct login (this is for my reference mainly!) for the mud is
AT+CIPSTART=4,"TCP","WWW.DARKERREALMS.ORG",2000
7) debugging can be tricky, because sometimes you do have the correct syntax but it comes back with a DNS error. There are arduino programs I have seen where it tries five times to connect.
8) I found it helpful to check a website is alive with PuTTY first. eg for Peter's site above, use Putty in telnet mode, for the address www.tachyonforth.com and port 10001 and it gives a signon message
9) Putty doesn't mind if you leave out the www bit. Am testing if the ESP8266 is ok with this too... Yes, you can leave out the www bit.
10) If the module is going to link to a website, it usually works within a second or so. Google seems to link reliably
AT+CIPSTART=4,"TCP","WWW.GOOGLE.COM",80
11) ok, another working site
AT+CIPSTART=4,"TCP","TACHYONFORTH.COM",10001
next thing to try out, how to build a transparent serial link. The above number 11 comes back with OK after each line and doesn't respond to commands, because if you type DIR,, it thinks the DIR is for the wifi module, not to pass through to tachyonforth This might be a putty setting, or maybe a different signon, or maybe need to write a different terminal handler. More to research here. Presumably if there is a transparent link, somehow you have to break out of that to go back to sending commands. I saw +++ somewhere which might do this. an explanation of the send protocol and the data coming back here http://fightpc.blogspot.com.au/2014/10/first-steps-with-esp8266-wifi-module.html
For a transparent link, a spin program to handle the CIPSEND command in the background, and to strip off the IPD header that comes back.
Steep part of the learning curve here and lots of things that didn't work, but I finally got the signon screen for a multi user dungeon.
1) generally the module stays linked to the router. So you can turn it off for a few hours, come back, turn it on and it will be part of the network and it is ready to connect to something.
2) I don't think it remembers the AT+CIPMUX status. So to test this, AT+CIPMUX? and if it comes back with zero, then reset it to AT+CIPMUX=1
3) Closing a connection - AT+CIPCLOSE may or may not work, I'm not sure yet. What is more definite is to use the number that was used in CIPSTART, ie if you use 4, then close it with AT+CIPCLOSE=4. actually I'm still not sure about the whole closing thing yet. more tests to come. Ok, yes, if you want to close a connection AT+CIPCLOSE=4 and it should come back straight away with "unlink". If not, then there is a fault, and ?? better to reset the module, and put in CIPMUX and then CIPSTART again.
4) the login syntax is AT+CIPSTART= then number not in quotes, then "TCP" in quotes, then the ip address or dns in quotes, then the port number not in quotes. IE no quotes, quotes, quotes, no quotes. Mess one up and it gives a syntax error
5) The port number is not necessarily 23 for telnet, nor is it 80 for http.
6) The correct login (this is for my reference mainly!) for the mud is
AT+CIPSTART=4,"TCP","WWW.DARKERREALMS.ORG",2000
7) debugging can be tricky, because sometimes you do have the correct syntax but it comes back with a DNS error. There are arduino programs I have seen where it tries five times to connect.
8) I found it helpful to check a website is alive with PuTTY first. eg for Peter's site above, use Putty in telnet mode, for the address www.tachyonforth.com and port 10001 and it gives a signon message
9) Putty doesn't mind if you leave out the www bit. Am testing if the ESP8266 is ok with this too... Yes, you can leave out the www bit.
10) If the module is going to link to a website, it usually works within a second or so. Google seems to link reliably
AT+CIPSTART=4,"TCP","WWW.GOOGLE.COM",80
11) ok, another working site
AT+CIPSTART=4,"TCP","TACHYONFORTH.COM",10001
next thing to try out, how to build a transparent serial link. The above number 11 comes back with OK after each line and doesn't respond to commands, because if you type DIR,, it thinks the DIR is for the wifi module, not to pass through to tachyonforth This might be a putty setting, or maybe a different signon, or maybe need to write a different terminal handler. More to research here. Presumably if there is a transparent link, somehow you have to break out of that to go back to sending commands. I saw +++ somewhere which might do this.
Here is a dump of the socket receive buffer if it helps
Leaving out the WWW: This depends on how the website's DNS is configured. A lot of providers default to forwarding www.sitename.com to sitename.com, but it's not always the case; for example, if you're hosted by nearlyfreespeech.net you have to deliberately configure this. Technically anything.sitename.com, including www.sitename.com, can direct to a different page than just plain sitename.com.
Working on ways around fixing a hang. The problem - you were connected to a certain AP and now it has gone, or you have moved your device to a different location, or you typed it in wrong.
Symptoms of the hang (can detect this with software?)
To replicate the problem,
AT+CWJAP="ABC","" which tries to join a non existant access point. This still returns Ok
In this state, you now cannot list access points. How to detect this in software, eg in Spin:
1) AT+CWLAP does not respond within a few seconds, or at all. Need a timer to detect this. Sending a <CR> returns "busy now"
2) AT+CWLIF returns a blank line, ie it does not return an IP address.
3) AT+CWQAP returns error the first time, then a blank line the second time
4) AT+CWJAP? returns a blank line (should return the current access point)
5) power cycling the board does *not* fix this problem.
Experimenting with fixes. One solution is to automatically be able to reset the board, which requires a dedicated propeller pin. The other way is to have a message come up in software to cycle the power at a certain point.
Detecting this state. Can't use AT+CWLAP as this then hangs the board again. One way that I think will work is AT+CWLIF and if this does not return an IP address, then the board hasn't got a connection.
So - on bootup, test the board is alive with
AT
reset it and test for a response with
AT+RST
then test if it is connected with
AT+CWLIF
if there is no valid IP address or CWJAP? returns a blank line (the CWJAP is probably the better one to use)
AT+CWJAP="","" - join a blank access point
message to the user to turn the power on and off
go back to the beginning
if there is a valid IP address
AT+CWLIF list the IP address
AT+CWLAP list the current access points
ask if the user wants to change access points to a new one
if yes, then log off with AT+CWQAP and then they can select one from the list and then join with AT+CWJAP="SSID","PWD"
AT+CWMODE=3
and then option to enter the name of the site to visit and the port number
This is for when it fails. When it has a stable access point and everything is working, the above all works very smoothly.
Hmm, thinking of the "internet of things", how small can a "thing" be - ie is it possible to have a device with no display and no keyboard and to work through all the above fault conditions with, say, just diagnostic leds.
What is the smallest practical display? For instance, it might be possible to do this with a 16x2 LCD and a few pushbuttons - it could list the access points for instance and you could scroll down the list to select the one to connect to. Or... would all that be in a Spin program?
Even without user input (ie it is pre programmed to connect to a certain router), you may still need a display to indicate that the router is not available, or the internet is down.
It's been a while since I have worked on my ESP8266 development. My free time for this project has dried up and I don't feel like I'll make any more progress. I've decided to include my spin files that I've developed so far for the reference of users in this thread. Feel free to take a look and use for your own projects, all that I ask is that any code developed using any part of my code be re-shared to the users of this forum.
Some more experiments - overall conclusion is there are still a huge number of bugs in these modules and I am not sure how reliable they would be in an "internet of things". In order to simplify experiments, I wrote a VB.Net program (attached). This automates many of the commands and greatly simplifies things.
Don't get me wrong - these modules do work. I got it working as a web server and as a simple web browser. The web server is particularly useful and can serve up data both within the local network and also on the internet.
I bought several batches. The original ones are 115200 baud but the new ones start off at 9600 baud. This is one of the first bugs you come to, because the change to 9600 baud is more recent, but only about half the data comes back at 9600 baud - the rest still comes back at 115200 and produces garbage characters. Put the baud rate back to 115200 though, and these garbage characters come through correctly. However, this does present a bit of a challenge when interfacing to arduino and propeller chips, because slower baud rates are safer and less error prone (1 metre of ribbon cable at 115200 will start to produce errors of its own).
What I wanted to do with the vb.net program was try to find out all the error modes. The one mentioned before are all still there and I still haven't really worked out a sequence to get the module out of a hang if it moves to a different router.
When running as a browser/client and logging into Google, it will work repeatedly many times, then will fail repeatedly many times with DNS errors.
When acting as a server, it will work repeatedly many times. The vb.net code just serves up a counter which increments, and you can get to 10 hits and it works fine, then it will stop working and then it is not possible to log in at all. Resetting the module doesn't help.
There was one experiment where resetting the router fixed the problem, but that really is not going to be a practical option.
The frustrating part is that each component of the system *almost* works, but when you put it all together, the whole system only works about half the time. Any software written in Spin/Arduino C is going to have to handle all the fault conditions.
Yes, they are fascinating modules - I don't want to give up yet. So many possibilities when a chip like the Propeller has access to the internet for a price so low. Storage for instance - maybe an SD card is not needed if data can be stored somewhere on the web? A display - not necessarily needed if any computer with a browser can be the display.
What I want to do is try to replicate the fault conditions more reliably so then I can work out ways to get out of a fault. The fault yesterday (which got me a bit frustrated I must confess!) was when I deliberately tried to read a web page via the module using two browsers at the same time. Module still sulking two hours later...
Certainly worth persevering.
Addit: http://www.cse.dmu.ac.uk/~sexton/ESP8266/ very interesting blog by someone who is working on the same problem - repeating things hundreds of times and getting the occasional error. The hardware reset pin might be the answer (plus all the code that recovers from various errors).
BEFORE connecting to a access point, you could check if it is in the list of currently available access points.
Get list of available access points (AT+CWLAP). Iterate list.
Compare ssid with own list of ssid, pwd for known access points. if found log in with AT+CWJAP="SSID","PWD"
if on end of list and still not connected iterate the list again, try to login without PWD, hoping to find open access point?
This would avoid logging into non existing access point - witch obviously hangs the module as by your example "ABC".
4 hours of testing - trying reset, quitting access points, powering down for different amounts of time. Sometimes it works, sometimes not. But I made one simple change and then tried repeatedly to break it but it seems much more reliable now. Added a 4700uF capacitor across the supply pins.
I'll keep testing but I think this might have solved a lot of the intermittent problems.
Working on a startup sequence now that seems reliable - reset, wait 2s, cwmode 3, wait 2s, cwjap join access point, wait 10s, list ip address, wait 2s, cipmux=1, wait 2s, run as a server and wait for connections.
Sorry if this is gibberish!
There are complex ways of looking for the text coming back to check each step works, but I think it might be simpler to consider the startup routine as a package, and it either works or doesn't, and if not, then start again. That makes the coding much simpler - just a few lines of Spin rather than parsing lots of strings.
For a client, the definition of working is being able to get a response from a website that is likely to stay around long term, eg www.google.com. For a server, it is a bit more complex as there might not be any clients connecting for some time, but maybe every now and then it can change from a server to a client and ping google, just to check the internet is still live.
Hopefully I can simplify all the complex commands down to something that doesn't need a display - maybe just a led that says "internet is live", and then another led that is "receiving a hit" as a server, or "requesting data" as a client.
Overall, lots of very positive progress this evening.
Addit: This is the vb.net code to ping google and test the internet is on. Takes about 5 seconds. (still writing in vb.net, easier to debug all the different fault conditions)
Dim destHost As String = "www.google.com"
Dim destPage As String = "/" ' or the actual page on that website
Dim destPort As String = "80"
Dim httpReq As String
MsgBox("Hardware reset here, or cycle power") ' and add a delay maybe 1 sec for signon message
SendString("AT" + vbCrLf) ' is the module alive?
DelayOK(3000) ' wait for ok or delay, whichever is first
SendString("AT+CWMODE=3" + vbCrLf) ' mode 3, doesn't return OK, returns "no change", usually remembers this from before
DelayOK(3000)
' join access point (though does usually remember this even after power down but not always)
SendString("AT+CWJAP=" + Chr(34) + TextBox2.Text + Chr(34) + "," + Chr(34) + TextBox3.Text + Chr(34) + vbCrLf)
DelayOK(10000) ' usually about 4 secs, returns OK
SendString("AT+CIPMUX=1" + vbCrLf) ' one connection
DelayOK(3000) ' returns OK
SendString("AT+CIPSTART=0," + Chr(34) + "TCP" + Chr(34) + "," + Chr(34) + destHost + Chr(34) + "," + destPort + vbCrLf)
DelayOK(10000)
httpReq = "GET " + destPage + " HTTP/1.1" + vbCrLf + "Host: " + destHost + ":" + destPort + vbCrLf ' + "Connection: close" + vbCrLf ' or close from this end with the close command
Send(httpReq) ' sends a line of text
DelayOK(10000)
SendString("AT+CIPCLOSE=0" + vbCrLf) ' close the link
DelayOK(5000)
I hope this is ok to post Ard**** code here - I'm starting easy and working up, first debugging this in VB.Net, then in Arduino C and I'll get to Spin...
This is a little demo that uses an arduino and turns on a Led if the internet is available (Google). There are times in code when you just want a simple Yes/No answer. If it is working, then other code can use this information to run a server or client. This code has been running for a long time now and seems robust.
Three secrets to getting it working:
1) test it in vb.net first, as there are bugs like command success is "OK", except when it is something else.
2) Add a 4700uF across the 3V supply
3) Toggle the reset pin - the software reset doesn't truly reset everything.
I need to get this working in Spin, because Arduino can't handle the number of bytes coming back when reading a website due to buffer overrun.
/*
ESP8266 module - run from arduino 3V3 supply but needs a 4700uF capacitor on the 3V line
CH_PD pulled high
newer ESP8266 modules boot at 9600 but can be reprogrammed back to 115200
reset pin to arduino pin 12 so can do hardware resets
echo data to arduino terminal
The circuit:
* RX is digital pin 10 (connect to TX of other device)
* TX is digital pin 11 (connect to RX of other device)
*/
#include <SoftwareSerial.h>
#define SSID "Oslo_Cabin" // insert your SSID
#define PASS "" // insert your password (blank if no password)
#define destHost "www.google.com"
#define destPage "/"
#define destPort "80"
SoftwareSerial espSerial(10, 11); // RX, TX
void setup()
{
// Open serial communications and wait for port to open:
Serial.begin(115200); // for debugging
while (!Serial) {
; // wait for serial port to connect.
}
Serial.println("Starting Arduino");
espSerial.begin(9600);
pinMode(13, OUTPUT); // diagnostic led
pinMode(12, OUTPUT); // ESP8266 reset pin
}
void loop()
{
digitalWrite(13,LOW); //led off
testInternet(); // led on if the internet is working, ie reply from google
delay(10000);
}
void testInternet()
{
resetESP8266(); // gets out of any hangs, eg if two browsers try to read at the same time
flashLed();
commandAT();
commandCWMODE();
flashLed();
connectWiFi();
//displayIPaddress(); // useful for debugging and working out what address this has been assigned
flashLed();
commandCIPMUX();
flashLed();
commandGOOGLE();
}
void resetESP8266()
{
int i;
Serial.println("Hardware reset ESP8266");
digitalWrite(12,LOW);
delay(200);
digitalWrite(12,HIGH);
for(i=0;i<1000;i++) // echo the startup message
{
if (espSerial.available())
Serial.write(espSerial.read());
delay(1);
}
}
void commandAT()
{
espSerial.println("AT");
if(delayOK())
Serial.println("AT OK");
}
void commandCWMODE()
{
espSerial.println("AT+CWMODE=3");
delay(200); // replies with "no change" not OK so need custom code here
if(espSerial.find("no change")) {
Serial.println("CWMODE OK");
}else{
Serial.println("Error CWMODE"); // the very first time the module runs this, will return an error, but remembers this forever in eeprom
}
}
boolean delayOK() // times out after 10 seconds or if no OK. Sometimes takes 4 to 5 serial.find loops ie 4-5 seconds to respond
{
int i = 0;
boolean abort = false;
serialFlush(); // remove any leftover things
do
{
if(espSerial.find("OK"))
abort = true; // will abort the loop
i+=1;
}
while ((abort == false) && (i<10));
}
void serialFlush(){
while(Serial.available() > 0) {
char t = Serial.read();
}
}
boolean connectWiFi()
{
String cmd="AT+CWJAP=\"";
cmd+=SSID;
cmd+="\",\"";
cmd+=PASS;
cmd+="\"";
Serial.println(cmd);
espSerial.println(cmd);
if(delayOK()){
Serial.println("OK, Connected to WiFi");
return true;
}else{
Serial.println("Cannot connect to the WiFi");
return false;
}
}
void displayIPaddress() // a useful way to check actually connected
{
espSerial.println("AT+CIFSR");
echoReply();
}
void echoReply()
{
int i;
for(i=0;i<3000;i++) // echo the reply
{
while (espSerial.available())
{
Serial.write(espSerial.read());
}
delay(1);
}
}
void commandCIPMUX()
{
espSerial.println("AT+CIPMUX=1");
if(delayOK())
Serial.println("CIPMUX OK");
}
void commandGOOGLE() // connect to google to test internet connectivity
{
String httpReq;
String cmd = "AT+CIPSTART=0,\"TCP\",\"";
cmd += destHost;
cmd += "\",80";
espSerial.println(cmd);
Serial.println(cmd);
if(delayOK())
Serial.println("CIPSTART OK");
espSerial.find("Linked");
httpReq = "GET ";
httpReq += destPage;
httpReq += " HTTP/1.1\r\n";
httpReq += "Host: ";
httpReq += destHost;
httpReq += ":";
httpReq += destPort;
httpReq += "\r\n\r\n";
commandSend(httpReq); // send the GET command to get the web page
//echoReply(); // display what comes back - this does seem to overrun the buffer, not sure why as works at 9600 into vb.net
// or light a led if got a correct website
if(espSerial.find("Found"))
{
digitalWrite(13,HIGH); // led on, found a website
Serial.println("Reply from GOOGLE");
}
espSerial.println("AT+CIPCLOSE=0"); // close the connection from this end
delayOK();
}
void commandSend(String LineOfText) // set up command to send a string
{
String cmd = "AT+CIPSEND=0,";
cmd += LineOfText.length();
espSerial.println(cmd);
espSerial.find(">"); // wait for the command prompt to come back
espSerial.print(LineOfText); // NOT println, just print as character numbers have to be exactly the same as CIPSEND number
}
void flashLed()
{
digitalWrite(13,HIGH);
delay(50);
digitalWrite(13,LOW);
}
I hope this is ok to post Ard**** code here - I'm starting easy and working up, first debugging this in VB.Net, then in Arduino C and I'll get to Spin...
This is a little demo that uses an arduino and turns on a Led if the internet is available (Google). There are times in code when you just want a simple Yes/No answer. If it is working, then other code can use this information to run a server or client. This code has been running for a long time now and seems robust.
Three secrets to getting it working:
1) test it in vb.net first, as there are bugs like command success is "OK", except when it is something else.
2) Add a 4700uF across the 3V supply
3) Toggle the reset pin - the software reset doesn't truly reset everything.
I need to get this working in Spin, because Arduino can't handle the number of bytes coming back when reading a website due to buffer overrun.
I haven't had a chance to play with these modules yet but based on your "secrets" I will give this a go in Tachyon to see what I can achieve and post the results. I doubt however that anyone would need a 4700uF cap to make it work, I'm guessing your regulator and type of decoupling has a lot to do with it. The typical maximum current is around 215ma but it may peak more than that so the regulator and decouplers need to be right otherwise the glitches will glitch the chip. I will post my findings when I get a chance, perhaps in the next day or two. I was intending to roll my own modules as chip itself is quite cheap even in "sample" volumes (hundreds). Prototype volume is more like thousands.... cough cough.
Thanks Peter, I look forward to your experiments.
4700uF is probably too high. I guess it is simple maths 1farad =1V/s with 1A. And these draw something like 200-300mA at peak draw, but the unknown is for how long.
I have my suspicions that one of the frustrating parts about getting these working is that when the module is trying to connect to a now non-existant access point, it is constantly transmitting and drooping the supply. So it latches up into this mode and you can't get out of it, but when it has a clean reboot it maybe sends one short 'can I join' message which doesn't take much power.
There are repeated comments on other forums replying to all the problems with "you need to re-flash the module". I don't believe this to be correct - I think these modules work fine, but they latch up in different ways. Sure, reflashing does fix the problem, but it is a fake fix, and it will latch up again next time two browsers try to connect at the same time.
I also suspect these are built to a price and size, and the capacitor I have across the supply is bigger than the actual module, so there would be an incentive to leave that out. Or maybe they debug it using a nice laboratory standard supply.
I'm excited by the possibilities.
Just reading some more information tonight - I think it might not be necessary to reset the module to prove the internet is available. Instead, ping google regularly using client code, and if that happens to fail, then do a complete reboot (pinging google is maybe half a second, a complete reboot is about 10 seconds). I think you can have several ports open, so it could be set up as a server on one port, and on a second port could be set up as a client to do the 'is the internet still on' tests.
Also some new commands - the IoT is going to need fixed IP addresses (can't have the washing machine and dryer swapping roles when the router reboots!), and there is a new command that I think came out in December, AT+CIPSTA= which fixes the IP address. I haven't tried it yet.
All good fun. Hopefully some others will chime in soon
This power supply thing reminds me of the GSM modules.
The average current drain is very low, but peak current is extremely high, and many strange behaviours are related to this issue.
The GSM module work perfectly with Lithium battery voltages, so this is a possible workaround. What is the voltage supply limit of the ESP8266?
Thanks Peter, I look forward to your experiments.
4700uF is probably too high. I guess it is simple maths 1farad =1V/s with 1A. And these draw something like 200-300mA at peak draw, but the unknown is for how long.
I have my suspicions that one of the frustrating parts about getting these working is that when the module is trying to connect to a now non-existant access point, it is constantly transmitting and drooping the supply. So it latches up into this mode and you can't get out of it, but when it has a clean reboot it maybe sends one short 'can I join' message which doesn't take much power.
There are repeated comments on other forums replying to all the problems with "you need to re-flash the module". I don't believe this to be correct - I think these modules work fine, but they latch up in different ways. Sure, reflashing does fix the problem, but it is a fake fix, and it will latch up again next time two browsers try to connect at the same time.
I also suspect these are built to a price and size, and the capacitor I have across the supply is bigger than the actual module, so there would be an incentive to leave that out. Or maybe they debug it using a nice laboratory standard supply.
I'm excited by the possibilities.
Just reading some more information tonight - I think it might not be necessary to reset the module to prove the internet is available. Instead, ping google regularly using client code, and if that happens to fail, then do a complete reboot (pinging google is maybe half a second, a complete reboot is about 10 seconds). I think you can have several ports open, so it could be set up as a server on one port, and on a second port could be set up as a client to do the 'is the internet still on' tests.
Also some new commands - the IoT is going to need fixed IP addresses (can't have the washing machine and dryer swapping roles when the router reboots!), and there is a new command that I think came out in December, AT+CIPSTA= which fixes the IP address. I haven't tried it yet.
All good fun. Hopefully some others will chime in soon
The thing is to make sure the regulator itself is up to the task and of course that the input supply doesn't droop so low that the regulator can't do it's job. If a big cap were to go anywhere it should be on the input side of the regulator, not on the output, and let the regulator do what it does best. I will confirm the exact requirements when I test these modules out and lay this "big cap" thing to rest.
I ordered four of these modules which arrived today.
So I looked through the posts to find documentation.
This page was helpful as it shows the pinout of the DIP 2x4 header of the whole module http://zeflo.com/2014/esp8266-weather-display/
See also attached picture.
How about creating a basic pinout of the wifi-module inside the spincode with the special characters of the parallax-font?
and some tips about what the CH_PD-pin is doing.
This power supply thing reminds me of the GSM modules.
The average current drain is very low, but peak current is extremely high, and many strange behaviours are related to this issue.
The GSM module work perfectly with Lithium battery voltages, so this is a possible workaround. What is the voltage supply limit of the ESP8266?
Massimo
I was going to say exactly the same thing Massimo. Those Telit modules always benefitted from a decent cap or two. Telit's own eval EVK2 board had a couple of huge electro caps from memory.
It'd be great if a couple of big caps sorted those strange issues.
During the week picked up one of these nice breakouts from tronixlabs. Its not that clear in the photo but the back thing in the background is a 3 AA battery holder
and some tips about what the CH_PD-pin is doing. Good question. ok,
Pinout:
Gnd to Gnd
3V to 3V
Tx to Rx on the propeller or arduino
Rx to Tx on the propeller or arduino
Reset to a pin on the propeller or arduino
CH_PD to 3V
GPIO_0 not connected
GPIO_2 not connected
So it is really just 3 pins; tx, rx, reset. Talks at 9600 baud which is a simple serial object in the obex library. You just send it commands and it responds - eg connect to a wifi hotspot, or give me all the html text on the google home page.
Re the capacitor, there are some schematics out there with 470uF and some with 1000uF. I just used 4700uF 10V because I picked up a job lot of 50 on ebay recently for a good price, and they are going to be my standard supply input capacitor.
But maybe can be a bit more scientific about this - 1 farad will drop 1V per second supplying 1 amp. So 300mA will be 300mV per second. 4700uF is 1/200th of a farad, which I think is 60,000mV per second, or 60mV per millisecond. So if a data packet is 1 millisecond, it wouldn't matter. If it was 10ms, it would drop 0.6V and if it was 100ms that is 6V. Not with a good regulator though - I'm assuming a terrible regulator that is undersized for the job (eg 100mA max), or perhaps (as in my case) a switchmode module that only has 100uF. The arduino board only has 47uF capacitors, and if powered via USB might also struggle. So a big capacitor covers lots of different situations.
I suspect the 4700uF capacitor is over-engineering things, but hey, it only cost me 28c.
Another intriguing thing which won't apply to the propeller but worth mentioning anyway, is 5V to 3V level translation. For an arduino running at 5V there are sites talking about level translation. I tried a 10k/22k voltage divider and it works fine on the reset line, but the Tx data didn't go through. Yet it works fine with 5V. There is some comment on the datasheet about the chip being tolerant to 6V. I did some tests with 100R resistors and measuring the current flow and got something like 100uA, so I think these modules are 5V tolerant.
I have one routine running now that just requests the google site regularly. Takes maybe 1/4 of a second. If that works, fine, if not, then do a complete reset. I'm getting a feel for the reliability of that connection - you can get 10 or 20 requests that work, then a bad patch where it only works a few times in a row. My setup has two wireless repeaters so opportunities for packets to go astray, plus 3 teenagers who are chatting via skype to their friends. My broadband connection gets a good workout! But I guess that is the real world - this is a pretty good connection, but not 100% reliable, and it is a matter of working with that.
A note regarding translating arduino C to spin - there is a function called Serial.find which looks for a specific string of text. It is very useful for parsing large text files like a website. The important thing is that it times out after 1 second, and if this is replicated in Spin, would need to keep that time constant, as there are quite a few times where things take a bit more than a second, so you might call serial.find three or four times in a row to allow for slower website loading. Essentially, there needs to be a spin routine that looks for strings of text and times out after a certain period - maybe a routine where you pass it both a string and a millisecond value.
so I tried the several SPIN-codes uploaded to this thread with zero success.
No respond at all from the ESP8266.
Which baud_rate do I have to use with the ESP-module 9600 or 115200 ? does this depend on the logic level of the CH_PD-Input?
Can anybody post the most simple SPIN-code to get the most easiest answer from the module?
I would like to narrwo down if its a hardware or a software-problem I have.
If I connect the module to power the small blue led makes two short flashes then the red led is permanent on
Is this OK so far?
the smaple-code should include really clear info what the pin-assignemend of rx-tx means
ESP8266-RX/Tx or Prop-TX/Rx which is opposite
Comments
This seems to be fairly robust and is probably the killer app for the ESP8266; it still resets once in awhile but it doesn't matter because it quickly recovers and doesn't lose the wifi connection. This code deals with the "human" interface waiting for all responses with timeouts, which seems to keep the resetting down to a dull roar.
I see you are annoyed with the echo responses from the ESP8266, as I was. I found that in order to speed up the communication process it was best to turn off that functionality. The command to do that is "ATE0". Why it's not the same format as any of the other commands, I have no idea. Also, this is not a saved setting, so you must run it each time the device starts up.
Thanks,
Marcus
I bought a few more modules - price has come down, now only $3.99. I only had one module to test but I have this idea of setting one up as a server, and several as clients, and getting them chatting to each other. Even if the "webpage" is just one line of text eg "Temp = x" , that is still very useful. Visions of swarms of little robots/quadcopters exchanging their GPS positions and flocking in order to take over the humans...
I did a writeup of the process on my website: http://taylorcoffelt.com/article/1
I have to wirte in this thread because i am a newibie and the my account keeps telling me to post on thread. But this may be very interesting for me in future because i want to design low cost home automation systems
thanks
Terminal program is Putty, and baud rate is 115200 as this module is an older version (newer ones are 9600 baud?)
So - AT+RST and it resets
AT+CWMODE=3
AT+CWLAP and it lists access points around my house.
Then I tried to connect, and I think this is where I have gone wrong, because all the commands this module likes need to be in capitals, so I had the caps lock on and when I typed
AT+CWJAP="SSID","password"
I typed the SSID in capitals, but the actual SSID of that router is a mix of upper and lower case.
Now the CWLAP command won't work. This is discussed more on this website http://www.esp8266.com/viewtopic.php?f=6&t=571
and the problem is that this module remembers the router it connected to in eeprom even after a reset. Further, it is not entirely clear whether it can be disconnected again. I think it has been set up so it keeps trying to reconnect a broken link so once it has been told about an access point, it really wants to stay friends with that access point
Try
AT+CWQAP
which is the quit command, and it responds, in rather charming Chinglish
"no, this fun"
The second try of this command came back with OK, but it is not entirely clear if it really did disconnect.
In any case, there are are a few blogs out there talking about how the CWAP command won't work if it is not connected. It hangs, or says it is busy, or returns an error.
Another test is CWJAP with "","" so that is a blank SSID and password but that doesn't seem to help either.
I suspect they have quite a few bugs which they are ironing out as we go.
So the next step is probably to update the firmware. I'm following the thread a couple above by ProcessingData. I'm on the steep part of the learning curve with Python, so what do I do with esptool.py? The link brings up the code in the web browser - do I need to save this somewhere?
And the link to the new firmware (electrodragon) appears to be broken now.
Any help with the firmware update process would be most appreciated.
Once that is working, I want to experiment more with not just how these modules work, but more importantly, how they fail. It seems that there need to be some delays between commands, and judging by the responses to manual commands, probably a certain number of retries with each command as well.
Addit:
AT+CWJAP="","" does work, but only after you then cycle the power.
So now once the access point has been totally reset
AT+CWLAP
is working again.
So now I have an IP address assigned to the module and I can ping it.
I think so far, any interface with the propeller is going to need the ability to power cycle the module.
More testing, can point the browser at this IP address - lots of text appears on the module terminal screen.
And also, power cycling the module and it is remembering the IP address and automatically reconnecting after only a couple of seconds.
One of the problems found is that you need to get a connection first before doing other things as the SSID and Password is written away to the eeprom. It would be worth following or asking on the ESP8266 forum.
I have an ESP-01 with the extra 2 GPIO connections. I ordered an ESP-03 a few days ago as this brings out more GPIOs.
Meanwhile I am waiting for a pcb design I sent off last w/e that uses a PropPlug connections both ends to permit insertion in between the PropPlug and Prop. I use my PropPlug version that taps the 5V from the USB, and my dev board adds a 3V3 regulator for the ESP8266. Its designed for the ESP-01 because I sent it off before I decided to order the ESP-03.
It seems some have put a larger cap (470uF-1000uF) on the power supply and that stops the ESP from resetting at random. This is way too high for putting on the USB bus for power so perhaps a 47uF tantalum or maybe 100uF electrolytic. Remember tho that USB recommends 10uF max.
The article has some good links and summary of the AT commands.
We are at the cutting edge here.
Ok, well for my problem the answer was to log off the current connection with a blank ssid and blank password. So that should be part of the disconnect sequence.
Are there any old MUD games online still (text based adventure games). I seem to recall that you needed to telnet to them. But the text that comes back ought to be much easier to parse than, say, html is. So it should be easier to get something going that is vaguely interesting without having to write some sort of html browser.
Am researching arduino telnet client code at the moment. OBC has some interesting posts over on PropellerPowered. Plus his nifty instructable. Need to open port 23 and then put in the IP address of the telnet server. Not sure what to do next though - in html you send GET but not sure what you do to a telnet server.
Am testing with just a terminal program like putty rather than adding in the propeller as it makes things simpler to debug.
This is fun!
Telnet is pretty much just a serial connection over the Internet and the server usually displays a welcome message and then talk to whatever shell or app it's in. You are welcome to connect to Tachyon running on an IoT5500 at tachyonforth.com but use port 10001 for the connection as port 23 is frequently being used by hackbots.
1) generally the module stays linked to the router. So you can turn it off for a few hours, come back, turn it on and it will be part of the network and it is ready to connect to something.
2) I don't think it remembers the AT+CIPMUX status. So to test this, AT+CIPMUX? and if it comes back with zero, then reset it to AT+CIPMUX=1
3) Closing a connection - AT+CIPCLOSE may or may not work, I'm not sure yet. What is more definite is to use the number that was used in CIPSTART, ie if you use 4, then close it with AT+CIPCLOSE=4. actually I'm still not sure about the whole closing thing yet. more tests to come. Ok, yes, if you want to close a connection AT+CIPCLOSE=4 and it should come back straight away with "unlink". If not, then there is a fault, and ?? better to reset the module, and put in CIPMUX and then CIPSTART again.
4) the login syntax is AT+CIPSTART= then number not in quotes, then "TCP" in quotes, then the ip address or dns in quotes, then the port number not in quotes. IE no quotes, quotes, quotes, no quotes. Mess one up and it gives a syntax error
5) The port number is not necessarily 23 for telnet, nor is it 80 for http.
6) The correct login (this is for my reference mainly!) for the mud is
AT+CIPSTART=4,"TCP","WWW.DARKERREALMS.ORG",2000
7) debugging can be tricky, because sometimes you do have the correct syntax but it comes back with a DNS error. There are arduino programs I have seen where it tries five times to connect.
8) I found it helpful to check a website is alive with PuTTY first. eg for Peter's site above, use Putty in telnet mode, for the address www.tachyonforth.com and port 10001 and it gives a signon message
9) Putty doesn't mind if you leave out the www bit. Am testing if the ESP8266 is ok with this too... Yes, you can leave out the www bit.
10) If the module is going to link to a website, it usually works within a second or so. Google seems to link reliably
AT+CIPSTART=4,"TCP","WWW.GOOGLE.COM",80
11) ok, another working site
AT+CIPSTART=4,"TCP","TACHYONFORTH.COM",10001
next thing to try out, how to build a transparent serial link. The above number 11 comes back with OK after each line and doesn't respond to commands, because if you type DIR,, it thinks the DIR is for the wifi module, not to pass through to tachyonforth This might be a putty setting, or maybe a different signon, or maybe need to write a different terminal handler. More to research here. Presumably if there is a transparent link, somehow you have to break out of that to go back to sending commands. I saw +++ somewhere which might do this. an explanation of the send protocol and the data coming back here http://fightpc.blogspot.com.au/2014/10/first-steps-with-esp8266-wifi-module.html
For a transparent link, a spin program to handle the CIPSEND command in the background, and to strip off the IPD header that comes back.
Here is a dump of the socket receive buffer if it helps
and here is the terminal capture for a quick session I just did:
Working on ways around fixing a hang. The problem - you were connected to a certain AP and now it has gone, or you have moved your device to a different location, or you typed it in wrong.
Symptoms of the hang (can detect this with software?)
To replicate the problem,
AT+CWJAP="ABC","" which tries to join a non existant access point. This still returns Ok
In this state, you now cannot list access points. How to detect this in software, eg in Spin:
1) AT+CWLAP does not respond within a few seconds, or at all. Need a timer to detect this. Sending a <CR> returns "busy now"
2) AT+CWLIF returns a blank line, ie it does not return an IP address.
3) AT+CWQAP returns error the first time, then a blank line the second time
4) AT+CWJAP? returns a blank line (should return the current access point)
5) power cycling the board does *not* fix this problem.
Experimenting with fixes. One solution is to automatically be able to reset the board, which requires a dedicated propeller pin. The other way is to have a message come up in software to cycle the power at a certain point.
Detecting this state. Can't use AT+CWLAP as this then hangs the board again. One way that I think will work is AT+CWLIF and if this does not return an IP address, then the board hasn't got a connection.
So - on bootup, test the board is alive with
AT
reset it and test for a response with
AT+RST
then test if it is connected with
AT+CWLIF
if there is no valid IP address or CWJAP? returns a blank line (the CWJAP is probably the better one to use)
AT+CWJAP="","" - join a blank access point
message to the user to turn the power on and off
go back to the beginning
if there is a valid IP address
AT+CWLIF list the IP address
AT+CWLAP list the current access points
ask if the user wants to change access points to a new one
if yes, then log off with AT+CWQAP and then they can select one from the list and then join with AT+CWJAP="SSID","PWD"
AT+CWMODE=3
and then option to enter the name of the site to visit and the port number
This is for when it fails. When it has a stable access point and everything is working, the above all works very smoothly.
Hmm, thinking of the "internet of things", how small can a "thing" be - ie is it possible to have a device with no display and no keyboard and to work through all the above fault conditions with, say, just diagnostic leds.
What is the smallest practical display? For instance, it might be possible to do this with a 16x2 LCD and a few pushbuttons - it could list the access points for instance and you could scroll down the list to select the one to connect to. Or... would all that be in a Spin program?
Even without user input (ie it is pre programmed to connect to a certain router), you may still need a display to indicate that the router is not available, or the internet is down.
Thanks,
Marcus
ESP8266 Test 10.10.14 - Archive [Date 2014.12.10 Time 17.24].zip
Don't get me wrong - these modules do work. I got it working as a web server and as a simple web browser. The web server is particularly useful and can serve up data both within the local network and also on the internet.
I bought several batches. The original ones are 115200 baud but the new ones start off at 9600 baud. This is one of the first bugs you come to, because the change to 9600 baud is more recent, but only about half the data comes back at 9600 baud - the rest still comes back at 115200 and produces garbage characters. Put the baud rate back to 115200 though, and these garbage characters come through correctly. However, this does present a bit of a challenge when interfacing to arduino and propeller chips, because slower baud rates are safer and less error prone (1 metre of ribbon cable at 115200 will start to produce errors of its own).
What I wanted to do with the vb.net program was try to find out all the error modes. The one mentioned before are all still there and I still haven't really worked out a sequence to get the module out of a hang if it moves to a different router.
When running as a browser/client and logging into Google, it will work repeatedly many times, then will fail repeatedly many times with DNS errors.
When acting as a server, it will work repeatedly many times. The vb.net code just serves up a counter which increments, and you can get to 10 hits and it works fine, then it will stop working and then it is not possible to log in at all. Resetting the module doesn't help.
There was one experiment where resetting the router fixed the problem, but that really is not going to be a practical option.
The frustrating part is that each component of the system *almost* works, but when you put it all together, the whole system only works about half the time. Any software written in Spin/Arduino C is going to have to handle all the fault conditions.
Would there be benefit in having two FDS's with the same receive pin, one at 9600 and one at 115200 to decode the variable bitstream?
What I want to do is try to replicate the fault conditions more reliably so then I can work out ways to get out of a fault. The fault yesterday (which got me a bit frustrated I must confess!) was when I deliberately tried to read a web page via the module using two browsers at the same time. Module still sulking two hours later...
Certainly worth persevering.
Addit: http://www.cse.dmu.ac.uk/~sexton/ESP8266/ very interesting blog by someone who is working on the same problem - repeating things hundreds of times and getting the occasional error. The hardware reset pin might be the answer (plus all the code that recovers from various errors).
BEFORE connecting to a access point, you could check if it is in the list of currently available access points.
Get list of available access points (AT+CWLAP). Iterate list.
Compare ssid with own list of ssid, pwd for known access points. if found log in with AT+CWJAP="SSID","PWD"
if on end of list and still not connected iterate the list again, try to login without PWD, hoping to find open access point?
This would avoid logging into non existing access point - witch obviously hangs the module as by your example "ABC".
Enjoy!
Mike
I'll keep testing but I think this might have solved a lot of the intermittent problems.
Working on a startup sequence now that seems reliable - reset, wait 2s, cwmode 3, wait 2s, cwjap join access point, wait 10s, list ip address, wait 2s, cipmux=1, wait 2s, run as a server and wait for connections.
Sorry if this is gibberish!
There are complex ways of looking for the text coming back to check each step works, but I think it might be simpler to consider the startup routine as a package, and it either works or doesn't, and if not, then start again. That makes the coding much simpler - just a few lines of Spin rather than parsing lots of strings.
For a client, the definition of working is being able to get a response from a website that is likely to stay around long term, eg www.google.com. For a server, it is a bit more complex as there might not be any clients connecting for some time, but maybe every now and then it can change from a server to a client and ping google, just to check the internet is still live.
Hopefully I can simplify all the complex commands down to something that doesn't need a display - maybe just a led that says "internet is live", and then another led that is "receiving a hit" as a server, or "requesting data" as a client.
Overall, lots of very positive progress this evening.
Addit: This is the vb.net code to ping google and test the internet is on. Takes about 5 seconds. (still writing in vb.net, easier to debug all the different fault conditions)
I hope this is ok to post Ard**** code here - I'm starting easy and working up, first debugging this in VB.Net, then in Arduino C and I'll get to Spin...
This is a little demo that uses an arduino and turns on a Led if the internet is available (Google). There are times in code when you just want a simple Yes/No answer. If it is working, then other code can use this information to run a server or client. This code has been running for a long time now and seems robust.
Three secrets to getting it working:
1) test it in vb.net first, as there are bugs like command success is "OK", except when it is something else.
2) Add a 4700uF across the 3V supply
3) Toggle the reset pin - the software reset doesn't truly reset everything.
I need to get this working in Spin, because Arduino can't handle the number of bytes coming back when reading a website due to buffer overrun.
I haven't had a chance to play with these modules yet but based on your "secrets" I will give this a go in Tachyon to see what I can achieve and post the results. I doubt however that anyone would need a 4700uF cap to make it work, I'm guessing your regulator and type of decoupling has a lot to do with it. The typical maximum current is around 215ma but it may peak more than that so the regulator and decouplers need to be right otherwise the glitches will glitch the chip. I will post my findings when I get a chance, perhaps in the next day or two. I was intending to roll my own modules as chip itself is quite cheap even in "sample" volumes (hundreds). Prototype volume is more like thousands.... cough cough.
4700uF is probably too high. I guess it is simple maths 1farad =1V/s with 1A. And these draw something like 200-300mA at peak draw, but the unknown is for how long.
I have my suspicions that one of the frustrating parts about getting these working is that when the module is trying to connect to a now non-existant access point, it is constantly transmitting and drooping the supply. So it latches up into this mode and you can't get out of it, but when it has a clean reboot it maybe sends one short 'can I join' message which doesn't take much power.
There are repeated comments on other forums replying to all the problems with "you need to re-flash the module". I don't believe this to be correct - I think these modules work fine, but they latch up in different ways. Sure, reflashing does fix the problem, but it is a fake fix, and it will latch up again next time two browsers try to connect at the same time.
I also suspect these are built to a price and size, and the capacitor I have across the supply is bigger than the actual module, so there would be an incentive to leave that out. Or maybe they debug it using a nice laboratory standard supply.
I'm excited by the possibilities.
Just reading some more information tonight - I think it might not be necessary to reset the module to prove the internet is available. Instead, ping google regularly using client code, and if that happens to fail, then do a complete reboot (pinging google is maybe half a second, a complete reboot is about 10 seconds). I think you can have several ports open, so it could be set up as a server on one port, and on a second port could be set up as a client to do the 'is the internet still on' tests.
Also some new commands - the IoT is going to need fixed IP addresses (can't have the washing machine and dryer swapping roles when the router reboots!), and there is a new command that I think came out in December, AT+CIPSTA= which fixes the IP address. I haven't tried it yet.
All good fun. Hopefully some others will chime in soon
The average current drain is very low, but peak current is extremely high, and many strange behaviours are related to this issue.
The GSM module work perfectly with Lithium battery voltages, so this is a possible workaround. What is the voltage supply limit of the ESP8266?
Massimo
The thing is to make sure the regulator itself is up to the task and of course that the input supply doesn't droop so low that the regulator can't do it's job. If a big cap were to go anywhere it should be on the input side of the regulator, not on the output, and let the regulator do what it does best. I will confirm the exact requirements when I test these modules out and lay this "big cap" thing to rest.
I ordered four of these modules which arrived today.
So I looked through the posts to find documentation.
This page was helpful as it shows the pinout of the DIP 2x4 header of the whole module http://zeflo.com/2014/esp8266-weather-display/
See also attached picture.
How about creating a basic pinout of the wifi-module inside the spincode with the special characters of the parallax-font?
and some tips about what the CH_PD-pin is doing.
best regards
Stefan
I was going to say exactly the same thing Massimo. Those Telit modules always benefitted from a decent cap or two. Telit's own eval EVK2 board had a couple of huge electro caps from memory.
It'd be great if a couple of big caps sorted those strange issues.
During the week picked up one of these nice breakouts from tronixlabs. Its not that clear in the photo but the back thing in the background is a 3 AA battery holder
Pinout:
Gnd to Gnd
3V to 3V
Tx to Rx on the propeller or arduino
Rx to Tx on the propeller or arduino
Reset to a pin on the propeller or arduino
CH_PD to 3V
GPIO_0 not connected
GPIO_2 not connected
So it is really just 3 pins; tx, rx, reset. Talks at 9600 baud which is a simple serial object in the obex library. You just send it commands and it responds - eg connect to a wifi hotspot, or give me all the html text on the google home page.
Re the capacitor, there are some schematics out there with 470uF and some with 1000uF. I just used 4700uF 10V because I picked up a job lot of 50 on ebay recently for a good price, and they are going to be my standard supply input capacitor.
But maybe can be a bit more scientific about this - 1 farad will drop 1V per second supplying 1 amp. So 300mA will be 300mV per second. 4700uF is 1/200th of a farad, which I think is 60,000mV per second, or 60mV per millisecond. So if a data packet is 1 millisecond, it wouldn't matter. If it was 10ms, it would drop 0.6V and if it was 100ms that is 6V. Not with a good regulator though - I'm assuming a terrible regulator that is undersized for the job (eg 100mA max), or perhaps (as in my case) a switchmode module that only has 100uF. The arduino board only has 47uF capacitors, and if powered via USB might also struggle. So a big capacitor covers lots of different situations.
I suspect the 4700uF capacitor is over-engineering things, but hey, it only cost me 28c.
Another intriguing thing which won't apply to the propeller but worth mentioning anyway, is 5V to 3V level translation. For an arduino running at 5V there are sites talking about level translation. I tried a 10k/22k voltage divider and it works fine on the reset line, but the Tx data didn't go through. Yet it works fine with 5V. There is some comment on the datasheet about the chip being tolerant to 6V. I did some tests with 100R resistors and measuring the current flow and got something like 100uA, so I think these modules are 5V tolerant.
I have one routine running now that just requests the google site regularly. Takes maybe 1/4 of a second. If that works, fine, if not, then do a complete reset. I'm getting a feel for the reliability of that connection - you can get 10 or 20 requests that work, then a bad patch where it only works a few times in a row. My setup has two wireless repeaters so opportunities for packets to go astray, plus 3 teenagers who are chatting via skype to their friends. My broadband connection gets a good workout! But I guess that is the real world - this is a pretty good connection, but not 100% reliable, and it is a matter of working with that.
A note regarding translating arduino C to spin - there is a function called Serial.find which looks for a specific string of text. It is very useful for parsing large text files like a website. The important thing is that it times out after 1 second, and if this is replicated in Spin, would need to keep that time constant, as there are quite a few times where things take a bit more than a second, so you might call serial.find three or four times in a row to allow for slower website loading. Essentially, there needs to be a spin routine that looks for strings of text and times out after a certain period - maybe a routine where you pass it both a string and a millisecond value.
Next step - server and client code.
so I tried the several SPIN-codes uploaded to this thread with zero success.
No respond at all from the ESP8266.
Which baud_rate do I have to use with the ESP-module 9600 or 115200 ? does this depend on the logic level of the CH_PD-Input?
Can anybody post the most simple SPIN-code to get the most easiest answer from the module?
I would like to narrwo down if its a hardware or a software-problem I have.
If I connect the module to power the small blue led makes two short flashes then the red led is permanent on
Is this OK so far?
the smaple-code should include really clear info what the pin-assignemend of rx-tx means
ESP8266-RX/Tx or Prop-TX/Rx which is opposite
best regards
Stefan