NRF52832 embedded in flexible device unexpectedly disconnects and shuts down when transmitting, now also draws too much current – what is causing it?

[pragathi]

Hello Devzone,

Our research group is using the NRF52832 chip embedded in a flexible substrate to transmit EMG (muscle) signals via Bluetooth. We’ve been having a couple issues with our device and have isolated two issues to the NRF chip. For some background, here is a picture of the device placed on a user’s calf muscle. The NRF chip is connected to an ADC chip that measures potentials and serially sends each electrode’s potential as a 16-bit integer. Each packet is sent as a Notification, so the device shouldn’t expect an acknowledgement from the central device.

 

1. Device disconnects unexpectedly only when flexing

Our device attempts to send 12800 bytes per second (0.0128 Mb/s) and does so smoothly until the user starts flexing. It first starts sending packets at a slower rate, but sometimes shuts down entirely. I read from this website (https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/) that the maximum throughput for a Bluetooth 5.0 device is 1.434 Mb/s. This sampling rate is also within the ADC chip’s limit of 1.05Ms per second (we sample at 32000 samples/second). The random disconnection happens with Android and Bluetooth devices (using the NRF connect app). I have not tried using the an NRF development board to connect to the device, but I will try that soon.

It seems that the device is struggling to send data at less than around 1/100 the expected bandwidth.

I think one reason may be the low transmitting power of the sEMG, which is consistently at -70 to -85 dBm a couple feet away from the BLE device. There is no backplane for the NRF chip which explains the low transmitting power.

Either way, we have observed that a larger sampling rate causes the device to disconnect and shut down sooner. Would you all have any solutions to this issue?

2. NRF chip draws too much current when powered

We use a probe station to connect to the VDD, GND, SDIO, and SDCLK pins on the sEMG whenever it needs to be reprogrammed (shown in the picture below).

After being reprogrammed 3-4 times, the device starts to draw much more current than listed in the spec sheet. When under a supply voltage of 3.3V with a current limit of 14 mA, the device draws the maximum current when it should be drawing 8-9 mA. This is affecting our ability to reprogram the samples and might also contribute the the issue of the device disconnecting unexpectedly.

I thought that probing may have caused a short in the device, but the resistance between the VDD and GND pads are on the order of kOhms, and the resistance of the the other IO and CLK pads to VDD or GND are on the order of MOhms.

Here is the picture of the power supply when we powered the device – supply 1 has to limit the output voltage to 2.698 to limit the current despite being set to 3.3V.

Also, here is a picture taken of the NRF chip and its connected ADC chip, as well as the closeup of the most damaged pin (VDD) – we didn’t see anything unusual here, but if there is anything that catches your eye, please let us know?

Any suggestions on how to identify the issue would be greatly appreciated – for now I am using a program with low data throughput to prevent the disconnects from happening and using a newer device (since the performance seems to degrade over time).

Thank you for your time!

 

Pragathi Venkatesh

UCLA CHIPS Lab

[ketiljo]

Hi Pragathi

There's no reason for the device to degrade over time. It should withstand thousands of flash programming cycles as well. So I'm thinking that it's relates to mechanical stress caused by the flexing of the PCB. Do you have the nRF52832 on a separate module? If so, how does the module look like? Is it on a rigid PCB?

best regards,
Ketil Aas-Johansen

[pragathi]

Also wanted to add that the module is from Taiyo-Yuden, the datasheet can be found here, and no it is not on a rigid PCB.

https://www.yuden.co.jp/wireless_module/document/datareport2/en/TY_BLE_EYSHSNZWZ_DataReport_V1_3_20180530E.pdf

[ketiljo]

Hi

Ok, that should be ok. The module requires external capacitors on VCC and DEC4: 

Do you have these?

cheers,

Ketil

[pragathi]

We do not have those capacitors implemented -

When the sEMG was being developed, we contacted the manufacturer to see if they were necessary, and were told they were only recommended. I think they weren't implemented because they were a bit too large (our flexible substrate relies on chips being only a couple mm wide for them to withstand routine bending), but now that we are redesigning the device's layout, adding the capacitors shouldn't be a problem.

We also looked for deep-trench capacitors, as they were the most compatible with our interconnects (thin, 0.1-1mm pitch copper interconnects)

We connect the chip to a 3.3V Li-ion battery, and the schematic you linked above is to prevent the chip from rapid voltage fluctuations - are you thinking that the power source may be unreliable during flexing?

[hmolesworth]

The battery on the leg is shown as a (nominal, so could be higher) 3.7 volt Lithium-Ion battery, which will (eventually) damage the nRF52832 in the sense that side effects similar to what you describe start to occur. The rated supply of the nRF52832 (module)  is only 3.6 volts, and although the absolute maximum of the nRF52832 is 3.9V note that "Maximum ratings are the extreme limits to which the chip can be exposed for a limited amount of time without permanently damaging it. Exposure to absolute maximum ratings for prolonged periods of time may affect the reliability of the device". A quick fix here is a series schottky diode.

With low expected BLE throughput it's worth compressing the EMG data with a simple compression routine that (for example) sends offsets from the most positive peak value in a group of EMG readings and also that peak. 50 16-bit readings can be transmitted as a single 16-bit reading plus 49 4-bit offsets but of course this depends on the anticipated dynamic range of groups of EMG readings. If not noisy sigma-delta encoding also works.

BLE at 2.4GHz does not perform well close to a ground plane (such as the floor) or through (moist) muscular tissue; try standing on a table and see if that improves performance (for confirmation).

[ketiljo]

The external caps are mandatory. Especially the cap on DEC4 is needed for the internal regulators operate properly. So you need to implement those. 

Max supply voltage is 3.6 V. Absolute max is 3.9 V for a _very short_ period of time only. Any higher will damage the device. With a LiPo battery, you need a regulator as the voltage can easily be higher than this, up to 4.3 V.