ESP8266 Client Problems POSTing to Azure Web API 2.0 service

NETMF & Gadgeteer
21

Some progress with the code from @ Jay Jay. The exception is mscorlib.dll has gone, but things still are behaving as I would like.

The first pass through the loop works great every time. However, when it’s on its second pass it always fails.

Here’s the output:


AT




OK
OK found...


AT
+RST




OK
OK found...






ets
Jan

8
2013,rst
cause:4,
boot
m
ode:(3,2)



wdt
reset

load
0x40100000
,
len
1320,
room
16


tail
8

chksum
0xb8

load
0x3ffe8000,
len
776,
room
0


tail
8


chksum
0xd9

load
0x3ffe8308,
len
412,
room
0


tail
12

chksum
0xb9

csum
0xb9



2nd
boot
version
:
1.3(b3)



SPI
Speed





:
40MHz



SPI
Mode






:
QIO



SPI
Flash
Size
:
4Mbit

jump
to
run
user1




rl
Žƒÿ

ready
Ready found...



AT+CWMOD
E=3




OK
OK found...


AT
+CWLAP



+C
WLAP:(3,"MY
WIFI
E2
99",-66,"b0:45:19:25:e2:99",6)

+CWLAP:(
4,"NETGEAR",-45,"00:1e:2a:3c:fb:f0",11)



OK
OK found...


AT
+CWJAP="NETGEAR","$$$$$$$$$$$$"






OK
OK found...


AT
+CIFSR


+CIFSR:API
P,"192.168.4.1"

+CIFSR:APMAC,"1a:fe:34:a0:33:a
b"

+CIFSR:STAIP,"192.168.46.34"

+CIFSR:STAMAC
,"18:fe:34:a0:33:ab"



OK
OK found...


AT
+CIPSTART="TCP","ww
w.jasonjames.co.uk",80




CO
NNECT



OK
OK found...


AT
+CIPSEND=191




OK
OK found...


>
> found...

PO
ST
/api/json
HTTP/1
.1
Content-Type:
application/x-www-form-
urlencoded;
charset=UTF-8
Host:
www.jasonjame
s.co.uk
Connection:
Close
Content-Length:
33

Value=27
.18&DeviceId=C3PO&Count=1



SEND
OK
OK found...



+IPD,417:HTTP/1.1
200
OK
OK found...


Cache-Control:
no-cache

Pragma:
no-cache

Content-Length:
108

Content-Type:
application/json;
charset=utf-8

Expires:
-1


Server:
Microsoft-IIS/8.0

X-AspNet-Version:
4.0.30319

X-Powered-By:
ASP.NET

Set-Cookie:
ARRAffinity=f6773f17995880729e4f99a31975fd627a10ff7d78e6036bc2480e516a51d57b;Pa
th=/;Domain=www.jasonjames.co.uk

Date:
Wed,
08
Apr
2015
13:31:47
GMT

Connection:
close



{"Id":73844,"V

+IPD,94:alue":"27.18","DeviceId":"C3PO","Co
unt":"1","CreatedDate":"2015-04-08T13:31:48.6766802+00:00"}CLOSED


AT
+CIPSTART="TCP","ww
w.jasonjames.co.uk",80



AT+CIPSEND=191


busy
p...


CO
NNECT



OK
OK found...


PO
ST
/api/json
HTTP/1
.1


ERROR
ERROR found...

Content-Type:
applicatio
n/x-www-form-urlencoded;
charset=UTF-8


Host:
www.j

ERROR
ERROR found...

asonjame
s.co.uk


ERROR
ERROR found...

Connection:
Close


ERROR
ERROR found...

Content-Length:
33


ERROR
ERROR found...




ERROR
ERROR found...

Value=77.34&
DeviceId=C3PO&Count=1

It look like the AT+CIPSEND is not waiting for AT+CIPSTART to finish before it sends the data. The call is wrapped in an AutoResetEvent, but it seems as though the call resets immediately and the next command is executed before it should be. As such the comms get out of sync and the outcome is an error.

Any ideas how I can wait for the first call to correctly finish before sending the second call, especially as it works for the first iteration?

22

It seems like the simplest of state machines to manage the timing of sending AT+CIPSTART, AT+CIPSEND and actually sending the message has improved the stability significantly. Now for some testing…

23

Running for an hour with 99.1% success rate. Only dropped two POSTs in over 200. :whistle:

1 Like
24

one important thing about how you catch the response of the AT… order is important.
basically the OK must be the last in the order…

and if you get busy… that would mean one of two things.

  1. length of the string you sent on the first AT is not the correct of the string you are sending after the > double check the length of your string and make they match.

  2. the first AT hasn’t finished sending so before you start the second iteration wait for the OK to come back. add the AutoRestartEvents before you start a new iteration this way it won’t send until you get an ok from the last send.

cheers,
jay.

1 Like
25

i also noticed you close the connection and reopen it to the same server, WHY???

try to keep the connection open and continue sending… set a higher timeout, which will kick in and close the connection when there is no activity.

ah one more thing you can try using the AT+CIPMUX=1 and then create an queue of from 0 to 5 which will hold 0,1,2,3,4,5 and create your connection by recycling those connection IDs as follow:
AT+CIPSTART=(int)myQueue.dequeue,“TCP”,“192.168.101.110”,1000

and when you catch connection closed you will enqueue that id back into the list.

cheers,
Jay.

1 Like
26

@ Jay Jay - I don’t suppose you have any worked examples of your suggestions you’d share?

27

can i post to that server you’ve shared in your code? if not please give me a server and i’ll run a test and share what i get done…
you can send me a PM if you want to keep it private, once i succeed i’ll share the code here.

cheers,
Jay.

28

@ Jason - Don’t trust someone that says their name twice… :whistle:

29

theoretically i wouldn’t be saying my name, it’s people calling me would be the ones saying it twice.

now sing with me Jay, jay jay ,…

now you are on my list @ Gary…

1 Like
30

@ Jay Jay - lol…finally I made someone else’s list besides my wifes

31

@ Jay Jay - I’ve PM’d you.

32

@ Jason - Just checked my latest test with the same code as before but using an external antenna and I get < 1% failure over 46k requests!

2 Likes
33

@ munderhill - That’s incredible. Mine dies after a few hundred to a couple of thousand posts. Going to keep working on it tomorrow.

34

Sometimes the OK never comes, or seems to come out of order. That was why I needed to add a small FSM to prevent it from continuing until certain conditions were met.

I get the OK the first time round the loop, but not the second and the code has an AutoRestartEvent in it.

I’ll keep looking and trying things for now.

35

I might recommend some code I have come across which is really cool for checking sequence on that. Its called packetizer and postmaster patterns. Check out GitHub - tessel/gprs-sim900: [UNMAINTAINED] JavaScript module for the SIM900 2G driver.

Or else, I can always recommend: http://stama.codeplex.com/

1 Like
36

Thanks for the links. I’ll take a look. Broadly speaking the sequencing is good. Everyone now and then it seems like something doesn’t get sent or two things do and the AutoResetEvent gets fowled up. I think so those circumstances I might need a timer to fire an event if I’ve waited too long for the AutoResetEvent to fire.

Something I need to look into I think.

37

@ Jay Jay - One of the issues I’ve observed is that the strings are occasionally split at points other than \r\n. I have seen that OK gets returned on two lines (sometimes) and therefore the AutoResetEvent is never cleared. This might be happening on other returned strings too.

Any ideas why this might be happening given I’m sure that’s not how the ESP is designed to behave, and I believe the modified SimpleSerial should stop this too, and how it might get fixed?

38

Another piece of the jigsaw.

The response from the server is not being waited for before the next message is send. Need to look into how to ensure the response has arrived before the next message is sent.

Two steps forward, one step back…

39

Reading from things like the ESP8266 and SIM800* blocks can be tricky because both of those send unsolicited notifications. For the Fona lib, I had to build a receive state machine that sucked up the unsolicited responses and turned them into calls to delegates or threw them away so that they would not get in the way of responses that were part of the send protocol.

So, even if you start reading for expected responses from the ESP, the unsolicited responses can mess things up. If it helps any, I wrote a bunch of SendAndExpect() routines and an async receive state machine that you might find useful. It is up on github toward the end of this file : SimComDotNet/FonaDevice.cs at master · PervasiveDigital/SimComDotNet · GitHub Look for ‘#region Sending Commands’ and “#region Serial Helpers”

I do plan to do a full ESP8266 stack in the same style as the Fona stack starting early next week when an expected new load of toys arrives.

1 Like
40

@ mcalsyn - Please keep me posted on your progress.