PLS8-E: HTTP uploads yield very small Bandwith using AT ^sisw | Telit Cinterion IoT Developer Community
February 14, 2018 - 12:46am, 1928 views
Hi,
we're HTTP-posting (uploading) a few files - about 1MB size per file - to a HTTP(S) webserver using the PLS8-E (REVISION 03.017, A-REVISION 01.000.05) modem and firmware using the AT command set over a HighSpeed USB (virtual serial ports) interface.
With a 3G or 4G connection we expected a very high data throughput, but we currently only see something in the range of only 20kB/sec! Is it possible that using the AT command set for data transfer limits the bandwith that much? What other channels to the Modem should we use?
Does it make any difference on transfer speed to the Modem if we use the Application or the Modem instance of the AT command interpreter?
The GSM cell itself seems fine: ^SMONI: 4G,1300,3,20,20,FDD,262,01,5211,194A001,53,31,-90,-8
And input is highly appreciated,
Regrads,
Christoph
Hello,
I think that besides the network quality or operator's limits (which is also possible) the factor that adds additional delays for the data transfer is that you probably use AT commands for sending the data (you can sent at most 1500 bytes with a single SISW call). This is probably not the optimal way for sending greater amounts of data. You could try the transparent connection but then you'd have to use bare socket instead of http and use your own POST implementation. But that would not be complicated.
It should not make any difference if you use application or modem interface for non-transparent mode. please note that the default interface for URC's is the application interface. So if you would like to use modem interface for non-transparent communication you should change this setting.
For the transparent mode you should choose the modem interface.
Best regards,
Bartłomiej
Hi Bartłomiej,
thank you for the quick response.
We are investigating the option to use transparent mode. In transparent mode, we are talking about TCP-sockets, right? Is it possible to use HTTP-stack of PLS8 in transparent mode at all?
We also noticed that it usually takes up to 7 seconds for the at^siso=3- command to URC-reply with "http connect..." for HTTP POSTing a file. Is this because the modem doesnt reuse its TCP session for our multiple http POSTs in sequence, or is maybe the IP connection dropped by the modem in between at^siso=3 and at^sisc=3?
our sequence is in essence as follows (some URCs are omitted here)
AT^SCFG="URC/DstIfc","app"
AT+CGDCONT=1,"IP"at^sica=1,1
at^siss=3,srvType,"Http"
at^siss=3,hcContLen,15150
at^siss=3,cmd,"post"
at^siss=3,secopt,0
at^siss=3,srvType,"Http"
at^siss=3,conId,1
at^siss=3,hcProp,"Content-Type: multipart/form-data; boundary=ourOwnUniqueBoundary237563"
at^siss=3,address,"http://ingestion.***.com/in"
at^siss=3,hcContLen,15150
at^siss=3,cmd,"post"
at^siss=3,secopt,0
at^siso=3
^SIS: 3,0,2200,"Http connect 18.x.y.z:80"
^SIS: 3,0,2200,"POST Bytes: 15150"
^SISW: 3,1
at^sisw=3,122
^SISW: 3,122,0
That you so much for your help!
Christoph
Hello,
This connection delay probably comprises some resources allocation on the module, on a network side, on a server side, some network packet exchange, network delays etc.
In transparent mode you can only use a socket connection. So you can't benefit from built-in HTTP protocol implementation. Therefore you have to implement all the necessary HTTP headers in your software.
AT^SISO command opens the connection and AT^SISC closes it. HTTP POST is implemented on the module in this way that you can only send one POST in one connection. So if you send multiple POST's one after another the new connection is established for each one.
Regards,
Bartłomiej
Hi, me and cvaesen above are trying to use the transparent mode and getting a "CME ERROR: operation not allowed". The steps we're doing are:
ret = run("AT^SQPORT?")
assert ret == "^SQPORT: Modem"
run("AT^SMONI")
run("AT+CGDCONT=1,\"IP\"")
run("AT^SICA=1,1") # activate cid(1)
#run("AT^SICA?") # returns OK
run("AT^SISS=2,srvType,\"Socket\"") # return ok
run("AT^SISS=2,connId,1") // this throws the error....
Maybe the problem is that "conId" is misspelled in your log it is "connId". Please check.