Troubleshooting the EmotiBit module
The device is never discovered
Cause. Either both EnableBroadcast and EnableUnicast are disabled, or LocalIPs still
holds its default placeholder addresses (192.168.1.188, 192.168.1.167) rather than the
workstation’s real local IP. Unicast discovery scans relative to LocalIPs; with the wrong
address it scans the wrong subnet and will never find the device.
Fix. Enable at least one discovery method, and set LocalIPs to the workstation’s actual
local IP address. See Configure.
The device is on the network but still not found
Cause. Unicast discovery only scans the last octet of the workstation’s own /24 subnet
(UnicastIpRangeLowerBound to UnicastIpRangeUpperBound). If the EmotiBit is on a different
subnet or VLAN, no unicast address the module scans will ever match it, and broadcast discovery
does not cross subnet boundaries either.
Fix. Put the workstation and the EmotiBit on the same subnet, or use a network configuration that permits UDP broadcast between them.
A sensor channel never appears in the capture
Cause. The channel’s type tag is not in SensorWhiteList. A tag left out of that list is
never requested, regardless of what the connected device supports.
Fix. Add the type tag to SensorWhiteList. See
Data produced for the tag reference.
Heart rate, inter-beat interval or skin conductance response readings are sparse or absent
Cause. HR, BI, SA and SF are event-based, not sampled on a fixed schedule - they are
only published when the device’s own signal processing detects a heartbeat or a skin conductance
response. A poor sensor-to-skin contact suppresses these events well before it visibly degrades
the raw PI/PR/PG/EA signals.
Fix. Check EmotiBit placement and skin contact; this is a device signal-quality issue, not a module fault. There is nothing to reconfigure in the module for this.