Hello,
some words for CAN driver technical background.
DASYLab expects the data stream continuously, complete and equidistant when receiving at a predefined block size. The receive is carried out with this under CAN measuring settings defined sampling rate and block size. If a sampling rate of 9 Hz and a block size of 9 are provided here, for example, then DASYLab must be made available for 9 data to the retention of the continuous, complete data stream every second. A multimedia Interrupt is used for the data recording of CAN telegrams by the driver. Within the processing of the multimedia Interrupts all CAN telegrams are received. From it on the base of software all telegrams are filtered and in a circle memory inter-buffered from the driver as I wish it with the circuit diagram application (At most 100000 telegrams fit in the circle memory). The current buffer filling level (in per cent) of the port telegram puffer can be sent out as a global variable. Each of these CAN telegrams has an exact receive time stamp, allocated by the programming library from CAN device producer. At the distribution of the telegrams to the handing over data blocks for DASYLab the individual receive time stamps of the CAN messages are taken into account for the exact position assignment within the data field. If to start of a data acquisition CAN messages isn't immediately available, then the concerned positions of the handing over data blocks are filled by the driver with zeros as default up to the arriving of a first sought-after CAN message. If furthermore no telegram is available after the CAN message receive for a position of a handing over data block, then the driver spends the previous CAN message on this gap arising with that again.
Notes for the data receive
In the example is assumed the CAN source generates repeating a data signal string 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. The individual CAN signals are created equidistantly in 10 ms steps (100 Hz) (0, then after 10 ms 1, then after 10 ms 2 ..., then after 10 ms 9, then after 10 ms 0 etc.).
Under the measuring settings the sampling rate with 50 Hz and the block size is agreed on with 1.
It is to start out with the following signal string when sending and receiving CAN if one excludes any temporal Jitter: 0, 2, 4, 6, 8, 0 ... Any second received telegram (data 1, 3, 5, 7, 9) cannot be assigned to the output block any more at the predefined temporal 50 Hz dissolving and is rejected therefore without further fault notes.
Under the measuring settings the sampling rate with 100 Hz and the block size is agreed on with 1.
It is to start out with the following signal string when sending and receiving CAN if one excludes any temporal Jitter: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, ....
Under the measuring settings the sampling rate with 200 Hz and the block size is agreed on with 1.
It is to start out with the following signal string when sending and receiving CAN if one excludes any temporal Jitter: 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8, 9, 9, 0, 0, ... At the predefined temporal 200 Hz dissolving no received telegram is available for every second output block, the previous CAN message therefore is used for the gap.
If the output rate is known, in this sample 100 Hz, one could receive the data stream in the ideal case at the same sampling rate with block size 1 and read the original signal string 0, 1, 2, 3, 4, 5, 6, 7, 8 , 0. Unfortunately both the CAN send and the CAN received have temporal equidistant fluctuations. This is, the consequence from this e.g. the expected telegram recognizably arrives at the time of the output of a block with a delay. This is recognizable at the time stamp. The driver spends the previous CAN message for this gap. For the next output block it is possible that available two received telegrams from the point of view of time matching. In principle, the last usable is used for the output. In this case e.g. the signal string 0 , 1, 2, 3, 4, 5, 6, 7, 8, 8, 0 would therefore arise (double output of 8, 9 is rejected).
A known CAN signal string only can summarizing himself be reproduced by oversampling for the CAN received fault-freely in the example 0, 1, 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 0 .... If you use in the example a sampling rate with 100 Hz for the CAN send you must use and therefore > 200 Hz to the CAN receive.
Although the CAN telegrams are already digitized, they must be looked at like analogous value.
You are following the example to treat the Shannon sampling theorem at the recording.
In the example signal strings like 0, 0, 0, 1, 1, 2, 3,.3 ,3, 4 ,4, 5 ,5 ,6 6, 6, 7 ,8 ,8, 9 ,9 ,0 then arise in the context of attention of the oversampling ...
Respect, CAN telegrams are put on the bus determined by the system after their priority. Another knot wants to put data on the bus at the same time then the knot is allowed this one has a telegram with a higher priority. The telegram with a lower priority is then tried to send once more after a short waiting period. If a collision then will be carried out again, sending is then delayed once more. CAN telegrams are distributed delayedly meant this at high bus burden again and again.
You can see it on the DASYLab receiving side as described before in the examples. The telegrams (signals) are possibly then sorted no longer "correctly". It looks so as if they have been lost in the output blocks.
This has to be expected at subsampling of the signal especially. One can never ensure 100%, e.g. a sine 1:1 can want to receive this cleanly and smoothly again.
Best regards,
MHa
