Sending large amounts of data from phone to nrf52840

RE: Sending large amounts of data from phone to nrf52840

bjorn-spockeli — Fri, 22 Feb 2019 14:41:29 GMT

Hi Chris,

I apologize for the late reply.

It turns out that a Queued Write is the same as a long write, i.e. multiple Prepare Write Requests in sequence with offsets followed by a Write Execute,see GATTC Characteristic or Descriptor Value Long Write and GATTS Queued Writes: App handled, no attributes require authorization. So the QWR module should be able to do what you're looking for.

Are you still having issues with getting this to work as it should?

Best regards

Bjørn

RE: Sending large amounts of data from phone to nrf52840

cirlam — Wed, 06 Feb 2019 16:04:54 GMT

Ahhh, that would make sense - the Queued Write module is initialized, as I have converted my application from the ble_cscs example.

I think the thing that is confusing me is that Queued/Reliable Writes are different to Long Writes - so wasn't aware you could implement both different methods using the Queued Write module.

With the queued write example, am I correct in thinking it shows the Queued/Reliable write implementation? If so, what would I need to modify to make it a Long Write?

The nrf_ble_qwr_evet_type_t values of EXECUTE_WRITE and AUTH_REQUEST sound very specific to Queued/Reliable writes, and not something useful in a Long Write?

RE: Sending large amounts of data from phone to nrf52840

bjorn-spockeli — Wed, 06 Feb 2019 15:49:10 GMT

Hi Chris,

I agree, the fact that you're getting the BLE_EVT_USER_MEM_REQUEST event should rule out that there is no user memory request pending.

However, are you initializing the Queued Write module in services_init(), i.e. calling nrf_ble_qwr_init()? If so then it could be that the event has already been handled by nrf_ble_qwr_on_ble_evt().

You could try to use the Queued Writes module instead of handling the BLE_EVT_USER_MEM_REQUEST yourself?

RE: Sending large amounts of data from phone to nrf52840

cirlam — Wed, 06 Feb 2019 09:19:50 GMT

Hi Bjorn,

I've fixed some fairly obvious bugs in the above code (namely, removing the CCCD seeing as its not a notifiable characteristic), and have tried testing the long write by sending a ~8600byte transfer to this characteristic (I'm using Nordic Android BLE Libary to issue this transfer from my Pixel 2 phone).

BLE_EVT_USER_MEM_REQUEST is successfully called in my peripheral, but when I go to "sd_ble_user_mem_reply", I get a return value of 8, which is NRF_ERROR_INVALID_STATE.

I can see this is either "Invalid Connection state or no user memory request pending.". Obviously the call to BLE_EVT_USER_MEM_REQUEST should mean the softdevice is expecting a memory block to be passed to it, so that leaves Invalid Connection State - but I am definitely connected at this stage, as the device continues to issue notifications (other characteristics) to the phone both before and directly after this event, with no disconnects inbetween. Any idea what could be wrong here?

My code now is as follows:

#define LONG_WRITE_LENGTH 9000

static uint8_t queued_write_buffer[LONG_WRITE_LENGTH];
static ble_user_mem_block_t mem_block;

static uint32_t assist_gps_char_add(ble_peripheral_service_t *p_peripheral_service) {
  // OUR_JOB: Step 2.A, Add a custom characteristic UUID
  uint32_t err_code;
  ble_gatts_char_md_t char_md;
//  ble_gatts_attr_md_t cccd_md;
  ble_gatts_attr_t attr_char_value;
  ble_gatts_attr_md_t attr_md;

  uint8_t encoded_gps_meas[ASSIST_GPS_MEAS_LEN];

  ble_uuid_t char_uuid;
  ble_uuid128_t base_uuid = BLE_UUID_PERIPHERAL_BASE_UUID;
  char_uuid.uuid = BLE_UUID_GPS_ASSIST_CHARACTERISTIC_UUID;

  err_code = sd_ble_uuid_vs_add(&base_uuid, &char_uuid.type);
  APP_ERROR_CHECK(err_code);

//  memset(&cccd_md, 0, sizeof(cccd_md));
//  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm);
//  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm);
//  cccd_md.vloc = BLE_GATTS_VLOC_STACK;

  memset(&char_md, 0, sizeof(char_md));
  char_md.char_props.read = 1;
  char_md.char_props.write = 1;
  char_md.char_props.notify = 0;
  char_md.p_char_user_desc = NULL;
  char_md.p_char_pf = NULL;
  char_md.p_user_desc_md = NULL;
  char_md.p_cccd_md = NULL;
  char_md.p_sccd_md = NULL;  

  memset(&attr_md, 0, sizeof(attr_md));
  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm); 
  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);
  attr_md.vloc = BLE_GATTS_VLOC_STACK;
  attr_md.rd_auth = 0;
  attr_md.wr_auth = 0;
  attr_md.vlen = 1;

  memset(&attr_char_value, 0, sizeof(attr_char_value));

  memset(&encoded_gps_meas, 0, ASSIST_GPS_MEAS_LEN);

  attr_char_value.p_uuid = &char_uuid;
  attr_char_value.p_attr_md = &attr_md;
  attr_char_value.init_len = ASSIST_GPS_MEAS_LEN;
  attr_char_value.init_offs = 0;
  attr_char_value.max_len = LONG_WRITE_LENGTH;
  attr_char_value.p_value = encoded_gps_meas;

  return sd_ble_gatts_characteristic_add(p_peripheral_service->service_handle,
      &char_md,
      &attr_char_value,
      &p_peripheral_service->gps_assist_char_handle);
}

case BLE_EVT_USER_MEM_REQUEST: {
  ret_code_t err_code;
    memset(&mem_block, 0, sizeof(mem_block));
    memset(&queued_write_buffer[0],0,LONG_WRITE_LENGTH);
    mem_block.len = LONG_WRITE_LENGTH;
    mem_block.p_mem = &queued_write_buffer[0];
     if (p_peripheral_service->conn_handle != BLE_CONN_HANDLE_INVALID) {
    err_code = sd_ble_user_mem_reply(p_peripheral_service->conn_handle, &mem_block);
    if (err_code != NRF_SUCCESS) {
      SEGGER_RTT_printf(0,"ERROR sd_ble_user_mem_reply: %u\r\n", (unsigned int)err_code);
    } else {
      SEGGER_RTT_printf(0,"USER_MEM_REQUEST OK\r\n");
    }
    }
    }
    break;
  case BLE_EVT_USER_MEM_RELEASE:
    SEGGER_RTT_printf(0, "MEM RELEASE\n");
    if ((p_ble_evt->evt.common_evt.params.user_mem_release.mem_block.p_mem == mem_block.p_mem) && (p_ble_evt->evt.common_evt.params.user_mem_release.mem_block.len == mem_block.len)) {
      SEGGER_RTT_printf(0, "MEM RELEASED!\n");
    }
    break;

RE: Sending large amounts of data from phone to nrf52840

cirlam — Tue, 05 Feb 2019 15:01:02 GMT

Thank you Bjorn.

I've set up my long write support as follows:

void ble_peripheral_service_on_ble_evt(ble_evt_t const *p_ble_evt, void *p_context) {
  ble_peripheral_service_t *p_peripheral_service = (ble_peripheral_service_t *)p_context;

  if (p_peripheral_service == NULL || p_ble_evt == NULL) {
    return;
  }

//  SEGGER_RTT_printf(0, "Peripheral on BLE EVT: %d\n", p_ble_evt->header.evt_id);

  switch (p_ble_evt->header.evt_id) {
  case BLE_GAP_EVT_CONNECTED:
    SEGGER_RTT_printf(0, "Connected as Peripheral\n");
    on_connect(p_peripheral_service, p_ble_evt);
    break;
  case BLE_GAP_EVT_DISCONNECTED:
    SEGGER_RTT_printf(0, "Disconnected as Peripheral\n");
    on_disconnect(p_peripheral_service, p_ble_evt);
    break;
  case BLE_GATTS_EVT_WRITE:
    SEGGER_RTT_printf(0, "Write as Peripheral\n");
    on_write(p_peripheral_service, p_ble_evt);
    break;
  case BLE_EVT_USER_MEM_REQUEST:
    mem_block.len = 7000;
    mem_block.p_mem = &queued_write_buffer[0];
    ret_code_t err_code = sd_ble_user_mem_reply(p_peripheral_service->conn_handle, &mem_block);
    if (err_code != NRF_SUCCESS) {
      SEGGER_RTT_printf(0,"ERROR sd_ble_user_mem_reply: %u\r\n", (unsigned int)err_code);
    } else {
      SEGGER_RTT_printf(0,"USER_MEM_REQUEST OK\r\n");
    }
    break;
  case BLE_EVT_USER_MEM_RELEASE:
    SEGGER_RTT_printf(0, "MEM RELEASE\n");
    if ((p_ble_evt->evt.common_evt.params.user_mem_release.mem_block.p_mem == mem_block.p_mem) && (p_ble_evt->evt.common_evt.params.user_mem_release.mem_block.len == mem_block.len)) {
      SEGGER_RTT_printf(0, "MEM RELEASED!\n");
    }
    break;
  default:
    // No implementation needed.
    break;
  }
}

Characteristic initilization:

static uint32_t assist_gps_char_add(ble_peripheral_service_t *p_peripheral_service) {
  // OUR_JOB: Step 2.A, Add a custom characteristic UUID
  uint32_t err_code;
  ble_gatts_char_md_t char_md;
  ble_gatts_attr_md_t cccd_md;
  ble_gatts_attr_t attr_char_value;
  ble_gatts_attr_md_t attr_md;

  uint8_t encoded_gps_meas[ASSIST_GPS_MEAS_LEN];

  ble_uuid_t char_uuid;
  ble_uuid128_t base_uuid = BLE_UUID_PERIPHERAL_BASE_UUID;
  char_uuid.uuid = BLE_UUID_GPS_ASSIST_CHARACTERISTIC_UUID;

  err_code = sd_ble_uuid_vs_add(&base_uuid, &char_uuid.type);
  APP_ERROR_CHECK(err_code);

  memset(&cccd_md, 0, sizeof(cccd_md));
  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm);
  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm);
  cccd_md.vloc = BLE_GATTS_VLOC_STACK;

  memset(&char_md, 0, sizeof(char_md));
  char_md.char_props.read = 1;
  char_md.char_props.write = 1;
  char_md.char_props.notify = 0;
  char_md.p_char_user_desc = NULL;
  char_md.p_char_pf = NULL;
  char_md.p_user_desc_md = NULL;
  char_md.p_cccd_md = &cccd_md;
  char_md.p_sccd_md = NULL;  

  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm); //was open
  BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);
  attr_md.vloc = BLE_GATTS_VLOC_STACK;
  attr_md.rd_auth = 0;
  attr_md.wr_auth = 0;
  attr_md.vlen = 1;

  memset(&attr_char_value, 0, sizeof(attr_char_value));

  memset(&encoded_gps_meas, 0, ASSIST_GPS_MEAS_LEN);

  attr_char_value.p_uuid = &char_uuid;
  attr_char_value.p_attr_md = &attr_md;
  attr_char_value.init_len = ASSIST_GPS_MEAS_LEN;
  attr_char_value.init_offs = 0;
  attr_char_value.max_len = ASSIST_GPS_MEAS_LEN;
  attr_char_value.p_value = encoded_gps_meas;

  return sd_ble_gatts_characteristic_add(p_peripheral_service->service_handle,
      &char_md,
      &attr_char_value,
      &p_peripheral_service->gps_assist_char_handle);
}

I'm thinking this part of the characterisitc initalization may need tweaking? or the long write behaviour completely independant to the characteristic initilization, and will work on any writable characteristic?

attr_char_value.init_len = ASSIST_GPS_MEAS_LEN;
attr_char_value.init_offs = 0;
attr_char_value.max_len = ASSIST_GPS_MEAS_LEN;

RE: Sending large amounts of data from phone to nrf52840

bjorn-spockeli — Tue, 05 Feb 2019 13:17:31 GMT

Hi Chris,

Yes, increasing the MTU size will give you a higher throughput compared to using the default ATT MTU size of 23, which gives you 20 byte payload. Although, the maximum size of a GATT attribute is 512 byte, the largest allowed MTU size in SDK v15.2.0 is 247 bytes.

Long write is simply multiple Write Requests to the same characteristic with offsets and this is the method that I would choose.

Reliable and Queued Write are essentially the same thing, but reliable writes have a lot of overhead as the value is sent in both directions before the actual write is being performed. You can write up-to 512 bytes using this method as its limited to the maximum attribute size.

If you want to set the ATT MTU on the nRF side to 247, then you need to use the GATT library( nrf_ble_gatt.c ) which will handle the GATTS ATT_MTU Exchange for you. You can use the ble_app_uart example as a reference.

/**@brief Function for initializing the GATT library. */
void gatt_init(void)
{
    ret_code_t err_code;

    err_code = nrf_ble_gatt_init(&m_gatt, gatt_evt_handler);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt, NRF_SDH_BLE_GATT_MAX_MTU_SIZE);
    APP_ERROR_CHECK(err_code);
}

// where NRF_SDH_BLE_GATT_MAX_MTU_SIZE == 247.