The gap between theoretical result and actual result

CAN FD and LIN Interface for High-Speed USB 2.0
Post Reply
we123456
Posts: 3
Joined: Tue 22. Dec 2015, 13:01

The gap between theoretical result and actual result

Post by we123456 » Tue 22. Dec 2015, 13:34

Dear developers,

I have a question about the actual bit rate of CAN-FD.
This is theoretical result which is provided by Bosch.
theoretical_result.png
theoretical_result.png (70.59 KiB) Viewed 10014 times
This is actual result I can get by performing experiments with PCAN-USB Pro FD.
actual_result.png
actual_result.png (22.18 KiB) Viewed 10014 times
We can understand that Average Bit Rate is less than Bit Rate Data Phase,
since Bit Rate Arbitration is 1Mbps.
However, can you explain why there is a gap between two results?

Here is the experiment setting.
- We use two PCAN-USB Pro FDs with two PCs.
- Sender sends continuously messages by using PCAN API (We use C language. We called WriteAPI in the infinite loop).
- Receiver receives messages by using PCAN-View progam.
- We checked two received times. The first one is the time when the 100th message arrives,
the other one is the time when the 200th message arrives. We used 'record' functionality in PCAN-View.

I'm looking forward to your response.

Thanks.

User avatar
PEAK-Support
Sales & Support
Sales & Support
Posts: 1646
Joined: Fri 10. Sep 2010, 19:34

Re: The gap between theoretical result and actual result

Post by PEAK-Support » Tue 22. Dec 2015, 16:05

Sorry, but with your information you gave us we could not give you a final answer.

What exacxt have you "measured" and is the graph you post your graph based on your result?
You wrote
We checked two received times. The first one is the time when the 100th message arrives,
the other one is the time when the 200th message arrives. We used 'record' functionality in PCAN-View.
How do you "checked" two times, could you explain what exact you have done ? and what you mean with "checked"

You also write
Sender sends continuously messages by using PCAN API (We use C language. We called WriteAPI in the infinite loop).
Do you know when sending in C/C++ in a loop without any delay, that you are thousend times faster sending CAN Frames as the CAN FD Controller could ever send ?

Try to undertasd what you are doing:
You write into a memory (the Msg Structure ) and call a API function which simply copy this memory to a buffer inside the Device Driver...the DATA is NOT send on the CAN Bus when you return from the function CAN_Write()
This is not possible (asynchron function otherwise you will block the OS)

You simply write to the Messgae Buffer in the driver and the driver will try to send out fast as possible but will reach very fast the limit and block!

Before you calculate any timings, try to understand what exact are you calculating....
--------------------------------
PEAK-System Technik
Technical Support Team
support[at]peak-system.com
-------------------------------

we123456
Posts: 3
Joined: Tue 22. Dec 2015, 13:01

Re: The gap between theoretical result and actual result

Post by we123456 » Tue 22. Dec 2015, 16:19

Here is my answer.

Above all, to get the maximum value of actual data bit rate, we made the bus overloaded.
To do that, we just called CAN_Write() function continuously, then, as you mentioned,
a buffer inside the device driver would be full.
Then the bus would be busy, and we expected that we could get the maximum value of actual data bit rate by measuring received times of messages (since we couldn't measure the time when the controller received data).
To measure received times of messages, we used 'record' functionality' of PCAN-View.
For example,

1.0 0x001 00 00 00 00 00 00 00 00 <------------- the first message in the recorded file
1.03 0x001 00 00 00 00 00 00 00 00
...
3.045 0x001 00 00 00 00 00 00 00 00 <------------- the 100th message in the recorded file
...
5.142 0x001 00 00 00 00 00 00 00 00 <------------- the 200th message in the recorded file
...

then, we can get that (5.142-3.045)/100 is average transmission time of one message.

This is what we done.
Then, could you reply to my question?

Thanks.

User avatar
PEAK-Support
Sales & Support
Sales & Support
Posts: 1646
Joined: Fri 10. Sep 2010, 19:34

Re: The gap between theoretical result and actual result

Post by PEAK-Support » Tue 22. Dec 2015, 16:32

1.
You cant "overload" the BUS. You only reach the limit of the TRX Windows Device driver buffer from our driver for your client - your Application.

2.
You could not measure on the same PC the same CAN Channel using PCAN-View - then you "measure" only virtual CAN - no real CAN. (Client to Client)

3.
The CAN-FD units have a Busload measuring option, use it and see the real Busload, and if you have error frames on the bus.

Show us how you setup your Bus - which Software is using which Hardware etc. Without this info we could not give you a feedback - as i wrote - explain your problem by give us ALL info about your Test Environment - most info is missing...and so you "measure" ...whatever....we also did not know your C code... to many question marks...
--------------------------------
PEAK-System Technik
Technical Support Team
support[at]peak-system.com
-------------------------------

we123456
Posts: 3
Joined: Tue 22. Dec 2015, 13:01

Re: The gap between theoretical result and actual result

Post by we123456 » Tue 22. Dec 2015, 17:06

1. OK. I understand.
2. we used 2 PCs which were connected 2 PCAN-USB Pro FDs.
3. OK. I'll try to set this option.

We used PCAN-View and PCAN-BASIC API (for C language). After doing additional experiments, I'll post the results.

Post Reply