I’m sure you understand that Its impossible for me to remotely debug custom hardware/software setups. I need to be able to reproduce the problem myself to be able to fix something. We already have USB-Serial adapters with all supported chipsets we test with, that is best we can do.
have you used FT232R?
What serial to USB device have you test with ? can you please list them?
Thanks,
Mostafa
We use total of 7 USB-Serial adapters with 5 different chipsets:
- FTDI
- Profilic
- CH3X0
- CDCACM
- CP21xx
thanks for the list,
FT232T is FTDI .
have used silicon lab Cp21xx, some work and some slow ad you have seem on my video, all worked work full speed with windows.
Yani, I am really trying to help you debug these issue, I have figure out a way around it for myself so just trying to help you out so these issues are solved and helps you for better product and user experience and expand your customers.
Have you test these device with date stream at highest payload? that is when they do not behave right,
My refresh rate is over 40 Hz with each frame full of data to be displayed.
Mostafa
For the stress tests we use our own ECU simulator software that can be configured to push data as fast as PC is able.
As you have the test setup, start by finding out of problem is due too much data by lessening the data rate, then increase it until you hit into problems. Then try with different adapters and use the one that works the best. Many Android devices do not handle USB traffic very efficiently. I have seen cases when using the USB hard will interfere with other systems like networking and Bluetooth etc.
It looks like I confirmed the problem, after explaining from KGTM…
What happens in a nutshell.
Connection Type USB-SERIAL
RDCAN protocol
ATMEGA328 controller (essentially not important)
Speed 2,000,000 (essentially not important)
I use a software filter on the controller in order to extract data packets from the general stream and get only the data I need. This is approximately 15 frames of 8 bytes each. In this case, everything happens perfectly. Visually, everything suits.
But if I stop using the software filter, in this way I will receive the entire stream of frames: 25 frames of 8 bytes each, the data in this case will slow down and visually it will be displayed as missing some fast frames, for example, turn signals and speed or speed.
There are, as it were, data voids.
What information can I provide? Log entry? Video?
T. E. With dense flow through RDCAN there is a clear loss of bandwidth.
What does this matter is not in iron. Since with other firmware and other software on the same hardware such a data stream passes without any problems.
Obviously a software problem.
In any case, I am ready to test and participate …
KGTM-confirm or deny … Are we talking about the same thing? Take a video …
How much data can be transmitted without noticeable delay to the eye?
I’m just trying to get the whole packet of frames, but all the time I am restricting the whole packet due to the same problem.
I’m trying to understand, is this a matter of firmware?
Or RealDash?
Different android devices give the same delay results.
I repeat, on another software it is possible to get the entire package from the machine without delay. Moreover, the speed is 115200
I have not encountered any delay after we updated to new Android USB serial library, even with 2M baud and reading all frames from 1000Mbps CAN device.
Look, I would love to fix this problem, but I’m unable to remotely troubleshoot custom one-off hardware. I will run all stress tests again after the 1.7.3 release, maybe I can find something.
OK thanks. It is enough that you do not confirm this. So the problem is not yours, but the problem on our equipment. We will also test and verify. So get in touch!
I understand that the log file will not give anything? What do you need for a better understanding? Maybe some tests from our side?
Next week I can make a test version that has extensive logging for RDCAN protocol.
sorry guys for late response, have been very busy with several project.
Yes this is the issue I see, as frame are almost to limit, no dead time in serial transmission, then it all goes bad but not for all serai lto USB device, only for some, only few have worked, WIFI seems to works all the time and at good speed.
My hardware updates at 40 hz, and sends as much data during the 25 msec, I used serial to wifi or serial direct, what I sent to serial does not change weather serial to USB or serial to WIFI, but as I have said before depsing what serai lto USB I sued I get different performance.
Please let mw now if I can help in any way.
Thanks,
Mostafa
I may have found something that can be related to this. While pushing 1Mbps CAN to Android thru Seedstudio CAN adapter running on 2M baud, sometimes frame data will interleave with previous frame data and that causes RealDash to ‘stutter’ on parsing the invalid stream. This seem to happen when adapter is pushing the data faster than serial is able to process. This could also be due if interrupts are used to retrieve data in adapter that next frame is written to serial before previous frame has been pushed out.
While this seem to be very rare occasion, it may cause problems on serial performance. This problem applies connection types ‘RealDash CAN’ and ‘CAN/LIN Adapters’.
I will soon push a new Beta that has improved detection of these interleaving CAN frames on serial data and invalid data parts are discarded by the CAN frame parser. Once new Beta is available, please test and report if you can see any difference to previous version.
Yes sir! Mine furrer will be done!
Hope not to remove due to sarcasm! With hope for humor! Vodka does not happen much)))) 
P. S. Although not block me in the forum)) 
This is actually very good news, and we are waiting for the beta to come out, as if a breath of fresh air!