This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Writing Values to Characteristics in the Image Transfer Demo

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.

Parents
  • 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

  • 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.

  • 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.

  • Hi 

    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

  • 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.

  • Hi 

    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

  • 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. 

Reply
  • 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. 

Children
No Data
Related