USB Serial on Android: responses are delayed and batched

[onimor]

Hello,

I’m experiencing a strange behavior with the UsbSerialForAndroid.Net library on Android when reading from a USB-connected device (COM-over-USB).

details:
I poll pages of data from my controller every second.

All pages work correctly, responses come immediately.

Page 0x02 behaves differently: the controller does not respond immediately to the first few requests. After ~7–8 requests, it sends all the pending responses at once.

This happens regardless of the polling interval (tested 100 ms, 1 s, 5 s).

On Windows PC using the same device and same code, all pages respond immediately, including 0x02.

Other pages (0x01, 0x03, 0x04, 0x05, etc.) always respond normally on Android.

Observations:
It seems like the Android USB stack (or the library) is buffering the first few requests for page 0x02 and only dispatching them together.

The issue is specific to Android; PC COM ports work fine.

The device always sends correct data, it’s just delayed/batched on Android.

PC: page 0x02
18.02.2026 17:35:40
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF

18.02.2026 17:35:40
Read: FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-39-DE-AD-BE-EF

Android: page 0x02
18.02.2026 17:35:40
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:41
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:42
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:43
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:44
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:45
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:47
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF
18.02.2026 17:35:48
Write: FA-CE-01-02-00-00-03-39-DE-AD-BE-EF

18.02.2026 17:35:48
Read: FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-25-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-25-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-26-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-26-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-27-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-27-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-28-DE-AD-BE-EF-FA-CE-01-02-14-00-08-08-00-00-00-00-00-00-00-00-DF-DF-FF-FF-6F-7F-C7-57-FD-FE-94-28-DE-AD-BE-EF

Page 0x01( responds immediately)
Write: FA-CE-01-01-00-00-00-3A-DE-AD-BE-EF
Read: FA-CE-01-01-19-00-10-10-67-00-00-00-00-00-00-00-00-00-00-00-00-00-1B-01-00-00-00-01-00-00-00-65-3A-DE-AD-BE-EF

Page 0x03 (responds immediately)
Write: FA-CE-01-03-00-00-02-36-DE-AD-BE-EF
Read: FA-CE-01-03-12-00-10-08-01-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-09-36-DE-AD-BE-EF

Page 0x04 (responds immediately)
Write: FA-CE-01-04-00-00-05-34-DE-AD-BE-EF
Read: FA-CE-01-04-0A-00-08-08-FF-FF-FF-FF-FF-FF-FF-FF-0F-34-DE-AD-BE-EF

Page 0x05 (responds immediately)
Write: FA-CE-01-05-00-00-04-33-DE-AD-BE-EF
Read: FA-CE-01-05-0A-00-08-08-00-00-00-10-10-10-10-10-1E-33-DE-AD-BE-EF

[onimor]

@alex3696 Do you know the reason?

[alex3696]

@alex3696 Do you know the reason?

We need more information.:
1 which adapter (driver) you using?
2 What is the speed, parity, etc.?
3 Is Dtr, cts used?

[onimor]

@alex3696 Do you know the reason?

We need more information.: 1 which adapter (driver) you using? 2 What is the speed, parity, etc.? 3 Is Dtr, cts used?

1. USB-SERIAL CH340
2. _driver.Open(9600, 8, UsbSerialForAndroid.Net.Enums.StopBits.One, UsbSerialForAndroid.Net.Enums.Parity.None);
3. no

[alex3696]

1. USB-SERIAL CH340
2. _driver.Open(9600, 8, UsbSerialForAndroid.Net.Enums.StopBits.One, UsbSerialForAndroid.Net.Enums.Parity.None);
3. no

To eliminate possible glitches (dma, etc.) on your device: you can connect your phone to your computer using 2 usb-com adapters and try to simulate sending and receiving such sequences.
The ch340 chip has many revisions, and there may be errors in the driver. Have you tried another ftdi/cp210x?

It is unclear: are requests delayed in sending or are responses not being received from the library buffer?

[onimor]

To eliminate possible glitches (dma, etc.) on your device: you can connect your phone to your computer using 2 usb-com adapters and try to simulate sending and receiving such sequences. The ch340 chip has many revisions, and there may be errors in the driver. Have you tried another ftdi/cp210x?

It is unclear: are requests delayed in sending or are responses not being received from the library buffer?

The requests are sent immediately and on time (verified in logs). There is no delay in sending.

The issue is that responses for page 0x02 are not delivered immediately on Android. After ~7–8 requests, all responses are received at once in a single bulk read.

Other pages respond immediately under the same conditions.
On Windows (same device and protocol), page 0x02 also responds immediately.

So the problem appears to be on the receive side (Android / library buffering), not on the transmit side.

The device uses a CH340 chip integrated on the controller PCB, so I cannot replace it with FTDI/CP210x.

[onimor]

@alex3696

We discovered an important detail that may help identify the issue.

When we modified the controller firmware to append extra bytes after the packet terminator (DE AD BE EF), we observed the following:

Adding +1 extra byte → page 0x02 on Android works normally.

Adding +5 extra bytes → all pages on Android stop receiving data correctly.

Windows continues to work correctly in both cases.

Important clarification:
The extra bytes do not affect our packet parsing logic.
We always detect packets strictly by start marker and end marker (DE AD BE EF), and any trailing bytes are discarded.
So the additional bytes only change the total number of bytes read from the COM port — they do not affect protocol framing or parsing.

This strongly suggests a USB bulk packet boundary issue on Android (possibly CH340-related).

It appears that when the total response size crosses a specific boundary (likely the endpoint max packet size, possibly 32 bytes), Android does not immediately dispatch the data and may aggregate or delay transfers.

This may also explain why page 0x02 behaves differently from other pages — its response size may align unfavorably with the USB bulk packet size.

Could this be related to how bulk IN transfers are completed when the transfer size is equal to or slightly exceeds the endpoint max packet size?

The device uses a CH340 (soldered on PCB, cannot be replaced easily).

Any insight would be appreciated.