I’me trying to use the sierraWirelessGL8200 and it seems that it doesn’t work in Hexadecimal transcoding mode. He only works in USC2.
When I try to configure in HEX, it responds me “OK” but when i receive messages from it, it’s encoded in USC2.
Moreover, when I lunch read request, it’s always transcoded in USC2.
Is it a “normal behaviour” ? I was wondering if there is something to flush to make it works.
In this state, we can’t advise our clients to use your product because, if Hex is not supported, they will have backward compatibility issues.
Also I think if the received SMS is encoded in UCS2 then there isn’t going to be an easy read across/translation from it to anything else. Could you give an example of what you are seeing?
SMS’s are a maximum of 140 bytes long, that’s a hard statement regardless of whether you are using a coding scheme of UCS2, hex or GSM 7 bit alphabet.
Re my CSCS setting I as a rule leave it as is and leave it on IRA but that does not change the scheme of the SMS to be sent, that is set in the PDU of the SMS itself, and as I say you would generally want to use PDU mode to send UCS2.
I want to use the The HEX transcoding with the Text mode. But the modem behaviour I observe is that:
With the configuration setted with CSCS = “HEX” and CMGF = 1 (TEXT mode).
When I send a message like Hello World, The modem sends 00480065006C006C006F00200077006F0072006C0064
Whereas, I expect to send
48656C6C6F20776F726C64
Why do you explicitly want to use the HEX coding scheme rather than a GSM 7 bit coding? If you want to send HEX data then you will be able to fit more into a text message using 7 bit coding than you would if you coded using HEX with text mode which clearly considers each character to be 16 bits.
If the objective is to send hexadecimal data then send it as GSM 7 bits characters (so for these they are the same as ASCII) characters and the other end just then reads it as hex.
Mixing text mode and different character sets is a recipe for disaster and misinterpretation/translation of alphabets at some stage.
Well, we chose HEX coding scheme because it’s recommended by the GSM ETSI :
chset (conversion schemes not listed here can be defined by manufacturers):
“GSM” GSM default alphabet (GSM 03.38 subclause 6.2.1); this setting causes easily software
flow control (XON/XOFF) problems
“HEX” character strings consist only of hexadecimal numbers from 00 to FF; e.g. “032FE6”
equals three characters with decimal values 3, 47 and 230