leaving transparent mode with DTR line toggling unreliable | Telit Cinterion IoT Developer Community
July 5, 2019 - 9:15am, 5596 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.
some more info:
- we're using a dedicated channel, not a multiplexed channel for our transparent mode.
- this problem can happen fairly frequenctly. In our tests one-in-four transparent-exits?
- problem only occurs with downloading a large file and then trying to exit transparent mode
Hello,
So you are not using multiplexer at all? Please write what hardware interface you are using and ig it's modem or application interface.
Does the module not reply on other inetrfaces also? Did you have a possibility to try if other ways of leaving transparent mode can help in this case? Please paste AT&V and AT^SCFG? outputs.
I cannot see any timings for toggling in the documents indeed - have you alos tried different timings?
Regards,
Bartłomiej
- we're using the modem interface, the device is connected via a USB port to a microcontroller
- nope, we are not using the multiplexer at all, in transparent mode we're completely dedicated to only sending data at the moment.
- using +++ is not an option (it emits the +++ to the server which can't happen)
- using just a 2 char escape code is not an option either
- haven't tried AT&V/AT SCFG yet, however, it almost always works. It only fails once every x-th time. The config we use must therefore be okay. I'm figuring a race condition on something. Can it happen that the modem sometimes resets RTS/CTS/etc. serial port pins (emulated over USB)? Can it happen that the modem's firmware hangs sometimes at switching off transparent mode? Can the modem switch back to the application interface (we've switched it to the modem interface by sending the modem configuration commands to do so)
Hello,
I don't think module can switch back to application interface. Not sure about reseting pins emulated over USB, however, in my opinion, it cannot influence reliability of using DTR to leave the transparent mode.
I will try to check it on my side. Please let me know few more things so that I will be able to mimic your scenario:
-What IP service do you use? What is the size of data you download / upload?
-I know it happens only with large files. Have you noticed any patterns when more exactly it happens? I mean, have you noticed some connections between frequency of occuring this issue and time of how long IP service is active or how many bytes were transferred?
-How long you keep DTR line high?
-Do you have access also to USB application port or to the serial port? Can you check if you can normally send AT commands on other port when issue happens?
One more thing, I think you test it on your device, not eval board. Are you sure, issue is not related to your device? Have you verified that when issue happens, DTR line state is really changed?
Thanks,
Adam
Hi Adam,
we're observing this when we, in a loop do:
- receive a 983040 byte download (the size is constant for our test)
- close transparent mode
- perform an ATI1 and then *sometimes* not seeing the reply of the ATI from the modem.
This is in our board, not the eval board, not tested yet if the emulated DTR line has changed, it was a suspicion of mine as to the cause..
- We keep the DTR high for a second.
- TCP/IP socket in transparent mode.
- upload is approx 1K http request header (also sent over same tcp socket), reply from request is 983040 bytes + a few bytes for http response header (say 256 bytes). Note: we construct our own http headers and parse the http reponse ourselves, we do not use the modem's builtin http stack. We only use the tcp/ip functionality of the modem.
Hello,
As I understand you are using HTTP in persistent connection mode ? If not, maybe waiting for host closing the connection is an option for you ? When Host closes connection module will send "Remote peer has closed the connection" URC and will came back to AT command mode.
We are preparing test setup and scheduling the test with very similar scerario in loop:
When the results are ready we will let you know.
Wojciech
Hi Wojciech,
Indeed, I'm using a persistent connection to allow many http requests to run over the the same socket, one after the other to save on connection costs per request (socket-open can be quite expensive for our use case given that we do plenty of requests). I'd rather not add hacks such as "send a http request to let the server close the connection" though. It it helps, I can send you some logs from my test.
I figure such a test can be added to your internal nightly? testsuite at Gemalto.
Hello !
Of course any log will be helpful to debug this issue. I'll wrote to you an email that you can reply to and attach logs.
If you willing to, we can also perform test using your sever to minimize diffrences between our setups.
Best Regards
Wojciech
Some more analysis I've been able to today:
- I've set it up so that APP is on USB0 and MDM on USB1. On both I see SYSSTART being echoed after modem startup.
- I do the above described loop of SISO-SIST-download-toggle-dtr-ATI-SISC test on MDM/USB1
- once the ATI gives no reply anymore due to the issue outlined above, I issue an ATI on the APP/USB0 interface, and I get an answer!
This means that the modem is not dead in the water. It is just not replying on MDM/USB1 anymore.
I also tried sending a +++ on USB1 instead of ATI1 but USB0 remains unresponsive.
Some more notes:
- sending a +++ on APP echos nothing and the ATI on the other USB didn't respond either
- sending a "ATI1" on the USB1/APP gives the full reply of "cinterion...lte...etc. "
- sending a SISC to try to async close the socket (where the other USB was using transparent mode on) echoed the "SISC" but didn't print "OK"
- sending a AT+CEER gave: AT+CEER|||+CEER: No cause information available||||OK|
- sending "SISO?" print SISO but no OK and no response
Hello !
Could you estimate reproduction rate of this issue - how many DTR toggles it ***** to cause this issue ? Or it can happen randomly ?
In our test we can see that there was problem exiting "online" mode and it happened after over 1000 cycles (dowload file -> toggle DTR -> issue AT -> go to online mode ) but we do not confirmed if the module stop replying then.
Best Regards
Wojciech
Edit:
This night we run test with 10000 sucesfull DTR toggles
Pages