# Libcanard for UAVCAN/CAN v1 is released **URL:** \ **Category:** Libcanard\ **Created:** [March 8, 2020, 4:07am UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774 "2020-03-08T04:07:49Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![Cherish-forever](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/cherish-forever/32/802_2.png) [@Cherish-forever](https://forum.opencyphal.org/u/Cherish-forever)\ **Post date:** [November 11, 2020, 4:12am UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774/32 "2020-11-11T04:12:46Z")
why libcanard v1.0 protocol not backward compatibility? ---
**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 11, 2020, 6:21pm UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774/33 "2020-11-11T18:21:04Z")
> [@Cherish-forever](#): > > but libuavcan v1.0 has not been released. Yes. This may (or may not? only @scottdixon knows) happen next year, though. > [@Cherish-forever](#): > > why libcanard v1.0 protocol not backward compatibility? Here, read this: - [UAVCAN 2019 roadmap](https://forum.opencyphal.org/t/uavcan-2019-roadmap/666) - [UAVCAN: a highly dependable publish-subscribe protocol for real-time intravehicular networking](https://forum.opencyphal.org/t/uavcan-a-highly-dependable-publish-subscribe-protocol-for-real-time-intravehicular-networking/557) (section _Brief history of UAVCAN_) ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [November 23, 2020, 5:43pm UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774/34 "2020-11-23T17:43:07Z")
> [@Cherish-forever](#): > > but libuavcan v1.0 has not been released. The tacit plan is to develop and release libuavcan before the end of next year with incremental functionality being released throughout the year. This is not a solid plan, however, and relies on finding additional contributors to collaborate on this effort. ---
**Author:** ![ashishraste](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/ashishraste/32/734_2.png) [@ashishraste](https://forum.opencyphal.org/u/ashishraste)\ **Post date:** [December 10, 2020, 10:05am UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774/35 "2020-12-10T10:05:02Z")
Hi @pavel.kirienko and UAVCAN developers, Firstly a big thanks on your awesome work, developing and implementing the UAVCAN standard and now pushing it to v1.0. My query on the above migration guide: Setup: A dual-stack application. I have a set of ESCs using v0 libcanard and running on STM32G4 board. I’m trying to command them from a v1 libcanard publisher. The DSDL I’ve used is the [one](https://github.com/UAVCAN/public_regulated_data_types/blob/192295c4f9b67f4a20b0eabf74757b6597415f2b/uavcan/equipment/esc/1030.RawCommand.uavcan) which worked with v0, but upgraded to v1.0 specification by 1. Included `@extent` in the DSDL file, and used Nunavut to generate appropriate serialization code. 2. Named the data-type identifier as an unregulated fixed-port type, in a different root namespace following v1 specification. Questions: 1. Was hoping to get the reception of (v1) frames working on the ESCs as per the suggestion in the migration guide above i.e. changed the mask of `MSG_FROM_TYPE_ID(x)` from `0x7FFFU` to `0x1FFFU` (in v0 `canard.c`) to clear the most significant two-bits of the subject ID. Couldn’t get lucky with that; is there anything else I’m missing here? Would this dual-stack setup work? 2. Do I need to take care of the toggle-bit in (received) payload frames as touched upon [here](https://forum.opencyphal.org/t/uavcan-v1-0-and-ardupilot/671/9)? Side notes: 1. Was able to verify the reception (and decoding) of v1 Canard RX transfers using SocketCAN media-layer. 2. Updating the MSB bits as above on the ESCs having v0 libcanard didn’t seem to affect much, as they behaved as expected with v0-based commands sent from `uavcan_gui_tool`. Cheers, Ashish ---
**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:** [December 11, 2020, 5:10pm UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774/36 "2020-12-11T17:10:53Z")
> [@ashishraste](#): > > Was hoping to get the reception of (v1) frames working on the ESCs as per the suggestion in the migration guide above i.e. changed the mask of `MSG_FROM_TYPE_ID(x)` from `0x7FFFU` to `0x1FFFU` (in v0 `canard.c` ) to clear the most significant two-bits of the subject ID. Couldn’t get lucky with that; is there anything else I’m missing here? Would this dual-stack setup work? Nope. UAVCAN v0 and v1 can coexist on the same bus, but they cannot communicate with each other. UAVCAN v0 is no longer recommended for new designs; I strongly advise you to get in touch with your ESC vendor and ask them to support UAVCAN v1 natively. I think this answer renders the other questions irrelevant. Feel free to point your vendor to this forum if they need help getting v1 supported. ---
**Author:** ![ashishraste](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/ashishraste/32/734_2.png) [@ashishraste](https://forum.opencyphal.org/u/ashishraste)\ **Post date:** [December 17, 2020, 2:18am UTC](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774/37 "2020-12-17T02:18:15Z")
Thanks a lot for your reply and confirmation. For now, I’ve migrated the ESC firmware to use UAVCAN/CAN v1.0. [Previous page](https://forum.opencyphal.org/t/libcanard-for-uavcan-can-v1-is-released/774.md?page=1)