CINTERION PDS5 -> Downloading problem in TCP transparent mode | Telit Cinterion IoT Developer Community
September 8, 2015 - 5:35pm, 5763 views
Hi everyone,
I have interesting problem with data transfer, better with receiving data on module PDS5-US ( potentially with PDS5-E too ).
HW information ( ATI1 ):
Cinterion
PDS5-US
REVISION 03.001
A-REVISION 00.000.13
Sequence for establishing connection:
:
:
V
AT^SICS=0,conType,GPRS0
OK
AT^SICS=0,apn,"...any_apn..."
OK
AT^SICS=0,user,"...any_apn_user..."
OK
AT^SICS=0,passwd,"...any_apn_psw..."
OK
OK
AT^SICS=0,apn,"...any_apn..."
OK
AT^SICS=0,user,"...any_apn_user..."
OK
AT^SICS=0,passwd,"...any_apn_psw..."
OK
AT^SISS=0,"srvType","Socket"
OK
AT^SISS=0,"conId","0"
OK
AT^SISS=0,"address","socktcp://Desired.url:80;etx"
OK
OK
AT^SISS=0,"conId","0"
OK
AT^SISS=0,"address","socktcp://Desired.url:80;etx"
OK
AT^SISS?
^SISS: 0,"srvType","Socket"
^SISS: 0,"conId","0"
^SISS: 0,"address","socktcp://Desired.url:80;etx"
^SISS: 0,"tcpMR","10"
^SISS: 0,"tcpOT","6000"
^SISS: 1,"srvType",""
^SISS: 2,"srvType",""
^SISS: 3,"srvType",""
^SISS: 4,"srvType",""
^SISS: 5,"srvType",""
^SISS: 6,"srvType",""
^SISS: 7,"srvType",""
^SISS: 8,"srvType",""
^SISS: 9,"srvType",""
OK
AT^SISO=0
OK
^SISW: 0,1
OK
^SISW: 0,1
AT^SIST=0
CONNECT
CONNECT
{ ... DATA TRANSFER ... }
Test files:
File_1:
- content type: string ( only visible characters )
- size of file: 1 kB
File_2:
- content type: string ( only visible characters )
- size of file: 25kB
File_3:
- content type: data ( characters in full range 0x00 - 0xFF )
- size of file: 410kB
Problem:
1) I am sending request to server + any data for server ( this part without problem )
2) Downloading one of file:
Case for File_1:
Whole file downloaded correctly.
Case for File_2:
From 25kB file was downloaded aprox. 20-24kB ( depend from attempt ).
Content was OK, without missing
charecters.
Transfer was done with sequence:
NO CARRIER
^SIS: 0,0,48,"Remote peer has closed the connection"
^SISR: 0,2
^SISR: 0,2
Case for File_3:
From 410kB file was downloaded 405kB.
I did't investigate how ended this transfer but I suppose the same such for File_2.
I had the same problem with modems Sierra Wireless configured as TCP transparent. Then I used CINTERION PCS3 for CDMA, also in transparen mode, I connecting to the same server, with the same request and there all working nice without problems.
By this module (PDS5-US) I tried play with parameters like timer, tcpMR,tcpOT in AT^SISS without any success.
Had anybody similar problem, or know anybody help me with this?
Thanks a lot!
Hello,
This problem has already been reported to Gemalto technical support and is being analysed.
PCS3 and PDS5 modules are working in different netowrk technologies. I wonder what Sierra Wireless module you have been trying. If there is the same problem for PDS5 and Sierra Wireless logged to the same network type the problem could be on the network side as well. It would be good to try some other operator then or some other location, possibly with better network coverage. PDS5 is 2G/3G so it can also matter what netowork type it was logged to while it happened.
Best regards,
Bartłomiej
Hi Bartłomiej,
Thank you for your answer.
I played with this modem, in order to find out more information.
I had one theory, that server close connection very early, but not all data are shifted to the modem ( they hanging somewhere in air btw server and modem as lost packed ), or internal buffer of modem is clean before I read out whole data from it. I would remind that I get on the end sequence NO CARRIER and so on ( see above ).
In practice I tried 2 things:
1) I sent any dummy data after my "useful data". That mean for case File_2 I sent instead of 25kB in example 30kB
2) we add on server side after sent data sleep delay for example 20 second.
Both this things we tested in order to postpone time of close of connection from server side immediately after sent all data.
In both case we was successful, we get whole data.
We are using Apache in standart default settings on server.
I would like to know where are that data which are missing on the end, when we didn't make this special magic on server side...or if you have any idea what could be wrong, or tip and tricks...give us :)
Thank you!
Matus
Hello,
This is very interesting.
Unfortunatelly I don't know any tips or tricks for that behaviour. These modules are quite new and this is not the known behaviour. Still that is interesting that you have written that you also have this kind of behaviour with Sierra Wireless module. So maybe it is somehow connected with the type of wireless network. Maybe for some reason the last packet reaches the module faster than the previous one which for some reason does not come on time or does not come at all. We can not exclude the possibility of incorrect behaviour of the module itself at his stage.
So you are using your own server - you could trace if all the packets have been sent by the server.
It could be still interesting to check with some other public server.
The best thing here is that you already have found the workaround. :)
Regards,
Bartłomiej
Hi,
I don't know if this is solution, I only found out any relationship btw modem and server.
Until now I tested download file ( all with the same results ) in combinations:
Combination 1:
- from two independent servers
- the same operator during test ( modem placed in USA )
Combination 2:
- one server used for test
- other operators ( modem placed in EU )
Matus
Hello,
I'm not sure what are the results for combination 1 and 2: in both cases fail without additional tricks and in both cases success with your tricks?
Regards,
Bartłomiej
Hi,
I those results was mean as unsuccessful cases, tested without tricks :)
Matus
Hello,
So it seems that the only thing that is common for both cases is the module.
As I have written before this report is being analysed by Gemalto.
If the behaviour will be confirmed in the tests in Gemalto labs we should have a fix.
Let's hope it will be clarified soon.
Regards,
Bartłomiej
Hi Bartłomiej,
I got from one guy which doing support for us something like this:
AT^SICS=1,conType,GPRS0
OK
AT^SICS=1,apn,"***"
OK
AT^SISS=2,srvType,"Socket"
OK
AT^SISS=2,conId,1
OK
AT^SISS=2,hcMethod,1
OK
AT^SISS=2,HcContLen,500
OK
AT^SISS=2,hcContent,"parameter=value&also=another"
OK
AT^SISS=2,address,"socktcp://DesiredSide.url:80;etx"
OK
AT^SISS=2,cmd,"post"
OK
AT^SISO=2
OK
^SISW: 2,1
AT^SIST=2
CONNECT
{...DATA TRANSFER...)
I am now tooo confused!!!
I documentation is write, that when we want to use TCP Socket is:
Mandatory:
-SrvType
-conId
-address
Optional:
-tcpMR
-tcpOT
...!!! NOWHERE !!! in doc is publicated about other settings like hcMethod, hcContLen, hcContent, cmd...
Can this additional settings have influence for proper work for Socket mode???? If yes, what are they doing?
Thanx a lot for explanation...
Matus
Hello,
These parameters are described in the AT commands specification (besides hcMethod) and are needed for sending data to http server with POST method.
However I think that you should ask the support for more detailed description and background for this example they sent you. I wouldn't like to guess their detailed intentions. But they are probably doing some testing to reproduce your scenario or to find some solution (if they were able to reproduce it).
Regards,
Bartłomiej
OK I have result from test of additional setting mentioned a bit above.
As I thought, it doesn't working for us... That settings are for HTTP mode and have not meaning for TCP (Socket) mode...
Pages