Writing Values to Characteristics in the Image Transfer Demo

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Wed, 06 Nov 2019 09:27:08 GMT

That's the HCI log on the Linux side I believe?

I am thinking of sniffer trace of what is happening over the air, similar to what you get from an Ellisys or Frontline Bluetooth sniffer, or the free Nordic sniffer.

Best regards
Torbjørn

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Tue, 05 Nov 2019 14:39:14 GMT

Hi Tor,

I made a post in this thread on October 23rd, 2019 at 16:22 with bluetooth sniffer logs. There are pictures of connections, and attempted image transfers on both the working and the non working devices.

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Tue, 05 Nov 2019 09:07:28 GMT

Hi Richard

Do you have some sort of BLE sniffer so you can see what's happening over the air when the Linux device is communicating with the image transfer demo?

Then I might be able to spot the issue without needing to test it myself on the same hardware.

Best regards
Torbjørn

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Thu, 31 Oct 2019 18:33:05 GMT

Hi Tor,

So I tested out the "ble_app_uart" demo on the nordic board, and I was successfully able to write to the device using my Bluetoothctl tool on the Linux device that has been having trouble.

When I write data from Linux device, the data shows up on the Serial port that the nordic device is connected to. Additionally, I was also able to write to that same serial port and have the data propagate up through the notify channel back to my tool on the Linux device

So as far as I can tell, this UART demo works perfectly on my system. That seems to confirm that the odd behavior on the image transfer program is isolated to just that program, and the way my bluetooth chip handles the interaction.

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Wed, 30 Oct 2019 09:26:43 GMT

Hi Richard

Have you tried to connect to one of the simpler Nordic examples?

Such as the ble_app_uart or ble_app_hrs example.

It would be interesting to know if this is a general problem with the Nordic examples, or something exclusive to the image transfer demo.

I am not very familiar with Linux BLE programming, but will get some help from one of the gurus in the office.

Best regards
Torbjørn

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Mon, 28 Oct 2019 19:21:11 GMT

So to update:

I decided to port my entire build system to Linux, and I am able to successfully connect to the Nordic board via Bluetoothctl. Everything works as intended using this tool in the current linux environment...

The problem that I am now facing, is that I can't seem to connect to the board with code that I've written. Most notably, I'm not able to connect to a socket created to communicate with the board. I am receiving an "OPERATION NOW IN PROGRESS" error, which denotes that the I'm checking the return value for connect() before the board returns. My code works with all other bluetooth devices that I've paired it with, except for the Nordic. I've attached a picture of the function.

I know that the original intention of this demo was the connect to Android, so I'm wondering if there are any special security levels or whitelisting that is required to connect to the board with a socket? As far as the board goes, I'm not even seeing an attempt at connection. I can confirm the socket code I'm using now work elsewhere, so I'm thinking that maybe it's returning faster than it can connect to the Nordic board.

Any tips connecting to the Nordic board manually would be helpful.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Fri, 25 Oct 2019 20:22:20 GMT

Hi Tor,

I am using a Qualcomm QCA9377 chipset for the Bluetooth. We are looking to see if we can update the firmware.

Additionally, the LE Create Connect packet can be seen in both of the log pictures above. Both return a "Success 0x00" status, and are then followed by a "LE Connection Complete" event where the information about the connection is delivered, such as MAC and Peer Address.

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Fri, 25 Oct 2019 08:32:02 GMT

Thanks for the added logs.

I can't seem to find the LE Create Connection packet for the non working device, showing the very start of connection establishment. Do you have this also?

Do you know what kind of Bluetooth hardware is used by the non working device?
Is it some kind of Bluetooth dongle?

Best regards
Torbjørn

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Wed, 23 Oct 2019 20:22:50 GMT

I've taken some more snippets of the successful image transfer, and an unsuccessful image transfer, as well as the connection messages for both sides. Something interesting that I've noticed on the client that's having trouble, is that there seems to be a

Here the connection log on the working device

And here is a successful start to an image transfer. A notification comes up through 6e400004 (handle 0x0012) and then the image transfer data begins streaming over 6e400003.

Here is the device connection on the non-working device.

And here is the unsuccessful image transfer on the non-working device. The image info notification propagates up through 6e400004, but nothing comes up through 6e400003, and the device times out. I can't see anything that explains the problems from this picture, other than the fact that the device that doesn't work isn't getting the notifications with the image data.

Something else that I've noticed that is different between the two, is that the non-working device records this odd bluetooth event every ~15 seconds while idle, although the timing is inconsistent. The working device does not record this message while idle. This might not be related to the problem, but I figured that I would include it.

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Wed, 23 Oct 2019 12:28:21 GMT

That is interesting. Are you able to compare the Bluetooth sniffer logs between the two implementations to see if you can spot the difference there?

Best regards
Torbjørn

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Tue, 22 Oct 2019 21:23:12 GMT

Update:

So, I decided to try and connect the Nordic device to a laptop running the same version of Bluetoothctl. Once connected, I was able to send and receive all commands correctly, proving that Bluetoothctl is capable of communicating with the Image Transfer code on the Nordic Device.

That tells me that my original problem is a problem confined to the Linux box that I'm trying to use Bluetoothctl on. I will continue to try and figure out what could be different on the Linux Box vs. my Laptop.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Tue, 22 Oct 2019 13:53:53 GMT

Hi Tor,

As I've experimented more with the image transfer, I can see that you are correct in your explanation that the Nordic board frequently returns NRF_ERROR_RESOURCES, and then recovers as it receives BLE_GATTS_EVT_HVN_TX_COMPLETE notifications.

The descrepency in behaviors seem to stem from the fact that BLE_GATTS_EVT_HVN_TX_COMPLETE notifications are not being returned, therefore the buffers never get rewritten and the process times out.

Where would you suggest we go from here?

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Tue, 22 Oct 2019 07:26:06 GMT

Hi Richard

[quote user="richardcoffey"]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? [/quote]

nRF Connect should go through service discovery, and should respond to requests from the peripheral to update GAP parameters (connection parameters) and GATT parameters (MTU size, data length). These settings might differ when using Bluetoothctl, depending on what parameters they support, but I don't understand why that should lead to such a big difference in behavior.

[quote user="richardcoffey"]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.[/quote]

The ID's are grouped by which sub-module in the Bluetooth stack they originate from (such as GAP, GATT server and GATT client). The event ranges are defined in ble_ranges.h, and here you can see that events 80, 85 and 87 belong to the GATT server module (as this corresponds to event 0x50, 0x55 and 0x57 in hex).

The exact events are defined in header files specific to the sub module, such as ble_gap.h, ble_gattc.h and ble_gatts.h.

Looking at ble_gatts.h you can see that 0x50, 0x55 and 0x57 corresponds to the following events:

BLE_GATTS_EVT_WRITE - a write was performed on one of your characteristics

BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST - the client is requesting to start an MTU request procedure

BLE_GATTS_EVT_HVN_TX_COMPLETE - one or more notifications have successfully been sent

While it is true these events are not handled in the main file directly all of them should be processed by one of the other modules in your application, such as the BLE service implementations or the nrf_ble_gatt.c module, so I don't think these events help much in tracking down the issue.

[quote user="richardcoffey"][/quote]

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)"

Getting the NRF_ERROR_RESOURCES error is normal and expected. They way to maximize throughput is to push data to the stack quickly, and hold back once this error is returned. When you get the BLE_GATTS_EVT_HVN_TX_COMPLETE in return from the SoftDevice this means more buffers are freed up and you can continue to send more data.

If you look at line 413 of ble_image_transfer_service.c you can see the handling of this event, and how it will continue uploading more data.

When you say it gets stuck in the while(ret_code == NRF_SUCCESS) check, are you sure it really gets stuck here?
That should only happen if the ble_its_send_file_fragment(..) function keeps returning NRF_SUCCESS.

If you put some log output or toggle a pin after the while loop, will you not see the code reaching here?

Best regards
Torbjørn

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Mon, 21 Oct 2019 20:21:17 GMT

Another Update:

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?

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Mon, 21 Oct 2019 18:57:22 GMT

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

Send the Nordic board a write request for a single capture (0x01) with my Bluetoothctl tool
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.
Then, I can connect the still running Nordic board to the nRFConnect app
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.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Mon, 21 Oct 2019 18:36:38 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Mon, 21 Oct 2019 14:00:22 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Fri, 18 Oct 2019 08:47:39 GMT

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

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Thu, 17 Oct 2019 19:20:11 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Thu, 17 Oct 2019 18:14:40 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Thu, 17 Oct 2019 17:44:15 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

ovrebekk — Thu, 17 Oct 2019 11:24:34 GMT

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

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Wed, 16 Oct 2019 20:05:28 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Wed, 16 Oct 2019 17:55:12 GMT

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.

RE: Writing Values to Characteristics in the Image Transfer Demo

richardcoffey — Wed, 16 Oct 2019 15:49:06 GMT

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