This example has two configurations to look at.
The first ("Pilot-Mux, Driver and Navigator.ycd") allows two wearables (Zephyr BioHarnesses in this case) to collect data at the same time. It then outputs all the data from these two wearables in a set of four (two messages per device) CAN messages. The way this is possible is that their Group is set to zero (rule: any device in group zero can connect, regardless of if other group zero devices have connected). The two wearables have been given different filter numbers (0 and 1) so that even though they are both connected, the data is sill kept separate. The CAN messages mirror this by have two of them on filter zero and the others on filter 1. The result is that if either or both wearables are present then the data is available on the CAN bus.
The second example ("Pilot-Mux, Multiple Single Drivers.ycd") is very similar but now has the Group set to '1' for both wearables; this means only one device will be connected at any one time. i.e. if device A connects then device B cannot until A disconnects. i.e. only one device can connect and it is first-come-first-served. Since only one can connect at a time then we can give them both the same filter number as they can't "overwrite or combine with" the other's data. Since our CAN message contains a UserNumber stream then the CAN message contains the information as to who is currently connected. This means a receiver only has to inspect one message to get, say, heart rate; rather than the receiver having to check two CAN messages and using some logic to decide which is the best one (and the receiver commonly doesn't have this sort of intelligence built in).
|File Name:||Pilot-Mux, Two Person.zip|
|File Size:||1.03 KB|
|Last Updated Date:||2023-04-14|