See the other Streams, Advanced Concepts pages.

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 values 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. The 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 device's 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 five heart rate monitors, with serial numbers 100 to 104.Normally we would assign them a filter each, so that their data can be identified elsewhere in the system. 

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:

[HeartRate@0][UserNumber@0][HeartRate@1][UserNumber@1][HeartRate@2][UserNumber@2][HeartRate@3][UserNumber@4]

The following table imagines the heart rate monitors connecting and disconnecting over time in the order given. Note how #101 and #102 swap position in the message from Time 7. This is because at Time 7 when #102 reconnects, it takes the first free slot, equally at Time 8, #101 takes the (now higher) first free slot. At time slot 9 we can see that #104 connects - we can state that it would be given the filter of '4' but since our CAN message is not defined to have an data for filter 4 then the message stays the same. i.e. in a real system you would need a second CAN message with data, for example, for filters 4 to 7. One takeaway from this example is that we can end up "missing" data if five devices connect and then one of the earlier to connect disconnects - the system won't move everyone's filter down in value to utilise the now spare filter.

Time Action Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7

1

#100 Connects, assigned filter 0

HR for #100

100

0

0

0

0

0

0

2

#101 Connects, assigned filter 1

HR for #100

100

HR for #101

101

0

0

0

0

3

#102 Connects, assigned filter 2

HR for #100

100

HR for #101

101

HR for #102

102

0

0

4

#103 Connects, assigned filter 3

HR for #100

100

HR for #101

101

HR for #102

102

HR for #103

103

5

#101 Disconnects, gives up filter 1

HR for #100

100

0

0

HR for #102

102

HR for #103

103

6

#102 Disconnects, gives up filter 2

HR for #100

100

0

0

0

0

HR for #103

103

7

#102 Reconnects, assigned filter 1

HR for #100

100

HR for #102

102

0

0

HR for #103

103

8

#104 Connects, assigned filter 2

HR for #100

100

HR for #102

102

HR for #101

101

HR for #103

103

9 #102 Reconnects, assigned filter 4 HR for #100 100 HR for #102 102 HR for #101 101 HR for #103 103