• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 54 subscribers
  • Views 2387 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.

Who trusts packet sniffer? How to make it more efficient?

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

Hi,

When I am doing the measurements by compating nr of sent packets and receiving packets I use sniffer also. However sniffer behaves unpexectedly. At first it starts well but after some time it says most of the packets have FCS errors although there is no retransmission. Additionally sometimes it stops sniffing although the packet transfer is still ongoing. Re-flashing it before each measurements helps sometimes. Does any of you have similar problems when using sniffer?

What are the recommended ways of using the cc2540 usb dongle as packet sniffer more efficiently?

  • 0
    TI__Genius 10955 points

    Is your packet sniffer far away from either of the communicating devices? Like any other radio link, the link between the packet sniffer and each BLE device is prone to errors. When the packet sniffer reports a CRC error, it means that there was one or more bit errors in the packet received by the sniffer. There may not have been bit errors observed by the communicating receiver, and thus no retransmission. Similarly, you may see retransmissions taking place without any CRC errors being seen by the sniffer, as the receiver may have had a bit error, but not the sniffer. If the reception on the packet sniffer side  is unreliable, you may also see the sniffer losing the connection because of too many lost packets or a lost connection parameter update.

    To get more reliable results, you should try to have the packet sniffer close to both ends of your BLE link. You should also try to eliminate strong interferers, such as WLAN, as they can behave different on the active BLE receiver and the sniffer. If you need to test in a noisy environment, I guess you could try to have a better antenna on the sniffer than on the other BLE devices, and maybe also place the sniffer with line of sight to both ends of the link, while these devices do not have line of sight. Due to multipath effects, it can be a little difficult to predict how this will work, though.

  • 0 in reply to hec
    Intellectual 625 points

    Thank you for the answer.

    If there are these kind of error possibilities what is the purpose of using sniffer? I mean in short range and low data rate it is working well but in high rates and middle or long range distances it doesn`t give trustful information about the lost or error packets at all. Definetly I should buy a stronger sniffer which are very expensive and I can`t afford :) Seems like there is no other methods than sniffing to determine the number of erronous and lost packets. Am I right?

  • 0 in reply to Cagatay Ulusoy
    Guru 18595 points

    Hi CAGAtay,

    BLE is not for high data-rates.

    Any kind of RF transmission is prone to errors.

    I do not think your development depends on the 1e-3 error probability the sniffer usually gives but you can try developing without it.

  • 0 in reply to Cagatay Ulusoy
    TI__Guru 57865 points

    Hi Cagatay,

    Cagatay Ulusoy said:
    what is the purpose of using sniffer?

    The Sniffer Tool is very useful when looking at the message flow during development (or learning Bluetooth low energy). The fact that you can get live feedback upon button pushed and so on is an awesome function, but that's just my opinion. It's free as well :)

    Cagatay Ulusoy said:
    other methods than sniffing to determine the number of erronous and lost packets

    If you are using our device (CC2540 or CC2541) as a Wireless Network Processor (WNP), you can use the Packet Error Rate Command. Read more in the Vendor Specific HCI Guide that is included with the stack installer.

    Best Regards

  • 0 in reply to J Lindh
    Expert 1305 points

    Nick L said:

    If you are using our device (CC2540 or CC2541) as a Wireless Network Processor (WNP), you can use the Packet Error Rate Command. Read more in the Vendor Specific HCI Guide that is included with the stack installer.

    Are we going to see this work for SoC solutions in the next stack update? Is it possible to get sth similar to the Packet Error Rate COmmand by evaluating the RSSI between each connection event?

  • 0 in reply to Hermann Menning
    TI__Guru 57865 points

    Hi Hermann,

    Actually, I'm not sure. We'll have to wait and see. 

    I am not sure if RSSI will do any good for you as I think it will only be available if you actually received a packet, although it could give you a indication on the link quality. I recommend to sample a couple of RSSI values and calculate some sort of mean value as the single RSSI value is related to one specific channel (of the 37) which is hopped every connection event. 

    Best Regards

  • 0 in reply to J Lindh
    Intellectual 625 points

    Nick L said:
    I recommend to sample a couple of RSSI values and calculate some sort of mean value as the single RSSI value is related to one specific channel (of the 37) which is hopped every connection event. 

    Hi,

    Could you please explain more how to get the channel information? I mean, I am sending advertisement packets on 37,38 and 39. I would like to embed the information of which channel is used to the  advertisement packets so that I could see the rssi of the recieved pakets at each channel separately

    Thanks in advance.

  • 0 in reply to Cagatay Ulusoy
    TI__Guru 57865 points

    Hi,

    I don't think you get channel information as of BLEv1.2.1. Might be such functionality is included in later releases.

    Best Regards

  • 0 in reply to J Lindh
    Intellectual 625 points

    Thank you for the answer. I am facing constraints while I am testing BLE. I think there should be channel information to observe the WiFi interference. What's more I want to embed information to each ADV packet. However, since the function that sends ADV packets is in BLE stack, I can not do it. Do you think can I write a custom callback function  that is executed when each time a packet is sent? 

    Regards,

  • 0 in reply to Cagatay Ulusoy
    TI__Mastermind 23440 points

    Hi,

    With the next version of the stack you will be able to get an OSAL event set on advertisement and data channel rf events.

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Intellectual 625 points

    Aslak N. said:
    With the next version of the stack you will be able to get an OSAL event set on advertisement and data channel rf events.

    Hello Aslak,

    Thank you for informing. When will the new version of the stack be released? Can you please make an estimation, prediction? I will start my thesis on this topic soon so it is important for me to make schedule.

    Regards,

  • 0 in reply to Cagatay Ulusoy
    TI__Mastermind 23440 points

    Hi,

    I've been told about mid-december, could be earlier, could be later.

    Best regards,
    Aslak