# Interoperability with other CAN protocols

**URL:** <https://forum.opencyphal.org/t/interoperability-with-other-can-protocols/874>\
**Category:** Applications & Usage\
**Created:** [July 16, 2020, 1:46am UTC](https://forum.opencyphal.org/t/interoperability-with-other-can-protocols/874 "2020-07-16T01:46:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![DrProton](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/drproton/32/615_2.png) [@DrProton](https://forum.opencyphal.org/u/DrProton)\
**Post date:** [July 16, 2020, 1:46am UTC](https://forum.opencyphal.org/t/interoperability-with-other-can-protocols/874/1 "2020-07-16T01:46:40Z")

</div>

I’m wondering if I can share a UAVCAN bus with another CAN protocol? This one specifically:

> **[SDK.pdf](https://www.foxtechfpv.com/product/cameras/eh2000/SDK.pdf)**
>
> 3.85 MB

From what I can see there shouldn’t be any “collisions” on the CAN IDs. I would also be sure to not set node ids to anything that makes are partial conflict.

I will have custom device on the CAN bus that talks to this gimbal as well as the autopilot via UAVCAN. I can design my device to manage the two protocols, and maybe even modify ardupilot source if necessary.

What will happen in a UAVCAN device (i.e. GPS, ardupilot, etc) if it receives a frame to/from this gimbal in the middle of receiving frames for some other message type?

Has this been done? What (if anything) do I need to worry about?

---

<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:** [July 16, 2020, 12:07pm UTC](https://forum.opencyphal.org/t/interoperability-with-other-can-protocols/874/2 "2020-07-16T12:07:56Z")

</div>

The spec says this:

 ![image](https://forum.opencyphal.org/uploads/default/original/1X/c06c648928b1dc1f9e310f11d73297d8c36f3c66.png)

_(the footnote 66 says: “For example, CANOpen or CANaerospace.”)_

It might work, it might not, depending on how you set up your port-IDs and priorities. No guarantees. You can make collisions unlikely if you make sure to avoid using conflicting port-identifiers and node-IDs; for that, please refer to the CAN ID layout diagrams in the Specification.

> [@DrProton](#):
>
> What will happen in a UAVCAN device (i.e. GPS, ardupilot, etc) if it receives a frame to/from this gimbal in the middle of receiving frames for some other message type?

If there are no port/node-ID conflict, nothing will happen – the irrelevant frames will be simply dropped. If there are conflicts, the frames might be misunderstood by the device as being part of a meaningful transfer, in which case there are two possibilities:

- If the frames are misinterpreted as single-frame transfers, the node may behave unpredictably due to misinterpreting unrelated data, unless the transfer-ID is misinterpreted as being invalid.
- If the frames are misinterpreted as part of a multi-frame transfer, they will likely be dropped due to a transfer CRC error.