csp: Falcom told me, that they aren't supporting the Modems any longer and don't have new firmware versions available.
I found out that resetting the modem with
AT+CFUN=0,1
AT+CFUN=1,1
seems to reset the counter , so it has the same effect as powercycling the modem.
However I found another interesting problem which also seems to occur when really powercycling the modem by hand:
The returned message number after reset is starting with +CMGS: 21 not with +CMGS: 1
When I first used the modem, it started with +CMGS: 1
After the first overflow error, it started with +CMGS: 20
Adter the second overflow error, it started with +CMGS: 21
Now that I tried the reset without overflow, it started with +CMGS: 21
I'm a bit confused by this and I don't know why the starting number seems to increase on overflow.
Maybe another firmware bug?
Could it also be some SIM storage that the outgoing message is being stored to, that gets full with messages that couldn't be sent and therefore the message numbers get reserved so the starting number increases? Just guessing...
Maybe someone has experience with that...
|
csp:
To avoid invalid addressing (when nothing was received), it could rather be:
if (*answer && answer[strlen(answer)-1]!='r') strcat (answer, "r");
You're right, forgot about that back when I made the patch. I just wanted to try it, it worked and I never fixed it, oops :-)
After 255 is reached, the modem should continue from 1. I do not know if there is "reset" command available. The firmware is buggy and you must upgrade it, or buy a new modem.
I contacted Falcom Support and they told be that there was only one Firmware version for this modem and this *might* be a Firmware bug and I should buy a new modem. :evil:
However it's not true that there is only one firmware version available.
Our company sent in 50 modems to get a firmware upgrade from a buggy firmware 10 years ago.
The firmware Version I'm currently running on is 01.93.07
It seems that there is 01.93.08 as well, according to this dump:
http://gatling.ikk.sztaki.hu/~kissg/gsm/cquery/falcom_a2.txt
So I told Falcom to recheck if this bug was fixed in some version as there are different firmware versions out there (I also have a modem with firmware 01.93.01).
In the past I have tested reference number in the PDU, but many modems did not accept it.
Unfortunately you are right, Falcom A2 also isn't accepting the Message number in the PDI, it seems to ignore it. :(
Seems that I'm stuck with powercycling the modem...
|
csp: Operating system name and version: SuSe Linux Enterprise Server 10.2
Version of smsd: 2.2.20
Smsd installed from: sources
Name and model of a modem / phone: Falcom A2
Interface: serial
Hi, I'm using SMS Tools with a Falcom A2 Modem (http://sup.xenya.si/sup/info/falcom/a2/manuals/A2man.pdf)
Btw.: I got it working by adding the following code to the end of read_from_modem in modeminit.c:
// cspert, 13.12.2006 -> Hack for FALCOM (doesn't always return \r)
if (answer[strlen(answer)-1]!='\r') strcat (answer, "\r");
It works fine sending SMS messages, however after sending 255 messages, I have to powercycle the Modem to be able to send messages again.
The reason for this is, that the return Value of AT+CMGS (Message reference numer) is 8bit, so it overflows after sending 255 messages.
2010-12-15 15:15:40,7, GSM1: <- AT+CMGS=91
>
2010-12-15 15:15:40,7, GSM1: -> 0011000C9134...
2010-12-15 15:15:41,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:15:46,7, GSM1: <- 0011000C9134...
+CMGS: 255
OK
And then:
2010-12-15 15:15:47,7, GSM1: <- AT+CMGS=91
>
2010-12-15 15:15:47,7, GSM1: -> 0011000C9134...
2010-12-15 15:15:48,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:15:50,7, GSM1: <- 0011000C9134...
+CMS ERROR: 1
2010-12-15 15:15:50,3, GSM1: The modem said ERROR or did not answer.
2010-12-15 15:15:50,5, GSM1: Waiting 10 sec. before retrying
2010-12-15 15:16:00,6, GSM1: Checking if modem is ready
2010-12-15 15:16:00,7, GSM1: -> AT
2010-12-15 15:16:00,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:16:01,7, GSM1: <- AT
OK
2010-12-15 15:16:01,6, GSM1: Checking if modem needs PIN
2010-12-15 15:16:01,7, GSM1: -> AT+CPIN?
2010-12-15 15:16:01,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:16:01,7, GSM1: <- AT+CPIN?
+CPIN: READY
OK
2010-12-15 15:16:01,6, GSM1: Checking if Modem is registered to the network
2010-12-15 15:16:01,7, GSM1: -> AT+CREG?
2010-12-15 15:16:01,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:16:01,7, GSM1: <- AT+CREG?
+CREG: 0,1
OK
2010-12-15 15:16:01,6, GSM1: Modem is registered to the network
2010-12-15 15:16:01,6, GSM1: Selecting PDU mode
2010-12-15 15:16:01,7, GSM1: -> AT+CMGF=0
2010-12-15 15:16:01,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:16:02,7, GSM1: <- AT+CMGF=0
OK
2010-12-15 15:16:02,7, GSM1: -> AT+CMGS=91
2010-12-15 15:16:02,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:16:02,7, GSM1: <- AT+CMGS=91
>
2010-12-15 15:16:02,7, GSM1: -> 0011000C9134...
2010-12-15 15:16:03,7, GSM1: Command is sent, waiting for the answer
2010-12-15 15:16:05,7, GSM1: <- 0011000C9134...
+CMS ERROR: 1
2010-12-15 15:16:05,3, GSM1: The modem said ERROR or did not answer.
...
Now I would like to know what the Standard says about the behaviour of the modem, if you send more than 255 messages so that the message regerence number overflows. Does it have to start with 1 again, so, is this a firmware bug of the modem?
Or do I have to specify a fixed message number in the PDU packet and can I reuse the number to solve the problem (so using a number >0 in the 3rd byte of the PDU).
Or do I have to reset the internal message reference number somehow with an AT-Command?
Any help would be apreciated. I don't want to powercycle the modem every month.
Regards,
ert
|
