BGS2 - Briefly stops communicating 2 minutes after power up | Telit Cinterion IoT Developer Community
October 19, 2017 - 11:45am, 4405 views
Hi,
One of our products uses a BGS2 modem to communicate using GPRS. We have noticed that 125 seconds after the modem has been powered up, if a socket has been opened, data sent either way does not arrive at its destination. Before this time, and about 1 second later we can send and receive data, but anything sent during this window is lost. Data sent to our device during this time does not get acknowledged at the TCP level. We have tried various BGS2 (E and W) modems and service providers and software revisions 04.030 and 01.301 with the same results. We know its timed from the power up condition; the problem occurs at the same time since power up, even if we delay sending the commands the modem. If we power up then wait 2 minutes before we send anything to the modem then all is well.
Clearly, we have a few work arounds available to us; either delaying at the start, or reopening the socket if its closed due to a TCP retry timeout. However, the nature of our product makes either of these un-desirable.
Has anyone any suggestions to what we could be doing wrong?
Kind regards
Steve
Hello,
Thank you for this report. That would need to be checked.
Please check the detailed firmware version with ATI1 command.
Are you using IP services over AT commands or dial-up?
Do you have any application traces with AT commands that are used? Have you done any traces on the server side? Was it always the same server?
Is it possible to use the same socket after problem occurs or it ***** to be closed?
Generally such situation should not happen and I can't think of anythink that you could have done wrong to cause this.
So if you are really sure about this (sounds rather improbably) and that your diagnosis is correct I think that you should report it to your distributor.
Regards,
Bartłomiej
Hi,
Thanks for replying. We have tried this on a BGS2-W and several BGS2-E.
The ATI1 response for the W version:
Cinterion
BGS2-W
REVISION 01.301
A-REVISION 01.000.03
And the E versions:
Cinterion
BGS2-E
REVISION 04.030
A-REVISION 01.000.15
We have only used one server and server application to date, but since it reliably fails at a time based on when the modem is powered – I had ruled server problems out. The same server has TC65 modems connected to it in the same way and these are fine.
I have not tried opening the same socket after the error.
We are using IP services over AT commands; log file below.
The time stamp in seconds from shortly after the modem is powered is shown in square brackets and a less than / greater arrow shows the direction. I have obscured the sensitive information.
[000.000] > ATE1Q0V1
[000.220] < ATE1Q0V1
OK
[000.320] > ATI
[000.560] < ATI
Cinterion
BGS2-E
REVISION 04.030
OK
[000.660] > AT\Q3+CMEE=2;+CMER=1,0,0,2;S18=1+CR=1;+CREG=2;+CLIP=1;+CSSN=1,1;+CUSD=1;^SCKS=1;^SSET=1;^SCTM=1;+CMGF=1;^SCFG="PowerSaver/Mode9/Timeout",5
[000.710] < AT\Q3+CMEE=2;+CMER=1,0,0,2;S18=1+CR=1;+CREG=2;+CLIP=1;+CSSN=1,1;+CUSD=1;^SCKS=1;^SSET=1;^SCTM=1;+CMGF=1;^SCFG="PowerSaver/Mode9/Timeout",5
^SCFG: "PowerSaver/Mode9/Timeout","5"
OK
+CIEV: battchg,5
+CIEV: signal,99
+CIEV: service,0
+CIEV: sounder,0
+CIEV: message,0
+CIEV: call,0
+CIEV: roam,0
+CIEV: smsfull,0
+CIEV: rssi,4
[001.040] > AT^SICS=1,"conType","GPRS0"
[001.290] < AT^SICS=1,"conType","GPRS0"
OK
[001.390] > AT^SICS=1,"apn","......................"
[001.610] < AT^SICS=1,"apn","......................."
OK
[001.710] > AT^SICS=1,"user",".............."
[001.930] < AT^SICS=1,"user",".............."
OK
[002.030] > AT^SICS=1,"passwd","...................."
[002.250] < AT^SICS=1,"passwd","...................."
OK
[002.350] > AT+CFUN=9
[002.570] < AT+CFUN=9
OK
[002.670] > AT^SISS=0,"srvType","Socket"
[002.910] < AT^SISS=0,"srvType","Socket"
OK
[003.010] > AT^SISS=0,"conId",1
[003.230] < AT^SISS=0,"conId",1
OK
[003.330] > AT^SISS=0,"address","socktcp://listener:..."
[003.560] < AT^SISS=0,"address","socktcp://listener:..."
OK
[003.660] > AT^SISO=0
[003.890] < AT^SISO=0
[036.912] <
OK
+CREG: 5,"5445","813F"
[037.012] > AT^SISO?
[037.262] < AT^SISO?
^SISO: 0,"Socket",3,3,0,0,"XX.XX.XX.XX:****","0.0.0.0:0"
^SISO: 1,""
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
OK
[037.362] > AT^SISS=1,"srvType","Socket"
[037.592] < AT^SISS=1,"srvType","Socket"
OK
[037.692] > AT^SISS=1,"conId",1
[037.912] < AT^SISS=1,"conId",1
OK
[038.012] > AT^SISS=1,"address","socktcp://XX.XX.XX.XX:***"
[038.242] < AT^SISS=1,"address","socktcp://XX.XX.XX.XX:***"
OK
[038.342] > AT^SISO=1
[038.612] < AT^SISO=1
[038.712] > AT^SISO?
[038.902] < AT^SISO?
^SISO: 0,"Socket",3,3,0,0,"XX.XX.XX.XX:***","0.0.0.0:0"
^SISO: 1,"Socket",3,2,0,0,"0.0.0.0:0","XX.XX.XX.XX:***"
^SISO: 2,""
^SISO: 3,""
^SISO: 4,""
^SISO: 5,""
^SISO: 6,""
^SISO: 7,""
^SISO: 8,""
^SISO: 9,""
OK
^SISW: 1,1
[039.053] > AT^SISW=1,69
[039.273] < AT^SISW=1,69
^SISW: 1,69,69
[039.373] > Raw data: 0x00 0x00 0x00 0x00 ..... Total 69 bytes
[039.613] <
OK
^SISW: 1,1
[039.953] <
^SISR: 1,1
[040.063] > AT^SISR=1,1500
[040.293] < AT^SISR=1,1500
^SISR: 1,12
[040.293] < Raw data: 0x00 0x00 .... Total 12 bytes
[040.293] <
OK
[040.393] > AT^SISW=1,24
[040.613] < AT^SISW=1,24
^SISW: 1,24,24
[040.713] > Raw data: 0x00 0x00 .... Total 24 bytes
[040.943] <
OK
^SISW: 1,1
[041.373] <
^SISR: 1,1
(back to back commuincation between server and client continues)......
[121.928] > AT^SISW=1,44
[122.148] < AT^SISW=1,44
^SISW: 1,44,44
[122.248] > 0x00 0x00 0x00 ..... Total 44 bytes
[122.478] < OK
^SISW: 1,1
[135.279] < ^SISR: 1,2
(The last message does not get through and the server closes the socket)
Hello,
Thank you fro these informations.
I can't see any newer firmware that you could try.
As for the server it could still be worth checking. You are probably using some dedicated server that communicates with your devices only and maybe it is configured in some non-typical way, for example some timouts are very short and it closes the connection too soon. If you were able to reproduce it with some public server it would confirm that there is a problem and would give us a chance to also reproduce it.
I can see that you are using sleep mode. Have you tried to test this without sleep mode?
Regards,
Bartłomiej
Hi
Further testing showed that after the initial 2 minutes outage further outages of a similar length occurred at 30 minute intervals from then on, and that this problem is restricted to roaming SIMS. I suspected that was related to the modem searching the network for an alternative operator; so, did some research and some more tests, switching to manual mode and selecting specific operators.
I concluded the problem we are having is that the modem is searching the network (PLMN Search) every 30 minutes, which takes 25-30 seconds during which time no data can get through; presumably being buffered in the modem.
This is the evidence I have:
PLMN Search period file set to 30 minutes in the SIM card
Strange that it only does this with the BGS2 and not the TC65.
Kind regards
Steve
Hello,
That sounds interesting - that would be quite a specific case with roaming card only. Hopefully there are some workarounds possible.
BGS2 and TC65 are completeley different modules so there may be differences between them.
We will also try to test this scenario and it will be analyzed if this behavior can be changed in a future.
Best regards,
Bartłomiej
Hi,
Thanks, in case this is restricted to a specific SIM vendor, we could send you a SIM that has this problem, if that would help?
Kind regards
Steve
Hello,
I have also checked the ETSI documentation and this is a desired behasvior that the UE performs a periodic search for HPLMN or PLMN with higher priority. The intervals may differ depending on the SIM provider and it may even be 8 hours. It may only take place if UE is in idle mode for circuit services or in Idle or Stand-by mode in case of GPRS. And if there is no data transmitted for a while the GPRS may be switched from ready to stand-by.
We have tried to test this scenario but haven't been able to reproduce this so far. We'll try some more.
But in a meantime I have a question to you - it is not clear for me what happens if the last message does not get through and the server closes the socket - is there any error on the module side or does the connection seem to be still active? What happens if you still try to transmit data?
On the other hand in the mobile network it may happen that connection is lost, GPRS is detached by the network, coverage is lost etc. and the user application must also be ready for this. So even with the workaround when this periodic network search will not be the case still some other situation may occure that will lead to the similar effect.
Best regards,
Bartłomiej
To know more about the situation you could add some additional checks between the reading and writing commands like AT^SMONI and AT+COPS? and additionally configure AT+CREG=2 to get URC's about registration state changes.
Then it could be seen if this problem only happens when the PLMN is changed or even if the search is done. And also how fast the application gets the information that the connection is no longer available and returns some error. There will be some timeouts before the connection can be treated as broken.
Regards,
Bartłomiej