Getting CELL BROADCAST message in Saudi Arabia

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

aquaa - 10 Aug 2006 14:55 GMT

To get the cell broadcast message in saudi arabia, using a local
operator, what do i need to do, and which AT commands are used?

Below the commands and their results taken using the siemens tc35i
modem, with ucs2 character coding.

> Sent commands:

at+cmgf=1
at+cscs=usc2
AT+CNMI=2,0,2,0,1+CSCB=0,"50,200","0-99"

> The Result:

+CBM: 49168,50,88,1,1
0040002400A300BF00F9002000D8004000440040002000A50070000D004000310040004400A300F200F9004000E60040002000F800C6003100A1004800A300F9005003A30038006200BF000D0040000D004000340040005000A300A100F90040039E004000680040002000A50040000D004000340040005000A300A100F90040039E004000680040002000A50040000D004000340040005000A300A100F90040039E004000680040002000A50040000D0040003400400050

Which alphabet, coding scheme used in cbm messages ?

Thanks ..

Reply to this Message

John Henderson - 10 Aug 2006 22:34 GMT

> To get the cell broadcast message in saudi arabia, using a
> local operator, what do i need to do, and which AT commands
[quoted text clipped - 10 lines]
>> The Result:
> +CBM: 49168,50,88,1,1

0040002400A300BF00F9002000D8004000440040002000A50070000D004000310040004400A300F200F9004000E60040002000F800C6003100A1004800A300F9005003A30038006200BF000D0040000D004000340040005000A300A100F90040039E004000680040002000A50040000D004000340040005000A300A100F90040039E004000680040002000A50040000D004000340040005000A300A100F90040039E004000680040002000A50040000D0040003400400050

> Which alphabet, coding scheme used in cbm messages ?

As per GSM 07.05, clause 3.4.1, the "+CBM: 49168,50,88,1,1"
result code indicates text-mode representation of the form:

+CBM: <sn>,<mid>,<dcs>,<page>,<pages>

indicating message serial number 49168, cell broadcast channel
50, 16-bit USC2 coding, and page 1 of 1. See GSM 03,38, clause
5, for the interpretation of your DCS 88 decimal (01011000
binary) as uncompressed USC2.

I can only assume that your modem isn't able to display the
range of USC2 characters, and has represented the message data
in hex format instead. Each hex character in this
representation codes 4 bits, so each 16-bit USC2 character is
in turn represented by 4 hex characters. So the first USC2
character is "0040", followed by "0024", and so on.

If there's any doubt about the encoding. I'd be inclined to read
the CB data in raw, uninterpreted PDU-mode, and decode that.
You can do this after a reset ("ATZ"), and setting up PDU-mode
("AT+CMGF=0"), but leaving out the "at+cscs=usc2" command.

John

Reply to this Message

John Henderson - 10 Aug 2006 23:39 GMT

I wrote:

> I can only assume that your modem isn't able to display the
> range of USC2 characters, and has represented the message data
> in hex format instead.

Reading some TC35 documentation, I see that your "at+cscs=usc2"
command _forces_ the display of the message data into
hexadecimal format thus:

"UCS2 character strings are converted to hexadecimal numbers
from 0000 to FFFF; e.g. "004100620063" equals three 16-bit
characters with decimal values 65, 98 and 99," So what do you
see in text-mode without that command?

John

Reply to this Message

Dean - 12 Aug 2006 20:09 GMT

>To get the cell broadcast message in saudi arabia, using a local
>operator, what do i need to do, and which AT commands are used?
[quoted text clipped - 14 lines]
>
>Thanks ..

Change the outgoing OCD to character set 4, it will work then.

Reply to this Message

aquaa - 12 Aug 2006 20:27 GMT

+CSCB: <mode>, <mids>, <dcss> = +CSCB=0,"50,200","0-99"

You mean the <dcss> part of cb request? Which is 0-99 in my cb
activation string ?

Dean yazdi:

> >To get the cell broadcast message in saudi arabia, using a local
> >operator, what do i need to do, and which AT commands are used?
[quoted text clipped - 16 lines]
>
> Change the outgoing OCD to character set 4, it will work then.

Reply to this Message

John Henderson - 12 Aug 2006 23:07 GMT

> +CSCB: <mode>, <mids>, <dcss> = +CSCB=0,"50,200","0-99"
>
> You mean the <dcss> part of cb request? Which is 0-99 in my cb
> activation string ?

I'm not sure what Dean means either, but changing your
"AT+CNMI"/"AT+CSCB" command will not change the appearance of
the decoded text.

What is the exact problem you're trying to solve? The hex data
you're getting isn't in the Arabic range, see:

http://www.unicode.org/charts/PDF/U0600.pdf

(USC2 is 16-bit unicode). Is that the problem?

I'd like to see what you're receiving in PDU-mode.

John

Reply to this Message

aquaa - 13 Aug 2006 12:02 GMT

this, is not an computer based tracking of cb messages,
but a sample kit with a gsm modem and a microcontroller and etc.

So, diving into the pdu decoding with my microcontroller :) is a bit
frustrating now :)

In european languages, there is no problem with sending messages, or
receiving CB.

But In arabic, text messages comes with %&++/ characters.
And with the ucs2 mode, the CB obviously doesnt come in between
0600-06FF which is unicode specification of arabic lang.

The above charaters are those that IC gets, when it requests CB from
the network.

The original CB consists of latin characters and arabic charachters
both.

The way i request the CB is having problems as far as i get.
The modem is siemens TC35 and 2.20 version. Dont think it doesnt
support kind of CB.

Any help, idea is appreciated..

Thanks for the time you share.

> > +CSCB: <mode>, <mids>, <dcss> = +CSCB=0,"50,200","0-99"
> >
[quoted text clipped - 15 lines]
>
> John

Reply to this Message

John Henderson - 13 Aug 2006 21:45 GMT

> this, is not an computer based tracking of cb messages,
> but a sample kit with a gsm modem and a microcontroller and
> etc.
>
> So, diving into the pdu decoding with my microcontroller :) is
> a bit frustrating now :)

OK, I understand, But PDU-encoding of USC2 characters will use
a much simpler algorithm than that used for the packing of
7-bit characters from the default GSM alphabet. That's because
character boundaries are also octet boundaries.

> In european languages, there is no problem with sending
> messages, or receiving CB.
[quoted text clipped - 3 lines]
> between 0600-06FF which is unicode specification of arabic
> lang.

I have a Siemens TC35 "AT Command Set" manual. It says that the
TC35 "uses 2 character sets: GSM 03.38 ... and UCS2".

The default 7-bit alphabet from GSM 03.38 is obviously of no use
to you in this application, so USC2 (via hex representation) it
has to be.

So I'd expect to see Arabic characters in the range 0600-06FF in
the "+CBM:" result, given the way you've got the TC35 set up.

Can your microcontroller handle these hex representations in the
way you need it to?

And why aren't we seeing them (06xx characters) in hex in your
output beginning
"0040002400A300BF00F9002000D8004000440040002000A"? The reason
I was hoping to see both a text-mode and a PDU-mode output from
the same cell is to try to understand where and how the USC2
characters might be having the high bits masked in the
translation to text-mode.

> The above charaters are those that IC gets, when it requests
> CB from the network.
[quoted text clipped - 5 lines]
> The modem is siemens TC35 and 2.20 version. Dont think it
> doesnt support kind of CB.

There may be a bug in the firmware. From reading the manual,
the TC35 is obviously supposed to support USC2 via hex
representation.

> Any help, idea is appreciated..

A look at PDU-mode output just might help us understand what's
going on, and possibly even devise a work-around.

> Thanks for the time you share.

You're welcome.

John

Reply to this Message