# Question about CAN example from Specification v1.0-beta

**URL:** <https://forum.opencyphal.org/t/question-about-can-example-from-specification-v1-0-beta/1517>\
**Category:** Development & Maintenance\
**Created:** [November 12, 2021, 12:17pm UTC](https://forum.opencyphal.org/t/question-about-can-example-from-specification-v1-0-beta/1517 "2021-11-12T12:17:09Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![xbron](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/xbron/32/985_2.png) [@xbron](https://forum.opencyphal.org/u/xbron)\
**Post date:** [November 12, 2021, 12:17pm UTC](https://forum.opencyphal.org/t/question-about-can-example-from-specification-v1-0-beta/1517/1 "2021-11-12T12:17:09Z")

</div>

Hello,  
I’m currently reading your specification (v1.0-beta) and I can’t understand one example from section 4.2.3 Examples (page 63). The example shows _Heartbeat from node-ID 42, nominal priority level, uptime starting from 0 and then incrementing by one every transfer, vendor-specific status code 3471 (decimal base)_.  
First, how is it possible to specify a vendor-specific status code that is **larger** than uint8? Second, maybe I don’t exactly understand serialization process of composite types. According to the description of `Heartbeat` data type field attributes `health` and `mode` have size of 1 byte, so after serialization `value` (from `Health` data type) must be followed by padding fields? Similar situation with `mode` field (from `Mode` data type).  
In the example according to spec `02 00 00 00` - is a value of `uptime` in little endian format.  
Next `E0 B1 01` - is `1110 0000 1011 0001 0000 0001`. It means first 5 zeros in least significant byte are values of `health` (`00`) and `mode` (`000`). Then we have bit sequence of value 3471 without any preceding padding fields. But why is it so? The specification says that the alignment of composite types is one byte.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [November 12, 2021, 3:07pm UTC](https://forum.opencyphal.org/t/question-about-can-example-from-specification-v1-0-beta/1517/2 "2021-11-12T15:07:54Z")

</div>

You found an error — the example you referenced is, indeed, incorrect. It was supposed to be updated after we introduced certain changes since v1.0-alpha.

For clarity, this is how it is actually deserialized:

```python
>>> import uavcan.node
>>> import pyuavcan
>>> pyuavcan.dsdl.deserialize(uavcan.node.Heartbeat_1_0, [b'\x03\x00\x00\x00\xE0\xB1\x01\xE3'])
uavcan.node.Heartbeat.1.0(uptime=3, health=uavcan.node.Health.1.0(value=0), mode=uavcan.node.Mode.1.0(value=1), vendor_specific_status_code=1)

>>> pyuavcan.dsdl.serialize(uavcan.node.Heartbeat_1_0(uptime=3, health=uavcan.node.Health_1_0(value=0), mode=uavcan.node.Mode_1_0(value=1), vendor_specific_status_code=1))
<generator object serialize at 0x7efcc5c4d580>

>>> b"".join(_)
b'\x03\x00\x00\x00\x00\x01\x01'

```

Would you volunteer to send a patch correcting these issues in the document?

---

<div class="post-metadata">

**Author:** ![xbron](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/xbron/32/985_2.png) [@xbron](https://forum.opencyphal.org/u/xbron)\
**Post date:** [November 12, 2021, 5:04pm UTC](https://forum.opencyphal.org/t/question-about-can-example-from-specification-v1-0-beta/1517/3 "2021-11-12T17:04:16Z")

</div>

Thank you for explanation! Now everything has fallen into place.  
I think that I can correct this issue.