cancel
Showing results for 
Search instead for 
Did you mean: 

Sending large amounts of data over SPWF01SA

Posted on April 26, 2017 at 14:51

Hi.

So I'm trying to send large amount of data to server (~200kB). I can send and receive smallish amounts ok (<2k), however at 3k the send fails. I'm sending data in 1000byte blobs to respect the 1021byte limit in the socket code.

I've added delays and tried smaller sends also, but no luck so far. I coudn't find any applicaple callback to syncronize fe 2k transfers.

How should I handle this sort of situation?

+WIND:1:Poweron (170111-665d284-SPWF01S)

+WIND:13:ST SPWF01SA1 IWM: Copyright (c) 2012-2016 STMicroelectronics, Inc. Al.

+WIND:3:Watchdog Running

+WIND:0:Console active

+WIND:32:WiFi Hardware Started

+WIND:2:Reset

+WIND:1:Poweron (170111-665d284-SPWF01S)

+WIND:13:ST SPWF01SA1 IWM: Copyright (c) 2012-2016 STMicroelectronics, Inc. Al.

+WIND:3:Watchdog Running

+WIND:0:Console active

+WIND:46:WPA: Crunching PSK...

+WIND:32:WiFi Hardware Started

+WIND:21:WiFi Scanning

+WIND:35:WiFi Scan Complete (0x0)

+WIND:19:WiFi Join:xx.xx.xx.xx.xx.xx

+WIND:25:WiFi Association with 'XXXX' successful

+WIND:51:WPA Handshake Complete

+WIND:24:WiFi Up:192.168.0.100

>>Socket Open OK

>>Socket ID: 0

Writing 1000 bytes to socket, left 128825

<<OK

>>Socket Write OK

Writing 1000 bytes to socket, left 127825

<<OK

>>Socket Write OK

Writing 1000 bytes to socket, left 126825

>>Socket Write FAIL

+WIND:55:Pending Data:0:ENC

+WIND:58:Socket Closed:0

Reached SockON_Data_Length

Data Receive Callback...

AT+S.SOCKR=0,313

HTTP/1.1 400 Bad Request

Server: Server

Date: Wed, 26 Apr 2017 12:29:29 GMT

Content-Type: text/html

Content-Length: 167

Connection: close

As the server reponds with the bad request something is sent.

5 REPLIES 5
Mridupawan Das
Associate II
Posted on April 27, 2017 at 08:11

seems like Socket Write has failed for some reason.

Currently all the 'Error' reasons are not decoded in the firmware to give a clearer picture.

Is it possible for you to check in wifi_module_uart_01.c, the function Process_Buffer(), the condition:

else if((((strstr((const char *)process_buffer,'ERROR'))) != NULL))

You can maybe debug this part to understand and see the process_buffer variable to check what is the description of the ERROR. If there is a description, then it would be more clearer.

Posted on April 27, 2017 at 09:22

Hmm... This might be problem with my data.

' Details:'AT+S.SOCKW=0,1000\r\n\r\nERROR: Server closed during data sending\r\n', '\0' <repeats 448 times>'

Posted on May 03, 2017 at 13:55

After quite lot of debugging I still cannot get this working. I suspect the problem is how I split the multipart transfer. First I tought the problem was after the header and middle of body, however I can get the problem appear just by sending the header and waiting a moment for server response (using Expect: 100-continue like Curl does).

The curl that I'm trying to emulate is(

https://miguelmota.com/blog/alexa-voice-service-with-curl/

:(

curl -v -o log.txt -X POST \

-H 'Authorization: Bearer ${TOKEN}' \

-H 'Content-Type: multipart/form-data; boundary=${BOUNDARY}' \

--data-binary @multipart_body.txt \

https://community.st.com/external-link.jspa?url=https%3A%2F%2Faccess-alexa-na.amazon.com%2Fv1%2Favs%2Fspeechrecognizer%2Frecognize

I can do less than 1k transfers and receive data OK.

Current iteration of the socket communication:

1. I send the header:

const static char *synth_header = 'POST /v1/avs/speechrecognizer/recognize HTTP/1.1\r\n\

Host: access-alexa-na.amazon.com\r\n\

Authorization: Bearer %s\r\n\

Content-Type: multipart/form-data; boundary=BOUNDARY1234\r\n\

Transfer-Encoding: chunked\r\n\

Cache-Control: no-cache\r\n\r\n';

Second I send the first part of payload (json):

const static char *synth_payload = '--BOUNDARY1234\r\n\

Content-Disposition: form-data; name=\'metadata\'\r\n\

Content-Type: application/json; charset=UTF-8\r\n\

\r\n\

{\'messageHeader\': {},\'messageBody\': {\'profile\': \'alexa-close-talk\',\'locale\': \'en-us\',\'format\': \'audio/L16; rate=16000; channels=1\'}}\r\n\r\n';

As this is first chunk I've added the size before above payload in hex:

fa

--BOUNDARY1234

Content-Disposition: form-data; name='metadata'

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

{'messageHeader': {},'messageBody': {'profile': 'alexa-close-talk','locale': 'en-us','format': 'audio/L16; rate=16000; channels=1'}}

And after that next part of the payload + audio data.

My question is that does the wifi module add the chunk size by default, so am I messing up things by manually adding this to sent data. Any ideas how the chunked multipart transfer should be handled with this module? I've verified the token I get from Amazon with curl so that should be OK. And as I said, if I use 'Expect: 100-continue' in the first header and wait for the server to ack my transfer I first get 100 continue and right away 400 error. So something is wrong with the header packaging.

BTW: is there way round the 1k max transfer forced by the library? Is this limitation by the wifi module?

Posted on May 03, 2017 at 19:21

Module allows sockw up to 4kb in length.

Posted on May 04, 2017 at 06:39

Hi Matti,

yes the library is currently is using only 1k limitation of write data. you can increase this size by increasing the size of the data buffer which is used for write buffer and remove the limitation from the function and see for yourself. (since it is reference code you can modify as per your needs)

The module does not do anything to the write data in the socket case.