Multiple Instances of a Single Source Stream
Because there is no practical use for updating a source in different modules at the same time, the system only creates one instance of the source information. If you configure different settings for the source in different modules the last in the configuration will be used. E.g. if you set different upper limits for the output (using the maths options) then the last module listed in the configuration would overwrite the limits set in the earlier module.
IMPORTANT: While it is acceptable for more than one module to be configured to output the same source/filter – you MUST:
- ensure that only one of the modules is active at any one time
- ensure that the settings for the source are common across all modules. i.e. maths options are the same.
For example, you have two Bluetooth heartrate modules both configured to output HeartRate@1. This is fine as long as other factors in the configuration or real-life usage avoids both modules being active at the same time (e.g. a person would only ever wear one heart rate monitor). If both become active (i.e. the person wears two monitors) you will get an unpredictable/flip-flopping combination of the module’s output values.
Multiple Instances of a Single Sink Stream
Sinks of data are created one per module and are unique to that module (which makes sense as you may want to output as CAN and ASCII and have different value representations across different transport layers).
IMPORTANT: since a sink is one per module, you cannot output data with different (maths) settings within that module.
IMPORTANT: using multiple sinks in a single module may have undesired results. For example, a CAN message with 8 ECG bytes in a single message is useful as each will ‘pluck’ the next ECG value from the incoming ECG waveform (ECG is always going to be a waveform). However, if the source data was something like heart rate, then you are unlikely to have 8 heart rate values buffered so many of the other values in the CAN message may then be zero.