This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Erik Ekman yarrick at kryo.seOn 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) > >