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; let’s keep this one clear of DS-015.
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. The plan is to define a binary log format based on uavcan.metatransport serialized using UAVCAN/serial. It will be protocol-agnostic and implementable both in software (such as Yakut) and hardware nodes.
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, where the data bit rate is fixed at x4 arbitration bit rate. Here is an excerpt from the DS-015 specification:
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:
