ME70-169 reproducable transmission error (end of line conversion?)

7 thoughts on “ME70-169 reproducable transmission error (end of line conversion?)

  1. Hi,

    I am seeing a reproducible bit error in the transmission between two ME70-169 modules.

    I am sending the following hexadecimal data to the first ME70-169 module:

    0000: 01914034 12100000 00000101 10000000 00029160 00000003 f03a40fe 80000000 ..@4...............`.....:@.....
    0020: 00000012 0000fffe 000001fe 80000000 00000012 0000fffe 00000281 0054335e .............................T3^
    0040: 24000103 bfbc5457 f00c0008 090a0b0c 0d0e0f10 11121314 15161718 191a1b1c $.....TW........................
    0060: 1d1e1f20 21222324 25262728 292a2b2c 2d2e2f30 31323334 35363738 393a3b3c ... !"#$%&'()*+,-./0123456789:;<
    0080: 3d3e3f40 41424344 45464748 494a4b4c 4d4e4f                              =>?@ABCDEFGHIJKLMNO
    I am sending the full Wireless MBus header including a "wakeup" byte at the beginning (I am using the Indication mode).

    At the receiver I get the following output from the second ME70-169 module:

    0000: 00914034 12100000 00000101 10000000 00029160 00000003 f03a40fe 80000000 ..@4...............`.....:@..... 0020: 00000012 0000fffe 000001fe 80000000 00000012 0000fffe 00000281 0054335e .............................T3^ 0040: 24000103 bfbc5457 f00c0008 090a0b0c 0a0e0f10 11121314 15161718 191a1b1c $.....TW........................ 0060: 1d1e1f20 21222324 25262728 292a2b2c 2d2e2f30 31323334 35363738 393a3b3c ... !"#$%&'()*+,-./0123456789:;?@ABCDEFGHIJKLMNO..

    The Wireless MBus frame contains 137 bytes of data... exactly in the middle (byte 0x48), a single bit is flipped and converts a 0x0d into a 0x0a.

    This looks like something did an "end of line" conversion.

    1. I managed to reproduce the same effect with a different payload at a different position in the bytestream. It seems something is converting all 0x0d bytes to 0x0a bytes.

      My configuration of the ME70-169 module (on both sides) is:

      static const struct telit_reg_init _init_telit_hw[] = {
        { 431, 5 }, /* serial timeout */
        { 400, 16 }, /* radio-mode N2-meter */
        { 401, 31 }, /* all tx-fields */
        { 402, 191 }, /* all rx-fields */
        { 403, 0 }, /* tx pin 0, rx pin 0 */
        { 420, 6 }, /* 19200 bps link-speed */
        { 422, 0 }, /* +21 dBm output power */
        { 440, 0 }, /* no standby */
        { 452, 0 }, /* no rx filtering */
        { 453, 2 }, /* listen before talk */
        { 490, 1 }, /* enable indications */
        { 500, 99 }, /* -99 dBm LBT treshold */
        { 501, 9 }, /* ALOHA lbt with reattempts */
        { 502, 5 }, /* max 5 ALOHA attempts */
        { 503, 3 }, /* LBT backoff exponential 3 */
        { 504, 750 }, /* LBT delay 750 ms */
        { 506, 20 }, /* LBT backoff period 20 ms */
        { 520, 3 }, /* LBT maximum reattemts 3 */
        { 521, 3 }, /* LBT backoff exponential 3 */
        { 522, 16 }, /* LBT RA period 1.6 seconds */
        { 530, 0 }, /* no frequent access cycle */
      };

      I am using the module with a serial linespeed of 115200 bit/s through the USB-to-Serial converter of the breakout board I got with the Demo Case.

       

       

      1. Hi,

        my suggestion, is program again the modules.

        The best solution will be send ATR before flashing (when module can receive the at command), after it flashing again the modules with the Sw you named.

        If this process does not help, please contact your distributor in order to swap modules.

         

        Let me know please

        Thanks

        1. Hi,

          my suggestion, is program again the modules.

          The best solution will be send ATR before flashing (when module can receive the at command), after it flashing again the modules with the Sw you named.

          I resetted all four modules (with ATR), reflashed them again with the Telit_ME70_169_Module_U03_01_06.zip firmware and resetted them again.

          I can see the same behavior with all four modules.

          If this process does not help, please contact your distributor in order to swap modules.

          Let me know please

           I think its very unlikely that all four modules have the same subtile defect.

          Is there something else I could do to provide more debugging information?

           

          1. Hi

            It is very strange, since we have not feedback about a similar issue with AT command lock

            could you send me module serial number in order to investigate better?

            Thanks

             

            Please email ts-emea@telit.com directly, referencing this forum thread.

          2. Hi

            It is very strange, since we have not feedback about a similar issue with AT command lock

            could you send me module serial number in order to investigate better?

            Your post that you could not reproduce the problem made me check everything on my side again… I checked an older firmware, without success. My program definitely doesn’t touch the incoming and outgoing binary data (and produce a hexdump for debugging purpose).

            BUT when I set the mac address in the Wireless M-Bus header to 10:00:00:00:00:0d it changed to 0x10:00:00:00:00:0a… after some more digging I found the real problem.

            It seems that the Linux ttyUSB driver defaults to a mode that does modify the bytestream… in this case the initialization of ttyUSB needed one more flag that prevent the modification of the “end of line” characters.

            With the additional flag the IP transmission over the Telit chip now works FINE.

            my current initialization of the “termios struct” (between a get and a set ioctl) is now:

            cfsetospeed(&tty, speed);
            cfsetispeed(&tty, speed); //set into raw, no echo mode tty.c_iflag = IGNBRK; tty.c_lflag = 0; tty.c_oflag = 0; tty.c_cflag |= CLOCAL | CREAD; tty.c_cflag &= ~CRTSCTS;
            //no parity tty.c_cflag &= ~(PARENB | PARODD);
            //1 stopbit tty.c_cflag &= ~CSTOPB;

            I hope this will help other people as a reference not to fall into the same trap.