# Nunavut compatibility for UAVCAN v0 and v1

**URL:** <https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110>\
**Category:** Nunavut\
**Created:** [February 3, 2021, 6:00pm UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110 "2021-02-03T18:00:36Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![kyle-pawlowski](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/kyle-pawlowski/32/543_2.png) [@kyle-pawlowski](https://forum.opencyphal.org/u/kyle-pawlowski)\
**Post date:** [February 3, 2021, 6:00pm UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110/1 "2021-02-03T18:00:36Z")

</div>

We are creating a battery monitor system that we already have working with UAVCAN v1. However, since Ardupilot uses UAVCAN v0, we want to make it work with that as well. The trick is, they use C++ headers generated using a custom Python script, and we would rather use plain C headers. So, I could use their DSDL file for the data type they use and compile it using the latest Nunavut version, but I’m worried about compatibility. Has much changed in the serialization algorithm since then, and if I serialize a message with my Nunavut-generated headers, will it be able to decode it on the other side?

---

<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:** [February 3, 2021, 7:05pm UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110/2 "2021-02-03T19:05:06Z")

</div>

> [@kyle-pawlowski](#):
>
> Has much changed in the serialization algorithm since then, and if I serialize a message with my Nunavut-generated headers, will it be able to decode it on the other side?

Unfortunately, this is not going to work.

The optimal course of action is to approach the ArduPilot maintainers (@jani.hirvinen @tridge) and inform them that the ecosystem is converging on the stable version of UAVCAN, which is v1, and there is demand in having v1 supported.

---

<div class="post-metadata">

**Author:** ![auturgy](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/auturgy/32/845_2.png) [@auturgy](https://forum.opencyphal.org/u/auturgy)\
**Post date:** [February 7, 2021, 6:51pm UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110/3 "2021-02-07T18:51:29Z")

</div>

Manufacturers should be targeting the stable protocol - v0 - as it’s supported by both key flight stacks, and is proven.  
v1 will see a lot of churn as it’s rolled out as it’s basically untested. Pushing vendors to it prematurely is irresponsible and will harm the ecosystem.

---

<div class="post-metadata">

**Author:** ![romain145](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/romain145/32/797_2.png) [@romain145](https://forum.opencyphal.org/u/romain145)\
**Post date:** [February 12, 2021, 2:55pm UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110/4 "2021-02-12T14:55:18Z")

</div>

V0 was never called “stable” but “experimental” instead: [UAVCAN](https://legacy.uavcan.org/)  
It is now legacy and deprecated.

I agree with @pavel.kirienko, new hardware should support the V1 and existing hardware should be updated to support V1 as much as possible.

---

<div class="post-metadata">

**Author:** ![tridge](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/tridge/32/119_2.png) [@tridge](https://forum.opencyphal.org/u/tridge)\
**Post date:** [May 3, 2021, 2:46am UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110/5 "2021-05-03T02:46:06Z")

</div>

> [@romain145](#):
>
> V0 was never called “stable” but “experimental” instead: [UAVCAN](https://legacy.uavcan.org/)  
> It is now legacy and deprecated.

not really. When originally announced what is now called v0 was supposed to be frozen in a stable release, all the way back in 2014.

This is from Pavel in August 2014:

> UAVCAN is a lightweight protocol designed for highly reliable communication  
> in UAV and robotic applications via CAN bus. Its key features are the  
> following:
> 
> - Very low data overhead - which makes it suitable for high frequency  
> distributed control loops.
> - Democratic network - no single point of failure.
> - Supports network-wide time synchronization with sub-millisecond  
> resolution.
> - Allows to efficiently exchange datagrams longer than can fit a single  
> CAN frame.
> - Publish/subscribe or request/response exchange patterns.
> - Doubly-redundant or triply-redundant CAN bus support.
> - Lightweight, easy to implement protocol (minimal sensor node can be  
> implemented in less than 300 lines of C99 [http://uavcan.org/Examples](http://uavcan.org/Examples)).
> - Can be used in deeply embedded systems (the full featured reference  
> implementation in C++ runs on a 32K ROM, 8K RAM MCU).
> - The specification and the reference implementation are open and free  
> to use (MIT License).
> 
> Half a year ago, UAVCAN RFC was first announced here:  
> [UAVCAN - CAN bus for UAV - Blogs - diydrones](http://diydrones.com/profiles/blogs/uavcan-can-bus-for-uav). Since then,  
> UAVCAN got a complete specification [http://uavcan.org/UAVCAN\_specification](http://uavcan.org/UAVCAN_specification)  
> and a full featured portable reference implementation in C++  
> [http://uavcan.org/Libuavcan](http://uavcan.org/Libuavcan) for Linux and embedded systems. It’s worth  
> noting that the list of officially supported embedded platforms includes  
> NXP LPC11C24 [http://uavcan.org/Libuavcan\_platform\_documentation:\_LPC11C24](http://uavcan.org/Libuavcan_platform_documentation:_LPC11C24) - a  
> low-cost ARM Cortex-M0 MCU with an embedded CAN controller and a CAN  
> driver, i.e. a true single-chip solution for cost-efficient CAN bus  
> applications.
> 
> Current release is a preliminary release, which means that some aspects of  
> the specification can be changed in a way that can break backward  
> compatibility. The specification and the standard data type set are  
> expected to be frozen by the end of 2014, which would make a final release.  
> Since the final release, standard data types won’t ever change at all, but  
> new types still can be added (it doesn’t break the backward compatibility).

---

<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:** [May 3, 2021, 6:10pm UTC](https://forum.opencyphal.org/t/nunavut-compatibility-for-uavcan-v0-and-v1/1110/6 "2021-05-03T18:10:41Z")

</div>

> [@tridge](#):
>
> When originally announced what is now called v0 was supposed to be frozen in a stable release, all the way back in 2014.

Yes, but it never happened. Instead, we made v1 out of that. It does not mean that v0 was ever stable.
