Failure to update ble advert data via radio notification event

[FormerMember]

I'm currently using ble_advdata_set to update the ble advert data packet. Before transmission I use the ble_radio_notification event. In this event for test purposes a single byte counter is incremented and transmitted.

The notification settings are below.

ble_radio_notification_init(...LOW,..5500US, ble_on_radio_active_event)

At the receiver end, even though the counter/transmitted data is incremented before each transmission, I sometimes see the same counter value twice.

For test purposes I tried a range of transmission rates, 20ms -> 100ms etc... However I still see the same result.

My next step was to raise the priority of the radio notifier.

ble_radio_notification_init(...HIGH,..5500US, ble_on_radio_active_event)

In the ble_on_radio_active_event, I place the ble packet update function in the app scheduler event queue using app_sched_event_put. The test results were similar to the previous results with duplicate counter values.

For the next experiment, I used the radio notify event to start a timer.

For example for a 100ms transmission rate, the radio notify event occurs for example 5.5ms before the transmission. Then a timer triggers a ble packet update 10ms later. The idea is there should be about 90ms of time to update the packet.

However even this strategy failed.

The timing of the duplicate values appears to be erratic. The app scheduler queue, is always 0 or 1 in length.

The base of the code is invensense ble_app_inv, This initialises the ble stack, the software device handler and various callbacks. I so far can see no evidence of the ble events (using the debugger). My initial thoughts was a high priority interrupt was delaying the packet update and hence the transmission of the duplicate packet. I think this is still a possibility.

I can carried out further tests. Placing the counter increment and ble packet update function directly in the radio notify event (With a low priority). I noticed at the test receiver end, with a transmission rate set at 100ms, the receive time was always just over 100ms. When a packet was received twice this time would become 3ms. I don't think it is possible for a packet to be transmitted with such a small time gap unless there is a problem. On the receiver end, the Android ble stack is known to have various problems, however I'm using Linux. Again there is the possibility the problem is on the receiver end.

[Stefan Birnir Sverrisson]

Hi

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)

[FormerMember]

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.