Streams, Advanced Concepts

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.

Stream Maths

Most configured streams allow simple maths to be applied to a stream value either as it is read in (say, from a CAN bus) or before it is output (say, via ASCII).

NOTE: zero values mean the option is not used i.e. you do not need to set multipliers or dividers to ‘1’ to get a value. (This avoids overheads in the embedded system and avoids issues like divide-by-zero errors.)

Options are carried out in the order listed here:

• Offset – This offset will be added to the stream value before transmission. This resultant is then passed to the multiplier.
• Multiplier – The stream output is multiplied by this value. If zero, no multiplication will be performed. The resultant is passed to the divider.
• Divider – The stream output is divided by this value. If zero, no division will be performed. The resultant is passed to the “Lower” filter.
• Lower Limit – output values can be stopped from going below the number in the box to the right. The options are: Ignore – no operation is performed; Truncate – if the value is below the limit set it will be set to the limit value; or Invalidate – if the value is below the limit it will be set to the invalid value (reserved – always zero).
• Upper Limit – same operation as Lower but for the high end limit.
• Mask – a hexadecimal value to be ANDed to mask or crop out parts of the result.

Further operations are:

• Format – Override the default formatting for this stream only. See Values (purple) above.
• Padding – Override the default number padding for this stream only. See Values (purple) above.
• Block – this provides a ‘hint’ to the system in how to size the stream data buffer. This option alters internal operations and should generally be left as-is.
• Downsampling – if the data coming in is faster than that going out it can be useful to apply downsam,pling i.e. for every n=downsample values only one value is output. There are multiple modes for doping this:
  • First – the first of each n samples is used, all other are completely ignored.
  • Average – all n are added together then divided by
  • Minimum – all n values are watched and the lowest of them is output.
  • Maximum – all n values are watched and the highest of them is output.
  • Accumulate Value – each value is added to the last until n samples when the accumulated value is output and the total resets to zero ready for the next n.
• Advanced: Propagation – this option allows a Pilot mastered CAN bus system to reflect messages up or down the hierarchy. Setting “upwards” will mean that data stored in this configured device will be reported to the Pilot master. Downwards is used on the master to explicitly ensure data is passed to one or more slaves.

Filtered Stream Memory Requirements

Filters can be thought of in most configurations as representing devices or people. Every Pilot™ device has a fundamental hardware limit to the number of connections it can simultaneously handle. For example, the Pilot™-Mux can make seven Bluetooth connections.

All devices also have a fundamental limit on storage and memory. Since these limits exist, the software is given the same limits as the hardware. i.e. there is no simple advantage in being able to transmit eight independent heart rates if only seven can ever be gathered.

Since it is not clear in advance how a Pilot™ will be configured, the limits of filters and streams is combined i.e. Each Filter+Stream is an entity to be stored. So, “HR/1”, “BR/1”, “HR/2” requires three storage units. i.e. there is no penalty of how filters and streams are combined.

The current release for Pilot-Mux allows 200 filtered streams to be configured. Pilot-CAN2 is limited to 35. Current releases are limited by available memory.

Groups

Groups can be used to allow/refuse more than one source of data per group. If two wireless devices both have their Group et to “1” then even if two eligible heart rate straps are in range, the first to connect means that the other can’t. This is useful in situations where only one person at a time should be monitored, or multiple people but not two of the same type at a time. E.g. driver and co-driver should be monitored at the same time but only one of each is ever permitted. For a yacht, it may be that tens can be monitored but you want to avoid each crew’s backup device if the primary is already in use.

Leaving a group at zero means this setting is ignored but setting it to non-zero means that only one configured item per group can connect. i.e. if you have five devices all in group zero then if all the devices are present. If they are in a non-zero group then only one per group can be connected to at any one time.

Non-zero group numbers have no numerical meaning beyond associating devices together. i.e. Group 1 behaves as, say, Group 55. There is no interrelation or priority between groups, they are separate entities.

Late Binding

Normally, a source of data, such as a heart rate monitor, is configured in the system with a Default Filter value that makes it clear where the data came from. i.e. if you have two people to monitor, you create two heart rate configuration modules, set one Default Filter to “0” and the next to “1”. Elsewhere in the system you can output each stream of data by using their filter valuers to define where they appear.

However, sometimes it is too limiting to work in this way. Late Binding tells the system that there is a set of kit that as and when it is connected to will be assigned a new Default Filter value. This allows more devices to be configured and downloaded than you might expect (or require) to operate simultaneously. There reasons include:

• You want a pool of more hardware than the Pilot can technically connect to. i.e. the hardware limit for Bluetooth connections on a Pilot-MUX is seven, but you might want to have ten available devices.
• You want to output a simpler output (e.g. CAN) message. i.e. you may want two devices (people) to be collected from but only one standard CAN message containing HR, BR, Serial Number etc. Late binding makes this simple.

From the above, you could, for example, have:

• 10 Bluetooth devices in the configuration and the first seven to arrive (the fundamental Bluetooth hardware limit) will each be assigned to its own filter so that it can be output elsewhere.
• Each Late Binding device must be described to the system. This is done by selecting the Late Binding Flag checkbox on each source device wireless settings. The flag is then used by the system to decide how to treat the devices outputted data.

Legacy: Previously, the Late Binding flag was signalled by adding 128 (technically, logically OR-ing) to the Default Filter value. This has now been replaced by the Late Binding checkbox.

Note: If you have a set of devices and each is powered and connects then the filter order will incremental. If you power multiple devices before they have all connected there is no way to predict which device will get which late binding filter slot, this is due to the way the wireless protocols work – the first device that can connect is not always the first device to be found.

Late Binding Example

We have six heart rate monitors, with serial numbers 100 to 106. We want a single CAN message that transmits heart rate and the serial number of the heart rate monitor. We configure a CAN message as:

The following table imagines the heart rate monitors connecting and disconnecting over time in the order given. Note how #200 and #300 swap position in the message from Time 7. This is because at Time 7 when #300 reconnects, it takes the first free slot, equally at Time 8, #200 takes the (now higher) first free slot.