nRF UART app works on android, not on iOS 8.4

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Fri, 18 Sep 2015 09:24:05 GMT

@Peterh: I'm glad that you found the issue. Regarding the reason #1, it was because sd_ble_uuid_vs_add() should be called (as in ble_nus_init() ) to add the NUS base UUID before you can use m_adv_uuids in advertising_init().

RE: nRF UART app works on android, not on iOS 8.4

peterh — Thu, 17 Sep 2015 12:16:47 GMT

In summary:

iOS UART needs the advertising packet to work, android does not.

The advertising packet didn't come across for two reasons:

services_init() was not called before advertising_init(). It has to be that way around.
The advertising packet was not built correctly, the length was too long (>31 bytes). Splitting the packet into an advertising packet and a scan response packet did the trick.

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Wed, 16 Sep 2015 10:30:07 GMT

Maximum size of an advertising packet is 31 bytes. You have to count all the over head such as the flags, length, etc. My suggestion is to reduce the device name. Let's say, make it 1 byte. Just to test.

You can have 31 more bytes using the scan response packet. It's the second packet that the advertiser sends when receive a scan request from a scanner. You can find the use of "scanrsp" when calling ble_advertising_init() in advertising_init() in the ble_app_uart example.

You can post your code here, so I can have a look.

RE: nRF UART app works on android, not on iOS 8.4

peterh — Wed, 16 Sep 2015 10:16:26 GMT

Success! If I put the adv_uuids into the scan response package, the UART works. Thanks for your help&patience :-)

RE: nRF UART app works on android, not on iOS 8.4

peterh — Wed, 16 Sep 2015 08:59:28 GMT

Aha! Now we're getting close to the issue I guess. I get NRF_ERROR_DATA_SIZE in the call to adv_data_encode, so I break out before even reaching the call to sd_ble_gap_adv_data_set().

I guess I have to reduce the amount of advertising data in some way - is there a good way to split the info, or is it necessary to leave some of the info out?

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Wed, 16 Sep 2015 07:48:36 GMT

@Peter: OK, I understand now. You meant with the example you can see local name and the NUS service UUID and you can connect using nRFToolbox and nRFUART, when with your application you can only see "Device is connectable" and can't find it using nRFUART on iOS.

I suspect there could be some issue when you set-up your advertising packet with advertising_init() function. You may need to check if the call for sd_ble_gap_adv_data_set() return NRF_SUCCESS.

If possible please update your code here so that I can test.

RE: nRF UART app works on android, not on iOS 8.4

peterh — Wed, 16 Sep 2015 05:17:27 GMT

That kind of puzzles me. The advertising info is different in the two cases as explained in my latest answer, but still you think the NUS service is included properly?

Regarding ble_app_uart/nRFToolbox app etc : please look at the top of this thread, it's what I have been doing all along ;-)

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Tue, 15 Sep 2015 15:54:28 GMT

This means the NUS service is included properly in the advertising packet.

I would suggest you to try again with the nRFToolbox app, there is a UART profile included in the app (make sure you update to the lastest one).

You should test with the ble_app_uart example from the SDK before testing with your application.

RE: nRF UART app works on android, not on iOS 8.4

peterh — Mon, 14 Sep 2015 14:58:38 GMT

The example shows: Device is Connectable: Yes LocalName: Nordic_UART Service UUIDs: 6E400001 etc (reverse of the array in code)

My code: Device is Connectable - and that's it I'm afraid...

Thanks for clarifying. I run services_init first, then advertising_init. Could there be something else I'm missing? I guess that some sort of mechanism keeps on advertising while the device is on, but is there something I should do or be aware of in connection with that?

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Mon, 14 Sep 2015 14:31:42 GMT

@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()

RE: nRF UART app works on android, not on iOS 8.4

peterh — Mon, 14 Sep 2015 14:19:36 GMT

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?

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Mon, 14 Sep 2015 12:26:12 GMT

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"

RE: nRF UART app works on android, not on iOS 8.4

peterh — Mon, 14 Sep 2015 07:36:46 GMT

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)

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Fri, 11 Sep 2015 14:41:26 GMT

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.

RE: nRF UART app works on android, not on iOS 8.4

peterh — Fri, 11 Sep 2015 13:27:10 GMT

Got sidetracked, but now I'm back looking at this issue...

You're probably right about the missing 128 bit NUS UUID. Next question is why it isn't there:

In my code the call : err_code = sd_ble_uuid_encode(&uuid, &encoded_size, NULL) returns NRF_ERROR_INVALID_PARAM when I call it with uuid = 1, type = 2 which I believe should represent the NUS. In the example code using SD 110 the same call returns NRF_SUCCESS, so what can I possibly be doing wrong?

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Fri, 21 Aug 2015 13:32:51 GMT

@peterh: The iOS app will look for the 128 bit NUS UUID in the advertising packet and only show devices with this in the advertising packet when you connect. The nRFUart Android app scan for any BLE device, and allow you to connect. After connected it will do service discovery and check if the NUS service is available or not.

You may want to edit the source code of the iOS app to not filter for NUS service in advertising packet. Or add the service into the advertising packet.

RE: nRF UART app works on android, not on iOS 8.4

peterh — Fri, 21 Aug 2015 12:53:37 GMT

The one in the toolbox doesn't recognize my device+software either.

As I commented above, the UART app can be used together with the exampleproject, but not with my current code. My current code does however work with android, so the software isn't entirely bad ;-)

RE: nRF UART app works on android, not on iOS 8.4

Hung Bui — Fri, 21 Aug 2015 12:47:40 GMT

@peterh: Please test with the nrfToolbox (make sure you have latest version). There is an UART profile in the app. It's more up to date than the nRFUart app on iOS.

RE: nRF UART app works on android, not on iOS 8.4

peterh — Fri, 21 Aug 2015 07:10:37 GMT

I can get the iPhone UART app to work with the ble_app_uart_s110 project, which indicates that my problem is in my parameter setup rather than "just" in the iOS part of the world.