leaving transparent mode with DTR line toggling unreliable | Telit Cinterion IoT Developer Community
July 5, 2019 - 9:15am, 5623 views
Our scenario is that we enter transparent mode to a server, send some data and close transparent mode to communicate with some other host, etc. We use DTR line toggling to escape from transparent mode. Now it seems that *some****** the modem becomes unresponsive after toggling the line. My assumption here is that the modem either some***** stops/halts or transparent mode remains on. Any idea which? The symptom is that issueing a command such as ATI in the error case does not respond *at all*.
- Is there a guidance for how long we should keep the DTR line high?
- it seems more reliable if we toggle the DTR line multiple *****? Is this true?
Note: ATI1 gives: Cinterion||PLS8-E||REVISION 03.017||A-REVISION 01.000.05||||OK in the normal case.
with my test it mostly happens within 10 to 20 iterations of the below loop.
1: SISO
2: SIST
3: <download>
4: toggle DTR once
5: issue ATI1 # this fails to reply after 10 to 20 iterations, but i've also seen it fail after just 3 iterations
6: issue SISC
7: goto 1
But atleast you've now been able to reproduce it! Given that it happens with only large downloads (approx 1 MB) on our side, its probably a data race somewhere in the modem.
I'm a little confused what you mean with #DTR toggles. I only do one DTR toggle per test loop above. I've tried to do longer DTR toggles and 1, 2 and 3 toggles of the DTR line but it had no effect. The issue reoccurs just as often regardless.
Hello,
As the test with 10000 iterations and some shorter tests were finished successfully we currently assume this one failure as an incident which could have been caused by an environment problem as well. So generally we are unable to reproduce it for now.
In our test DTR is pulled low for 1 second and then back high. Then the script waits additional 5 seconds before sending an AT command (5 seconds is quite much but please make sure that your software also waits a while to let the module make a switch).
As it seems to be quite easiy reproducible on your side, did you consider testing with creating separate connection for each HTTP reuest just to verify if this will also be occuring? I know it's not a good solution because of traffic increase as you have already mentioned.
Regards,
Bartłomiej
Hi Bartłomiej,
Our setup is like that as well (we also tried for a second to keep it low), but then immediately send the ATI1. Waiting a bit after the transparent-mode-exit I tried just now, same results. It goes well and after a while the ATi doesn't respond even through now there's a 5 sec delay between the toggle and the sending of the ATI1.
Are you also testing with modem FW |PLS8-E||REVISION 03.017||A-REVISION 01.000.05| ?
Cheers,
Ronald.
Hi,
My collegues were testing this with the same version.
Could you also provide AT^SCFG? and AT^SSRVSET="current" output?
Regards,
Bartłomiej
Here you go (unprintable chars such as /r/n translated to ||)
+ [DEBUG] [gsm trafic, sending] ATI1|
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, ATI1| received] ATI1|||Cinterion||PLS8-E||REVISION 03.017||A-REVISION 01.000.05||||OK||
+ [DEBUG] [gsm trafic, sending] AT+CGSN|
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, AT+CGSN| received] AT+CGSN|||358709054113885||||OK||
+ [DEBUG] [gsm trafic, sending] AT+CIMI|
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, AT+CIMI| received] AT+CIMI|||234500010300290||||OK||
+ [DEBUG] [gsm trafic, sending] AT^SCID|
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, AT^SCID| received] AT^SCID|||^SCID: 8944500512173002908||||OK||
+ [DEBUG] [gsm trafic, sending] AT^SSRVSET="actSrvSet"|
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, AT^SSRVSET="actSrvSet"| received] AT^SSRVSET="actSrvSet"|||^SSRVSET: 10||||OK||
+ [DEBUG] [gsm trafic, sending] AT^SQPORT?|
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, AT^SQPORT?| received] AT^SQPORT?|||^SQPORT: Modem||||OK||
+ [DEBUG] [gsm trafic, AT^SCFG?| received] ||^SCFG: "Audio/Loop","0"||^SCFG: "Audio/SvTone","0"||^SCFG: "Call/ECC","0"||^SCFG: "Call/Speech/Codec","0"||^SCFG: "GPRS/Auth","2"||^SCFG: "GPRS/AutoAttach","enabled"||^SCFG: "MEopMode/CFUN","1","1"||^SCFG: "MEopMode/DTM/Mode","1"||^SCFG: "MEopMode/ExpectDTR","current","acm1","acm2","acm3","acm4","rmnet0","rmnet1","asc0"||^SCFG: "MEopMode/ExpectDTR","powerup","acm1","acm2","acm3","acm4","rmnet0","rmnet1","asc0"||^SCFG: "MEopMode/NonBlock/Cops","0"||^SCFG: "MEopMode/PingRsp","1"||^SCFG: "MEopMode/PowerMgmt/LCI","disabled"||^SCFG: "MEopMode/PwrSave","disabled","52","50"||^SCFG: "MEopMode/PwrSave/Delay/USB","10"||^SCFG: "MEShutdown/OnIgnition","off"||^SCFG: "MEShutdown/Timer","off"||^SCFG: "Misc/CId",""||^SCFG: "Radio/Band","2928787"||^SCFG: "Radio/CNS","0"||^SCFG: "Radio/Mtpl","0"||^SCFG: "Radio/OutputPowerReduction","4"||^SCFG: "RemoteWakeUp/Event/ASC","none"||^SCFG: "RemoteWakeUp/Event/URC","none"||^SCFG: "RemoteWakeUp/Event/USB","none"||^SCFG: "RemoteWakeUp/Ports","current"
+ [DEBUG] [gsm trafic] successful send
+ [DEBUG] [gsm trafic, AT^SSRVSET="current"| received] AT^SSRVSET="current"|||^SSRVSET: "usbcomp","0061","","1E2D","0061","Cinterion","LTE Modem",""||^SSRVSET: "srvmap","MDM","USB1","NONE"||^SSRVSET: "srvmap","APP","USB0","NONE"||||OK||
Best regards,
Ronald.
Hello,
SCFG output seems to be incomplete but I can't see anything bad in what's available.
There's newer firmware available for release 3 - there's no evidence that it may change anything but you might try to test.
Regards,
Bartłomiej
we'll have to think about potential firmware updates of the modem firmware over-the-air for this...
It looks like there is no easy fix. For the SCFG, I only added a 1K download buffer for the SCFG result.