Is this approach accurate or which is the mask intented to use when using messages? The intrigue started when reviewing the below section of libuavcan v0, and found that the default mask as 0xFFFF80, which covers more than the 13 subject-ID bits on both sides; but couldn’t find the v0 pdf to compare the bit layout with v1.
Instead, you can refer to PyUAVCAN; in the internals under pyuavcan.transport.can you will find a function that computes the set of acceptance filter configurations for a given list of subject-identifiers:
Further, you may need to handle the case where the set of subject-IDs you are supposed to receive is larger than the set of the available acceptance filters. In this case, the coalescing algorithm that is described in the Spec in “Automatic hardware acceptance filter configuration” and implemented in pyuavcan.transport.can.media may be of help:
The default filter config I was looking for will end up with the ID field as (0x1FFF << 8), and in the case of the mask, same as line #195 from the PyUAVCAN function you shared, adding 3 bits to the mask aside from the (0x1D55 << 8).
I also found the migration guide below that clarifies why the bits 22 and 21 are being ignored in the mask. This completes the explanation of all the bits particular when dealing solely with messages, as in the simplest case mentioned earlier.
I think this step of configuring the filter is the only one that is skipped from the libcanard example provided in the repo’s readme; and adding this step to the section that demonstrates how to setup reception could be of support for the documentation.
I think it would be more valuable to add a short paragaph of text about acceptance filters. It is better than code because libcanard itself does not provide any facilities for acceptance filter configuration. A pull request with that change to the README would be accepted.