• State Verified Answer
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 3471 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 117673
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connection parameters: nRF Connect & finding them in Wireshark

Vala

Hi,

Could someone help me about the following questions?

Q1: What are the connection parameters set by the Android app nRF Connect? Can I change them?

Q2: How can I find out about these parameters via nRF Sniffer, more specifically, the connection interval? I know that the final decision is made by the Central (Initiator) and is reported in CONNECT_REQ packet. Does this packet contain the final settings? What types of packets should I look for to understand what the final connection interval is?

Q3: Can delta time parameter in the Wireshark be used to find the connection interval? Please see the attached images. In this connection, the CONNECT_REQ showed that the connection interval is 50 ms. Although, the delta time for the Rcvd Handle Value Notification, which I assume is the packet that contains the data (I recognized some the bytes that the Peripheral sent), shows a value of 150 us and 382 us for end to start and start to start parameters, respectively. On the other hand, there are some Empty Data PDUs that show a value of ~47000 us for these parameters, which makes sense according to the connection parameters set in the CONNECT_REQ packet. Is there anything that I don't understand correctly? Can the delta time parameters be used to find out about connection interval?

The Rcvd Handle Value Notification packet: image description

The Empty Data PDU packet: image description

-Vala

  • 0

    OK I guess I found the answers to the question No.3. There are some items that can show the start of the a new connection, and therefore 'delta time' showing the connection interval.

    1- The event counter is updated for each connection.

    2- All the transmissions in one connection is sent in one channel. Therefore, changing the number of the channel shows the termination of a connection.

    Thus, the delta time of those packets which show a new connection should be checked for connection interval.

  • 0

    I checked the Core Specification document to see what the SN and NESN fields mean. That raised a question. In the documents it claims that:

    "The transmitSeqNum and nextExpectedSeqNum parameters shall be set to zero upon entering the Connection State.

    For each new Data Channel PDU that is sent, the SN bit of the Header shall be set to transmitSeqNum.

    When a Data Channel PDU is sent, the NESN bit of the Header shall be set to nextExpectedSeqNum."

    I see in Wireshark that there are some packets from Master to Slave with the right value of delta time (comparing to the connection interval value), a change in the channel and a event number change with respect to previous packet, all showing the start of a new connection, but showing '1' for the SN and NESN fields. Could some one tell me what it means when these fields are set to '1' at the start of a connection?

  • 0

    Hi Vala,

    You can have a look at this blog, it discusses a little bit about the flow control and on how to read the connect request packet.

    Regarding the connection parameter set by nRF Connect, it actually doesn't set any parameter. Like any Android (and iOS) applications, it can't control initial connection parameter. The parameters are decided by the operating system. However the application can request a connection parameter update using this API.

    As far as I know the nRFConnect hasn't provided a way for user to call this.

    In short, the connection parameters are various and user can't change it, for now.

    You can use the delta time, start to end (start to start is not reliable) to detect the distance between packet and can find which packets are in same connection event and which are not, and can roughly get the interval by doing calculation. But it's easier to look at the connect request and the connection parameter update packet, if any.

  • 0

    @Vala: 2. All the transmissions in one connection event is sent in one channel. The channel is changed on every connection event. This is called channel hopping.

    The delta time only tell the distance between a packet and the next one. It's not necessary represent the connection interval. The reason is that there are more than one packet per connection event. At least 2 one from master one from slave, there could be more (typical 6 from each side) if the peer has more data to send. The distance between them can be very short, as you already found. When there is nothing to send, only 2 packets per connection event, and you can see the delta time close to the connection interval.

Related