Attachments (4) Download All
Nordic Case Info
  • Case ID: 213063
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Write Queued Characteristic with Less than 20 bytes

jloliveira

Good afternoon,

Following up my previous case, to which I got no reply, how can I use a queued write characteristic to write less than 20 bytes of data?

I'm using it to mainly write more than 20 bytes of data but when I write less than 20 bytes it just halts the application. How can I overcome it?

Thank you,

João

Parents
  • 0

    Hi João, 

    please find the QWR and QWRS source and header files with the necessary changes to receive less than 20bytes and propagating this to the application. The only changes in main.c should be the addition of NRF_LOG_HEXDUMP_INFO(&p_evt->rcvd_data,p_evt->rcv_length) to the BLE_QWRS_NEW_DATA_RCVD case in queued_write_example_service_evt_handler, i.e. 

    Attachments:

    Fullscreen nrf_ble_qwrs.c Download
    nrf_ble_qwrs.hnrf_ble_qwr.h
    Fullscreen nrf_ble_qwr.c Download

  • 0 in reply to bjorn-spockeli

    Hi Bjørn,

    Thank you for your reply.

    Just updated the QWR and QWRS files and now the queued write is working like a charm for less than 20bytes.

    As a last question, is there a way to write more than 510bytes to a characteristic, with QWR or by any other means?

    Thank you,

    João

  • 0 in reply to jloliveira

    Hi again Bjørn,

    For writing more than 510bytes to a characteristic I mean writing up to 1024bytes.

    Thank you again,

    João

  • 0 in reply to jloliveira

    Hi,

    Unfortunately, the Softdevice limits this:

    #define  BLE_GATTS_FIX_ATTR_LEN_MAX   (510)
     
    #define  BLE_GATTS_VAR_ATTR_LEN_MAX   (512)
  • 0 in reply to run_ar

    Dear Runar,

    But is there any other means besides QWR to write more than 510bytes through a characteristic?

    Thank you,

    João

  • 0 in reply to jloliveira

    Not really. But you could consider storing the data in your application instead and use the characteristic only as a means of transportation. I think that is a more common way of handling this, instead of using QWR.

Reply
  • 0 in reply to jloliveira

    Not really. But you could consider storing the data in your application instead and use the characteristic only as a means of transportation. I think that is a more common way of handling this, instead of using QWR.

Children
  • 0 in reply to run_ar

    Hi Runar,

    I understand your proposal, but since I'm considering a characteristic with variable length, from 10bytes to 1024, I would have to create a protocol that would communicate the number of bytes being transmitted in every transaction, besides the actual data.

    Do you have any proposal or example to workout such variable length characteristic up to 1024bytes?

    Thank you,

    João

  • +1 in reply to jloliveira

    Hi,

    I think there are several projects you can look at. Not sure what is easiest, but there is the GLS project that has a protocol to transfer records. The ATT MTU throughput example is also set up to transfer larger amount of data. And there is our DFU solution.

    The easiest would probably be to set up something similar to the dfu solution. with one characteristic for data transfer and another one for control operations. start every packet with a length field, or maybe just packets that is divided across several MTU's.

    Thinking about it, you could have an ekstra characteristic as a control point that you use to notify the peer in case you are sending more than one MTU, and possibly to confirming crc across these packets. so if you are sending only one MTU (MTU size can be configured), you are not doing any additional work. But in case you are sending more data you notify the peer how many packets to expect, and do a crc confirm.

Terms of service