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

csp wrote

Version of smsd: 2.2.20

Why?

csp wrote

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");

[ Select ]

To avoid invalid addressing (when nothing was received), it could rather be:
if (*answer && answer[strlen(answer)-1]!='\r') strcat (answer, "\r");

...or with !strchr(), but with well working modems this has never been required.

csp wrote

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.

...

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?

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.

In the past I have tested reference number in the PDU, but many modems did not accept it. You could try by changing the source code: change 00 to 23 and recompile. If you then receive a reference number 35 for each message, your modem will work with selectable reference number. But currently there is no option for this, not even in 3.x.

keke wrote

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 :-)

keke wrote

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.
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).

keke wrote

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...

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 wrote

Falcom told me, that they aren't supporting the Modems any longer and don't have new firmware versions available.

Not a surprise...

csp wrote

I found out that resetting the modem with

AT+CFUN=0,1 AT+CFUN=1,1

[ Select ]

seems to reset the counter , so it has the same effect as powercycling the modem.

With eventhandler you could check if the counter has gone too high. With SMSTools3, regular_run* features could be used for sending those commands to the modem. But still this does not look very good...

csp wrote

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?

There can be anything... Sooner or later you have to buy a new modem. This Falcom A2 belongs to the museum, or trash...

csp wrote

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...

I'm not sure what storage this device uses for sending. In the case of SIM, smsd will read all messages out, and outgoing or "stored sent" messages are not handled. All messages are however deleted.