• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 3005 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Case Studies with Notifications using CC2540 Packet Sniffer

Cagatay Ulusoy
Intellectual 625 points
Other Parts Discussed in Thread: CC2540

I am using Packet sniffer with CC2540 USB dongle. However, the documentation of the software is not very clear for me in many cases.

Regarding this post http://e2e.ti.com/support/low_power_rf/f/538/p/106575/376118.aspx#376118 I am still wondering how to know which packet is sent by which side? I see the answer to the thread but it is understandable when two L2CAP-C packets are sent within one connection event. I attached the screenshots of 4 more cases. In all cases 4 packets are sent in one connection event

1- In the first case, 3 of the packets are L2CAP-C and 1 is L2CAP-S packets (Btw, -C is probably Control but what does (L2CAP)-S refer to?). So I am confused about what do these first 3 L2CAP-C packets tell to me? Which one is sent by the master and which one(s) are from slave?

2- In the second case, the  third L2CAP-C packet has an FCS error. So what should I understand from that? Is it a packet that has sent from slave or master? What happened to this packet and what was its purpose to be sent? Since it has an error will it be re-sent?

3- In third case all of the packet types are L2CAP-C so the PDU length is 0. Which ones belong to master and which ones belong to slave? Why 4 L2CAP-C packets are sent at one time? What is the purpose of sending 4 of them at one time if the PDU is 0?

4- In the last case there are 2 notifications in one connection event. These notifications are supposed to be sent periodacllay per one second as I programmed so. How come two sequential notifications are sent in one communication events? What do the other L2CAP-C packets stand for? Are they ACKs? 

5- My last question is about ACK messages. I know that notifications do not expect confirmations from the master. But as far as I know this is a Stop and Wait - ARQ protocol. So the sender doesn't send any further frames until it receives an (ACK) signal. DO we see the ACK messages in Packet Sniffer?

I know it is a long post but if you could answer some questions I am sure you will contribute to knowledge of many of other readers.

Thanks! 

  • 0
    Guru 18615 points

    Hi! :)

    I'm also interested in question number 5, which I do not know.

    For 1) perhaps, S stands for signalling, I think.

    2) You obviously can have FCS errors, detected by CRC, these are RF communications :)

    3) Can they be connection events?

    4) You have to be careful about setting the EVT period for the burst. I've directly discarded this and I'm callind sendData() from the main code.

    Good luck :) I'll check your answer about 5).

  • 0 in reply to kazola
    Intellectual 625 points

    Hello Kazola Thanks for your interest and answer. Since I have written a long message you missed to answer some other parts :)

    1. There are three L2CAP-C messages. Which ones are sent by Master and which ones are sent by slave? How can I distinguish it using sniffer??

    2. Since there is a detected FCS error, will the same packet be re-sent? I think it is about ACKs and it should be re-sent.

    3. They are obviously connection events. These empty PDUs are sent in each connection events if there is no data to be sent. Usually, I can see two of them in one event. Why would there be 4 packets with empty PDU in one connection event? Isn't it waste of energy to send extra packets in one connection interval?

    4. Can you please explain more about the negative side of setting EVT period? What is the difference between sendData()?

    5. I will be waiting for the answeR:)

    Thank you again for your interest!

  • 0 in reply to Cagatay Ulusoy
    Guru 18615 points

    In 4) what I mean is that I do not like using the OSAL timer too much, it is far imprecise as you can see in sniffer captures.and it may get delayed if there are other OSAL tasks with higher priority to be done.

    For 2) check slide 31/74 in this link :)

    http://www.slideserve.com/Samuel/ble-101-bluetooth-low-energy

    It is late in Catalonia right now and I've not finished working yet (11:30pm) so we'll talk tomorrow :)

    Bye!

  • 0 in reply to kazola
    Intellectual 625 points

    Hi Kazola,

    I think I got most of the answers I need. Thank you. 

    The only missing answer is detecting which packet is sent by master and which is sent by the slave. Currently, I am analyzing .psd binary file of Packet Sniffer using MATLAB but I think the data packets do not have this information. It might be due to the point to point communication between master and slave.

  • 0
    Expert 1690 points

    From my understanding, L2CAP-S and L2CAP-C stands for continuation or start of an L2CAP message. See BT4.0 spec:

  • 0
    Intellectual 555 points

    1) Any packet with a payload will start with a L2CAP-S (Start) segment.  All 0-length packets (ie link maintenance and acks) will come as L2CAP-C (continuation) as a 0 length continuation has no affect.

    2) It looks like the FCS Error may have only occured at the sniffer (of course, the sniffer might receive different data than the peer device depending on rf conditions).  This error packet is successfully ACK'd in the next packet (see below for ack scheme)

    3) Every connection event should start with the Master transmitting.  If the master has no data/signalling to transmit, it will transmit an empty packet to give the slave a chance to respond.  If the slave has nothing to send, it will respond to the master with an empty packet (unless slave latency is enabled, then the slave is allowed to skip this connection event if it has nothing to send).

    4) Lots of timing dependencies can result in this happening.  Inaccurate timer, long connection interval, etc.

    5) Yes.  The ACK scheme is based on the NESN (next expected sequence number) and SN (sequence number) fields. So:

    Frame 3461: Master sends empty packet to start the connection event, NESN=1 SN =1

    Frame 3462: Slave sends data packet NESN = 0 SN = 1   (The NESN = 0 here means that the packet in frame 3461 has been ACK'd and the slave expects the next packet from the master to have SN = 1.  Also note that the MD flag "more data" is set here, this basically lets the master know that the slave has more data and the master should give the slave another chance to transmit during this connection event if possible.

    Frame 3463: Master sends empty packet to give slave a chance to tx again, NESN=0,SN=0 (NESN =0 Acks the packet from frame 3462)

    Frame 3464: Slave sends data packet NESN = 1, SN = 0 (NESN = 1 Acks frame 3463 packet.  Note MD is 0 here meaning the master doesn't need to extend the connection event)

    Hope this helps.  Reading the core spec or Robin Heydon's book would answer all of these questions too.

    -Tyler