Dear developers,
I have a question about the actual bit rate of CAN-FD.
This is theoretical result which is provided by Bosch.
This is actual result I can get by performing experiments with PCAN-USB Pro FD.
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.
The gap between theoretical result and actual result
- PEAK-Support
- Sales & Support
- Posts: 1646
- Joined: Fri 10. Sep 2010, 19:34
Re: The gap between theoretical result and actual result
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
You also write
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....
What exacxt have you "measured" and is the graph you post your graph based on your result?
You wrote
How do you "checked" two times, could you explain what exact you have done ? and what you mean with "checked"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.
You also write
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 ?Sender sends continuously messages by using PCAN API (We use C language. We called WriteAPI in the infinite loop).
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
-------------------------------
PEAK-System Technik
Technical Support Team
support[at]peak-system.com
-------------------------------
Re: The gap between theoretical result and actual result
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.
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.
- PEAK-Support
- Sales & Support
- Posts: 1646
- Joined: Fri 10. Sep 2010, 19:34
Re: The gap between theoretical result and actual result
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...
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
-------------------------------
PEAK-System Technik
Technical Support Team
support[at]peak-system.com
-------------------------------
Re: The gap between theoretical result and actual result
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.
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.