• State Not Answered
  • Replies 46 replies
  • Subscribers 22 subscribers
  • Views 3260 views
  • Users 0 members are here
Options
Related

System 8 sensor pairing for ANT

flocsy🤠

I started to get reports from users who participate in beta program and have already upgraded their device to system8 that my datafield stopped working. My datafield uses ANT with GenericChannel (see code below).

I wonder if anyone managed to do whatever changes we need to do in our apps? If yes, can you share the insights?

The only information I found regarding this is from the announcement: https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/system-8-beta-now-available :

Sensor Pairing

If your device application or data field communicates wirelessly with a sensor or peripheral using ANT, ANT plus, or Bluetooth Low Energy (BLE), then you will need to implement a pairing process. Connect IQ allows you to implement a Sensors.SensorDelegate that allows you to have your device pair as part of the device’s sensor paring UI flow. See the SensorDelegate 

In my datafield I specifically ask the users not to pair or at least disconnect their ANT HR band from the device's Sensors menu, and I connect to it from the datafield using Ant.GenericChannel:

Ant.GenericChannel.initialize(method(:onMessage), new Ant.ChannelAssignment(
    Ant.CHANNEL_TYPE_RX_NOT_TX, // Bidirectional Receive (Slave)
    Ant.NETWORK_PLUS)
);

var devCfg = new Ant.DeviceConfig( {
    :deviceNumber => 0,                    // Set to 0 to use wildcard search
    :deviceType => 0x78,                   // Heart Rate Sensors: 0x78 = 120
    :transmissionType => 0,                // Set to 0 to use wildcard search
    :messagePeriod => 32280,               // 4Hz: 8070, 2Hz: 16140, 1Hz: 32280
    :radioFrequency => 57,                 // ANT+ Frequency 2.457GHz
    :searchTimeoutLowPriority => 10,       // Timeout in 25s
    :searchThreshold => 0} );              // Pair to all transmitting sensors
GenericChannel.setDeviceConfig(devCfg);

GenericChannel.open();
  • 0 in reply to flowstate

    I mean, I 100% understand the implementation reasons for why the message is the way it is- when you scroll to a CIQ data field, the field (app) has to start up in order to show the field preview. But this also means that any automatic/unprompted actions such as making a GenericChannel connection will also be carried out by the app, and in this case it means an annoying and confusing warning will appear.

    I've even seen the warning appear after returning to the watchface from an activity using a hotkey, where the generic message makes even less sense.

    TL;DR I don't think you *have* to implement SensorDelegate but it might make for a nicer user experience.

    Then again, people have reported user experience issues with SensorDelegate too. 

    e.g.

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/native-sensors-appearing-under-sensors-connect-iq-menu-ciq-system-8 

  • 0 in reply to flowstate

    I am not sure if it really makes any difference if I implement it. I don't know because it doesn't seem to work in the simulator and I haven't seen any ciq app yet that implemented it (or it's not noticable on real device either)

    Maybe it only makes sense when the app uses sensor (not Generic channel)? Not clear from the docs.

    Also would it work, it might render my app useless (at least that was one of my 1st thoughts when I read the announcement) because it might pair the ant device to the Garmin device, which would meant the app won't see it...

  • 0 in reply to flocsy🤠
    flocsy🤠 said:
    I am not sure if it really makes any difference if I implement it

    I think if you implement it, the user won't see the message that we discussed above at "random" times, since they will go through the native pairing process. At worst they will see it during the native pairing process, but I think that would be a lot more user-friendly, as the user is now taking explicit action to pair a sensor. (i.e. There's a huge difference between editing a data field, scrolling to a random CIQ field and getting a generic message "do you want to make an insecure connection?" vs. actually going through the sensor pairing UI and getting the same message.)

    It's up to you. I already described above how the current message implementation is very user-unfriendly by default, and you've seen it yourself.

    I mean, I haven't updated my old apps to use SensorDelegate, so I'm not exactly in a position to tell anyone what to do.

    I'm only saying that there would be a benefit afaict.

    flocsy🤠 said:
    Also would it work, it might render my app useless (at least that was one of my 1st thoughts when I read the announcement) because it might pair the ant device to the Garmin device, which would meant the app won't see it...

    We already talked about this a long time ago when you brought it up at the time of the announcement.

    It would make 0 sense for it to work that way - why would Garmin provide CIQ devs a new way to utilize the native pairing process for ANT+ devices in such a way that their apps can no longer communicate with the ANT+ devices in the same way or even at all? 

    "Here's a useless feature that will break your apps by design. Enjoy!"

    That wouldn't make any sense, and it isn't supported by any of the documentation or anything that Garmin said.

    If it really worked that way, there would be no reason to introduce new features in the CIQ API to accomplish the outcome you described. Users can *already* pair a ANT+ sensor natively with a Garmin watch in such a way that CIQ apps cannot directly connect to the sensor, without any need for the apps themselves to somehow participate in that process.

    Unless ofc you are thinking of the very specific use case where a CIQ data field wants a sensor to be paired completely natively (in a scenario where the user wouldn't otherwise do so on their own), but the data field will read the data indirectly through some standard CIQ API. For example, until about 1-1/2 years ago, some CIQ data fields asked users to pair their Stryd running power meters natively as (cycling) power meters so that the data field could indirectly access power data via ActivityInfo.*power fields. Well, that one use case doesn't even work anymore. I can't really think of any of comparable use case. 

    Ofc that's just my read of the situation - you don't have to agree, but maybe apply Occam's Razor and also consider that Garmin wouldn't do a bunch a work for a feature that is worse than useless.

    https://developer.garmin.com/connect-iq/core-topics/pairing-wireless-devices/ 

    Pairing a Device

    The user will be presented with a list of devices to choose from. If a device associated with your app is selected, your Sensor.SensorDelegate will be re-instantiated, and the SensorDelegate.onPair() will be called with the Sensor.SensorInfo passed as a parameter. At this point, your app should do the necessary steps to pair the device. On ANT, this could be as simple as capturing the device id and persisting it

    I think this should make it very clear that:

    - it's the app itself which is doing the "pairing", CIQ / the device firmware is only providing a nice, standard UI to accomplish this

    - as described, the app itself is in complete control of the actual "pairing"

    - the fact that the docs describe the ANT "pairing process" as being as simple as the app "capturing the device id and persisting it" implies that the app itself will later make a connection to device itself (outside of this pairing process) - i.e. devs can continue to use Ant.GenericChannel to their heart's content

    There's also the fact that, as other devs described, there is a separate category/sub-menu in the sensors menu for Connect IQ sensors. If these sensors were truly paired directly to the watch (as they would be without CIQ involvement), it wouldn't make much sense for that separate category to exist.

  • 0 in reply to flowstate

    Ofc regardless of what you think of my guess/analysis above, the best way to find out is to try it yourself.

    Btw, I've said this before, but I think the motivation for this "new" CIQ native pairing process feature is exactly the same as the motivation for the "insecure connection" message - the new EU regulations.

    The insecure connection message is motivated by the new EU regulations, and Garmin wants to give CIQ apps a way to play with this new system/UI in a *user-friendly* way. (Again, the way the message is displayed for existing CIQ apps that use ANT+ connections without SensorDelegate is *not* user-friendly, because the message basically comes out of nowhere at unexpected times, without adequate explanation or context.) See the problem is if a CIQ app makes an ANT+ connection "in the background" (with no user intervention / UI), there's no good way to display the insecure connection message in a user-friendly way. By allowing apps to use the standard native pairing UI, Garmin can display the insecure connection message in a more predictable and user-friendly way (at least that's how I think it works).

  • 0 in reply to flowstate

    Also, 6 months ago, maca88 literally posted a github repo with a Monkey C project which:

    - uses SensorDelegate to save an ANT ID for a bike light 

    - uses Ant.GenericChannel to connect to the bike light 

    https://github.com/maca88/SmartBikeLights/blob/master/Source/SmartBikeLights/source-common/BikeLightSensorDelegate.mc 

    See also:

    https://github.com/maca88/SmartBikeLights?tab=readme-ov-file#individual-light-network 

    So you could just look at the code or ask them how it works in practice....

  • 0 in reply to flowstate

    I looked at it. Of course it's doing whatever it does, but what I wrote a over still applies: I have that same "skeleton" and every method logs it's name when called, but I was not able to see any of the methods called in the simulator...

Copyright © 1996-2025 Garmin Ltd. or its subsidiaries