This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Separate BLE Tx from SPI/I2C operation

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.

Parents
  • FormerMember
    0 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.

  • FormerMember
    0 FormerMember in reply to 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.

Reply
  • FormerMember
    0 FormerMember in reply to 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.

Children
No Data
Related