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

current optimisation in terms of conn interval and slave latency

Hi 

which is better for reduced current consumption 

1. lesser value of of MIN_CONN_INTERVAL, MAX_CONN_INTERVAL with large SLAVE_LATENCY 

2. or vice versa

Thanks.

  • There will be an data exchange every (min_conn_interval * (slave latency + 1)) between the central and peripheral. In general it is preferred to have a low connection interval to allow packets to be sent with short latency when there is data available, but have a large slave latency to sleep and save current consumption when there is no data to be sent.

  • Seems we are all after the same goal :-) My notes so far, indicating "Write Command" is preferable for improved throughput and implicit lower power consumption since repeated receive packet processing is avoided:

    // BLE Packet Transmission
    // =======================
    // Packet format - see Bluetooth 5.0 spec (was Vol 6, Part B, Section 2.2)
    // https://www.bluetooth.com/specifications/bluetooth-core-specification
    //
    // BLE packets are sent ping-pong fashion, with maximum throughput occurring when Master->Slave
    // packets have no payload
    // Packets are separated by the Inter Frame Space (IFS) of 150uSecs
    // Note - MIC Encryption field adds 4 bytes, included in timings below
    //
    // Connection interval: Determines how often the Central queries data from the Peripheral.
    //   Peripheral may request an update between between minimum 7.5 ms and maximum 4 sec
    // Slave latency: A Non-zero slave latency allows the Peripheral to not answer when the
    //   Central asks for data up to the slave latency number of times. However if the Peripheral
    //   has data to send it can send data at any time. This enables a peripheral to stay sleeping
    //   for a longer time, if it doesn't have data to send, but still send data fast if needed
    // Connection Supervision Timeout: Determines the timeout from the last data exchange untill
    //   a link is considered lost. A Central will not start trying to reconnect before the timeout
    //   has passed, so a short timeout is preferred for devices often going out of range
    //
    // "Write Command" is a write without acknowledgement and "Write Request" is write with acknowledgement.
    // The ATT will automatically send ack when you transmit write request from the central device. Write
    // Command on the client side should generate BLE_GATTS_EVT_WRITE(WRITE_CMD, data) event on the server
    //
    // An integral number of packets can be sent in each connection interval. Shortest interval
    // is 7.5mSecs, longest 4,000mSecs in steps of 1.25mSecs
    

  • Make sense yes.

    A small addition, all data transfer in BLE is reliable on the link layer, ensured by sequence numbers, thereby the difference between write command and write request is mainly handling in application layer. The most common (and efficient) way of sending data is typically through notifications.

Related