At the moment I am writing a program manager for the uavcan network, for internal use.
When testing sending and receiving uavcan.protocol.debug.LogMessage messages under a low network load (up to 100 messages per second), quite often, several times a minute, I receive invalid text messages.
Which are mostly cut or incorrectly glued. I am using libcanard library (Copyright © 2016-2017 UAVCAN Team).
When analyzing the work of the assembly receiving mechanism, a problem was found that, in conjunction with the “optimization trimming” of the ends of packets, revealed a weak assembly information mechanism in the last 8th byte of can frames.
Assembly byte (at the end of the frame):
1 - bit - Start multi frame / frame
1 - bit - End multi frame / frame
1 - bit - togle (packet loss control)
5 - bit - Seq / Req ID.
Question 1: what happens when two consecutive frames from the multipacket of this message are simply lost in the network and the “togle” bit detection is valid ?!
Question 2: is there any fixes in the V1 spec regarding this issue ?!
Question 3: is it possible to see a low-level specification of the internal message format of the V1 frame, since I want to embed the processing of V1 messages in the program now and write the assembly mechanism for receiving myself.
Does V0 or V1 provide “mandatory” sync commands to create transaction time windows for devices on the network?
Is there any general rule of synchronization of nodes (for example: behavior for certain commands / messages) for the possibility of implementing timeslots in versions V0 and V1?
Are there commands for the eventual presence of a “transaction” coordinator?
I understand the mechanism and advantages of can bus hardware to regulate collisions, but this is probably good only in theory …
With an increasing network load, sooner or later all physical transmissions will be synchronized by collisions in successive waves of priority transmissions (seen with an oscilloscope).
The number of devices in the collision will increase the packet wavelength.
Setting the transmission intervals of packets from different manufacturers of equipment for two or three devices on the bus is quite real, but if there are several dozen devices, then the setting will be comparable to the difficulty of a Nobel laureate.
Internal transmission intervals of the device are local only for the device, delays in physical transmissions due to hardware “deliberations” of collisions will lead to a decision or increase the transmission buffer (will not solve the problem),
or discard the current transmission because of the next higher priority (not solving the problem, but creating it on the receiving part of the network).
Due to the asynchronous operation of the logic of the device with the physical process of completion of transfers, the operating time of “passively waiting for sending data to the network” will be delayed,
which will increase the operating time of the controller before hibernation (or make hibernation impossible).
Poor setting (any setting for a large network) of message time periods or their erratic behavior (from different manufacturers) can drastically reduce the peak bus bandwidth.
Mandatory support for some synchronization commands can improve the situation radically or make collisions predictable.