bakai wroteBelow answers form polish hardware reseller&support:
Thank's for the answers.
QuoteNo, baud rate is OK, but answer is unexpected by minicom - containing additional prefix before oryginal modem response, prefix as '-->gxx > ' where xx are module number.
That is not the issue.
Minicom is just a terminal program which will show any response received from the modem. In this case, the prompt for PDU (>) was not received. From the screen capture we can see it:
at&g0=AT+CMGS=16
<++g00 AT+CMGS=16 (long wait, about 20s)
OK
The line mentioned is missing. The communication should be (missing line shown in red):
at&g0=AT+CMGS=16
<++g00 AT+CMGS=16
-->g00 >
OK
From the log of smsd it can be seen, that the module was trying to give the prompt, but the gateway did not deliver it to the serial port at the correct time:
GSM0: -> at&g0=AT+CMGS=19
GSM0: Command is sent, waiting for the answer. (20)
GSM0: Incorrect answer, put_command expected (>)|(ERROR), timeout occurred. 1.
GSM0: time 20527 ms <- at&g0=AT+CMGS=19 <++g00 AT+CMGS=19
GSM0: -> at&g0=001100099106368895F00000FF0673F29C3C2703.
GSM0: Command is sent, waiting for the answer. (60)
GSM0: time 505 ms <- -->g00 > -->g00 +CMS ERROR: 500 OK (Unknown error)
GSM0: Command is sent, waiting for the answer. (20)
GSM0: Incorrect answer, put_command expected (>)|(ERROR), timeout occurred. 1.
GSM0: time 20527 ms <- at&g0=AT+CMGS=19 <++g00 AT+CMGS=19
GSM0: -> at&g0=001100099106368895F00000FF0673F29C3C2703.
GSM0: Command is sent, waiting for the answer. (60)
GSM0: time 505 ms <- -->g00 > -->g00 +CMS ERROR: 500 OK (Unknown error)
The answer which was received before timeout expired is shown in green, and it contains first two lines only. After the next command is sent to the gateway, missing prompt is received. It's shown in red.
In the first post of this topic there was at&g0=AT+CMGF=1 used and SMS was sent successfully. I assume that at&g0=AT+CMGS=destination_number and at&g0=Message was used, which means that with ASCII mode the communication works as expected. However, smstools does not use ASCII mode because all messages cannot be presented using this mode.
Quote> Do you know if there are any possibilities to upgrade the firmware for
> those modules?
No possiblities, for upgrade modules will be removed from device and insert to dedicated service box.
My question probably was incorrect
. I meant firmware of the Gateway, because it seems that there is nothing wrong in the GSM modules.QuoteFor send SMS via 2N gateway is necessary send different commands - special macro commands to gateway, not to module.
As described below:
;catch SMS controlling to interface who sending command (serial port in this case)
...
This means that whole gateway is locked (to low-level controlling for SMS) when any interface wants to send single SMS using single device. Only one SMS can be sent at the time, even if there are up to 31 devices available (depending of a model of the gateway). This does not sound very good, but of course I understand that the main purpose of this gateway is not sending lot of SMS using the serial interface.
In this topic the question was about using one device only, but I have also been asked whether support for multiple devices (4, or up to 20 - 40) can be provided by smstools3. It of course is impossible, or makes no sense, when only one device can send at a time. Those who need multiple devices for bulk sending should select a different gateway.
The locking is required if there are other interfaces which can use devices, or the gateway itself sends some SMS. I do not know this 2N device well, and have none of them, but at least in the manual there is some "no answer sms text" mentioned, and this may mean that gateway will send SMS in some cases. If this kind of usage can all be disabled, there should be no reason for locking and direct AT commands could be used - if they work properly. Also the gateway should work without problems even when there is lot of traffic, let's say more than ten or twenty devices sending and receiving simultaneously. I have no experience on how this gateway can handle simultaneous traffic, so cannot say anything about this.
In any case the syntax for low-level controlling is specific for this device, and I'm not willing to add non-standard commands to the smstools3. Even when some "AT^SM=#,Len,PDU,chk" looks easy, it's not enough. "Locking" and other commands are required too, and the next support question may be "how can I select the module used for sending". Or "receive SMS only from the module which is used for sending".
So, I recommend to use this device just as a GSM gateway, which is it's main functionality, and use different modems for SMS gateway.
It clearly is not the bug in minicom, but this attitude is a common: always the bug is in the "another" software...