>Hey Guys, I'm trying to send an operator logo to a 3390 handset, and Im
>having some weirdness. i can send data, but when I hit save, it doesnt
>actually replace my logo (I read thats because the MCC/MNC dont match the
>ones used on my phone currently) I've determined that FIDO (my carrier) uses
>302-37 as the MCC/MNC. I converted these to HEX and came up with 12E 25 (So,
>I put in %12%0E%25 into my URL). Still no luck. Can anyone explain? I've
>been pulling my hair out reading hte nokia specs all day. thanks
The operatorcode is constructed:
%30 %ab %cd %ef %0A
where %ab %cd %ef are operator specific. They are constructed out of
the mobile network code and the mobile coutry code and are in
reversed BCD format.
Meaning for a MCC = 234 and MNC = 10 (BT Cellnet)
you will get %32%F4%01
so your 302-37 becomes %03%F2%73.
I've attached a document I once wrote for encoding. Gives a few hints...
--
Andreas Fink
Fink-Consulting
------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com
------------------------------------------------------------------
Something urgent? Try http://www.smsrelay.com/ Nickname afink
Here's some examples for you.
--HEADER---
To send binary messages you have to set "udh" to the following value
&ud=%06%05%04%a1%a2%b1%b2
a1/a2 are the sender port
b1/b2 are the receiver port (usually zero)
%06 says that the total UDH header is 6 bytes
%05 says its a information element of "WAP Port"
%04 says that this information element is 4 bytes long
%a1%a2 are the two bytes specifying the destination port
%b1%b2 are the two bytes specifying the source port
Example:
VCALENDAR
&udh=%06%05%04%23%F5%00%00
PICTURE + TEXT (Multipart)
&udh=%06%05%04%15%8A%00%00
OPERATOR LOGO
&udh=%06%05%04%15%82%00%00
RINGTONE
&udh=%06%05%04%15%81%00%00
--CONTENT---
The content is the content of the &text= value and can be binary and
contain zero's. So it is as usual URL encoded.
Pictures (in general) are constructed using the OTA spec.
OTA means:
byte 0: Version & flags. Usually %00
byte 1: width of the image
byte 2: height of the image
byte 3: bithdepth of the image. %01 for black and white.
byte 4: and following are the pixels of the image.
Then whats following is the image as a BITALIGNED structure.
If you are familiar with LogoManager (www.logomanager.co.uk), they
are writing the image file (NLM) the same way but with 6 bytes in
addition in the header and the image being BYTE aligned. I use the
NLM format for storing the image so I have a C routine which changes
from byte-aligned to bitaligned. This does only apply for large
pictures as the small ones are falling on a bit/byte boundary. If you
need that, let me know. It's a plain C routine.
The operatorcode is constructed:
%30 %ab %cd %ef %0A
where %ab %cd %ef are operator specific. They are constructed out of
the mobile network code and the mobile coutry code and are in
reversed BCD format.
Meaning for a MCC = 234 and MNC = 10 (BT Cellnet)
you will get %32%F4%01
Ringtones you apparently have the spec. I've never created ringtones.
I simply send whats in the file and use LogoManager's converter to
create OTT files which are the binary representation of the ringtones.
Pictures with text (Multipart message)
This is
%30 version
%00 text part
%length of text (high byte)
%length of text (low byte)
....bytes of text...
%02 picture part
%length of picture (high byte)
%length of picture (low byte)
...bytes of picture...
etc. etc.
----------------------------------------------------
Now to the splitting of SMS. On our system you dont have to split the
data. The system does automatically split the data into chunks and
modifies the user data header on the fly.
If you dont leave the splitting of SMS to us you have to expand the
UDH header by adding another information element, the concatenation
element.
generally a UDH header is built out of:
byte 1: length of total UDH header
byte 2: information element type
byte 3: length of this information element
byte 4...n the information of that element
byte n+1: next information element type
byte n+2: next information element size..
etc etc.
information element types:
type=%05 means its a WAP port information
type=%00 means its a concatenation information
there are others I never used.
WAP Port information (type %05)
Example:
%06 %05 %04 %23%F5 %00%00
%06 means there are 6 bytes total in this UDH (not including this byte)
%05 means this is a WAP port information
%04 means there are 4 bytes following
%23%F5 is the destination port
%00%00 is the source port
concatenation example:
%06 means there are 5 bytes total in this UDH (not including this byte)
%00 means it is a concatenation info
%03 means there is 3 bytes in this info element
%F1 means this is in reference to message F1 (To distinguish separate
SMS from each other)
%02 means there are two parts in total
%01 means this is part 1
If you have both informations as when sending a large picture:
%0B means there are 11 bytes total in this UDH (not including this byte)
%05 means this is a WAP port information
%04 means there are 4 bytes following
%23%F5 is the destination port
%00%00 is the source port
%00 means it is a concatenation info element
%03 means there is 3 bytes in this info element
%F1 means this is in reference to message F1 (To distinguish separate
split SMS from each other)
%02 means there are two parts in total
%01 means this is part 1
Example
First one:
%0B %05 %04 %15 %8A %00 %00 %00 %03 %0F %02 %01
Second one:
%0B %05 %04 %15 %8A %00 %00 %00 %03 %0F %02 %02
The code I use does pack 128 bytes into the first packet. Why 128?
There are total 140 bytes to be used (if you encode text, its 160
bytes but there the text is 7 bit encoded, not 8 bit binary). Now the
user data header is part of the message too. In the above example it
uses 12 bytes. 140 - 12 are 128 bytes you can use for "payload".
hope this helps to get further...
