CC2640: Beacon Advertisement Packets are Missing

I have assigned an expert to comment.

Great, looking forward to it.

Any update?

Hi Ameer,

I am so sorry for the late response.

I just had a look at the simple_broadcaster example project from the latest CC2640R2 SDK, running on a CC2640R2 LaunchPad. The out of the box example gives me a stable 10 advertisements per second (with packets on channels 37-39 every time). From the latest software, I can't seem to recreate your issue.

Please let me know:

• What version of the SDK are you using?
• What version of the BLE-stack are you using?
• What sniffer software/application are you using to get the above screen-shot?

Best regards,

Vetle 

Hi Ameer,

Did you get this to work with the latest SDK?

Best regards,

Vetle

I am using SimpleLink_3.3.

The software I used was nRF connect on android mobile.

Also since you are saying that your performance was 10/10, I also have a few other Beacons running at the same place, could interference between them be causing the packets to miss (but that shouldnt be the case as the transmission interval is 200ms and the transmission time is hardly in a 5ms window)? On that note I would also like to ask which application and receiver type you are using.

If you have lots of beacons running at the same time, your phone will sometimes get the data from other beacon since there is no way for you to control all the beacons broadcast at different times. It's what it is and you can't really change it. 

If you are suspecting software issue, can you try to make sure that when there is only one beacon presents, you are still not able to see all the packets.

Also you need to make sure your scan interval can cover your advertising interval in order to get all the packets. 

Ok so I even secluded the beacon and used my mobile to scan it and it still missed packets at 200ms advertisement rate. I am scanning via my mobile, can you recommend a specific app to use to scan it. 

Also if there is any other method you could recommend to scan it, please do suggest.

What's the advertising rate of other vendor's chip you are using? 

Can you try to use the same advertising parameters and same app to do the comparison?

The parameters for the both the chips are the same at 200ms and it is to be noted that even the vendor chip usually gives a packet rate of 80% reception in a spam of 30seconds.

I even tried the simple_peripheral example just to see if there might have been a firmware level issue but still I saw a high rate of packet loss (packets not received)

Hi,

When we use a high end sniffer(Ellisys, frontline) or a TI sniffer, we can see that simple_peripheral advertise 10 packets within 1 second(the yellow lines marks the adv packets from simple_peripheral 3.30 CC2640r2 sdk).

When I am using nRF52 connect with iPhone when turning off wifi, I sometimes can get 8~9 advertising packets per second.

However, since it's not possible to control those scan parameters with phone, I don't really know what's imposed in all the different phone vendors,

But the problem is not on our software nor hardware, it's the scan parameter and BLE time for the different OS on phones.

Why do you need to receive the packets 100%? 

Can sharing the schematic be of help in diagnosing?

As stated, this is not a hardware issue.

It's the scan parameters sets by the phone. Also in reality, there is really no need to receive all the beacon adv packages.

I am using dedicated hardware in which we have 100% duty cycle scan interval and scan window are of the same value. Even then packets are dropping. I am comparing this with another beacon of another manufacturer with the same advertisement interval but the TI CC2640 is dropping a lot of packets in it still.

Also for not being able to receive all packets, there are times when no packet is received in a second when having a 200ms interval.

P.S.: I am using CC2640F128

Hi Ameer,

At this point we are not able to reproduce your issue. As both explained and illustrated with the sniffer log, we can verify that a cc2640r2 launchpad with the simple_broadcaster example is transmitting the expected number of packets. I know you have included the scan response in your initial post, but it would be useful if you can also verify this with a high-end sniffer.

Another option would be for you to monitor the TX/RX activity (RF obserables) as described in the debugging guide (same approach for either BLE stack):
http://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_3_40_00_10/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-rf-output

This way you will be able to monitor GPIO's toggling when the radio is transmitting and receiving, and this way count the number of advertisements going out.

Please also share your schematic.

Best regards,

Vetle