TP-UDL differs between modems


I’ve been writing some code to support the sending/receipt of UCS-2 encoded SMS messages within our software product. (With a view to supporting Russian/Cyrillic).

I have test-run my code using a couple of different GSM modems, and have seen inconsistent results. I do not know if I’ve failed to set the appropriate device mode, mis-interpreted the GSM standard, or whether one or more of the modems I’ve used could be at fault.

The problem is this:

I send a 70 character long UCS-2 message to my Siemens TC35i modem. I see the result code come in

+CMT: , [],[,,,,,,,]

(I have set AT+CNMI=3,2 so that the TA forwards all unsolicited SMS results/messages to the TE).

I’ve also set +CSDH=1, so that I see all of the above message parameters.

I see the following field values:
= 0
= 8
= 140,

all of which is as I would expect.
Notably, the of 8 indicates that the message is not compressed (otherwise bit 5 would be set), and that UCS-2 encoding is being used (bit 3 is set).
And the field is 140 because the message is 70 UCS-2 characters i.e. 140 octets since each UCS-2 character is 16 bits.

When I send the same message to my Wavecom WMOD2 modem (from the same handset) I see a similar result code come in. (Obviously timestamp and message reference are different, but most of the important message parameters are the same.
The big difference which I do not understand is that the length is given as 70 not 140.

i.e. it’s as though it’s saying “70 characters” as opposed to “140 octets”. Can anybody please explain why this might be?

Section of GSM 03.40 seems fairly clear to me, that the length should be given in octets.
“If the TP-User-Data is coded using UCS2 data, the TP-User-Data-Length field gives an integer
representation of the number of octets within the TP-User-Data field to follow.”

Can anybody clarify please?
Is it the Siemens modem that is wrong, the Wavecom that is wrong, or are they both right - and I’m wrong!?

Are you using the same SIM in both modems?

Yes. Same SIM.

I should have added:

I see the same thing using a Maestro100 Lite modem, which as I understand it is ‘Wavecom inside’.

The length observed in the SMS Result when using the Siemens seems to my mind to be more in line with what it says in the standard, octets, - but currently I’m running two-to-one in favour of length being given in (UCS2) characters.

(Again it was the same SIM I used - transferred to the Maestro, and same message sent from same handset).

Any ideas?

You are right that the Maestro is “Wavecom Within” - it’s effectively just a Fastrack in a slightly different case!

You might try seeing what the following tools make of the message:

PDU Decoder at

Thanks for the links.

Perhaps I should have mentioned I set the command

(Text mode)

So typically I don’t see the incoming PDUs in the form expected by these programs, but in the more verbose style indicated in my top post.
It is arguably more human readable, I’d say, although feel free to disagree.

Anyway I have sent the same message again (from the same handset) to each modem (swapping over the SIM) - without setting this command.

Here are my PDU’s - I have just scrubbed out my phone number with asterisks, because I didn’t want everyone to know it.

Wavecom WMOD2

Siemens TC35i

Maestro 100 Lite

The difference between these PDUs comes down to just 3 or 4 bytes. The message is the same in each… a load of Cyrillic characters starting 042004210422042304240…
i.e. РСТУФ…

If we chop all that follows off just to make comparison easier, we get…

Which you can see is identical in each case up to the last four bytes.

The length appears to be the same in each, 8C, which allowing for byte/nibble-order is C8, which is 140 in decimal. Which is what I expect.

I’m not sure what the other three bytes mean. Again allowing for order I have:

46 38 00

38 15 00

30 00 00

I cannot see any difference in the decoded output as described by PDUSpy.

Incidentally, I do see a difference for any given PDU in the decoded outputs produced by the two tools.
PDUSpy says “No More Messages Waiting” which is what I’d expect, whereas PDUDecoder says “More Messages Waiting” - I decided to not use the latter any more since I don’t think it’s right (and it doesn’t seem to give as much information as PDUSpy anyway).

Anyway If anyone can tell me what these three bytes mean, and why they might result in a difference in the or TP-UDL when CMGF=1, I’d be most grateful.


These three bytes are just the difference in the time-stamp, aren’t they?

  • Which leaves me at a loss to my original question about length differing between modems.