Writing Values to Characteristics in the Image Transfer Demo

[richardcoffey]

Hello, I've set up the image transfer app from Nordic Playground with the idea in mind to remove the Android App from the equation. I've picked through the Android app itself, and have found the characteristics advertised on the Nordic nrf52-DK necessary to capture images from an Arducam and transmit them over BLE as intended. 

public static final UUID IMAGE_TRANSFER_SERVICE_UUID = UUID.fromString("6e400001-b5a3-f393-e0a9-e50e24dcca3e");
public static final UUID RX_CHAR_UUID       = UUID.fromString("6e400002-b5a3-f393-e0a9-e50e24dcca3e");
public static final UUID TX_CHAR_UUID       = UUID.fromString("6e400003-b5a3-f393-e0a9-e50e24dcca3e");
public static final UUID IMG_INFO_CHAR_UUID = UUID.fromString("6e400004-b5a3-f393-e0a9-e50e24dcca3e");

Above are the three UUID's that I have been writing to via the nrfConnect app. Using nRFConnect, I turned on notifications for UUID's 6e400003 and 6e400004. Then, according to the Android app, writing "0x01" to UUID 6e400002 should trigger a "StartSingleCapture". This is confirmed to work on the nRFConnect app, and I can see the picture data being transferred over.

However, when using the ubuntu tool Bluetoothctl, it seems like writing to the UUID 6e400002 does not trigger a notification on neither of the UUID's 6e400003 and 6e400004. According to a bluetooth sniffer, I am sending the data over, I'm just not getting a response from the Nordic board. Clearly this could be due to a variety of issues, but I wanted to reach out and ask if anyone on the Nordic team has had experience writing values to the nrf52DK using the bluetoothctl tool (version 5.50).

The goal of this experiment is to be able to trigger an image transfer from the stock Nordic image transfer code on the nrf52, and receive the notification data on the linux side sending the data, essentially sidestepping the Android app all together. 

If you need any more information, please reach out.

[richardcoffey]

Update 4:02PM EST

I've traced the disconnection error to the ble_its_img_info_send() function. It returns a value of 8, which according to the documentation denotes an NRF_ERROR_INVALID_STATE error.

As previously mentioned, this only happens when sending the bits with Bluetoothctl, not with the nrfConnect app. I will continue to look into what could be causing it to get to a bad state.

[ovrebekk]

Hi Richard

If you look at the ble_its_img_info_send(..) implementation it will return NRF_ERROR_INVALID_STATE either if you are not connected or if the notifications are not correctly set on that characteristic (6e400004). 

I assume you are connected, so most likely the issue is that the notifications are not properly enabled. 

One thing that can be confusing with BLE is the endianness of multi byte values. To enable notifications you should send 0x0001 to the CCCD, but when breaking this up into multi byte commands you often have to send {0x01, 0x00} rather than {0x00, 0x01} for the data to be properly interpreted. 

Maybe you could show me the code you use to enable the notifications?
There might be some issue here that prevents the notifications from being enabled properly. 

Best regards
Torbjørn

[richardcoffey]

Hi Tor,

On connection, it seems like the CCCD for UUID's 6e400003 and 6e400004 have already been set to {01, 00}. That being said, I did also set notifications on the UUID's themselves. I was not setting the notifications for the image transfer info UUID, but now that I am, I am getting a return value of 0, which means that it was a success!

However, I am still seeing a disconnection after that request. I added some prints to display the event id in ble_evt_handler(), and I will also post the data from my bluetooth sniffer, as well as the program that I'm using the interface with the Nordic Device.

Here is a snip of the Segger logs, where the image is clearly taken, with a successful return value. The "Current Event State" of 17 is of interest here, as this is the value that the p_ble_evt->header.evt_id has before entering into the switch statement in the ble_evt_handler() function before a time out.

Here is a snippet of me writing to UUID 6e400002. The value of the attribute is already {0x01}, but writing another {0x01 00} causes it to disconnect.

And then here are the logs of my bluetooth sniffer, in which you can see that I receive a notification from what looks like UUID 6e400004, but nothing from the UUID 6e400003, before receiving a connection timeout.

I can confirm that both UUID's (6e400003/4) had notifications enabled. Hope this helps.

[richardcoffey]

I would also like to mention, that from a clean reboot, any request for information, whether it be a StartStream, StartSingleCapture, etc, leads to a "Connection Timeout".

The data that I receive in the 3rd picture above from UUID 6e400004 of {0108180000} is the same data I get from that UUID when I successfully transfer data from the Nordic Device to the nRFConnect app. This is telling me that setting the notification for that UUID is working, and that it's specifically the reception of the data on UUID 6e400003 that is causing the issue.

[richardcoffey]

Another comment, when the device gets stuck in a weird state while experimenting with the nRFConnect app, refreshing the services (with the refresh services button that appears to call "gatt.refresh()") seems to trigger the command that was queued up. Unfortunately I have no way of refreshing the services using my bluetoothctl tool on ubuntu.