I have a text
“This is part 1.”

when it is encoded without padding bits it has the following encoded hex values
54 74 7A 0E 4A CF 41 F0 B0 9C 0E 8A B9 00

but when with padding is used then it has the following hex pattern
A8 E8 F4 1C 94 9E 83 A0 61 39 1D 14 73 01

I can not convert from gsm-7 character set to gsm-7 character set with encoding , I need to know that how ths is done , I used this algorithm mentioned in this blog but it doesnt seem to be working for this , please help me out what I am missing

Thanks in regards

/*
GSM-7 packing routing.
Written by Emil.E
emil.elazar@mail.huji.ac.il
Israel
*/

int SMS_GSMDecode(unsigned char *dest, const unsigned char *source,int length)
{
int i = 0, j=0, s=0;
int num_ext_bits = 1;
unsigned char ext_bits[7]={0,0,0,0,0,0,0};
unsigned char temp=0;

for (i = 0; i =8) num_ext_bits=1;
ext_bits[j] = source[s] >> (8-num_ext_bits);
temp = source[s]<>(num_ext_bits);
if(j>0)
dest[i] = (dest[i] << j) | ext_bits[j-1];

num_ext_bits++;
}

dest[i] = '';
return 1;
}

Best Regards,
Emil

“How to UNpack septets characters into GSM-7 charset”?

My complication is that I am actually trying to pack the text to be sent in an SMPP msg that will then
be sent via GSM to the handset. The length in SMPP is defined in octets.

Is this even valid? Or should the SMSC (the receiver of the SMPP msg) be the one doing the packing?

Thanks
Tom

In my personal experience, all modern devices look at the UDL (User Data Length; which in the case of GSM-7 is expressed in septets) to determine the size of the payload. This avoids any confusion regarding padding bits being interpreted as ‘@’ and <CR> being ignored.

So to be short, as long as you have your UDL correct, this does not need to be handled (I know my code doesn’t handle this).

It is a common bug to first encode the payload and then determine the UDL from the number of octets that the encoded payload occupies. In this case the section you quote may save you.

Jeroen

http://www.3gpp.org/ftp/Specs/html-info/23038.htm
From 3GPP TS 23.038 V9.1.1 (2010-02)

If the total number of characters to be sent equals
(8n – 1) where n=1,2,3 etc. then there are 7 spare bits at the end of the message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the carriage return or <CR;> character (defined in clause 6.1.1) shall be used for padding
in this situation, just as for Cell Broadcast.

If <CR> is intended to be the last character and the message (including the wanted ) ends on an octet boundary, then another <CR> must be added together with a padding bit 0. The receiving entity will perform the carriage return function twice, but this will not result in misoperation as the definition
of <CR> in clause 6.1.1 is identical to the definition of <CR><CR>. The receiving entity shall remove the final <CR> character where the message ends on an octet boundary with <CR> as the last character.

If not, then how is this case handled in gsm sms?