|
This matter really shocked me. |
Until one day, I felt that this matter might not be so simple and worth pondering.
A very simple example is our country’s BeiDou system, which has put in a lot of effort to develop atomic clocks for high-precision timing, as this clock greatly impacts the performance of the BeiDou system.
Another example is the autonomous driving testing solution of Shanghai Kunyi Company, whose core advantage in leading globally lies in their high-precision timing synchronization performance.
Shanghai Kunyi has made tremendous progress in the field of autonomous driving testing.
Scenario
Suppose you are testing a performance parameter, and you send a message to the DTU, expecting it to return the message on the same network or different networks, with a requirement on response time. Typical applications include event message routing, UDS diagnostics, remote frames, etc.
Moreover, for the convenience of subsequent trace analysis, you have adopted a “real-time recording + offline analysis” testing solution.
However, when you analyze the timestamps of the message sequence, you find that the timestamp value of the sent message is unexpectedly larger than that of the received message.
This means that the DTU responded before receiving your request, making you start to question your life???
First, let’s conduct a few typical experiments.
As shown in the figure, id0x308 is our experiment. In the trace interface, we can clearly see that the timestamps for sending and receiving the message are both 42.536914s, and they are completely equal.
This is as it should be, after all, on the bus, sending and receiving are simultaneous.
Next, let’s change the testing method. We add hardware, the TC1013 from the same star company, short-circuiting CAN1 of 1016 and CAN1 of 1013, and then send the 0x308 message through CAN1 of 1013 to see what happens.
Of course, we need to modify the hardware channel mapping first; this is common sense and does not need further explanation.
Let’s send a message and see.
Does it feel a bit unexpected?
Clearly, there should be sending before receiving, and both should be equal, but the timestamp of the received message is unexpectedly smaller than that of the sent message, with a difference of -0.163ms.
At this point, I suspect that it is due to the insufficient synchronization precision of the 1013 and 1016 devices at the moment Tsmaster connects, as both have their own timers, but the values of the counters are different.
At this moment, many people might think that if we reverse it and send the message from 1016 to 1013, the timestamp difference should be 0.163ms, as the error should be stable; Tsmaster is still running and has not reconnected, and the clocks of 1013 and 1016 are still running, so the error should be fixed.
Next, let’s conduct an experiment by sending a message from 1016.
As shown in the figure, the timestamp difference is 0.605ms, rather than the 0.163ms I imagined, which might surprise many.
At this point, some people might directly take the opportunity to criticize.
“Look, domestic products really are not good!”
Next, let’s see what level vector’s products are at.
First, we only use one VN1640A module, and the trace of sending messages is as follows, first sending forward and then backward.
The timestamps of vector in the same device seem a bit strange.
No matter if sending forward or backward, the timestamp value of the received message is smaller, which I personally find unreasonable.
For messages, shouldn’t this time start counting from the synchronization segment? Shouldn’t the two timestamps be equal?
Why does it feel a bit like Martian timestamps!!
Forget it, let’s not get hung up on a single CAN box; let’s directly enter the phase of multi-module synchronization investigation.
We use two VN1640 modules, short-circuiting their hardware CAN3 and mapping these two hardware CAN3 to CANoe’s logical channels CAN1 and CAN2.
We continue to send the 0x308 message and see the result.
Conversely, continue to send.
|
The reason why CANoe experiences visible lag when the “run” button is pressed is that I suspect CANoe is coordinating the time synchronization of various CAN boxes, which consumes a lot of computer performance. |
Conclusion
To summarize, in most usage scenarios, Tsmaster and CANoe are almost indistinguishable, such as in-car debugging, message recording, viewing signal values, etc. In fact, in diagnostics and flashing fields, Tsmaster is even more user-friendly and simpler to use.
However, in terms of high-precision synchronization, Vector indeed shows certain advantages.
Though I personally feel it resembles data fabrication, it may not necessarily be that they are truly fabricating data; it could also be due to my insufficient knowledge reserve and misunderstanding.
Therefore, if your testing application requires high-precision timestamps, such as an error not exceeding 0.2ms, then I recommend using a single module from the same star company, avoiding the use of multi-module parallel setups.
This solution has superb performance, and the clock records align well with theoretical analysis, making it the best choice in the industry at present.
After all, the CAN boxes from the same star company have enough channels to meet needs.
If budget is not an issue, just use Vector’s box with hardware synchronization, as this does not require a specific number of channels for a single box.
Vector’s hardware synchronization feature is very useful when coordinating with other devices, such as triggering PICOSCOPE to capture waveforms…
Final Thoughts
For such high-precision applications, besides Vector and the same star company, other brands of CAN boxes are not worth considering; none can compete, and some do not even synchronize timestamps, directly using the time from the computer when plugged in via USB as the starting time 😂😂😂.
Bus Lecture 10, the best Excel2DBC tool in the Eastern Hemisphere, always free to give away.
