The BGS5 and EHS6 activate the URC "^SISR: x,1" without the open service | Telit Cinterion IoT Developer Community
August 5, 2016 - 3:22pm, 4039 views
We have an application that works properly with the TC65T and now try to adapt to BGS5, EHS6.
The application does not use JAVA, only AT commands in the ASC0 port to handle the TCP/IP stack, and consists of a server waiting for incoming connections on port 502.
Service Profile: socktcp://listener:502
The problem is that the event "Receive data ready" URC "^SISR: x,1", is activated when there is an incoming data connection, and without opening it. Also, sometimes the URC "^SISR: x,1" is activated before the incoming connection URC "^SIS: x,1,x,'ip-remote' '.
Sometimes the incoming connection event URC "^SIS: x,1,x,'ip-remote'" is lost, and only activates the URC "^SISR: x,1" this usually happens if two or more simultaneous connections.
Our application with TC65T can work with 3 or 4 simultaneous connections perfectly and stably.
The connections are very short, from 3 to 12 seconds from php sockets (Web server) and others.
In the TC65T the URC "^SISR: x,1" is activated if the incoming connection contains data, and only when we open the service incoming connection, not before.
This seems a bug in the firmware. How can we solve it?
----------------------------------
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.10
----------------------------------
Cinterion
EHS6
REVISION 03.001
A-REVISION 00.000.14
----------------------------------
We appreciate your help
Hello,
are you able to provide log file from your tests to see this behavior ?
Is this happening also when you have one incoming connection ( only one client) ?
Best regards
Lukasz
Hello,
In answer to your question to try it with a single client, It is that it works correctly.
And also I put the log where two clients sends queries continously to BGS5T.
The waiting time of clients for receive the responses (timeout) is 20 sec.
Service Profile 2:
--------------------------
AT^SISS=2,srvType,Socket
AT^SISS=2,alphabet,1
AT^SISS=2,conId,0
AT^SISS=2,address,"socktcp://listener:502"
Free Service Profiles for incoming connections: 1,3,4,5,6,7
RS232 (ASC0) 9600,N,8,1 and no flow control
LOG WITH TWO CLIENTS:
-------------------------------------
Data packet number 000038 ---> ^SISR: 3,1
- Missing ^SIS: 2,1,3
Data packet number 000279 ---> ^SISR: 1,1
- Missing ^SIS: 2,1,1
Data packet number 000441 ---> ^SISR: 4,1
- Missing ^SIS: 2,1,4
Data packet number 000531 ---> ^SISR: 6,1
- Missing ^SIS: 2,1,6
--------------------------------------
In the log is observed that frequently loses URC ^SIS: x,1,x
Note that the URC ^SISR: x,1 appears before or after the URC ^SIS: x,1,x
In my opinion the URC ^SISR: x,1 should not appear until the service is opened with AT ^SISO=x, in the same way that the TC65T.
Thanks for your cooperation
bgs5_log_two_clients.pdf
Hello,
I did some test and I cannot confirm this issue also when more client ( I used 5) conecting to the module.
But I used HW flow control which is strongly recommended and data exchange was slow - manuall conection via putty.
In your case where is low baudrate and no HW flow control in case when more client are conected you loosing some URC ^SIS: x,1,x and for strange ^SISR: 3,1 explanation could be that these are buffered URC from earlier connection which are not relevant anymore as service is not opened by AT^SISO.
When I check time stamp in your log it seems that data exchange is quite fast - To confirm that my suspision is right please try to use more client but slowly maybe manually and I believe no issue will occur.
Best regards
Lukasz
Hello,
Our applications are generally used to communicate with industrial equipment, and do not use flow control.
In industrial equipment usually they work at low speeds, for example 9600 or 19200 baud. These velocities have greater immunity to electrical noise and does not require flow control.
Do not use flow control in the BGS5T is not the problem, because with the TC65T functioning properly and has the same configuration: RS232 (ASC0) 9600, N, 8,1 and no flow control
There have been two types of test for BGS5T and TC65T.
All tests have been made with the same configurations, and are published in the previous post.
The first Test is to make queries manually with two clients, and leaving a gap of time between queries to a client of 1..3 sg. To test the simultaneity: First the client (A) runs and 1 or 2 seconds later, the client (B) is executed.
---> Client(A)...2sg...Client(B)...3sg...Client(A)...2sg...Client(B)...3sg...
Logs:
bgs5_man1_two_clients.pdf (Lost several URC "^SIS: 2,1,x")
bgs5_man2_two_clients.pdf (Lost several URC "^SIS: 2,1,x")
tc65_log_two_clients.pdf (No waiting time between queries and works well. It is included to compare)
--------------------------------
The second Test is to manually make 4 queries in just two seconds with the same client. It is similar to make 4 quick clicks (in 2 seconds) on the submit button on a form.
---> Client(A)...Client(A)...Client(A)...Client(A)
|------------------- 2 sg -------------------|
Logs:
bgs5_4query_in2sec_1client.pdf (Lost URC "^SIS: 2,1,3")
tc65_4query_in2sec_1client.pdf (All works well)
---------------------------------------
Best regards
XRMNET
On August 10 we posted five logs for information and analysis of the problem exposed. From this date we see no answer.
Regarding the operation of the URC "^SISR: x, 1", our impression is that this is a bug in the firmware. And we reaffirm it because in the manuals "BGS5 and EHS6 AT commands", you can see the following:
AT Command Set BGS5_ATC_V01.100. Page 208:
AT Command Set EHS6_ATC_V03.001. Page 243:
Another reason why we think it is a bug, is that the notification of incoming connection (URC "^SIS: x, 1, x, 'ip-remote' ") is lost many *****. And so it is impossible to synchronize the application with the TCP/IP stack.
We reiterate that this problem does not exist in the TC65 or TC65i. And the description of operation of these URC is the same in the TC65 and BGS5 or EHS6, according to their respective manuals.
- How to solve this?
We appreciate your help
Hello,
As my colleague was unable to reproduce this case and suggested flow control issue, I'd like to ask you if you have tried to use flow control for test? Please also make sure that you don't use power saving on the UART interface of the module (AT^SPOW).
I've went through your logs - they are quite long and it's not easy to find the lost '^SIS: x,1,x' URC's there - if the application does not see the incoming connection it does not answer it - how do you know that there should be an incoming connection - from the client's log? Is it possible that it is some other problem like network issues?
Another thing regarding URC's that is described in the documentation - if an AT command is finished (with "OK" or "ERROR") the TE shall always wait at least 100 ms before sending the next command (for baudrates below 9600 it should be more) in order to give the module the opportunity to transmit pending URC's and do some other things. Could you please try to add such timeout before sending each command to check if it changes anything?
Regards,
Bartłomiej
Thanks for answering Bartomiej
Steps to reproduce the problem of the operational manner of the URC "^SISR: x,1"
----------------------------------------------------------------------------------
Connection profile: 0 (Set up GPRS connection)
....
....
....
Service profile: 2 (Set up listen server of non transparent tcp)
AT^SISS=2,"srvType","Socket"
AT^SISS=2,"conId","0"
AT^SISS=2,"address","socktcp://listener:4000"
------- START TEST -------
AT^SISO=2 (Open service listen server)
OK
<--- Some time later
^SIS: 2,5 (GPRS connection established)
AT^SICI=0 (Read IP address assigned to server)
^SICI: 0,2,1,"176.81.198.73"
OK
<--- Client step 1: Make connection to server "176.81.198.73:4000"
^SIS: 2,1,0,"185.32.19.187:4401" (Notification of incoming connection)
<--- Client step 2: Send text "Hello world"
^SISR: 0,1 <--- *** This is wrong, it should not appear until the service has been opened
AT^SISO=0 (Open the service 0. In this case , it is the incoming connection)
OK
^SISW: 0,1
<--- (At this point missing the "^SISR: 0,1", because this appeared before)
AT^SISR=0,1500 (Read data from the opened connection)
^SISR: 0,13
Hello world
OK
AT^SISR=0,1500 (Read data from the opened connection)
^SISR: 0,0
OK
AT^SISC=0 (Close connection)
OK
------- END TEST -------
The correct way to synchronize the application with the TCP/IP stack is that the "^SISR: x,1" appears when the incoming service connection with AT^SISO=x is opened. This is the operational manner described in the manual.
Also remember that the "^SISR: x,1" sometimes appears before the URC incoming connection, this typically occurs when a client requests the connection and it already has the data included.
We're doing some tests and soon we post the results and conclusions. Or questions.
Regards,
XRMNET