I still think that you are looking at the wrong direction. This has something to do with the comm link.
This PDU with the dozens of FFs at the end, is certainly *not* a bad encoded PDU. I understand that you are giving the CGMR command by hand (i.e Hyperterminal?) and still get those FFs, right? Have you tried to play with XON/XOFF or hardware handshake settings and see if it makes any difference? On Mar 2, 10:14 pm, sgr <[email protected]> wrote: > Hi, > > thanks for the hint. I tried as suggested, but it didn't change a bit. > I think you're right with the buffer overflow: the TP-UDL (length of > the message) comes _after_ the originator address, and as such is > already garbled (does the mobile device look at that same field?). I > guess that's why we see the FFs (and I've seen 00's as well in other > garbled messages). Furthermore, the behavior is reliably reproducable > -- regardless of which SM arrives first, the one with the "bad" > originator string is always garbled. > > I think I need to bite the bullet at decode the raw PDU string by hand > to see where exactly things go awry. My bet is that the originator > string is NOT encoded as expected, and looking at the comments in the > PduParser, there seems to be some room for interpretation. > > I'll keep you posted, but would still appreciate any hints... > > Bye > Stefan > > On Mar 2, 8:30 pm, Thanasis <[email protected]> wrote: > > > > > Hi, > > > I've seen this sequence of FFs before, but had nothing to do with the > > actual message. Those strange FFs are sign of a communication failure, > > maybe a buffer overflow or something going wrong with the serial port > > connecting the phone. > > > Try to work with different baud rates. Start with 9600, test and > > increase baud rate. I could bet that this has nothing to do with the > > originator string. > > > On Mar 2, 2:34 pm, sgr <[email protected]> wrote: > > > > Hi, > > > > I have trouble parsing a PDU message with an originator address other > > > than an international phone number. Let me briefly explain the purpose > > > and setup before I go into the message specifics. > > > > I need to receive an SM sent by a business partner. They probably send > > > the SM via a bulk SMS gateway, using an arbitrary string as the > > > originator address. I also have access to a bulk SMS gateway, so I can > > > approximate what the partner sends us. I receive the SM on a GSM-Modem > > > (Siemens M20), using the smsserver component of smslib. I'm > > > interpreting the received SM by implementing > > > org.smslib.smsserver.interfaces.Interface#MessagesReceived. > > > I've tested the implementation by sending an SMS to the modem from my > > > mobile phone. Works like a charm. > > > > However, things change when I receive messages from certain originator > > > addresses of type D0, for example, "Renz Stefan". All PDU data > > > following the originator address block seems to be garbled, looking at > > > the resulting SmsDeliveryPdu object. I've seen TP-PIDs of 0x21 and > > > 0x58, where 0x00 is expected. Also, the TP-SCTS is either way in the > > > future, or in the past (by years). > > > > Here's the raw PDU that I read from the modem (e.g. by issuing AT > > > +CMGR=...): > > > 0891534875001040F30414D0D2B25B0F0000000000000F30204420B2AF0F90A0CBE6B01B000 > > > > > > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > Using a different originator, say, using now "Stefan Renz" instead of > > > "Renz Stefan", works out well: the SMS is well parsable by the > > > PduParser: > > > here's the raw PDU String I copied from the terminal program: > > > 0891534875001040F30414D0537AD91C7683A465B71E0000013020017560400CC7F79B0C6AB > > > FE5EEB4FB0C > > > > The only difference between the two are the originator address, and > > > the time sent. Immediately striking is the fact that the garbled > > > message is much longer and seems to be somewhat padded. > > > > In order to play with those messages, I directly use > > > org.ajwcc.pduUtils.gsm3040.PduParser#parse, passing in those raw PDU > > > strings, and looking at the resulting Pdu objects. > > > > Does anyone have an idea of where I go wrong, or what the problem may > > > be? The whole issue looks rather strange to me, especially since the > > > PDU data received on the modem already looks garbled. > > > > Thanks in advance, > > > Stefan -- You received this message because you are subscribed to the Google Groups "SMSLib User Group" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/smslib?hl=en.
