Connect IQ BLE scan issue

First thing is make sure you watch the breakout session where this was announced

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/adding-bluetooth-connectivity-to-your-connect-iq-projects

Understand this is a very limited implementation on the garmin devices, where things like the amount of data you can receive is minimal. no security, you need to define your services and characteristics in your app, you don't always see names and/or UUIDS, etc, and you are limited to .registering at most 3 profiles.

Without seeing your code, what I usually suggest is a simple hack to the NordicThingy52 sample in the SDK to see what's happening with scanning.  In the ThingyDelegate.mc, add the following line to contains, and you'll see everything seen when scanning

    private function contains(iter as Iterator, obj as Uuid) as Boolean {
        for (var uuid = iter.next(); uuid != null; uuid = iter.next()) {
//Add this line
//System.println(uuid.toString());    
            if (uuid.equals(obj)) {
                return true;
            }
        }

        return false;
    }
}

As far as the real device, I have an app that shows you exactly what the Garmin can see with scanning and you can see a time stamp for when the scan result was seen.

https://apps.garmin.com/apps/9bcc8b66-8385-4afb-b93e-f69e01422284

Different size UUIDs also come into play,  For example, I need to use the base UUID for a BLE HRM.

//Using 16 bit UUIDs
//Ref. the Bluetooth Core Specification 5.2, Vol 3, Part B, section 2.5.1 UUID:

//The first UUID in this pre-allocated range is known as the
//Bluetooth Base UUID and has the value 00000000-0000-1000-8000-00805F9B34FB

//(...)

//The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple
//arithmetic operation.

//128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID


//128_bit_value = 32_bit_value * 2^96 + Bluetooth_Base_UUID"

//What it means in practice, is that you take a "base UUID" of 0000xxxx-0000-1000-8000-00805F9B34FB, 
//and replace the x-es with the 16 bit UUID.

First thing is make sure you watch the breakout session where this was announced

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/adding-bluetooth-connectivity-to-your-connect-iq-projects

Understand this is a very limited implementation on the garmin devices, where things like the amount of data you can receive is minimal. no security, you need to define your services and characteristics in your app, you don't always see names and/or UUIDS, etc, and you are limited to .registering at most 3 profiles.

Without seeing your code, what I usually suggest is a simple hack to the NordicThingy52 sample in the SDK to see what's happening with scanning.  In the ThingyDelegate.mc, add the following line to contains, and you'll see everything seen when scanning

    private function contains(iter as Iterator, obj as Uuid) as Boolean {
        for (var uuid = iter.next(); uuid != null; uuid = iter.next()) {
//Add this line
//System.println(uuid.toString());    
            if (uuid.equals(obj)) {
                return true;
            }
        }

        return false;
    }
}

As far as the real device, I have an app that shows you exactly what the Garmin can see with scanning and you can see a time stamp for when the scan result was seen.

https://apps.garmin.com/apps/9bcc8b66-8385-4afb-b93e-f69e01422284

Different size UUIDs also come into play,  For example, I need to use the base UUID for a BLE HRM.

//Using 16 bit UUIDs
//Ref. the Bluetooth Core Specification 5.2, Vol 3, Part B, section 2.5.1 UUID:

//The first UUID in this pre-allocated range is known as the
//Bluetooth Base UUID and has the value 00000000-0000-1000-8000-00805F9B34FB

//(...)

//The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple
//arithmetic operation.

//128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID


//128_bit_value = 32_bit_value * 2^96 + Bluetooth_Base_UUID"

//What it means in practice, is that you take a "base UUID" of 0000xxxx-0000-1000-8000-00805F9B34FB, 
//and replace the x-es with the 16 bit UUID.

Understand that if Garmin decides to change the BLE on their devices, it will very likely only be rolled out to the newer devices,  Many device rarely, if ever get new FW after they've been out for a while.  It's been over 4 months for the Fenix 6 series and over a year for the fr945 and fenix5+

Yeah, good point, but perhaps Nordic has made a specific FW to be used together with CiQ? So made by Nordic for Garmin. But not sure, perhaps just the generic BLE FW.

Regarding discoverable. We have a product already on the market which advertises the way it does. Plus, I feel like discoverable doesn't really mean much in BLE. It used to in classic BT (BR/EDR) and has sort of just made its way into BLE to make sure BLE fits the spec. If a BLE device advertises (and doesn't advertise non-connectable) then it by pure logic is discoverable, regardless of the flag or not. So disregarding what we're doing it still sounds like a good idea for Garmin to look into why they indeed require the flag and if that's really a good thing.

The hex file you flashed is from Nordic, not Garmin.

Is there a reason you don't want your devices to be discoverable?

Yeah, you actually got it. It's the GeneralDiscoverable flag which makes it not work.

Our peripheral devices doesn't advertise it. Android, iOS, wearOS watches, watchOS watches don't care about that. But apparently CiQ for Garmin does. 

Also find it a bit strange that their FW on a nRF dongle doesn't care about it but their actual watches do.

Anyway, now we know. I guess all we can do is hope that they change it. Thanks for help!

I'm actually not sure I could get what you want.  Seems there is something with the way you advertise.  Maybe experiment with your advertiser and see if you can get blescan to see it, or get a Thingly52 so you can see first hand what works, grabbing any data you need yourself.  I suspect it has to do with the flags in the advertisement.  With nRFconnect on my android phone and a Thingy52, the flags are:

GeneralDiscoverable,BrEdrNotSupported

(Same on my Pi devices)