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

nRF52832 hardware feasibility for the application

Hello,

To the nordic experts, please share your opinion or any suggestions are welcome in finding the feasibility of nRF52832 SOC in our product based on the information below.

Brief about our product, BLE enabled product whose functionality 

1. To get input from the user through Capacitive touch sensor(5 channels are required in total) such as Turn ON/OFF or enter PAIR UP mode or confirm. 

2. Collect sensor data through ADC such as temperature, level sensing, measurement of battery state of charge. 

3. Digital PI controller

4. Real-time clock

5. BLE to send or receive data/commands from a users mobile application.

Concerns:

Firstly, Capacitive touch sensor cannot be implemented using COMP, as nRF52832 has an anomaly 84. While soft device enabled, Cap_touch_sense will not work because it uses PPI directly. 

Second, all the sensor data is read using app_timer but when these modules are integrated with Softdevice, BLE works abnormally such as pairing up takes longer than usual more than 10 seconds and same with characteristics discovery and ble events are all delayed. After brief research online tried to implement application timer events through app_scheduler but nothing changed, in fact, BLE stopped advertising completely. 

Third, do nordic have API's have PID libraries?

Finally, In hindsight, I realized soft-device have many implications and some limitations in using complete hardware blocks.  Kindly share your opinion for the above concerns and also give any suggestion whether we could make use of nRF52832 or move to a higher version or do we need to go for external harward components for some of the functionality in our product.

Looking forward to hearing positive responses.

  • Hi Shivrath, 

    You are right about the Erratum 84 causing the COMP peripheral is not usable as production grade. The solution is to use Csense library with SAADC instead. The drawback is that you would need to use 2 GPIO pins and a resistor for each cap sensor pad. I would like to stress that the capsense library is provided as a example of what you can do with the COMP/SAADC, but not as a production level module to be used out of the box. 

    I don't really understand your question regarding PPI ? Why would the softdevice causing any trouble with using PPI directly ? The softdevice only use some PPI channel dedicated for it, not all PPI channel. 

    Second, all the sensor data is read using app_timer but when these modules are integrated with Softdevice, BLE works abnormally such as pairing up takes longer than usual more than 10 seconds and same with characteristics discovery and ble events are all delayed. After brief research online tried to implement application timer events through app_scheduler but nothing changed, in fact, BLE stopped advertising completely. 

    I don't understand what you are asking about in this sentence. If you need to do any peripheral reading, try to do it in APP_LOW priority. This way the softdevice can work normally when you do your task. Please have a look at chapter 16 Interrupt model and processor availability in the Softdevice spec. 

    - We don't have PID library out of the box, but you can have a look here. Could you give a list of the limitations of the softdevice that you think could be a trouble ? 

  • the capsense library is provided as a example of what you can do with the COMP/SAADC, but not as a production level module to be used out of the box

    See: https://devzone.nordicsemi.com/f/nordic-q-a/45270/unhelpful-documentation-capacitive-sensor-low-level-library---anomaly-84/178113#178113

Related