ESP8266 Community Forum

- 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.

- Sun Oct 19, 2014 9:31 am #1770 I've been quietly progressing this... if I set the timeout short, when my code locks up - it will come back to life after the timeout.. it only happens if I send commands to quickly. But when I say too quickly I'm only talking as fast as two fingers can press 2 buttons on a phone.. The problem is in a working situation the phone software might be requesting status of various bits as well as responding to button pushes... and all of this works absolutely reliably on standard Ethernet socket software for Arduino so there's nothing up at the phone end...

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

- Sat Nov 08, 2014 11:07 am #2333 None of the attempts at fixes I've seen have worked to date... the unit displays "busy s" if overloaded or sent partial commands (I've not yet figured out the EXACT sequence to send it braindead like this) and the only way out is a proper reset - and of course - any software at the OTHER end which was expecting a response - doesn't get it! More work needed on this chip before it's useful.. I'm trying to document everything at scargill.wordpress.com and people are coming back to me but no-one has yet managed the combination of being able to compile and blow chips AND understand and fix the issue.

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