Where would I be sending my data using sd_ble_gatts_hvx?

[Mitch996]

OK. Weird question. I know, but that's only because I'm in the middle of a large program that I'm reading, believe me, I had done my fair share of homework and I understand the "send" and "receive" operation of GATT is a bit well, unique in that it sort "updates" and "pushes" "characteristics" using mostly notification and indication so conventional wisdom, as in 3 wire UART comm. doesn't really apply... all that well.

So I just copy pasted a bunch of codes that I don't really understand, I can "notify" my nrf51422 mcu with gatt packets, sent from my android phone using a program I coded well, a month ago, everything is fine, but then things got a bit awkward: when I try to hvx-push data FROM nrf51422 to my android phone, I don't really know where I'm sending the data. I have this little text box that will pop up once it receives data, any data, but it's not really doing anything when I execute the sd_ble_gatts_hvx() function, and the mcu program doesn't crash afterwards, everything is fine, with all the right parameters.

Please understand that I understand this could be tricky, because there could be an huge mistake in my android app and I haven't figure it out yet but let's start from something more basic shall we? Where will sd_ble_gatts_hvx send data to? Does it identify with a service? In that it will send data to that service, "shared" by all the characteristics, then that service will try to "relay" the data to the right characteristic, or does it send directly to a specific characteristic?

Please help me! Thanks!

[Mitch996]

Hello Keton, thank you so much for being patient with me and being with me so far, I'm having a bit of problem understanding step #4, "perform secondary discovery to find CCCD handle of this characteristic", how do you mean by that? I don't recall reading it in the nordic semi tutorial.

[Keton]

all of service/characteristic/descriptor stuff is an abstraction made for humans. BLE protocol works on handles - unique 16bit numbers representing entry in ATT table that can be any BLE entity. Those numbers are auto generated by server's BLE stack and there's no way to predict them. So you cannot hard code them in your application (there are exceptions but that's the best practice). In order to have some link between "my characteristic I want to work with" and ATT entry 0x0XYZ of given device UUID numbers were introduced. Those 16 bit (for official SIG stuff) or 128 bit numbers (for custom services/characteristics made by developers) are your unique "thing to remember" your app should be looking for. But all operations require to specify handle so procedure called "service discovery" is needed to map UUIDs to ATT handles. It is a series of steps ("What services do you have?", "What characteristics are inside of service X?", and so on). Because it's time and power consuming APIs typically split it into several operations hence I wrote about "secondary discovery".

PS. as for your question here: devzone.nordicsemi.com/.../ "Method 2" won't work because central's BLE stack will drop unsolicited notification packet the same way a firewall silently drops unwanted incoming IP traffic. This is per spec. As for sd_ble_gatts_sys_attr_set() - this is used by peer manager to restore bond information. In case of bonded device you are supposed to remember CCCD descriptor state for each characteristic and each bonded peer and silently restore it upon connection start. This still won't change anything if central thinks that given notification is disabled. There's no way to have notification working without client subscribing to them first. If you really need such king of functionality consider implementing additional GATT server inside central device and using write instead of notifications. Nordic proximity example demonstrates such use case.

Maybe you should focus on your Nordic board code first and use generic "BLE explorer" app such as nRF Connect for Android as temporary interface. This way enabling notifications on the phone is a simple click of a button.