Nordic chars replaced
Tagged: char nordic 7bit
- This topic has 6 replies, 2 voices, and was last updated 11 years, 7 months ago by
Bryon Davis.
-
AuthorPosts
-
May 7, 2013 at 8:48 am #2926
Thomas
ParticipantWhen iSms 400 recieves a message containing nordic letters they are read wrong.
Examples:
“ø” becomes: “o”
“Ø” becomes: “O”
“Öäöå” becomes: “{|”
“€” (euro sign) becomes: “e”
When going to extreme and sending something like this:
§€£°C°F,öäå
is becomes:
00A720AC00A321032109002C00F600E400E50020
Is there a way to get these commonly used characters interpreted correctly og making iSMS send them as Hex then sending to non-polling http page?
Thanks
Thomas
May 10, 2013 at 7:35 pm #4530Bryon Davis
ModeratorHi Thomas,
The new v1.51.14 firmware supports the 3GPP 23.038 character set, which is a 7 bit characters set. All of those character are supported in this set. Below are the link to the v1.51.14 firmware.
To get support for the special characters change the following settings after you upgrade:
1. In SMS Settings menu, check “Enable PDU Mode” and click save.
2. In SMS Settings menu, change the ASCII 7 bit character set to “3GPP 23.038” and click save.
3. In SMS Settings menu, make sure Unicode and Extended ASCII are disabled, unless you plan to specify ASCII 7 bit encoding during the send.
SF100:
SF400-800:
Regards,
Bryon
August 19, 2013 at 10:23 am #4634Thomas
ParticipantHi,
The issue is solved with the solution provided, but the message is not send correctly to the Server default page when using the Non polling mode.
It seems that iSms is doing some kind to conversion before sending the XML to the non-polling page.
When sending a message like “æøå” the message looks o.k. when looking at it in the Inbox of the iSms. However when the XML is recieved on the server the Message has been transformed and the message looks like this: “���”
I have tried with “Preferred Character Set” set to “ISO-8859-1” and “UTF8”, but the result is the same. Actually the xml EncodingFlag is “ASCII” no mater the setting of “Preferred Character Set”.
When converting the recieved characters to bytes i get:
Using c# default encoding (ASCII): 65533;65533;65533;
Using c# UTF8 conversion: 239;191;189;239;191;189;239;191;189;The current firmware is v1.51.21.
Do you have any solution for this issue or any suggestions?
Thanks
Thomas
August 19, 2013 at 10:37 am #4635Bryon Davis
ModeratorHi Thomas,
If you are using ASCII 7 bit, the important setting for special characters is in the SMS Settings menu, change the ASCII 7 bit character set to “3GPP 23.038″ and click save. Using PDU mode may also help.What did the non-polling message show as the encoding type? If the encoding type is 8 bit Extended ASCII, there may be a difference in the character set used.
If you send from the iSMS back to itself, does it look correct? If you’re sending 7 bit it should ensure that you receive 7 bit, which should work with the “3GPP 23.038″ character set setting.
Regards,
BryonAugust 20, 2013 at 4:54 am #4637Thomas
ParticipantThe settings is as follows:
PDU mode: Enabled
ASCII 7-bit configuration: Charset = 3GPP 23.038
Ext. ASCII 8 bit conf: Nothing selected
Unicode conf: Nothing selected
HTTP API Configuration: Preferred Char Set: UTF-8The recived XML states “ASCII” in the EncodingFlag field. This doesn’t change regardless of the Preferred Char Set in the HTTP API Configuration.
When sending a message from the iSms Webinterface to a mobile phone the SMS is recieved correctly.
When sending a message from the iSms Webinterface to the iSms the SMS is recieved correctly.
I think the issue is related to the iSms’s generation of the XML scheme/content in th API as the modem side seems to work correctly after the firmware update and with 3GPP.
Best regards
Thomas
September 11, 2013 at 6:37 am #4662Thomas
ParticipantStill no solution for the non-polling mode.
Switching to polling mode. It works at it should.
September 11, 2013 at 7:57 am #4664Bryon Davis
ModeratorHi Thomas,
If you want to follow up on the non-polling issue, please create a case in our support portal at support.multitech.com. It will be much easier for us to troubleshoot it there.A couple of notes. The SMS Setting menu’s Extended ASCII and Unicode selections as the default encoding won’t effect the encoding of received sms messages. The encoding is controlled by the sender. The UTF-8 setting in the HTTP API Configuration is for receiving API requests. The non-polling posts are still the ISO-8859-1 character set. Sorry, the menu setting wasn’t clear on this.
Regards,
Bryon -
AuthorPosts
- You must be logged in to reply to this topic.