BGS2T RS232 flow control issue | Telit Cinterion IoT Developer Community
March 28, 2018 - 3:55pm, 7104 views
a few years ago I developed an embedded solution where my MCU communicates via the GPRS connection of a Cinterion MC55i terminal. The PPP connection is established with AT commands thrugh the RS232 interface, baud rate 115200, RTS CTS hard flow control.
Now I need to replace the modem with the newer BGS2T RS232 model but I've got some incompatibility issues. It seems to be something related to flow control because if I disable it the MCU can establish the PPP connection while if enabled it fails in handshaking phases. Maybe these terminals have different default settings so I need to adjust them to get it work with my application.
I setup the connection with the following AT commands:
Are there anyting else I should do to get it work succesfully?
AT+CFUN=1 restores full functionality mode in case the module is in a sleep mode. Sleep mode could potentially cause some problem especially if there is no hardware flow control configured (AT\Q0). But '1' is the default and factory setting and it is also restored by AT&F. You could check AT+CFUN? when the module starts. But I suppose that it should be 1. So this solution is interesting especially that in the link there is a discussion about some other manufacturer's module.
as you've already supposed the AT+CFUN? return 1 when the module start. Could this behaviour be related to an issue on the firmware? Anyway it seems to work for me but I'm continuing with other test to be more sure.
I don't think that there is some firmware issue especially that we have here two modules from two different vendors. Until these two have the chipset inside that comes from the same third party company which in theory is possible. But I'd rather think that this is some specifics of the Linux system (I don't know if your MCU runs Linux but in the link that you have provided there is Linux system used), hardware or ppp stack implementation. Some tracing would be needed to possibly catch if something specific is happening on the interface after CFUN command or what are the differences when the module is connected to Windows system for example. I believe that this command should not be needed there or is not issued by the standard dialup procedure. You could at least compare the serial interface trace of what happens with your MCU in both cases. But anyway this investigation might be time consuming and it's not obvious that you will be able to find the cause easily. So the best thing here is that you have the solution that only ***** to be tested more deeply.