Failure to update ble advert data via radio notification event

RE: Failure to update ble advert data via radio notification event

FormerMember — Mon, 09 Feb 2015 05:46:17 GMT

Thanks for the answer. I currently have a Braveridge AP-XX Uart-debug Rev 2.2 board. I tried the binary/hex on that board with no success. The sniffer application was unable to find the sniffer app over the COM port (It was connected). I did however find the scanning api for ble, so I am now able to scan for ble advert data, and send it to my PC using the UART. I`m not sure if this is adequate for ble sniffing.

I will look into getting one of the above boards.

RE: Failure to update ble advert data via radio notification event

FormerMember — Wed, 04 Feb 2015 12:53:42 GMT

I suspect the issue is at the receiver end. However I currently don't have the necessary equipment to do a proper test. I have a usrp, which allows me to do SDR ( software defined radio), however there is currently no open source Bluetooth stack. I'm guessing there is specialized hardware for the monitoring of Bluetooth transmissions.

RE: Failure to update ble advert data via radio notification event

Stefan Birnir Sverrisson — Tue, 03 Feb 2015 11:55:47 GMT

I would expect that data should always be up to date in each packet if you use radio notifications. I am suspicious that this may be a problem on the receiver end. Perhaps the best way to figure this out is to see what is happening on air. From your description it sounds like a packet is retransmitted and the receiver does not filter out the retransmitted packet if it actually did receive the former one. But since your device is only advertising that could not be the case.

When advertising, the peripheral will advertise the same data on all three advertising channels. The central will scan for advertising packets in its scanning window on a specific channel, then switch to another channel and scan that channel. Perhaps the scanner is picking up the packet on one channel just before switching, and then scans the same packet when it starts to scan on another channel. I am just guessing here for the sake of bringing up ideas, I may be talking nonsense.

I think the best way to find out is to see if the duplicated packet transmission is really reflected on air. If not, then it is a receiver problem.

Update 6.2.2015 To see BLE transmissions on air, use Nordic's BLE "nRF Sniffer". It is free of charge, you only need one of the following kits:

• nRF51822 Evaluation Kit (PCA10001) and a mini USB cable
• nRF51422 Evaluation Kit (PCA10003) v3.0.0 or later and a mini USB cable
• nRF51422 Development Kit (PCA10028) v1.0 or later and a mini USB cable
• nRF51822 Development Kit dongle (PCA10000)

RE: Failure to update ble advert data via radio notification event

FormerMember — Sun, 01 Feb 2015 00:19:39 GMT

The sample code I used for test purposes came from:

www.braveridge.com/bluetooth en.html

There are two applications:-

AP-THA, a temperature, humidity and pressure sensor example.
AP-6x, the invensense sample code.

In both cases, I simply add an nrf notification event, which updates the ble advert packet with a counter value (1 bytes). In both cases, I see this spurious transmission of the same data packet. The delay from the previous packet is always about 3ms, at the receiver end. The problem is seen using Android and Linux. At the moment I can live with this problem, simply because I can use the counter to filter out duplicates.