corrupt 7 character on 655


#1

Hello all

I have developed application to send sms using modem wavecom fastrack M1306B, and it work well (I have 20’s client). But when new modem arrived and I’m using it, there is error. Incoming message that received by ME (Mobile Equipment) is corrupt 7 character in the beginning, EX: when I’m sending message “Try this message” then the message that show by ME is “s message”. I check the new modem, the only difference between the old one and this new modem is in the firm wire, and the old one using 651 and the new one is 655. Does this difference create the error? I’m using text mode to send the message and not using PDU type.
Please help me.

Thanks


#2

How is the ME “showing” this?

ie, is the problem in receiving the message, or in processing the received message?

For info, Note that the term is “firmware”

Does the the same problem appear in other modems using 655 firmware?

If you load 651 firmware into this modem, does the problem go away?


#3

Awneil wrote:
How is the ME “showing” this?

ie, is the problem in receiving the message, or in processing the received message?

The problem I have is that when I try to send SMS using my application (developed using VB6) with the new modem (Firmware 6.55), the outgoing SMS will lose 7 characters in front of the text message (when it was received by a mobile phone), but when I tried to send SMS using hyperterminal, there was no such problem. I also have the older GSM Modem (Firmware 6.51), but I don’t have any problem with my application.

Awneil wrote:

For info, Note that the term is “firmware”

I’m sorry for the wrong term. Thank you.

Awneil wrote:

Does the the same problem appear in other modems using 655 firmware?

If you load 651 firmware into this modem, does the problem go away?

I have the same problem with the other modems from the same shipment (Firmware: 6.55). I have not tried to change the firmware because I don’t have the software that I need to update the firmware (dwldwl). My distributor gave me an invalid link to download that application.


#4

Hello Alfredo,
I am also using VB6 to send SMSs trough a 6.55 Fastrack and I haven’t seen that problem in months.

If you are able to send complete SMSs via hyperterminal then the problem is likely to be in your VB application. I would try to find the difference between hyperterminal and your app. I can think of 2 possible answers:

  1. Comm settings: baud rate, stop bits, handshake
  2. Typing speed (your hand is a lot slower that VB): when you send the AT+CGMS command, are you sure your app waits enough for the ‘>’ symbol before sending the message?

#5

optomation wrote

My setting application setting is :
115200,N,8,1

My modem setting is :
at&v
Q:0 V:1 S0:000 S2:043 S3:013 S4:010 S5:008
+CR:0 +CRC:0 +CMEE:1 +CBST:0,0,1
+SPEAKER:0 +ECHO:0,1 &C:1 &D:2 %C:0
+IPR:115200 +ICF:3,4 +IFC:2,2

optomation wrote

I use string variable, so when all the string is complete i use prosedure to sent the string into the port. Not by typing it. I Have text file that capture all (log file) the ATCommandR(espond) this is some of them :

This is a new one that i add some string so it work normal, but to me this method not the suitable/good one.


#6

After doing AT+CMGS=…
You need to WAIT for > to appear before you put in the text you want in the SMS.


#7

tobias wrote

It solved my problem. After I make some delay before sending message string, the program run smoothly. :smiley: .

But begining to think that on firmware 655 the algorithm had change and it make to proccessing string that come from rs232 became late.


#8

Of course it would.
The ‘>’ is what indicates that the module is ready to accept the text of the message; therefore, you should not send anything before you get that indication!

That is pure luck.
You need to wait for the ‘>’ prompt.
That’s why it’s called a “prompt” - it’s what indicates to you that you may send the message content

No; the algorithm is completely unchanged: the module sends the ‘>’ when it is ready - no sooner, no later.
There is absolutely no guarantee whatsoever as to the time that the module may take to give that prompt - that’s why you must wait for the ‘>’ prompt.
If an arbitrary delay happens to work, that is purely a matter of luck and is not to be relied upon!