ELS61-E: Hardware flow control CTS signal remains HIGH indefinitely | Thales IoT Developer Community
August 10, 2020 - 2:54pm, 1745 views
Hi,
I'm using ELS61-E module to stream binary data using ASC0, 921600 baud with Hardware flow control enabled.
I use the transparent TCP service as explained in the Cinterion® ELS61-E2 documentation (10.15.10, page 6/08/2).
The CTS signal remains "LOW" as long as I have stable LTE connection, but when the connection is 2G/3G the signal goes "HIGH" and remains in this state indefinitely, evenif I stop streaming data and reset RTS signal.
any suggestions what the problem could be ?
The module I have is:
Cinterion
ELS61-E
REVISION 01.000
A-REVISION 00.026.00
Best regards,
kbehaimanot
Hello kbehaimanot,
persumably ****m locks interface as due to no network coverage loss it's not possible to send data, and ****m internal buffer is full - that's why CTS goes high and stays this way.
Prior entering transparent **** please configure DTR toggle to exit data **** and return to command ****.
Side question - what kind of host sends data over ****m? A PC/MCU?
In case you are using STM32 microcontroller with HW flow control enabled, this MCU will toggle RTS line very frequently (after every single byte received) which may lead to ****m interface lockout.
Thanks for the prompt response,
It is fully understandable that CTS stays high in case of network coverage loss; however when modem switches back to 2G, I would expect CTS signal to toggle while sending the data at a lower data rate. The same would be true when the SIM card reaches maximum data volume and speed is throttled.
In both cases CTS stays high and modem stops reacting to any command including +++ escape sequence. Would using DTR ON/OFF instead make a difference ?
PS: the host controller is DSP (Analog Devices).
Kind regards,
Hi Tymoteusz,
I was wondering if anyone has got a solution/workaround to the problem. Would upgrading perhaps to a latest version help?
Kind regards,
Hello kbehaimanot,
I'm very sorry for missing your response - something failed and I didn't get any notification.
How do you check that ****m switches back to 2G from 3G or 4G? Via USB? ASC1?
CTS staying high indicates serial buffer overflow. The only way to recover would be to reset the ****m.
First of all please verify how often your host controller toggles RTS line - this is the main culprit of serial interface freeze.
When you meet ****m freeze condition, please check if it's still operational via USB.
Also let me know how much data are you trying to send.
Furthermore please try decreasing baudrate for sending data over transparent **** via serial.
Alternatively switch to USB.
Also update the ****m to arn0003000 as I can see there were some performance fixed included.
Hi Tymoteusz,
to check status of the connection, I use the "AT^SMONI" command via ASC0 (shortly before entering transparent ****).
The host controller toggles RTS immediately after CTS goes HIGH and waits for CTS to go LOW, which i believe is correct.
The ****m is used in an application where data files are to be continuously sent at 125Kbps. Considering the overhead of the opening/closing the internet service, entering/exiting transparent **** I have to use the maximum baud rate possible (921600).
The host controller does not support USB, so it is not an option.
Could you send me the download link of latest version (arn0003000 ) and the steps to do the update?
Best regards.
Hi,
I've sent you the link to the firmware. Please try.
Best regards,
Bartłomiej
Hi Bartlomiej
thanks, after i did the firmware upgrade, I'm getting new error during initial configuration.
^SYSLOADING
+PBREADY
ATE0
ATE0
OK
ATQ0
OK
AT^SPOW=1,0,0
OK
AT+CMEE=2
OK
AT^SCFG="tcp/withurcs","on"
^SCFG: "Tcp/WithURCs","on"
OK
AT^SICS=0,"conType","GPRS0"
+CME ERROR: Unknown
Regards,
kbehaimanot
Hello,
It looks like JRC is probably not running. This command is implemented in JRC and there is no ^SYSSTART URC in your log.
There must have been some error in firmware update procedure - JRC was not installed or autostart not activated. Please check AT^SJAM=4 to see if JRC is installed (compare with the installation package if the version is correct) and AT^SCFG to verify if userware autostart is enabled. You can also check the gWinSwup log file. If JRC is not installed you can try the complete procedure again or copy JRC files to the module and install like any other MIDlet.
Regards,
Bartłomiej
Hello kbehaimanot,
what I meant with RTS toggling is how often is this pin toggled by host device during normal operation.
Frequent RTS toggling is known to be a culprit of modem interface freeze.
Please check that with a logic analyser.
Best Regards
Tymek
Hi Tymoteusz,
the host does not toggle RTS during normal operation.
regards,
kbehaimanot