ESP8266 Community Forum

- Thu Oct 16, 2014 1:51 am #1706

more discoveries.. after the AT+RST it now reverts back to 9600

Yes, that's how it's designed. It does not save the baud preference as of now. But I guess, if the external micro controller sets the baud as part of the initialization procedure, it should not be a problem. But let me see how much effort saving the baud rate is going to take, I guess not much.

after a following AT+GMR it goes back to 115,200... that can't be right....

I haven't seen this happen. The only automatic baud rate change you would experience is when you change the baud to something other than 9600 and upon reset, it is restored to 9600. It would never automatically change to 115200.

Can you check again?

After flashing the firmware, power down the chip and power up with appropriate settings on MTD0, GPIO0 & GPIO2
Set up your APN details and Restart the module with AT+RST
Check if the module has received an IP from your APN (It will show two IPs if you are using Station + softAP mode, check if the station IP is valid)
Proceed with using the module.

I sometimes have had to restart / power cycle the module more than once after firmware upgrade to get it to work right.

What is the exact part number of your ESP8266 chip?

Also, I think you are comparing the behavior of the firmware with one that has the CIOBAUD command. That is not the official firmware so can't say anything about differences in output. I try to not touch the official AT Commands and add a X prefix to all new commands. This way, you get identical behavior from the standard commands irrespective of whether you are using the official firmware or the modded one.

- Thu Oct 16, 2014 11:39 am #1719 Ok, here's an update that remembers the baud rate across power cycles

NetIO has been enabled so you can benchmark the throughput of your ESP8266!

If you had flashed the previous version, you can just run AT+CIUPDATE to get the this version. The version number won't change in AT+GMR, this is intentional. However, you will see "NetIO Enabled" at start-up.

Attachments

ESP8266 Cloud Update with XRST XIPR NetIO.zip

(135.43 KiB) Downloaded 404 times

- Fri Oct 17, 2014 2:13 am #1745 Thanks for the update - tested it last night. This is a good step forward. I am coming to think however that there is a basic flaw in the firmware that needs fixing. Either that or I'm missing the point.

I have some phone software with 2 buttons - to turn a light on and off. I set up the WIFI board as a socket listener which is using my router... everything works.

A can press a screen button to tuen a light on and off, but regardless, the phone phone software sends info requests every 500ms and this is what comes into the serial port.....

Simple enough

+IPD,0,3,GO

I have the ESP8266 send a response using AT+CIPSEND=0,3 followed by a single digit value and \r\n

After AT+CIPSEND=0.3 I wait for the ">" then send the response... I then wait for another OK and we're back to square 1.

This works constantly... but then something happens and from that point on the BUSY problem comes in... when sending AT_CIPSEND=0,3 I see "busy s.." - and that's the end of the communication... but after a while there the AT+CIPSTO timeout kicks in.. and I see "Unlink" . and once again the WIFI board responds to incoming signals but again responds "busy s..."

So it's NOT that the busy message is stopping incoming signals !!!! It's as if someone has forgotten to reset a flag..... I really don't want to have to send a reset every time this happens with the attendant delays... I'm hoping this issue in the firmware can be fixed.

Peter Scargill - http://tech.scargill.net

- Sun Oct 19, 2014 1:42 am #1767 I will look into this today. My intuition is, the fix is going to be non trivial.

Secondly. A remote connection, especially wireless, is inherently unreliable and application code has to embrace this reality. I generally treat no connectivity as the default and good connectivity as a welcome exception.

I do see that locking up the module with "busy.. s" response prevents the user from taking any corrective measures and I think this can be fixed. However, as has been the case with all wireless modules, the user code can't be fire and forget, it has to have exception handling and recovery features as first class citizens. This is a general comment and not specific to your code.