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

The 17 event is simply the disconnected event, and the link has already disconnected once this event is forwarded. 
You could try to print the disconnect reason inside the event, like this:

NRF_LOG_INFO("Disconnected. Reason: %i", p_ble_evt->evt.gap_evt.params.disconnected.reason);

Another thing you could try is to send write command rather than a write request from the bluetoothctl side. In theory both should work, but it is possible that the write response is somehow delayed when you start sending a lot of notifications on the 6e400003 characteristic, and that this will cause issues. 

When you send a write command you are not dependent on getting an explicit ACK from the server side, and this is the intended behavior. 

Do you know how to change from a write request to a write command through the bluetoothctl API's?

Best regards
Torbjørn

[richardcoffey]

Hi Tor,

I do not know how to send a write command in the Bluetoothctl, as far as I know all the commands are write requests. I will look into it.

What stumps me is that the nordic nRFConnect app sends write requests, and that command flow works very well most of the time. Additionally, sending write requests to change things like resolutions and PHY layer configurations works on Bluetoothctl, and the notifications come back on UUID 6e400004 successfully.

We are looking more into the C code to learn about the states.

Could it be possible that there is another layer of communication that the nRFConnect app performs with the Nordic board that we could be missing? Considering that the Nordic device seems to become unresponsive when starting just image transfers, we are thinking that maybe it's blocking on a configuration setting that we failed to setup.

[richardcoffey]

Hi Tor,

Do you think you might be able to give me some insight into the ble_evt_t ID's that I am seeing? Specifically the events 80, 85, and 87? In the ble_evt_handler() function, all three of those ID's are not caught by the switch statement, but they seem to come up frequently.

It is a bit difficult to determine where these codes originate from, as the ble_evt_t  type contains a bunch of additional event types. The "header" value is where I'm getting the numbers 80,85, and 87. Perhaps knowing what those values denote will help me track down where the data is getting lost/not sent.

[richardcoffey]

I've also discovered that I can get the Nordic board to recover from it's suspended state by doing the following: 

1.  Send the Nordic board a write request for a single capture (0x01) with my Bluetoothctl tool
2.  The Nordic board will send a small string through 6e400004 (like normal) but nothing will come through 6e400003. The Nordic board is now in a weird state, and will then disconnect.
3. Then, I can connect the still running Nordic board to the nRFConnect app
4. And then, if I write a "0x06" to request BLE params, I will get the typical info from 6e400004 that sending a "0x06" does, but I will also get image data  coming up through 6e400003!

So, it seems as if capture image command is blocking somewhere! All we have to do is determine where it's blocking, and why sending it another command seems to let the blocked notifications come through.

[richardcoffey]

Another Update:

So I've determined that the Nordic board is running into a problem in ble_its_string_send(). The function sd_ble_gatts_hvx() seems to queue too many notifications when trying to send a file, and returns an NRF_ERROR_RESOURCES. 

This gets the Nordic board stuck in a while loop in main.c at the very bottom, in the line

"while(ret_code == NRF_SUCCESS)"

right after ble_its_send_file_fragment function. After about 4 iterations of the resources error, the board times out and disconnects! So now the problem is trying to figure out why the notifications are getting queued but not taken out of the queue. I run into a problem here because I can't seem to find the inner workings of sd_ble_gatts_hvx().

In the file ble_gatts.h, the function description seems to mention that we should try "waiting for a BLE_GATTS_EVT_HVN_TX_COMPLETE event and retry". Any idea where to go from here?