Separate BLE Tx from SPI/I2C operation

[djqtsg]

I have an application that first reads ADC sensor data from a SPI device, then transmits out through BLE. I have a 4ms timer; once it times out

1. Read sensor data through SPI fuction calls
2. Put data inside a BLE packet and send it out by calling ble_nus_string_send(). I use UART service to implement my application

Now I have an issue with the ADC data, there are spikes in the data values occasionally. We suspect it may be caused by the BLE transmission, because if I sends the data through UART, I see much less spikes in data.

So we want to do an experiment in which SPI calls and BLE tx are separated. For example, if in on_ble_evt() there is something like radio idle or tx done, then I make the SPI call.

For my current implementation, although I do the two things in sequence, I am not sure if ble_nus_string_send() immediately starts BLE tx.

[FormerMember]

To avoid to reading sensor data when the radio is active, you can use radio notifications to notify the application when the radio is active and not active.

If your device is in a connection, and it only sends one packet per connection interval, the radio will be turned off for quite some time for each connection interval.

[djqtsg]

I found this tutorial devzone.nordicsemi.com/.../

It is not clear to me how to link radio active event to SWI1_IRQn.

What if I want to be notified by both active and inactive event.

radio_evt in SWI1_IRQHandler() is a bool variable: does true mean radio active, false mean inactive?

[FormerMember]

I'm not sure if the radio notification signal indicates active/nactive or indicates that there is a radio notification. But you know for sure that the first radio notification is "active". I would therefore recommend you to just have a local statemachine (state variable) keeping the state of the radio notification.

[djqtsg]

I thought to do similar thing.

However, how can I make sure I would not miss SWI1_IRQHandler()? One missing call will mess up the state machine.

[FormerMember]

I can agree that it may seem a little fragile. To make sure that it works properly, the initialization of the radio notifications should be done right after the initialization of the softdevice: (sd_radio_notification_cfg_set documentation) *To ensure that the radio notification signal behaves in a consistent way, the radio

•    notifications must be configured when there is no protocol stack or other SoftDevice
  

•    activity in progress. It is recommended that the radio notification signal is
  

•    configured directly after the SoftDevice has been enabled.*
  

Another, perhaps more complex option is to use the timeslot API.