| Splitting long binary EMS message |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through March 09, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Dimitris Unregistered guest |
I am trying to split a long EMS picture message. I receive a message but without the picture so I guess that I do not use the UDH correctly. I am trying to send the following picture: 00000001FFFF80000000000006001FF000000000000800183E00000000003000300B800000000040 003009E000000000800060087000000001000078083C000001FFFFF1FC0BFE00007FF55FFFFFFFFF 0003FF7FFFFFFFFFFDC005FBFFFFFFFFFFFEE009F7E7FFFFFFFFFFF00BFFC3FFFFFFFFFFF00FFFC3 FFFFFFFFFFF81FFFC7FFFFFFFFCFF83FFFEFFFFFFFFF3FF82FFFFFEEFFFFFE76E01BFFFFFBBFFFFA 7D001F0809CFFFFEFE77000FFFFF9DFBBFF23F0007013FAB6FF8011E0000867FBFF400008400007E 008EF000007800001C008FE00000000000000064E0000000000000003B8000000000 I try to split the message and use the following two UDHs: a) 8B0003020201128400091A00000001FFFF80000000000006001FF000000000000800183E00000000 003000300B800000000040003009E000000000800060087000000001000078083C000001FFFFF1FC 0BFE00007FF55FFFFFFFFF0003FF7FFFFFFFFFFDC005FBFFFFFFFFFFFEE009F7E7FFFFFFFFFFF00B FFC3FFFFFFFFFFF00FFFC3FFFFFFFFFFF81FFFC7 b) 730003020202126C00091AFFFFFFFFCFF83FFFEFFFFFFFFF3FF82FFFFFEEFFFFFE76E01BFFFFFBBF FFFA7D001F0809CFFFFEFE77000FFFFF9DFBBFF23F0007013FAB6FF8011E0000867FBFF400008400 007E008EF000007800001C008FE00000000000000064E0000000000000003B8000000000 As I mentioned I receive a message but an empty one so I guess there is something wrong with the headers. Has anyone tried something like this? Thanks in advance Dimitris | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1398 Registered: 10-2002 |
Hi Dimitris, The way that EMS requires the actual picture data or ring tone to be in the UDH is one of the most frustrating things about EMS. I've never used this particular technique before, so I can't give you an exact example, but hopefully I can point you in the right direction. In order to send this, I believe that there are two ways to do it. The preferred method is to send it as a EMS User Prompt Indicator, which allows you to specify that multiple variable picture objects within a set of concatenated messages should be stitched together. (The alternate approach is to use the EMS extended object format, but I don't think that is as widely supported.) So let's take your example, which is a 9 x 26 variable picture (72 pixels horz by 26 vert). Because of the UDH headers that are involved, there's going to be a good bit of overhead. I need to break the picture into 3 spearate pictures. The first will be 4 x 26 (the first four horizontal rows), the second will also be 4 x 26, and then the final picture will be 1 x 26. First: 00000001FFFF80000000000006001FF000000000000800183E00000000003000300B800000000040 003009E000000000800060087000000001000078083C000001FFFFF1FC0BFE00007FF55FFFFFFFFF 0003FF7FFFFFFFFFFDC005FBFFFFFFFFFFFEE009F7E7FFFF Second: FFFFFFF00BFFC3FFFFFFFFFFF00FFFC3FFFFFFFFFFF81FFFC7FFFFFFFFCFF83FFFEFFFFFFFFF3FF8 2FFFFFEEFFFFFE76E01BFFFFFBBFFFFA7D001F0809CFFFFEFE77000FFFFF9DFBBFF23F0007013FAB 6FF8011E0000867FBFF400008400007E008EF00000780000 Third: 1C008FE00000000000000064E0000000000000003B8000000000 Applying the UDH headers, the messages will look like this... Message #1: 75 (UDH Len) 0003FF0301 (concatenation header, msg 1 of 3) 130103 (EMS UPI, 3 parts) 126B00041A (variable picture 4 x 26) 00000001FFFF80000000000006001FF000000000000800183E00000000003000300B800000000040 003009E000000000800060087000000001000078083C000001FFFFF1FC0BFE00007FF55FFFFFFFFF 0003FF7FFFFFFFFFFDC005FBFFFFFFFFFFFEE009F7E7FFFF Message #2: 71 (UDH len) 0003FF0302 (concatenation header, msg 2 of 3) 126B00041A (variable picture 4 x 26) FFFFFFF00BFFC3FFFFFFFFFFF00FFFC3FFFFFFFFFFF81FFFC7FFFFFFFFCFF83FFFEFFFFFFFFF3FF8 2FFFFFEEFFFFFE76E01BFFFFFBBFFFFA7D001F0809CFFFFEFE77000FFFFF9DFBBFF23F0007013FAB 6FF8011E0000867FBFF400008400007E008EF00000780000 Message #3: 23 (UDH len) 0003FF0303 (concatenation header, msg 3 of 3) 121D00011A (variable picture 1 x 26) 1C008FE00000000000000064E0000000000000003B8000000000 I was able to send this out to a T68i, and the phone recognised it as a download object, and prompted me to save it. The picture was garbage, however, so I'm not sure if that's because it was garbage to begin with, or if I did something wrong in the encoding. If you're doing complex EMS stuff like this, you might want to look at the toolkit from www.businesms.com. I haven't had the time to try the toolkit myself, but I do see from the spec that it supports this type of UPI encoding for EMS. Good luck! -bn | |||
| Dimitris Unregistered guest |
Thank you, Bryce, that was the way and it worked pretty well on an Ericsson T300 and a Siemens SL55. The difficult part was - and is from now on - to split the picture vertically in smaller parts and not horizontally as you did (thus taking parts of 4 bytes for each line from the binary and concatenating them and not just splitting the binary). Thanks again Dimitris | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1402 Registered: 10-2002 |
Dimitris, I thought you were supposed to split the picture horizontally. At least a diagram in the SonyEricsson EMS Developers' Guidelines document seemed to say this was how it was done. Could you post the resulting messages that you generated from your example above? -bn | |||
| Dimitris Unregistered guest |
I thought so to and when I tried to split a 72 x 28 picture horizontally in two 72 x 14 pictures the message was received with a 144 x 14 picture so then I tried splitting it vertically. The following picture was sent successfully : 00000000000000000000000000000000000000000001FFFF80000000000006001FF0000000000008 00183E00000000003000300B800000000040003009E000000000800060087000000001000078083C 000001FFFFF1FC0BFE00007FF55FFFFFFFFF0003FF7FFFFFFFFFFDC005FBFFFFFFFFFFFEE009F7E7 FFFFFFFFFFF00BFFC3FFFFFFFFFFF00FFFC3FFFFFFFFFFF81FFFC7FFFFFFFFCFF83FFFEFFFFFFFFF 3FF82FFFFFEEFFFFFE76E01BFFFFFBBFFFFA7D001F0809CFFFFEFE77000FFFFF9DFBBFF23F000701 3FAB6FF8011E0000867FBFF400008400007E008EF000007800001C008FE00000000000000064E000 0000000000003B8000000000 with the following 3 messages : 1st: 7D0003110301130103127300041C0000000000000000000000010000000600000008000000300000 004000000080000001000001FFFF007FF55F03FF7FFF05FBFFFF09F7E7FF0BFFC3FF0FFFC3FF1FFF C7FF3FFFEFFF2FFFFFEE1BFFFFFB1F0809CF0FFFFF9D07013FAB00867FBF007E008E001C008F0000 00640000003B 2nd: 7A0003110302127300041C0000000000000000FFFF8000001FF00000183E0000300B80003009E000 6008700078083CF1FC0BFEFFFFFFFFFFFFFFFDFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFF FFFF3FFFFFFE76BFFFFA7DFFFEFE77FBBFF23F6FF8011EF4000084F0000078E0000000E000000080 000000 3rd: 260003110303121F00011C0000000000000000000000C0E0F0F0F8F8F8E0000000000000000000 Try it and if you would like to know how I created the three binaries tell me to describe it in another post. Dimitris PS: The 041A size that you used in your previous post is a 32 x 26 picture, not 4 lines of the original picture. I guess that it is the UPI that requires the picture to be splitted vertically. | |||
| Andrew Molteno Unregistered guest |
Hi This is very interesting and just what I needed. I have a comment/question. If you define the 'split images' as variable pictures 72 pixels horizontally then possibly you could split the full image horizontally. i.e. the reason you have to split the image vertically in this example is that the width of your split images is 32 pixels. I have not tested this. | |||
| Kirk Bateman Unregistered guest |
The width part of the image is the width in pixels div 8, so for a 72x28 image the width would be 9. Just thought i'd mention that. | |||
| Anonymous |
Hi I am just studying the format of EMS picture msgs. Wld request You to explain how u created the above 3 binaries tks pk | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1682 Registered: 10-2002 |
I think we might have some terminology issues here as to whether the image is split horizontally or vertically. But I think that Dimitris has indeed split the image horizontally, as the picture will be stitched together horizontally by the receiving device. (In my earlier example, I actually split the image vertically, which was incorrect.) So let's look closer at Dimitris's example ... The example is a 72 (width) x 28 (height) picture. He has split it into 3 pictures. The first is 32 (width) x 28 (height), the second is 32 (width) x 28 (height), and the last is 8 (width) x 28 (height). So, maybe my way of thinking is wrong, but in my mind the picture has been split horizontally, as it is the 3 pictures are stitched together horizontally. Let's revisit his example: 00000000000000000000000000000000000000000001FFFF80000000000006001FF0000000000008 00183E00000000003000300B800000000040003009E000000000800060087000000001000078083C 000001FFFFF1FC0BFE00007FF55FFFFFFFFF0003FF7FFFFFFFFFFDC005FBFFFFFFFFFFFEE009F7E7 FFFFFFFFFFF00BFFC3FFFFFFFFFFF00FFFC3FFFFFFFFFFF81FFFC7FFFFFFFFCFF83FFFEFFFFFFFFF 3FF82FFFFFEEFFFFFE76E01BFFFFFBBFFFFA7D001F0809CFFFFEFE77000FFFFF9DFBBFF23F000701 3FAB6FF8011E0000867FBFF400008400007E008EF000007800001C008FE00000000000000064E000 0000000000003B8000000000 Splitting this image horizontally is challenging, but here's another way of looking at the above picture. Let's reformat the data so that the hex display includes one vertical row per line of text. A 72 width image is represented by 9 bytes of data. So all I've done here is taken the above data and put a line break after every 9th byte: 000000000000000000 000000000000000000 00000001FFFF800000 00000006001FF00000 0000000800183E0000 0000003000300B8000 00000040003009E000 000000800060087000 000001000078083C00 0001FFFFF1FC0BFE00 007FF55FFFFFFFFF00 03FF7FFFFFFFFFFDC0 05FBFFFFFFFFFFFEE0 09F7E7FFFFFFFFFFF0 0BFFC3FFFFFFFFFFF0 0FFFC3FFFFFFFFFFF8 1FFFC7FFFFFFFFCFF8 3FFFEFFFFFFFFF3FF8 2FFFFFEEFFFFFE76E0 1BFFFFFBBFFFFA7D00 1F0809CFFFFEFE7700 0FFFFF9DFBBFF23F00 07013FAB6FF8011E00 00867FBFF400008400 007E008EF000007800 001C008FE000000000 00000064E000000000 0000003B8000000000 If we want to split this image horizontally for sending out over EMS, we need to break it apart horizontally. We can do two 32 (width) x 28 (height) images, and one 8 (width) x 28 (height) image. As the image is being split horizontally, the data nees to be split horizontally. The first four bytes of each row of data represent the 32 pixels of the image. So the blue bit shows the first 32 x 28 image, the green bit shows the second 32 x 28 image, and the red bit shows the final 8 x 28 image. This gives you the following messages: Message #1: 7D (UDH len) 0003110301 (concatenation header, msg 1 of 3) 130103 (EMS UPI, 3 parts) 127300041C (variable picture 4 x 28 or 32 x 28 pixels) 00000000 00000000 00000001 00000006 00000008 00000030 00000040 00000080 00000100 0001FFFF 007FF55F 03FF7FFF 05FBFFFF 09F7E7FF 0BFFC3FF 0FFFC3FF 1FFFC7FF 3FFFEFFF 2FFFFFEE 1BFFFFFB 1F0809CF 0FFFFF9D 07013FAB 00867FBF 007E008E 001C008F 00000064 0000003B Message #2: 7A (UDH len) 0003110302 (concatenation header, msg 2 of 3) 127300041C (variable picture 4 x 28 or 32 x 28 pixels) 00000000 00000000 FFFF8000 001FF000 00183E00 00300B80 003009E0 00600870 0078083C F1FC0BFE FFFFFFFF FFFFFFFD FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFCF FFFFFF3F FFFFFE76 BFFFFA7D FFFEFE77 FBBFF23F 6FF8011E F4000084 F0000078 E0000000 E0000000 80000000 Message #3: 26 (UDH len) 0003110303 (concatenation header, msg 3 of 3) 121F00011C (variable picture 1 x 28 or 8 x 28 pixels) 00 00 00 00 00 00 00 00 00 00 00 C0 E0 F0 F0 F8 F8 F8 E0 00 00 00 00 00 00 00 00 00 A bit challenging to explain, but quite simple in concept. -bn | |||
| Anonymous |
For what i see the SMS is divided in 3 messages. How should i post these 3 messages? One by one, or the program detects that the data is longer than 1 sms message and places and divides the sms message ? My question is, who generates the data header's? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1694 Registered: 10-2002 |
You would submit these three messages as separate messages. If you were using the web interface of NowSMS, you'd go into Send Binary Message Other, and plug the data into the User Data Header field. Leave "Binary Data" blank. Leave PID and DCS at 0. User Data Header for Message #1: 7D0003110301130103127300041C0000000000000000000000010000000600000008000000300000 004000000080000001000001FFFF007FF55F03FF7FFF05FBFFFF09F7E7FF0BFFC3FF0FFFC3FF1FFF C7FF3FFFEFFF2FFFFFEE1BFFFFFB1F0809CF0FFFFF9D07013FAB00867FBF007E008E001C008F0000 00640000003B User Data Header for Message #2: 7A0003110302127300041C0000000000000000FFFF8000001FF00000183E0000300B80003009E000 6008700078083CF1FC0BFEFFFFFFFFFFFFFFFDFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFF FFFF3FFFFFFE76BFFFFA7DFFFEFE77FBBFF23F6FF8011EF4000084F0000078E0000000E000000080 000000 User Data Header for Message #3: 260003110303121F00011C0000000000000000000000C0E0F0F0F8F8F8E0000000000000000000
You do. That's why I explained how it is done. We might do some of this automatically in a future version of NowSMS. | |||
| Laura Unregistered guest |
I have just sent the above EMS Message (picture of a car) to a Motorola A835. One message was received containing four lines: the first was a question mark in a box, the second line was the front part of the car, the third line the middle part of the car and (you guessed it) the fourth line the end of the car. Can anybody explain why the picture has been broken up in this way? And more importantly how I can make it complete? Thanks, Laura | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1815 Registered: 10-2002 |
Laura, Unfortunately, not all EMS phones support UPI (user prompt indicator), which you need to use in order to have an object span multiple messages, and then get stitched together. I would expect newer phones, such as the Motorola A835 to support it. There is another approach for EMS concatenation, called "extended objects", which is part of EMS Release 5. But I suspect that is even less widely implemented than this UPI feature. (UPI was part of EMS Release 4.) According to specs on the Motorola web site, the A835 supports EMS 4.2. But I cannot find any more detail than this. As such, I would not expect it to support EMS release 5's extended objects. And from the sound of things, it does not support EMS UPI (User Prompt Indicator). The UPI control tells the phone that there are 3 objects, in this case, that need to be stitched together upon receipt. From your description, it sounds like the phone does not understand the UPI part of the message, but it recognises that it is an EMS control, so it displays it as a question mark. It then treats the individual picture components as separate messages. I doubt there is anything you can do. But quite frankly, when you talk about phones with color screens, such as the A835, I'm not convinced that users would find black and white EMS pictures all that exciting. -bn | |||
| Kirk Unregistered guest |
Bryce, Ok I'll clear up the question from Laura (I work with her). The message was sent PERFECTLY !!! to a Sony Ericsson T610 (received correctly and save request, so the UPI worked properly). When we sent the same messages to the A835 (which claims EMS 4.2 as you said) it shows up as an attachment message with the ? and then two bits of the car. However, if I resend the image received on the T610 to the A835 directly (not using our lovely smpp system) it appears as a picture message correctly :-) It almost looks like the T610 receives UPI correctly but doesnt send it with UPI and possibly the A835 doesnt support UPI at all. Anyone with a clue out there ??  Cheers for all your help though anyway. Kirk | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1883 Registered: 10-2002 |
Kirk, So the T610 can send the EMS message to the A835, and the A835 receives the EMS picture in its entirety? That is interesting. I wonder how the T610 is formatting this message to allow it to go through? Here's what I'd do to find out. Hook a GSM modem (or phone ... the T610 will work just fine for that) to NowSMS. Configure the SMSC connection to the phone so that it receives messages. Have the T610 resend the message to whatever phone number is connected as the GSM modem. NowSMS should receive the message(s) and store the received message(s) in the SMS-IN directory. However, NowSMS tries to reassemble the message when there is a concatenated message, and I think it will lose some of the UDH from messages after the first. For that reason, make sure the debug log is enabled (manually edit SMSGW.INI, and add Debug=Yes under the [SMSGW] section header, then restart the SMS service). We can then manually parse the received message(s) out of the SMSDEBUG.LOG if you can post that here. -bn | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5170 Registered: 10-2002 |
Just a follow-up... I still reference this thread a lot, and decided that it was worth exploring why what Kirk described is possible. If you send the multipart EMS image referenced above to a SonyEricsson phone, the image is received correctly. Most Motorola phones will not receive the image correctly, because they do not understand UPI. However, after receiving the image on the SonyEricsson phone, you can then forward the image to a Motorola phone, and it is received properly. Why? What does the SonyEricsson phone do differently when it sends the message? Well, I decided to follow my own advice above, and have the SonyEricsson phone send the picture to a GSM modem. To my surprise, the SonyEricsson phone actually sends the image in Nokia Smart Messaging format, instead of using EMS. As it turns out, quite a few SonyEricsson and Motorola phones can also receive images in Nokia Smart Messaging format. -bn | |||
