About the allocation of dynamic nodes

Applications & Usage Libcanard
1

[https://legacy.uavcan.org/Specification/6._Application_level_functions/]
I have seen the example of dynamic allocation of nodes in this link

Time CAN ID CAN data field
1.117 1EEE8100 01 44 C0 8B 63 5E 05 C0
1.117 1E000101 00 44 C0 8B 63 5E 05 C0

1.406 1EEBE500 00 F4 BC 10 96 DF 11 C1
1.406 1E000101 05 B0 00 44 C0 8B 63 81
1.406 1E000101 5E 05 F4 BC 10 96 DF 21
1.406 1E000101 11 41

1.485 1E41E100 00 A8 BA 54 47 C2
1.485 1E000101 29 BA FA 44 C0 8B 63 82
1.485 1E000101 5E 05 F4 BC 10 96 DF 22
1.485 1E000101 11 A8 BA 54 47 42

  1. The assignee sends a unique ID to the assignee three times, 1.117 1EEE8100 01 44 C0 8B 63 5E 05 C0, 1.406 1EEBE500 00 F4 BC 10 96 DF 11 C1, 1.485 1E41E100 00 A8 BA 54 47 C2, but I don’t To understand what the first byte of each frame means, the first bytes of the three frames sent by the assignee are 0x01, 0x00, and 0x00 respectively. I did not see the anonymous frame format from this link. I hope you can tell me the meaning of the first byte

  2. 1.117 1E000101 00 44 C0 8B 63 5E 05 C0 responded by the distributor,
    What does this first byte 0x00 mean?
    1.406 1E000101 05 B0 00 44 C0 8B 63 81
    1.406 1E000101 5E 05 F4 BC 10 96 DF 21
    1.406 1E000101 11 41
    I believe there are two bytes for the first three bytes to check, but I don’t know whether the check is 0x05, 0xB0 or ​​0xB0, 0x00. I prefer 0xB0, 0x00 to check, but the first byte of 0x05 is the same meaning
    1.485 1E000101 29 BA FA 44 C0 8B 63 82
    1.485 1E000101 5E 05 F4 BC 10 96 DF 22
    1.485 1E000101 11 A8 BA 54 47 42
    Same as above

  3. This completes the process. Next time the allocatee sends an allocation request, it will be provided with the same node ID.

The values ​​used in the example above were the following:

Name Value
Unique ID 44 C0 8B 63 5E 05 F4 BC 10 96 DF 11 A8 BA 54 47 (hex)
Preferred node ID 0 (any)
Allocated node ID 125

I don’t know if there is an algorithm, but I’m very confused and can’t see how the node id125 was obtained during the request response process. I am sorry for being stupid.

Hope to get a reply, thanks in advance！

2

I think you are missing this bit of the Spec, where the fields of the data type are defined:

You can see from the above that the first byte contains the node-ID in the seven most significant bits (the bit order was changed in v1 btw) and the flag first_part_of_unique_id in the LSB.

The response is the same basically. Note that the last byte of every frame pertains to the transport layer (it’s called the “tail byte”), and the last two bytes of a multi-frame transfer payload contain the transfer-CRC.

4

I understand the first byte. I ignored the transmission format of dsdl and caused confusion. But how do I get the node ID through a certain calculation through unique_id, because I saw the example directly send three frames of unique ID directly. The node ID (125)? ? ?
Name Value
Unique ID 44 C0 8B 63 5E 05 F4 BC 10 96 DF 11 A8 BA 54 47 (hex)
Preferred node ID 0 (any)
Allocated node ID 125

In fact, I still don’t understand how the 125 node ID is derived. There seems to be no 125 (0x7D) in the value returned by the distributor.

5

This is incorrect, sorry. I forgot that you are working with the legacy protocol, where the transfer CRC is located in the first two bytes of the transfer rather than last two as is the case with the stable UAVCAN v1.

It is there though, but remember that it is in the same byte with the flag first_part_of_unique_id. If the flag is zero, then the byte that contains your 125 becomes 125<<1, which is 0xFA. This is the first byte in the response payload after the transfer CRC.

6

Thank you very much, i think i get it