FOR FTDI;
Last known working dash was around 1.6.x.x; we have tried the graphics reduction to one item and also tried power save mode. No change at all.
FTDI 2.12.28.0 is driver. if we go to device manager, serial port settings, advanced settings and set to latency timer 1mS, then it continuously “connect” and " not connected", nothing works. If we slow to above 10mS, it works but then is choppy. Again, same settings and cable with RealTerm work fine.
Here is video made last year showing FTDI laggy response with latency timer above 10;
https://www.youtube.com/watch?v=J-0Zgh66P4c&feature=youtu.be
we did two videos showing simple test. In this test, we had one device streaming serial data, two instances of Realdash displaying it. One dash had FTDI (right side ), other had SiLabs CP2102 original, not N (left side).
in the hardware we had set to 115.2, we connected the TX pin out to both the FTDI RX in and Si Labs RX in pins in parallel. hardware was simply outputting a counter as fast as possible, both dashes were displaying that counter. each dash was mapped to separate USB dongle.
In the first video the latency timer is set to 1mS, in the second it is set to 12mS. Note in second video, the stuttering intermittent behavior of data on right;
here is links to videos
https://youtu.be/uWajHSQ7DWI
https://youtu.be/T34PPZp4OF0
below is device manager setting
oh, is this Windows 10?
I dont have this setup… 
RealDash has an input ‘Calculated Values->Data update rate (values/s)’. Use that along your running number to see the differences.
I don’t know what I can do based on this. Those serial settings are totally invisible to RealDash and only affect the Windows serial driver.
We may have another clue from last night testing. Please recall we noted that all the testing we do in parallel with RealTerm we dont see this issue;
We suspect that if you run an experiment using FTDI cable and send data from a device at a very slow baud rate, such as 9600, you will see issue of intermittent or stuttering streaming…
There are different modes that the serial driver can be called or opened, is there a “time out” value that is being passed to function on the port? What value is timeout?
At a very fast throughput or baud rate this issue may never be seen…
I believe you that problem is real, that is not an issue. The default timeout on RD CAN protocol is 5 seconds, so that should not be the one causing the issue.
I will run some tests on 9600 baud rate to see if I can catch something.
For port handling, there would be two items rhat would force handling of port data;
buffer full and timeout. Timeout I would think should be in low milliseconds, like 5mS, or such.
In an extreme example, what if hardware only send 1 byte every millisecond and had a indicator on dash to display the ascii of char, what would happen? Windows buffer takes long time to fill, timeout takes long time to expire, port rearely gets handled…
I’ve been trying to look for information about this and stumbled across this:
https://github.com/MicrosoftDocs/winrt-api/issues/980
Windows version of RD is an UWP app and is unable to access the traditional win32 ‘file like’ serial interfaces. Instead it must use interfaces from Windows::Devices::SerialCommunication. I found other articles too that SerialDevice ReadTimeout does not work consistently across the Windows computers and USB drivers. This could be the root issue on slowdowns you are experiencing.
Windows RD has used same port timeout values from day one, so that will point against this as you are certain that these problems were non-existent on some previous versions of RealDash.
This is a tough nut to crack.
I may have found something, but it is actually exact opposite of what suspected by EE_Steve. If data is sent continuously and fast, the receive function in Windows serial will not return unless the receive buffer has been filled completely. As receive buffer is relatively large, this may cause noticeably delay in data processing as incoming data is processed in bigger chunks than necessary.
I will make a change to this for 1.8.9, hope it will be an improvement.
Hi Yani,
Steve is my issues, we are saying the same thing, so did something new today and results.
when we use FTDI, with high buffer it does not work, and this may be because we send frame coutinuselty, there might be at most 2 msec breaks here and there but for most part it very continues, so if buffer is set to 256 or so then it work , this may be same as what you described, when the buffer is larger it process is getting delayed since this is not much break in data being send and serial device with larger buffer is no being over loaded.
So added a pause in our send for testing only and when this delay was was large enough it started working with both cp2102N and FTDI, buffer size in FTDI can stay at 4096 with no issue.
3 . Prolific , PL 2302 does not work at all, not sure ever has on windows for me.
this has been been a major issue for us, just had not been consistent, on window only one that works great is discontinued CP2102 and no CP2102N the new version.
Lets hope next update will be an improvement.
Good news , seems like ftdi is working better now. Prolific, however, still not working, at all. It works in realterm, but we see “connect” in Realdash but never get useful data exchange. No idea why just does not work.
I have one Prolific USB serial adapter in testing cycle. Its a ATEN brand, and Windows reports the driver version of 3.3.7.131. Testing with a ME221 ECU on Windows version of RealDash 1.8.9, this adapter works for me without any problems.