Hello,
We are evaluating VirtualHere for our energy management system and would like to purchase a license. However, we are experiencing intermittent serial communication timeouts and would appreciate help identifying the cause.
Our setup:
- **Server:** Raspberry Pi running VirtualHere USB Server Trial Edition.
- **USB device:** CH340/CH341 USB-to-RS485 adapter, USB ID `1a86:7523`.
- **Client:** ARM64 Linux/Yocto device, kernel `6.1.187-cip60-yocto-standard`, VirtualHere Client **6\.0.3**.
- **Protocol:** Modbus RTU, **19200 baud, 8E1**, one slave and one active Modbus master.
- The forwarded adapter appears as `/dev/ttyUSB0`. The client runs in normal mode, not daemon/service mode.
We performed a comparison using the **same Python reader, request sequence and 900 ms response timeout**, without retries:
| Connection | Duration | Result |
|---|---:|---|
| Direct serial access on the Raspberry Pi, with VirtualHere stopped | 10 minutes | **1942/1942 requests successful**, no timeouts |
| Forwarded access through VirtualHere on the Linux client | 3 minutes | **460/469 requests successful**, 9 timeouts |
A subsequent five-minute test using our native application also showed interruptions:
- 150 application-status samples; only **58% reported a complete, fresh and usable dataset**.
- **Six serial timeout events**, with the longest application-data interruption approximately **32 seconds**.
- The USB device remained connected throughout the test.
- No gateway restart or new UART receive errors were recorded. The gateway continued receiving responses from the heat pump.
The native application rejects a collection if any register read fails, so its dataset availability percentage is different from the individual-request success rate above.
VirtualHere’s active TCP connection uses the Raspberry Pi’s LAN address. A concurrent ping test showed **0% packet loss**, with approximately **8 ms average and 29 ms maximum RTT**. The previous comparison used the Pi over Wi-Fi.
One possible contributing factor is client load: the Linux client had a high load average during the test, and a follow-up measurement showed approximately **99% CPU utilization across its two cores**. We therefore cannot yet attribute the problem specifically to VirtualHere or Wi-Fi.
Could you advise:
1. Are there known issues or recommended settings for CH340/CH341 serial adapters?
2. Which client/server logs would help determine where responses are delayed or lost?
3. Could client CPU load or Wi-Fi cause this behavior despite the relatively low ping latency?
4. Are there trial-version limitations that could affect this communication?
We can provide request logs, timestamps and diagnostic counters. We would like to establish reliable operation before purchasing and deploying the licensed setup.
Thank you for your help.
.
No its nothing to do with load. It is simply your network latency. Virtualhere never drops or corrupts data.
There is a delay taking the serial data from the CH340 USB end and putting it on the network due to network latency. The ringbuffer in the UART chip is really small so it just overwrites the ring buffer while the USB data takeoff is delayed, and this corrupts the data.
If you control the end device firmware, you should switch to flow control and that will help but will still not guarantee transmission. Currently you have no flow control so of course any latency > a few ms will cause trouble.
Some chips like the cp210x and ftdi ones have status bytes after every tx/rx byte and that tells you when there is a buffer overrun/underrun occuring and you can retry. I dont think the cheap ch340 chips have this status bit mixed in the data stream. I checked the linux source for the ch341 (https://github.com/torvalds/linux/blob/master/drivers/usb/serial/ch341.c) and it doesnt seem to have the extra status bits. Note the normal COM status bits are not good enough you need to non-standard chip status bits to really be accurate.
Thanks for the explanation…
Thanks for the explanation. We replaced the CH340 adapter with an FTDI FT232R (0403:6001) and repeated the comparison using the same read-only Modbus test program.
Settings remained unchanged: 19200 baud, 8E1, 900 ms response timeout, no retries, and the same gateway firmware. VirtualHere client version was 6.0.3.
Results:
Directly on the Raspberry Pi, 10 minutes: 1,902/1,902 requests successful.
Through VirtualHere to our development machine over VPN, 3 minutes: 522/522 successful.
Through VirtualHere to the original EMS over the local network, 3 minutes: 522/522 successful.
We observed no timeouts or CRC errors. The FTDI driver also reported no overruns, parity errors, or framing errors during either forwarded test.
Previously, the CH340 produced 9 timeouts in 469 requests during the three-minute EMS comparison. The adapter change therefore looks promising in our setup, although these short tests do not yet establish long-term reliability