How Many Generic ANT Channels are Allowed

Is it possible to have more than 1 Generic Ant Channel operating at the same time?

I would like to collect data from 2 to 4 Moxy sensors at the same time.

When I try to open a second channel, I get "Unable to acquire channel."
  • Currently, only one channel is allowed. In the next release we plan to extend this to allow a Connect IQ developer to open as many generic channels that are available on the device. The number of available channels depends on the current number of generic channels the Connect IQ developer is using as well as the channels in use by the ant main subsystem (ex: channels used by the HR profile, Bike Speed profile, etc).
  • Former Member
    Former Member over 9 years ago
    Did Support for multiple channels happen

    I want to connect multiple power meters with a view to performing field comparison tests.
  • Former Member
    Former Member over 9 years ago
    Yes, with CIQ 1.2.0, which is now available in beta, multi ant channel support was added. Typically, depending on ant chip in the device, you can use up to 8 channels.
  • Former Member
    Former Member over 9 years ago
    I want to connect multiple power meters with a view to performing field comparison tests.

    I don't think this will practically be possible, despite theoretically being possible. As far as I can tell, without white/black lists there is no way to stop all the channels from picking up the same device.
  • I was just playing with this a little bit. Of course with Moxys instead of Power Meters.

    There's no user input available on a Data Field so I just had it go through a sequence of pairing first to one Moxy and then to the next. I set up a 5 second delay after the first sensor paired before looking for the second one. Since it's using proximity pairing I was able to move the first sensor away and move the second sensor in close during the 5 seconds. It worked, but if you make a mistake and pair to the wrong sensor, you have to start over. This seems a bit too complicated.

    I haven't thought through it much yet, but I'm wondering if the new App Settings could be used to assign sensor numbers for each ANT channel. The user could enter the sensor numbers they want in Connect Mobile or Express. This is easy for Moxys because the sensor number is marked on each unit. I don't know if most power meters are marked or not, but it's easy enough to find the numbers from the Garmin watch's native Pairing menu.

    Even better would be if I could write a Sensor Pairing Watch-App that would just be for pairing the sensors and writing the data back in the App settings. I'm not sure if Apps and DataFields can share the same settings though.
  • Former Member
    Former Member over 9 years ago
    ..... assign sensor numbers for each ANT channel.....
    Assuming you can do this, how do you stop the channel from picking up another sensor? As far as I can figure, you can only choose to ignore an incorrect sensor, and re-initiate the pairing process. So you have to keep moving the items around, and keep your fingers crossed. In short, the process is essentially random, and that is unprofessional IMHO. You just wanna train.... users should not have to do a pairing dance :)
  • Hi sharkbait,

    Thanks for you post. I'm not sure I understand the problem you are describing. My vision is to make 2 or more ANT channels like below.

    class MoxyField extends App.AppBase
    {
    var mSensor;
    var mSensor2;

    function onStart()
    {
    mSensor = new MO2Sensor();
    mSensor.open();
    mSensor2 = new MO2Sensor2();
    mSensor2.open();
    }

    function getInitialView()
    {
    return [new MO2Field(mSensor, mSensor2)];
    }

    function onStop()
    {
    return false;
    }
    }


    The each MO2Sensor will have the following code:

    mDeviceConfig = new Ant.DeviceConfig({
    :deviceNumber => sensorId, // This would be set from the App Settings
    :deviceType => CONFIG_DEVICE_TYPE,
    :transmissionType => CONFIG_TRANSMISSION_TYPE,
    :messagePeriod => CONFIG_MESSAGE_PERIOD,
    :radioFrequency => CONFIG_RADIO_FREQUENCY, // Ant+ Frequency
    :searchTimeoutLowPriority => CONFIG_SEARCH_TIMEOUT_LOW_PRIO, // Timeout in 25s
    :searchTimeoutHighPriority => CONFIG_SEARCH_TIMEOUT_HIGH_PRIO, // Timeout in 5s
    :searchThreshold => searchThreshold // 0 if Sensor Number is known, otherwise Proximity Pair
    });


    If sensorId is set to 430 for MO2Sensor and set to 431 for MO2Sensor2, then the user should never get connected with the wrong sensor. The only issue is how to set this up the first time. That's where I'm thinking the user could manually enter the numbers into an App Setting or use a separate pairing app that would write to the App Setting. I haven't played with the App Settings yet though so maybe this wouldn't work.

    Let me know if I'm missing your concern. I don't want to go a long way down a dead end.
  • Former Member
    Former Member over 9 years ago
    My thought is that although you can specify the device id, you have to wait until a device connects to check that id. If it is not the desired id you need to re-initiate the pairing, and what's to stop the incorrect id from being found again? So I see a potential loop of reconnecting to an incorrect id multiple times.

    Black/White lists are part of the ANT+ specification. Although since you have me thinking about this again, I guess I can't really see how they can not work on the same principle of connect, check, decide. I had envisioned trying to pair, find an incorrect device, add to temp blacklist.

    My thinking way back when, was that if you did not get the desired device, you could increment the proximity value, and search again. However my testing of this found that the proximity value seemed to make pairing more problematic.

    Maybe I'm just overthinking it, and it won't be a problem. I don't want to be a pairing pooper, especially when I'm mostly theoretical atm.
  • My thought is that although you can specify the device id, you have to wait until a device connects to check that id.

    I thought that if you specified the device id, other devices would not be found (possibly assuming the searchThreshold value is set to 0). Am I not remembering this stuff correctly?
  • Former Member
    Former Member over 9 years ago
    I thought that if you specified the device id, other devices would not be found (possibly assuming the searchThreshold value is set to 0). Am I not remembering this stuff correctly?
    Sounds right to me, but that's on the face of things. Surely an incorrect device has to connect, get checked, then dropped. So I guess I'm questioning if there is a way to prevent the same unwanted sensor from being picked up. I was thinking of the lists, then realized they probably have to work in the same fashion. So I think that leaves us with proximity, or like Roger said, you can do the sensor dance and get them to pair. The dance (moving the watch to the next device) is a hack in my opinion. Does incrementing the proximity value provide a solution?