Module sends wrong data (SSEND)

17 thoughts on “Module sends wrong data (SSEND)

  1. Normal
    0

    21

    false
    false
    false

    DE-CH
    X-NONE
    X-NONE

    Normal
    0

    21

    false
    false
    false

    DE-CH
    X-NONE
    X-NONE

    Hello

     

    I’m
    using a GE864-Quad and a Quad V2 to transfer data over GPRS. Normally it works
    properly fine.

    But
    sometimes it’s getting a clutter in the payload data. The strange thing is that
    the GPRS checksum always is correct, which concludes me that the problem probably
    appears before the module sends the data over GPRS.

    To
    transmit the data to the Telit module I use a RS-232 Serial connection. I
    already have checked this connection; the data payload is transmitted correctly
    to the Telit module also in the error case.

     

    An
    example:

     

    This
    should have been transmitted:

    ASCII:
    C200945.02300,##V010034,91=40,86=Schuler 02300,87=C200945.02300,A4

    HEX:
    43 32 30 30 39 34 35 2E 30 32 33 30 30 2C 23 23 56 30 31 30 30 33 34 2C 39 31
    3D 34 30 2C 38 36 3D 53 63 68 75 6C 65 72 20 30 32 33 30 30 2C 38 37 3D 43 32
    30 30 39 34 35 2E 30 32 33 30 30 2C 41 34

     

    This
    effectively has been transmitted:

    ASCII:
    °         300,##V0t


    Ðt


    4¶<


    =St


    Ðt


     ¶<



      œ[1] €¯Æ , à›

     

    HEX:
    B0 20 20 20 20 20 20 20 20 20 33 30 30 2C 23 23 56 30 10 1D 74 03 D0 17 74 03
    01 34 B6 3C 13 03 3D 53 10 1D 74 03 D0 17 74 03 01 20 B6 3C 13 03 03 20 08 20
    9C 02 20 80 AF C6 13 20 2C 20 E0 9B 10 20

     

    The
    Module is running in the selint=2 mode and the sockets are running in the
    command mode.

    Below
    a code fragment I use to transmit the payload. REQ means request sending to the
    Telit module RES is the response from the module.

     

    REQ AT#SCFG=1,1,1500,30,190,50;#SCFGEXT=1,1,0,3;#SD=1,0,52956,www.XXXXXXXX.com,0,0,1

    RES OK

    REQ AT#SSEND=1

    RES
    >

    REQ
    C200945.02300,##V010034,91=40,86=Schuler 02300,87=C200945.02300,A4

    RES OK

     

    Does
    anybody have observed similar things? Or any ideas why this happens? Or how I
    can solve this problem?

     

    Kind
    regards

  2. Normal
    0

    21

    false
    false
    false

    DE-CH
    X-NONE
    X-NONE

    Adding
    note:

    Sometimes
    the module adds strange messages to the payload. And some parts of the payload
    are equal (red letters)

    Two
    examples:

     

    Correct: C201021.06716,##V010058,91=40,87=C201021.06716,A2=22803,A115=310511_135550_00_5D49,86=WIB
    06716    ,25

    Wrong: S
    e l f   S e r v i c e   =40,87=Cð?(
    ð5(7 :2=22803,A115=310511_135550_00_5D49,86=WIB
    06716    ,25

     

    Correct: C200955.50986,##V010045,91=42,86=Schuler
    50986,87=C200955.50986,90=250511_124539,DA

     

    Wrong: C
    o m b o x   ##V0P’t
    ð&t 4¶<=S ­ €h¿( – (Ÿ+41794997979 86,90ð?t ‘t2¶<,D
     

    What’s
    the meaning of  "Self Service" or "Combox" in this context?

    1. Are you 100% sure isn’t your that sends wrong data? Can you observe/sniff RS232 link in some way? What is/where is your application running? In case is an Windows application you can use for example HHD free serial port monitor.

      1. Normal
        0

        21

        false
        false
        false

        DE-CH
        X-NONE
        X-NONE

        Hello Mr. Buhu

         

        Thanks for responding

        I already have checked the
        RS232 link with a sniffer. The data’s transmitting correctly to the Quad
        module. The baud ratio is 9600 baud.

         

        1. Please explain exactly what hardware and software you are using, to have the big picture maybe some ideas will come.

          1. Normal
            0

            21

            false
            false
            false

            DE-CH
            X-NONE
            X-NONE

            Well, I use
            the GE864-Quad in a embedded system. The communication between main processor
            and telit module is a RS 232. I do not use any additional software. The
            communication is with AT commands.

            I’ve used
            this module since long time in the same architecture without any problems. At
            this time the module was used in the online mode. Since April the sockets now
            are opened in the command mode. Since the module is open the sockets in the
            command mode the module is sending these strange things.

            Is this
            information helpful? Or did I misunderstand your question?

          2. That is is what I asked for, however cannot say much more … One idea is to check the numbers of bytes sent/received and compare with the ones at the other party, and try to conduct the traffic manually from a PC.

             

             

  3. Normal
    0

    21

    false
    false
    false

    DE-CH
    X-NONE
    X-NONE

    Normal
    0

    21

    false
    false
    false

    DE-CH
    X-NONE
    X-NONE

    Hi

    I’ve
    noticed that only the quad V1 module has these problems. The quad V2 always
    sends the correct data.

    The quad V1
    has the FW Version 07.02.005 and the V2 has the Version 10.00.23.

    I’ve tried to
    send the commands manually by hand from PC to the Telit module and the data
    still was sent wrong.

     

    For energy
    safety reasons I power down the module if I don’t need it. If the module has to
    transmit something, the module goes power up and sends the data before it goes
    power down again. The duration between power up and send the data is around
    30sec.

    Could it be
    that the module still isn’t ready to send data? also when I get a ‘>’ as
    response of AT#SSEND?

    1. Hi Michael,

       

      this is a good point. What do you mean for "power down". It is a complete shut down (ON/OFF or AT#SHDN) or a power saving (AT+CFUN=0 or 5) ?

       

      First test: try to increase the delay between OK received after AT#SD= and  next AT#SSEND=1 ? Which is the current delay?

       

      Second test: try increasing the delay between the ‘>’ prompt and the string of data? Let’s say 100ms, 500ms and 1s ?

      1. Normal
        0

        21

        false
        false
        false

        DE-CH
        X-NONE
        X-NONE

        Hi Andrea,

         

        Well ‘shut
        down’ in mi case means complete shut down (cut power source)

         

        Delay between OK and SSEND

        At moment the
        delay between the "OK" and the "SSEND" is about 530ms. I
        increased it up to 1s and still the same thing.

         

        Delay after ‘>’

        The delay
        after receiving the ‘>’ is around 30ms. After increasing the delay up to 1s,
        the problem still appears.

         

        So, I tried
        to increase both delays up to 2 seconds (at the same time) and the problem
        still appears. Although not as often as without delay.

        1.  

          I’ve made some comparison test even if it is not so easy to reproduce this behavior with the 7.02.605 firmware.

          It seems that the 7.02.607 improves the "SSEND" behavior…so I kindly ask you to test this version.

          You can request it to your distributor or writing an email to ts-emea@telit.com.

        2.  

          I’ve made some comparison test even if it is not so easy to reproduce this behavior with the 7.02.605 firmware.

          It seems that the 7.02.607 improves the "SSEND" behavior…so I kindly ask you to test this version.

          You can request it to your distributor or writing an email to ts-emea@telit.com.

          1. Normal
            0

            21

            false
            false
            false

            DE-CH
            X-NONE
            X-NONE

            Normal
            0

            21

            false
            false
            false

            DE-CH
            X-NONE
            X-NONE

            Hi

            Thanks a lot for your
            answer.

            I tried to reproduce the
            error with the 7.02.607 FW and in fact it seems that with this FW the error
            does not appear anymore. That’s good news, but for me it’s not possible to
            upgrade all modules. So I’d like to find a workaround for the old FW
            (07.02.005). Are there any parameters or settings to change to avoid this
            strange behavior?

          2. I think the only possible workaround is to add more delay between the > and the string to send.

             

            The alternative it is to switch between online and command mode:

             

            AT#SO=1

            CONNECT

             => send the data

            <1s> pause

            +++

            OK

             

            => send AT commands.

          3. Normal
            0

            21

            false
            false
            false

            DE-CH
            X-NONE
            X-NONE

            The second work around
            doesn’t work in mi case because sometimes there will be "+++" in the
            sending string.

            So I’ll try to find a short
            delay to work with.

  4. Encountered similar problem. GL868-DUAL, 10.00.186. Modem is controlled by Python script. Data are periodically read from serial interface and sent to FTP. Additionally there are two listening sockets: TCP-Serial bridge and console. Settings:

    SER.set_speed(“2400”, “8E1”), no flow control is required for connected device
    AT&K0 (on both MDM and MDM2)
    AT#SCFG=1,2,300, 0,600,20
    AT#SCFG=1,3,300,90,600, 1
    AT#CPUMODE=3

    Most of such systems works fine. But on some after heavy data exchange over TCP-Serial bridge data from ASC0 come distorted when connection is active. E.g.: when there is no active connection then data are read succesfully and then sent to FTP. If connection is active (bridge is used or debug reading is made from console) data contains garbage and amount of data differs from expected. Checksum is verified after reading from SER and before data is sent to socket. Example of good and bad data are given in attachment.

    In the same time, short packets (below 10 bytes) are sent and received succesfully. Maximum packet length is 256 bytes. Reboot, AT&K3, +IPR, +ICF, AT&F1 on MDM and MDM2, SER.set_speed() right after connection was accepted didn’t help.

    What can affect “SER/ASC0 – device” communication when connection is activated?