This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF UART app works on android, not on iOS 8.4

My ANT BLE application runs on a custom board with a nRF51422, SD 310 rev 2.0.0

I can use the nRF UART app on an android phone, but on an iPhone with iOS 8.4 I can't even see the device.

I can see the device in the list in the DFU Tool in the nRF Toolbox, but in nRF UART nothing.

Are there any connection/advertising/timeout/... parameters I should be aware off, in order to use iOS for UART?

  • You need to make sure you have called sd_ble_uuid_vs_add() to the UUID base database before you call sd_ble_uuid_encode().

    However, we are talking about the advertising packet here. So it may not related to sd_ble_uuid_encode() issue. Could you check what you are advertising ? Make sure you have

    m_adv_uuids[] = {{BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}}; 
    

    and added m_adv_uuids into the advertising packet or scan response packet.

  • You were right about the incorrect order of uuid_vs_add and uuid_encode. Switching the calls makes encode call return success now.

    Doesn't solve my problem though. The codebase I use does not have a NUS_SERVICE_UUID_TYPE defined, but a peek in the s110 example tells me that the type is 2, so uuids array lloks like this: static ble_uuid_t adv_uuids[] = { {BLE_UUID_NUS_SERVICE,BLE_UUID_TYPE_VENDOR_BEGIN}, {BLE_UUID_CYCLING_POWER_SERVICE, BLE_UUID_TYPE_BLE},{BLE_UUID_CYCLING_SPEED_AND_CADENCE, BLE_UUID_TYPE_BLE},{BLE_UUID_BATTERY_SERVICE, BLE_UUID_TYPE_BLE}, {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE} };

    Is there a way in which I can check what is actually advertised? (where should I stick a breakpoint to see if the correct function is called)

  • The NUS_SERVICE_UUID_TYPE tells the stack of the index of the base UUID that we add to the database inside the stack using sd_ble_uuid_vs_add().

    sd_ble_uuid_vs_add() function returns the index of the UUID in uuid_type as the output. You can then use the value of uuid_type for the value of m_adv_uuids.

    We use NUS_SERVICE_UUID_TYPE (=0x02) just because in the example we only have one Vendor specific base UUID, and it will be at index = 0x02. But if you have more than one you should use the value returned when you call sd_ble_uuid_vs_add.

    Note that the advertising packet setting up is a separate process with the service and characteristic initialization process. They are 2 independent setting up.

    You can see what is advertised using Master Control panel application either on PC or on Android, or with iOS you can use 3rd party app called "LightBlue"

  • Using the returned value - which is 3 by the way - doesn't do anything good either.

    In LightBlue the advertisement data do not contain a local name or any Service UUIDs, as is the case when using the example.

    The answer may lie in this statement from you: "Note that the advertising packet setting up is a separate process with the service and characteristic initialization process. They are 2 independent setting up."

    This paragraph makes no sense to me, could you please try to explain in some detail? What is the "characteristic initialization process" for example?

  • @peterh: Please double check, the 128 bit NUS UUID is added to the scan response packet when advertising in our ble_app_nus example. In LightBlue you can see the advertisement data when connected and click "Show" button next to "Advertisement Data".

    The setting up of advertising packets (advertisement and scan response packet) are on GAP (Generic Access Profile) and the setting up of services and characteristics are on GATT (GENERIC ATTRIBUTE PROFILE). They are not the same and doesn't have to be related to each other. In the source code one is done by advertising_init() and the other is by services_init()

Related