It could be a timing issue. If you're missing the first few characters, then put in a small time delay before sending the message. It could be that the receiving hardware can't quite prepare for the message before your program is sending it out.

As an example, a long, long time ago, I had a similar problem with a different bit of equipment. In that case, it was due to a timing issue. You see, when you send a carriage return to a teletype (excedrin headache ASR-33), you need to wait a little while before sending the next character, unless you wanted to see it smudged through the center column as the printhead is returning to the left margin.

A few years later, working with some video terminals, I encountered something similar: Some sequences (clear screen, IIRC) needed an extra character time before you sent anything else, or the next character would be dropped. At least it wouldn't smudge somewhere on the screen... 8^)

Later still, working on a cow feeding system--(Don't ask!)--I encountered yet more systems where you needed to give a pause between particular control sequences. It's a relatively common thing to encounter in lots of embedded systems. Give it a try to see if that helps. (Just to prove it to yourself, I'd go ahead and use a significant delay, such as a couple seconds, to see if it clears things up. If so, then trim the time down until you get as much speed as you can reliably get. Then back off a bit.)

--roboticus

Update: After looking at your code, I notice that you're using the AT command codes to talk to your modem. You could insert the sequence "ATD;,\015" into your command sequence to provide a delay. (You can adjust the delay by setting the appropriate value in the S8 register. See an AT command reference for details.