Yeah, I guess its better to find another phone or modem to test with as well.
On Mar 3, 4:16 pm, sgr <[email protected]> wrote: > Hi Thanasis, > > thanks for taking the time. I appreciate your effort. > > On Mar 2, 10:09 pm, Thanasis <[email protected]> wrote: > > > I still think that you are looking at the wrong direction. This has > > something to do with the comm link. > > In that case I would expect that I either get randomly messed up > messages, or at random times, or problems at regular intervals (after > x characters, something like that). But what I observe is that the > messages are _always_ bad when using _one_ originator, and _always_ > good when using a different one. No matter how much I've done in the > same terminal session before, no matter in which order I send the > messages, always the same pattern. > > > > > This PDU with the dozens of FFs at the end, is certainly *not* a bad > > encoded PDU. > > I can see why you say that. However, look at what the terminal session > shows. I sent off three SM with originator "Stefan Renz", each with > more text appended to the content. Then, I sent the same content in > the same order, but this time with originator "Renz Stefan". Here's > what shows up: > > +CMGL: 2,1,,34 > 0891534875001040F30414D0537AD91C7683A465B71E0000013030414101400CC7F79B0C6AB > FE5EEB4FB0C > +CMGL: 3,1,,54 > 0891534875001040F30414D0537AD91C7683A465B71E00000130304141024023C7F79B0C6AB > FE5EEB4FB0CA2BF41F977DD052ADACBF23C1D9D769F41EFF50F > +CMGL: 4,1,,71 > 0891534875001040F30414D0537AD91C7683A465B71E00000130304172944036C7F79B0C6AB > FE5EEB4FB0CA2BF41F977DD052ADACBF23C1D9D769F41EFF50FF444B3407474987E029DE5E5 > 307DF30A01 > +CMGL: 5,1,,163 > 0891534875001040F30414D0D2B25B0F0000000000000F30204420B2AF0F90A0CBE6B01B000 > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > +CMGL: 6,1,,163 > 0891534875001040F30414D0D2B25B0F0000000000000F30604420B2AF0F90A0CBE6B01B000 > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > +CMGL: 7,1,,163 > 0891534875001040F30414D0D2B25B0F0000000000000F30704420B2AF0F90A0CBE6B01B000 > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > So I rule out that I mis-use the bulk gateway, because in that case I > would not be able to decode the first three messages. I also rule our > that the message length has something to do with it, as I sent > different content. > > I've also sent the messages to my mobile phone, where they come out > right. > > > 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? > > Yes, I'm working off kermit on Linux, tried different settings, > speeds, etc. Unfortunately, to no avail. > > So what I can rule out: > * cause in smslib, as smslib is not at all involved (so I'm even more > grateful for your help) > * improper use of the bulk SMS gateway (see above) > > Leaves me with > * serial communication is broken (what you suggest) > * Pdu package is broken (apparently, but why?) > * SIM card broken > * provider broken > * modem broken > > I'll need to get a different device, so I can rule out or prove the > last three points. > > Oh, BTW, Nokia 6500c is not compatible with smslib as it doesn't > support +CPMS and +CMGL, so I can't use my mobile phone to verify my > issue :-( > > Thanks, bye > Stefan > > > > > > > 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.
