General Guidance in Sensor Application Design

[Stefan Wyss]

I'm developing a battery powered BLE sensor application where I need some basic guidance on how to implement this:

The sensor action consists of a measurement process where a PWM signal is generated and some analog values are continuously sampled with the ADC module of the nRF52. The total processing time of this sensor measurement takes about 2ms. One important requirement for the (2ms) PWM/ADC measurement is that it is not interrupted by softdevice/BLE events, because this sensor measurement is highly sensitive to interruptions and power supply variations.

My first question is:

1) Could this be implemented with a read characteristic from the central?

I tried this, but when I handled the read request in the nRF52 firmware, the device got disconnected while measuring and I think it might be because the read command might have some timing requirements. So I wonder...

2) What are the timing requirements for processing a read characteristic event? (How long can the peripheral wait to deliver data to the central after receiving a read event?)

I think that the measurement could also be done with a "notify" event. So after the central performs a read event, the peripheral could start the measurement and once the measurement is complete, it could notify the central with the measured sensor values. This might also be better in terms of measurement sensitivity. Maybe there are other strategies?

3) Which strategy would you recommend for such an uninteruptible and sensitive measurement with 2ms measurement duration?

Sorry for asking such a general and unspecific question, but some opinion and basic guideance would help me a lot with not heading into the wrong direction right at project start.

Thanks in advance,
Stefan

[bjorn-spockeli]

Hi Stefan,

Q1: I would say that its makes more sense for the BLE sensor to send the sampled data stored in the characteristic as a notification, rather than having the central "polling" the characteristic for new data. 

Q2: Ref Q1, I recommend using notifications instead. The BLE sensor(peripheral) can queue the notification between each connection event. The notification is then sent on the first upcoming connection event. The delay between the notification being queued and the data being sent over the air will depend on the connection interval. 

Q3: Our SoftDevices have a Radio Notification feature, is a configurable feature that enables ACTIVE and INACTIVE (nACTIVE) signals from the SoftDevice to the application notifying it when the radio is in use. So you can trigger the 2ms measurement when the Incative signal is received. If you're in a connection then you know that the radio will not be turned on until the next connection event, which are minimum 7.5ms apart. 

We also have the more advanced Timeslot API, where you request a timeslot from the SoftDevice, where there is no SoftDevice activity, the Complete Radio Timeslot session example in the SoftDevice specification shows a complete Timeslot session.

 Best regards

Bjørn