pc-ble-driver-js
pc-ble-driver-js copied to clipboard
NordicSemiconductor
Problem in getting notifications
Hello, I have a device to which I can connect correctly using NRF52 DK board. I do get the services and characteristics also correctly. I turn on notifications on all the characteristics that support notifications - all of which return success. I use following code for doing this.
this.adapter.startCharacteristicsNotifications(characArray[index]._instanceId, true,
error => {
if(error) {
console.error("Failed to turn on notification for " + characArray[index].uuid + ", " + error);
} else {
console.log("Turned on notification successfully for " + characArray[index].uuid);
}
}
);
But I am not getting any notifications on them. Following is the code that I expect should get hit which actually never gets hit.
this.adapter.on('deviceNotifiedOrIndicated', (remoteDevice, characteristic) => {
console.log("Received notification from " + remoteDevice.address);
});
I can see the characteristic value change if I use the NRF connect app - which means my device "is" correctly sending the notifications.
Am I missing on anything? Thanks Amruta
Hi, I'm not sure why you're not getting any notifications here. Could you enable logging and show the output? adapter.open, logLevel: 'debug'
Hello, Following are the logs from the point the device attributes are discovered, notifications are enabled and some data is sent on a different characteristic.
[18:54:51.427] Discovered service 6E401234B5A3F393E0A9E50E24DCCA9E
[18:54:51.428] Discovered characteristic 6E401236B5A3F393E0A9E50E24DCCA9E
[18:54:51.429] Discovered characteristic 6E401235B5A3F393E0A9E50E24DCCA9E
[18:54:51.430] Notification is on for characteristic 6E401235B5A3F393E0A9E50E24DCCA9E
< HERE THE NOTIFICATION IS BEING TURNED ON>
NRF_Log: 1: 275/ 1 <- []
type: ACK reliable: no seq#:0 ack#:5 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 276/ 1 <- [01 9c 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:1 ack#:5 payload_length:6 data_integrity:1 header_checksum:a9 err_code:0
NRF_Log: 1: 246 -> []
type: ACK reliable: no seq#:0 ack#:2 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: GATTC_EVT_WRITE_RSP time:2018-08-16T13:24:51.482Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:16 writeOp:1 offset:0 len:0
NRF_Log: 1: 277/ 1 <- [02 38 00 00 00 00 00 00 00 10 00 01 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:2 ack#:5 payload_length:10 data_integrity:1 header_checksum:7 err_code:0
NRF_Log: 1: 247 -> []
type: ACK reliable: no seq#:0 ack#:3 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 248 -> [00 9c 00 00 01 01 00 21 00 00 00 02 00 01 02 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:5 ack#:3 payload_length:10 data_integrity:1 header_checksum:14 err_code:0
[18:54:51.485] descriptorValueChanged for 2902
[18:54:51.487] Turned on notification successfully for 6E400003B5A3F393E0A9E50E24DCCA9E
NRF_Log: 1: 278/ 1 <- []
type: ACK reliable: no seq#:0 ack#:6 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 279/ 1 <- [01 9c 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:3 ack#:6 payload_length:6 data_integrity:1 header_checksum:9f err_code:0
NRF_Log: 1: 249 -> []
type: ACK reliable: no seq#:0 ack#:4 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: GATTC_EVT_WRITE_RSP time:2018-08-16T13:24:51.576Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:33 writeOp:1 offset:0 len:0
NRF_Log: 1: 280/ 1 <- [02 38 00 00 00 00 00 00 00 21 00 01 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:4 ack#:6 payload_length:10 data_integrity:1 header_checksum:fd err_code:0
NRF_Log: 1: 250 -> []
type: ACK reliable: no seq#:0 ack#:5 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 251 -> [00 9c 00 00 01 01 00 27 00 00 00 02 00 01 02 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:6 ack#:5 payload_length:10 data_integrity:1 header_checksum:3 err_code:0
[18:54:51.578] descriptorValueChanged for 2902
[18:54:51.580] Turned on notification successfully for 2A19
NRF_Log: 1: 281/ 1 <- []
type: ACK reliable: no seq#:0 ack#:7 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 282/ 1 <- [01 9c 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:5 ack#:7 payload_length:6 data_integrity:1 header_checksum:95 err_code:0
NRF_Log: 1: 252 -> []
type: ACK reliable: no seq#:0 ack#:6 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 283/ 1 <- [02 38 00 00 00 00 00 00 00 27 00 01 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:6 ack#:7 payload_length:10 data_integrity:1 header_checksum:f3 err_code:0
NRF_Log: 1: 253 -> []
type: ACK reliable: no seq#:0 ack#:7 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: GATTC_EVT_WRITE_RSP time:2018-08-16T13:24:51.678Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:39 writeOp:1 offset:0 len:0
[18:54:51.680] descriptorValueChanged for 2902
[18:54:51.681] Turned on notification successfully for 6E401235B5A3F393E0A9E50E24DCCA9E
[18:54:51.682] Completed enabling notifications for all the characteristics for D5:5F:FA:29:B7:08
[18:54:51.682] Device service discovery completed for : D5:5F:FA:29:B7:08
[18:54:51.683] Connection successful for My_Device
[18:54:51.694] Sending data 99,5,0 with response.
NRF_Log: 1: 254 -> [00 9c 00 00 01 01 00 0d 00 00 00 03 00 01 63 05 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:7 ack#:7 payload_length:11 data_integrity:1 header_checksum:e2 err_code:0
NRF_Log: 1: 284/ 1 <- []
type: ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 285/ 1 <- [01 9c 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:7 ack#:0 payload_length:6 data_integrity:1 header_checksum:cb err_code:0
NRF_Log: 1: 255 -> []
type: ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: 286/ 1 <- [02 38 00 00 00 00 00 00 00 0d 00 01 00 00 00 00 ]
type: VENDOR_SPECIFIC reliable:yes seq#:0 ack#:0 payload_length:10 data_integrity:1 header_checksum:31 err_code:0
NRF_Log: 1: 256 -> []
type: ACK reliable: no seq#:0 ack#:1 payload_length:0 data_integrity:0 err_code:0
NRF_Log: 1: GATTC_EVT_WRITE_RSP time:2018-08-16T13:24:51.765Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:13 writeOp:1 offset:0 len:0
[18:54:51.766] value of 6E400002B5A3F393E0A9E50E24DCCA9E changed 99,5,0: undefined
[18:54:51.767] Received response for write
[18:54:51.768] Successfully sent data on 6E400002-B5A3-F393-E0A9-E50E24DCCA9E to D5:5F:FA:29:B7:08
After sending this data, I expect some data to be received on the characteristic 6E400003-B5A3-F393-E0A9-E50E24DCCA9E, which I do not.
Is the notification being enabled properly?
Hi,
Thanks for pointing me to logs. I could solve my problem by setting requireAck to false in the API below.
startCharacteristicsNotifications(characteristicId, requireAck, callbackopt) → {void}
May I understand how is the requireAck affecting the notification?
After the notifications were enabled, I expected the event deviceNotifiedOrIndicated to be fired giving me the remoteDevice and the characteristic.
What I saw was that the characteristicValueChanged was getting fired.
In which scenarios is deviceNotifiedOrIndicated fired? I see that even the battery notifications dont land up on deviceNotifiedOrIndicated.
Thanks Amruta
Hi,
the requireAck controls if the write operation should be done as WriteRequest or WriteCommand. WriteRequest requires a WriteResponse in return, WriteCommand does not require a response.
The deviceNotifiedOrIndicated event is used in the reverse case of characteriticValueChanged. It is used when the local ATT server emits a notification or indication to the remote device.
Ooooops! I had interpreted the deviceNotifiedOrIndicated and characteristicValueChanged exactly opposite. Maybe the documentation needs to be more elaborate for this. But no issues there.
I still fail to understand how does setting the Ack true in startCharacteristicsNotifications affect reception of actual notification. It would be helpful if you can shed some light on that.
Another problem I see is w.r.t the RSSI value of element while it is connected. I get the device.rssi as null. How can I get the range of a device while it is connected?
Thanks Amruta
The documentation could be more explicit about describing the difference between the two types of events, I agree.
By setting the Ack parameter to true, it means that you require the peer to respond with a WriteResponse when writing to the CCCD descriptor. However, by looking at the log it does seem to get a resonse, so all should be ok. I do not understand why it works for you when using Ack=false, and not with Ack=true, from the log it looks fine.
Regarding RSSI in a connection, that has not been added API for in adapter.js. However, there exists a function that can be called with adapter._adapter.GapStartRSSI. Disclaimer: Since we haven't made an API for it, it hasn't been tested. See SoftDevice API doc for more info about the arguments.
Yeah! The ack thing is a puzzle. But that was the only diff between my logs and those of NRF Connect.
About the RSSI, I'll check the API you mentioned. Thanks
Hello, With the characteristicValueChanged function, I see one more problem. Consider a scenarios where I have a characteristic which supports read as well as write. There is a two step operation to be done. Step 1: Central writes some data on this characteristic Step 2: Central expects some response back on the same characteristic. Now the way characteristicValueChanged is implemented, this function would be called the moment step 1 is done - and would be called with the same value that central wrote on it. What central is actually interested in is the value that the peripheral writes on this characteristic as a part of step 2.
There is now way for the event listener to distinguish between these two conditions, or is there? How do I get around such cases? Thanks Amruta
Hi, Will the latest pc-ble-driver-js code work with the NRF52 DK board flashed with the latest (S132 v5.0.0) hex file (from pc-ble-driver github)? I am getting following error if I do so. Error occured when enabling SoftDevice. Errorcode: NRF_ERROR_INTERNAL (0x3)
Hi, in your 2-step scenario, could you describe what roles are on pc-ble-driver and what roles are on the peer device. As the roles central, peripheral, server and client can be on both sides in "any" combination, I couldn't draw that info from your description.
Currently pc-ble-driver-js will only work with SD API v2 and v3, though support for SD API v6 is in progress.
Hi, The pc-ble-driver is acting as a central in the above case. Nonetheless, I could workaround that issue.
About the "requireAck" flag in the startCharacteristicsNotifications, I realized that the Ack is associated with the indications. So if one has to turn on notification, the requireAck should be false, and if one has to turn on indication, the requireAck needs to be true.
This can go into the documentation as well.
I need to use the softdevice v5 with the JS library. Can you refer me to any documentation that I can refer to get this done faster?
On current softdevice (v3), I see that if I send writeWithoutResponse, it takes nearly 80ms to get the ack back. This seems to much. What can I do to speed it up?
Once in a while, it also happens that the scan does not discover any of the advertising devices. No error is generated either.
Thanks Amruta
So if one has to turn on notification, the requireAck should be false, and if one has to turn on indication, the requireAck needs to be true.
Correct, will add a note in the docs.
I need to use the softdevice v5 with the JS library. Can you refer me to any documentation that I can refer to get this done faster?
There is no documentation avilable on how to update the pc-ble-driver-js language bindings (addon), apart from the source code itself. I should mention that the pc-ble-driver is currently undergoing restructuring as work is done adding SD API v5 and v6 support. After the updated pc-ble-driver has been released, we will continue with adding v5 and/or v6 support in pc-ble-driver-js language bindings.
it takes nearly 80ms to get the ack back. This seems to much. What can I do to speed it up?
There is not much that can be done to speed things up, as the major delay on the devkits is the relaying of traffic through the jlink OB chip, which adds delays for every packet fragment. It should go faster on the new nRF52840 dongle as it does not depend on external usb2uart conversion.
Thanks for the update on the pc-ble-driver.
About the speed problem, I am encountering it on the NRF52840 dongle itself. I have played around with the conn_bw parameters during enableBLE and the conn_interval parameters during connect. None of them seem to be helping. Are there any other knobs which I can try besides these?
If you want to maximize data throughput you could increase attmtu packert length to get across more data per packet. If you just want to send packets faster I think there is not much to do as the bottleneck is the transport layer that requires all transport packets to be acked, adding delays.
Thanks.
On Thu 23 Aug, 2018, 9:26 PM Bjørn Inge Hanssen, [email protected] wrote:
If you want to maximize data throughput you could increase attmtu packert length to get across more data per packet. If you just want to send packets faster I think there is not much to do as the bottleneck is the transport layer that requires all transport packets to be acked, adding delays.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NordicSemiconductor/pc-ble-driver-js/issues/187#issuecomment-415469388, or mute the thread https://github.com/notifications/unsubscribe-auth/ASn2qsxSrmEdcIWRe8qPYCB9DaDqVjqFks5uTtCsgaJpZM4V_U52 .
@bihanssen I had tried to flash soft device v5 and connectivity firmware on 52840 dongle but it got in to bad state and did not even get detected as USB device. I picked up connectivity firmware from pc-ble-driver/hex/sd_api_v5/connectivity_2.0.1_1m_with_s132_5.0.hex. Then we came across documentation that SD v5 is only for 52832. Are there any other steps to be carried out for connectivity firmware to work?
regards, -Prashant.
Hi, the driver/hex/sd_api_v5/connectivity_2.0.1_1m_with_s132_5.0.hex connectivity is targeted for jlink based devkits. It does not contain the USB endpoint configuration that is required when used with the dongle PCA 10059, or the secondary USB port of the PCA10056.
My recommendation would be to wait until we have finalized the next release of pc-ble-driver. It will contain all the required files to support the various SD APIs on the different HW kits, along with many improvements to builds scripts etc. You can follow the activity in branch feature/consolidate-sd-apis.
Currently pc-ble-driver-js will only work with SD API v2 and v3, though support for SD API v6 is in progress.
We have March 2020 and last commit on branch feature/support-softdevice-v6-remove-v3 was April 2018...
@SzymonLisowiec, SDK API v6 development in ble-driver-js has been discontinued in favour of SD API v5 only. v5 has been merged to master(#235) and will be published in an upcoming release. This thread has been kept open due to some action points being mentioned, but should ideally be closed and/or split in separate issues.
@bihanssen I have bought nRF42840 Dongle for make a gateway for zigbee devices. Only softdevice s140 and s340 have support for ZigBee and in latest release of https://github.com/NordicSemiconductor/pc-ble-driver/releases/tag/v4.1.1 are connectivity v3/v5 hex files only for s132. Is possible to make zigbee gateway without going indeep in low-level programming?
@SzymonLisowiec s140 is only supported for v6, which you will find support for in pc-ble-driver. Since there is no support for v6 in ble-driver-js, the only option currently is to use pc-ble-driver (not -js).