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.

[ovrebekk]

Hi Richard

Did you make sure to enable notifications on the 6e400003 and 6e400004 characteristics when running your test on Ubuntu?

Did you try to run the debugger on the nRF52 side to see if the its_data_handler is actually called when you send the command?

I can't really see any particular reason why this shouldn't work on Ubuntu. As you have seen the command structure for the BLE service is quite simple. 

Best regards
Torbjørn

[richardcoffey]

Hi Tor,

I can see from my bluetooth sniffer that I have enabled notifications on both UUIDs. I will try and use the debugger on the nRF52 side to confirm that the its_data_handler is actually called. Is there some literature you could point me to that could help me use the debugger on the device side?

[richardcoffey]

Update 11:25AM EST

I started the debugger and found that my writes to UUID 6e400002 were getting through and triggering the functions! The debugger correctly printed that the command I was sending was triggering a picture, starting/stopping the stream, etc.

However, I was not receiving notifications of the data on UUID's 6e400003/4.

As mentioned, I do see the notification data on the nrfconnect app, however it seems like the app automatically registers it's notifications in the logs. As far as I can tell, I am registered for notifications in my program. Another problem I'm seeing is that once I request a single capture, I cannot seem to request any more single captures. I am able to turn on/off the stream mode as much as I want, but the single capture seems stuck.

For this reason, I'm thinking that the device is trying to send the data but maybe getting stuck? I have not yet been able to receive any data on my ubuntu machine once the image capture is triggered as far as I can tell.

Thanks for your help. 

[richardcoffey]

Additionally, I'm seeing Connection Timeouts quite frequency when reading/writing from the UUID's.

[richardcoffey]

In particular, I am seeing a timeout when I request a StartSingleCapture (sending a 0x01 byte) on UUID 6e400002 before I've received the data for another StartSingleCapture. Starting and stopping stream mode does not have this issue, and can be requested repeatedly.