# Handling mixed v0/v1 and Classic CAN / CAN FD networks **URL:** \ **Category:** Development & Maintenance\ **Created:** [May 4, 2021, 3:30am UTC](https://forum.opencyphal.org/t/handling-mixed-v0-v1-and-classic-can-can-fd-networks/1230 "2021-05-04T03:30:07Z")\ **Posts on this page:** 1\ **Showing post:** 2
**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 4, 2021, 5:18pm UTC](https://forum.opencyphal.org/t/handling-mixed-v0-v1-and-classic-can-can-fd-networks/1230/2 "2021-05-04T17:18:00Z")
> [@tridge](#): > > I know that my nomenclature with things like “sensor node” goes against the philosophy of v1. That is quite deliberate. Users will see a physical device on their vehicle and the primary purpose of the device is providing sensor data. That is a “sensor node”. Hiding that distinction does not help. The philosophy of UAVCAN v1 does not have anything to say about sensor nodes. DS-015 does, but it does not “hide” anything, it just models the network differently. I [explained this in the adjacent thread](https://forum.opencyphal.org/t/problems-with-ds-015/1219/18); let’s keep this one clear of DS-015. > [@tridge](#): > > Being able to save a full bus trace in a format that can be uploaded to a forum for analysis will also be very useful, much like we use tlog for mavlink logs. This is true. I actually have a solution for this that I intend to work on personally in the foreseeable future. If you require it urgently, let me know, then I will assign this task a higher priority. I have outlined the solution very briefly in the Wireshark thread: [UAVCAN v1 Wireshark plugin - #2 by pavel.kirienko](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/2). The plan is to define a [binary log format](https://github.com/UAVCAN/yakut/issues/1) based on [`uavcan.metatransport`](https://github.com/UAVCAN/public_regulated_data_types/tree/master/uavcan/metatransport) serialized using UAVCAN/serial. It will be protocol-agnostic and implementable both in software (such as Yakut) and hardware nodes. > [@tridge](#): > > How do we do this for mixed v0/v1? I must admit that I’m still quite fuzzy on the node ID stuff in v1, but the bit that I think I may understand makes me nervous about this case. How can we robustly detect that a v0 GNSS packet is a duplicate of a packet from the same node that came is as v1? I do hope the answer is not going to be that we shouldn’t support such mixing, as that would just cause v1 deployment to be deferred a lot longer. This is trivially handled by subject configuration. Suppose there is node A that broadcasts certain data using both v0 and v1. Then there is subscriber B that is v0-only and subscriber C that is also mixed v0/v1. Then, seeing as v0 does not require subject configuration (there are data type identifiers instead of that), you don’t need to do anything to link A and B, they just work. Likewise, leaving node C not subscribed to the v1 subjects ensures that only the v0 link is active. Removal of data type identifiers greatly simplifies the design and configuration of networks. * * * Regarding the bit rate, the plan adopted by DS-015 is [derived from SAE J2284-4](https://forum.opencyphal.org/t/uavcan-can-can-fd-profile/867), where the data bit rate is fixed at x4 arbitration bit rate. Here is an excerpt from the DS-015 specification: ![Screenshot_20210504_193100](https://forum.opencyphal.org/uploads/default/original/1X/57a3f0de862e0163a1d2e34bfe80e816ca646dc2.png) This means that the maximum is currently limited to 4 Mbps. In general, DS-015 defines not only the application layer but also the physical layer, which can be discussed separately: ![Screenshot_20210504_193019](https://forum.opencyphal.org/uploads/default/original/1X/26649ae3f41dc44553ac026cca002a2e08b578b0.png) --- _[View the full topic](https://forum.opencyphal.org/t/handling-mixed-v0-v1-and-classic-can-can-fd-networks/1230)._