We're loosing serial bytes from PC to phone

[Erik Ekman]

On Sun, Mar 21, 2010 at 10:35, Harald Welte <laforge at gnumonks.org> wrote:
> Hi!
>
> It seems we're loosing serial characters on their way from the (Linux)
> PC to the phone.
>
> I think I've seen this at some point in the past, but now I'm seeing it
> constantly.
>
> Let's assume we're trying to send the following sequence of bytes from
> the PC side to the phone in one of the HLDC connections:
>> send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
>> 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
>> 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
>
> what we actually get from the sercomm callback on the phone is:
>
>> l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
>> 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a
>> 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
>
> as you can see, there is a '00 01' missing between the '00' and the '02'.
>
> Interestingly, putting a usleep(10000) after every serial write does not
> solve the problem, so it is not timing related.  We don't get any UART
> overflows on the calypso, either.
>
> If I change the data pattern, then the first bytes are transmitted fine,
> but as soon as there is one 00 bytes, two characters are missing from
> the stream.
>
> If I strace osmocon, it is clear that we write every character,
> including the null-bytes, and all of the writes are successfully.
>
> I've again looked at (and played with) the termios settings, but could
> not find any problem (nor solution).
>
> It's also not the sercomm layer that is loosing bytes, as I the
> characters appear already lost when printing them from within the
> calypso UART driver, as you can see here:
>
> getchar_nb(1) = 7e      // flag character
> getchar_nb(1) = 05      // hdlc
> getchar_nb(1) = 03      // hdlc
> getchar_nb(1) = 0a      // l1ctl_hdr (undefined msg_type 10)
> getchar_nb(1) = 00      // padding
> getchar_nb(1) = 02      // here should be 00, 01, 02...
> getchar_nb(1) = 03
> getchar_nb(1) = 04
> getchar_nb(1) = 05
> [...]
>
> Any ideas? It's really strange and I don't really know what else to do.
> I'm quite sure our binaries contain multiple successive null-bytes and
> their download is working great...

I had similar problems when developing an app in C that communicated
with a GPS. I lost incoming bytes now and then (probably the same
pattern as you see). Because of this and other reasons I switched to
Python and pySerial which worked perfectly fine. I did never
understand what happened either, I also tried to get as raw mode as
possible.

/Erik
>
> Regards,
>        Harald
> --
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
>