Let’s discuss briefly tag settings and implications on latency and power consumption.
The lower the refresh interval and backchannel period the lower latency but also shorter battery life.
Firstly, please revise knowledge about refresh interval and sleep modes on page Motion Detection and Sleep Modes.
Backchannel extends the feature set and appends a few options on top of the standard operation. The following tag settings influence the operation and latency of the backchannel:
Avg. The interval between two blinks (0xBB) messages
Refresh interval in sleep mode
Avg. The interval between two positioning messages in sleep mode
Backchannel period in sleep mode
BC period in sleep mode
This parameter is almost the same as the BC period, the only difference is that this one is applied when the tag is in Sleep mode (because of no-motion). The Refresh Interval in Sleep mode must be set to a non-zero value.
Latency and RX Period
The time of backchannel message delivery takes a specific time so-called RX_period.
This period depends on the Refresh interval and BC period for the tag in motion, Refresh interval in sleep mode, and BC period in sleep mode once the tag is stationary.
RX_period [s] = Refresh interval [s] * BC_period [-]
There should be noted that the real value of the Refresh interval is randomized in the range from <0 to 2* Refresh Interval>. So in the absolute worst case, the RX_period value can be double. Anyway, the random deviation of the RI has a uniform distribution (Aloha requirement), so the average value of RX_period will correspond to the calculation.
Let’s assume the following example:
Refresh interval = 1s;
BC period =10 ;
Sleep mode = Disable;
The BC frame, which is prepared on an anchor for a given tag, should be delivered to the tag approximately in 10 s and the worst case in 20 s.
If the tag would have activated sleep mode and it is in a no-motion state (static tag), the RI in Sleep mode and BC_period in Sleep mode should be used for the calculation of RX_period [s].
Latency for Typical Tag Settings
The latency of LED reaction to any request depends on several aspects. First of all, are the configurable parameters of the tag. The second aspect that can impact the latency is the tag is in motion or not. Moreover, it is dependent on the radio environment where the system is running.
average latency [ms]
maximal latency [ms]
Pick-by-light - low power
Pick-by-light - responsive
Pick-by-light - aggressive
All values are calculated for the free radio channel without any collisions.
In the real world, radio communication is always affected by collisions. The Sewio system uses Aloha, which is random access of the tags to the UWB channel. The probability of collisions increases with data traffic and data traffic increases with decreasing RI of the tags and with an increasing number of the tag in the same area.
LED Power Consumption
The LED on the tag has non-negligible power consumption, so as tags are battery-powered devices, it must be taken into account. The maximal time of LED ON state and LED blinking state is limited to the 511s.
Moreover, Tag Asset is powered from a Coin battery that has maximally allowed constant current drain = 2mA. As a LED in ON state drain battery with something about 12mA, there is not recommended to set the LED to the constant ON state on these tags. The preferred variant for this tag is to use the blinking with a pulse width lower than 16% with a period lower than 1s.