On 1.7.1 we are seeing problem with physical serial port. We first saw this on 1.7.0, still seeing it on 1.7.1. Using FTDI cable, once we set the latency in windows in device manager (Ports, Port settings, advanced) from default 16mS to 1 mS, we connect dash command to hardware, the port initially connects, then 3 seconds later disconnects, then reconnects, over and over. I went back to older PC, found dash command 1.6.4 just to compare, it does NOT have this issue. We are also seeing similar issue with Android devices. This causes serious problems with real-time device readings.
Are you testing with Dash Command or RealDash. I cannot really comment anything on your tests with Dash Command.
SOrry, RealDash. Not used Dash Command for years. Mental Block…
With Android, please test 1.7.2-beta1. I will run full test set for the Windows 10 serial module.
I tested 172.b1 on android 7.1 with usb rd can connection.
Not a single failure was found! All just great!
Thanks for testing!
Although, I found something odd on Windows 10 serial system. As on debug version everything works correctly, there is something that causes an exception in connection when app is built with Release settings. I’m on to this and hope to find the fix soon.
We downloaded prerelease, still see it. We are using FT2323 cable, it is odd; It sort of gets a bunch of data, then pauses, then gets more, then pause, over and over. Same happens with SiLabs serial cable.
This is just guessing as you don’t specify what you are connecting to and what connection type you are using, but it sounds like its timeout- so no data is received for some seconds and connection reconnects.
No, the data is synchronous and we see it in RealTerm serial terminal continuous; This is at 115200K. It is like a buffer fills and must be cleared, over and over.
What protocol are you using to communicate with RealDash?
Can? Obd?
What type of connection?
Usb …
How much data is transferred?
10 inquiries?
100 frames?
1000 bytes?
Write more details please. We do not understand the problem if you do not describe it?
So far, I realized that you are assuming that the buffer on the receiving side cannot handle the data stream.
As far as I understand, this is about ELM327?
Maybe you are pushing too much data. Try to increase baud rate or lessen the data send frequency.
With 1.7.2 we did extensive USB-serial tests, and we achieved over 6000 values per second using the Seedstudio CAN adapter using 2M baud. But still you can overburden the serial, especially on Android where implementations vary on different devices.
172 ANDROID 7.1 tv box beelink ultimate 1 - just tested the speed of 2Mbod the result is stable. I’m watching! The amount of data is 800-1000 per second!
On Windows 10 the USB type does not matter too much, they all do the same, it connects and works great, but in about 3 to 4 second it disconnects and reconnects, otherwise it is all good. same device using WIFI and serial conduit works total find, so it is not the sending device, the same device works fine with 1.6.7.
On Android, the the FTDI (FT232R) chip connect and works ok expect it is choppy and not continues as it should, again same device works fine with serial to WIFI.
Now I have found one serial to USB that seems to work fine and that is it, I do not know the brand and it is on my car and the car is not here right now. I had this issue with older revs on Android but no on Window.
The Serial to USB shows up As FT232R USB UART on Android. this is samsung Tab S5E
So I hope this helps.
Mostafa
Mostafa. Is it a can adapter or an obd scanner? How difficult it is to extract information from you)))
What you say FTDI is a serial port driver. It supports speeds of up to 3,000,000 baud, so one hundred I do not think that the problem is ttenno in it!
using Real dash Can mode, All rate rates are at 115.3K, I do not have serial port error on my end, sending or receiving.
So today got window update and thing are back to way use to be on window 10, rev 1.7.2, so there was something wrong with 17.0. and 17.2, thanks for fixing this what every it was.
Now to android , it behaves differently depending on USB to serial type, using same cable on windows is fine but no on Android, I have one type that work. check videos, good, bad , windows 10 same as bad video.
well can not attach video.
working Andriod https://www.youtube.com/watch?v=qsDBwwq0eX8&feature=youtu.be
not working FT232R not continues… https://www.youtube.com/watch?v=J-0Zgh66P4c&feature=youtu.be
window 10 FT232R USb to serial https://www.youtube.com/watch?v=rr1dHJ3Iuw0&feature=youtu.be
My hardware is the same in all modes, to be clear this did not work in older version real dash either on Android.
brought about so many and and found that worked well. but do not know what type since bought a ling time ago, this should all work.
My data is fast and continus, but it is not wrong.
If I use wifi with same serial stream it also works fine. but do not want to use WIFI and Android does not work well when no connected to network and keeps log period of no data, but works fine if internet connected.
Thanks,
Mostafa
None of these devices talk readdash can, so off course it is non of them.
It is my own design for my car BCM ( body control modules.
it is no my device.
in case of FT232R, It does the same choppy ness if the setting on windows are not set to
short delay, windows defaults for this device are 16msec, if same option exist at driver level on Android then they may need to be changed to 1 msec.
Mostafa
At 2 Mbuad, you data rate should be about 200K char/second and not 800 to 1000, unless there are lots of gaps in data.
it is less about the baud rate as this get set in hardware and works, but if the data rate is high as char/second, when this is high, some devices do not work., my sustain char rate is over 10k/second
Yani, do you think you can buy and FT232 and test this, I have done all I can to help on this.
https://www.amazon.com/gp/product/B06ZYPLFNB/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Thanks,
Mostafa
16 bucks a piece of wire?
The point is not how much data should be, the point is that this speed now works for me, I think that the arduina will not be able to physically transmit. But the fact that speed is supported from two sides and there are no glitches is wonderful.
You never said who initiated the data transfer. The fact that you have a wire with a USB chip we understand, but who is the sender in UART? What stone is up to rx / tx chips? Maybe he is the reason for “overflow”?