FTDI AND PROLIFIC not working suddenly

General Bugs and troubleshooting
1

OS windows 10 32bit
Realdash Rev 1.8.6

Always now says “connecting”. no longer works with FTDI or Prolific cables, but Si lab cables still work. Have many of each, so easy to confirm is not bad cable.

Was sluggish port response last week, but latest build killed it.

We think 1.8.1 was working.

2

Ok, I will run tests on Windows serial, although the serial drivers are completely handled by Windows drivers and app code has no differences regarding the chipset.

3

Tests run on Megasquirt 3 and ME221 ECUs using 115200 baud.

FTDI: FTDIBUS\VID_0403+PID_6001: Works
FTDI: FTDIBUS\VID_0403+PID_6015: Works
ATEN: USB\VID_0557&PID_2008: Works
PL2303: USB\VID_067B&PID_2303&REV_0400: Works

I did not have other adapters handy, but at least with those, 0 problems.

4

Thanks for testing; Was this Windows 32 or 64 bit? Seems like this issue might be 32 bit only machines;

Also on these same machines we are using same FTDI/ Prolific cables with Realterm program, menu system and comms work as normal, so this is only Realdash having this issue.

Steve

5

Tests running on Windows 10 20H2, 64 bit.

Try to bring down your baud rate to 115200 max to see if that helps.

6

Sorry, did not mention baud rate. It is 115200 fixed;

Thanks,

Steve

7

same problem,
PL2303(HXD): USB\VID_067B&PID_2303&REV_0400
not working. Windows terminal program shows normal communication. Changing the baudrate have no success.
With Android PL2303HXD and PL2303HXA working.
Driver version is 3.8.31

8

I test it with win10/64 bit, PL2303HXD (new driver) and PL2303HXA (old driver), booth not working.
You found a solution meanwhile?

9

I made a long running test on Windows 10 with Seeedstudio USB-CAN adapter using 2M baud. Ran continuously for 4 hours without problems.

I have not been able to reproduce any problems on Windows 10 serial.

10

maybe helpful if you tell us the driver version you use, 64 or 32 bit, the chip version…

11

Seeedstudio USB-CAN adapter is a CH340 device with USB\VID_1A86&PID_7523. No installed drivers, uses what ever Windows chooses for it. Other details are in previous posts.

12

thank you, so I try this chip!

13

We are using Realdash CAN and custom XML file for our work. Our hardware sends a very constant stream of data to Realdash which displays data almost realtime. It has been solid for quite some time, just recently become problematic. Here are some observations;

  1. There are three major brands of USB to serial devices; FTDI, Prolific, SiLabs. I want to start a separate thread about these, we have had continuous luck with ONLY SiLabs (only with the CP2102 chip, the CP2102N might have an issue, still trying to root cause it). Prolific is awful and laggy. FTDI works well under certain conditions but not in every PC option.
  2. If I stop sending data on serial side to Realdash suddenly, Realdash locks up, in all cases. the only way to recover it is to yank the USB serial cable, then it springs back to life.

I think the key here is the constant stream of data, almost synchronous, to Realdash. Asynchronous sporadic bursts of serial result in different experience.

14

Here the same.
SiLabs CP2102 working on Android and Windows without problems, the other USB to serial devices on Android, but not Windows.
CH340 dont try until now.

15

BTW, not that this is an issue, but please be aware of it…We have seen external mouse cause USB/SERIAL cable go nuts…If you see strange behavior, always remove external mouse as first option.

16

So we did some more testing on the SiLabs CP2102N, again very disappointed in the SiLabs newest part. Just for reference, the host laptop is Windows 10, 32 bit, home edition. version rev is 2004, 2.20.1904.1706. We are using Realterm as a reference, doing a capture and a hex capture, we see no errors in cable. We run Realdash, we are seeing slow, spuratic, freezing. Again, we do NOT see this on the CP2102, only the 2102N version.

17

The CP2102N compare to the CP2102 dont support Line Break Transmission. Maybe this is the reason for the problems. Here a text from the AN976: CP2101/2/3/4/9 to CP2102N PortingGuide:

Line Breaks (also called a Break Condition) occur when the transmission line to logic low for more than one character time. TheCP2102/9 devices have the ability to transmit a Line Break or Break Condition by directly setting the device’s break state property. Thisforces the transmission line to logic low until the break state property is cleared. This feature is not directly supported on the CP2102N. However, a break condition can be emulated by temporarily lowering the baud rate, then transmitting a null character. The duration ofthis emulated break condition can be controlled by adjusting the baud rate, but it cannot exceed 27ms (8 bits at the lowest availablebuad rate, 300bps).

18

No, we do not send breaks. Thats not issue…

19

Now that 1.8.8 is out, I can try to help with this.

Note: the following applies to Windows 10 version of RealDash only.

Do you remember the last RealDash version on Windows that serial worked well for you? At some point Windows serial/Bluetooth handling was moved to its own separate thread to improve graphics rendering performance and minimize latency on serial data. While this has been an improvement on our tests, it is possible that on slow computers the serial thread does not get enough processor time to run continuously.

Could you test this theory? Try the following:

  • Set RealDash to Offline mode from ‘Settings->Application’
  • Create a dashboard with nothing but couple of text gauges to verify that you are receiving data.
  • Connect to your serial device and see if there is a difference in serial performance.

You can also try to further reduce the graphics rendering CPU usage by using power save option in ‘Settings->Application’

If you see significant improvement in serial performance, this may mean that serial thread is not getting enough CPU time to run.

20

Give me a day or so to set this up.

Thanks