ANT Device Numbers?

Why do I get this apparent contradiction? In a Garmin EDGE computer, in Sensors/About, it seems to list the 752963 value. So what is the 32067 value? Thanks!!

RadarSensor.getDeviceState().deviceNumber = 32067

function onMessage(msg) {
        var payload = msg.getPayload(); //get the data payload

        msg.deviceNumber = 752963

  • 32067 = 0x7D43

    752963 = 0xB7D43

    Without looking any further into it, I would venture a guess that the 0xB in the latter device number has some special meaning (maybe it's some sort of status / modifier.)

    i.e. perhaps the actual device number is only the least significant 16 bits, and the most significant 16 bits is additional information. I seem to recall that ANT device IDs are only 16 bits, but i could be mistaken since it's a while since I've looked at this stuff.

    Welp, guessed wrong again.

  • In some places you get 16, in other places 20 bit ANT ID. I also read/understood that the ANT ID is 16 bit, but some users reported that theirs is longer, and then I found out that they can be 20 bit as well. This doesn't even depend on the function you use / field you look at, since from Monkey C's point of vie all these are declared as Number. In the same place you will usually find 16 bit numbers, but sometimes 20 bit number. Looks like it depends on the device, but I'm not even sure about that, as your example shows the same device shows up different in 2 places in the code...

    Short answer: be prepared to 20 bit numbers

  • That makes sense. But in this case, the SAME device reported back two different numbers. FlowState seemed to solve this issue. THANKS!

  • Makes sense. Interesting that the Garmin EDGE unit reports the longer number with the extra bits. But regardless, this solves the issue for me. THANKS!

  • In some places you get 16, in other places 20 bit ANT ID.

    Thanks Gavriel! This is the correct answer.

    But in this case, the SAME device reported back two different numbers.

    It's the same device but a different API call. I hate to speculate again since I'm wrong half the time, but it could be that getDeviceState() only returns the lower-order 16 bits of the device number for compatibility reasons.

    Here's an official resource regarding extended (20-bit) device numbers:

    https://www.thisisant.com/developer/resources/tech-bulletin/pairing-to-devices-with-extended-device-numbers

    The device number is used to identify individual ANT master devices (i.e. to distinguish between two heart rate monitors). If the top nibble of the transmission type is used to extend the device number, then the resulting "extended device number" consists of 20 bits, allowing the 2^20 devices to be separately identified - that's 1 048 576 devices. For comparison, devices using the non-extended two byte device number, 2^16, or 65 536 individual devices can be identified. So if large numbers of sensors are expected, consider using extended device numbers to make the channel ID more uniquely identifiable.

    So, how does the ANT slave match it's channel ID to that of the master it wishes to find?

    Typically the slave knows what kind of device it is looking for and can set its device type accordingly. But, unless the correct transmission type and device number of the ANT master have been programmed into the ANT slave (either at the factory or because the device has paired to the master before and has stored the information) then these values will need to be wildcarded (i.e. set to zero for the search).

    However, once connected, the ANT slave learns the full channel ID of the master, and can store this value for use in future searches. Then when the user turns on the device it will automatically connect to the same sensor.

    In crowded environments, for example gyms, or large race events, the user is likely to switch on their device when surrounded by many possible slaves. But if the full channel ID is used for the search then it will still only connect with matching masters.

    If the master used the extended device number: this means that there is a (number of nearby devices)/ (1 048 576) chance that another nearby device is found instead of the one that the user owns. 

    If the master did not use the extended device number: this means that there is a (number of nearby devices)/ (65 536) chance that another nearby device is found instead of the one that the user owns.

    This difference is the reason that the extended device number is used. It's all about pairing reliably.

    Please note that if a display shows the device number to the user, it may show either the 2 byte device number, or the 20 bit extended device number (if the upper nibble of transmission type is used), or possibly the device number and transmission type. These display options are all acceptable. If the display allows the user to key in the device number from the display keyboard, the display should consider there are two possible "device numbers" that could be keyed in.

    To make slave devices interoperable with both the standard and extended device numbers, the display device typically needs to wildcard both the device number field and transmission field to perform the first pairing search.

    In conclusion: The extended device number is not intended as a number that must be displayed - it is intended to increase a device's chance of pairing to the right device every time - even in crowded environments.

  • Great insight. Garmin did decide to display the EXTENDED device number.