NHS3100 drop of voltage when in NFC field

[pivic]

Hi,

I'm currently working on a project based around the NHS3100 and the example code dp_tlogger. 

The data is being logged no problem but retrieving the data creates a drop in the supply voltage. This drop is sometimes sufficient to be logged as a "battery depleted" message and therefore stopping all future measurements. 

This behaviour is similar on the NHS3100 dev board. 

We are looking for a solution on how we can actually use the NFC field as a power source when retrieving the data, instead of using the battery (3V CR1225). 

Is there any application example?

Thanks

[driesmoors]

Hi,

To be clear:

• You start a battery powered logging session
• At some point, the battery is depleted - or you yank it out of the holder.
• You tap the tag with your phone running the tlogger demo app
• Reading out all datapoints starts, but stops after reading out x% of the measurements.

Is this summary correct?

• Is the moment that reading out stops seemingly random chosen?
  If you clear the history (three-dots menu > App settings > Clear history), retsrat teh app, and retry, do you have a break-off at the same moment?
• o you see the same problem when using an NFC USB reader and the Win10 version of the demo app? Or when using a different phone?
• Does reading out continue after re-tapping?

Best,
Dries.

[pivic]

Hi,

Thank you both for your replies. 

Here is what we are doing and the problem: 

• Start a battery-powered logging session
• Measurements occur regularly at the preset time. 
• Bring the NFC field from the phone with the App running and download the data. 
• Battery shows depleted (even though it is not) 
• "Reset Tag" from the App
• "Set configuration" from the App. And back to the beginning. Repeat. 
• The battery is never disconnected.

Now the problems: 

• Each measurement will make the battery voltage to drop a bit due to the high internal resistance of the button cell battery. 
• When bringing the NFC field from the phone running the App, the voltage drops even further thus triggering a "battery depleted" message. 
• This means that when we go to read the data out from the tag, we are highly likely to force stop the measurement at that time, and therefore need to Reset the Tag before restarting the measurements. 

We appreciate that the battery voltage dropping is due to the battery (CR1225) having a high internal resistance. But we would like to be able to use the NFC field as a power source while reading the data out - so to stop pulling power from the battery, and stop this erroneous "battery depleted" message state happening. 

We can't find any example application of the "Chip_PMU_Switch_OpenVDDBat" which we think could do the trick. The current dev board reacts the same way as our custom device. 

We are also wary of using this function because if we lose the NFC field while the data is being accessed, and the VBAT is being disconnected, we might lose power completely to the device and need to reset the configuration anyway. 

Do you have any working examples of the switching between VBAT and NFC field? 

Regards,

Alex

[driesmoors]

Ok. Thanks for the insights.

• The battery empty message is a translation of the bit APP_MSG_EVENT_BOD in field status of the application response (the MIME payload) with ID APP_MSG_ID_GETCONFIG and structure APP_MSG_RESPONSE_GETCONFIG_T.
• That bit is likely set after running Chip_PMU_SetBODEnabled in the function DeInit in the embedded firmware. (There are 3 locations where this bit can be set, so the options are limited.)
• You may reduce the load on the battery a bit by reducing the clock speed of the application. Check ResetISR in the main file. 500kHZ and 1MHz may still be good enough - but beware: ensure you can create a valid NDEF message at startup in time (you have around 15 msec max or so).
  
  
• It is possible to switch between NFC powered and battery powered, even when a battery is present. This is not exposed as an API in the PMU driver of the firmware. For good reason: you already mentioned why.
  To do this nonetheless, you will need to adapt pmu_nss.c yourself. Check the HW User Manual: four bits are involved to select the power source: VBAT, FORCEVBAT/FORCEVNFC, and PMULPM. Be careful as not all combinations of these bits are meaningful. First try this out in a separate project, with recovery mechanisms: plenty of wait time after a reset before switching, use of a button to enter an infinite wait loop, and doublecheck that the SWD pins remain active at all times
  Then try: VBAT 0b0, FORCEVBAT/FORCEVNFC 0b10, PMULPM 0b0. This will force selection of VNFC. Use 0b00 to enable autoswitching again.
  May I repeat that this is very much not advised?

Some general remarks:

• Be sure to switch to the latest SDK, if you haven't done so already. The current latest is SDK 12.4. Read the release notes beforehand and make proper backups before upgrading.
• The reduction in total current consumption will be minimal. You will be able to reduce the load at those peak moments, however.
• Adapting the code to reduce the load is also possible: remove compression, only use eeprom for storage, reduce SysClock, reduce eeprom flushes (since SDK 12.3), and using an external cap (or two) to overcome those peak moments (take care to load them slowly, of course). These have all drawbacks, so you have to weigh this against your specific use case.

Kind regards,
Dries.

[pivic]

Hi,

Thank you for your message. Here is an update on the progress:

We log data on the NHS3100 while being battery operated. Once in a while, we bring it to an NFC field to download the data. Once coming out of the NFC field, we carry on logging data. 

In the firmware, therefore, we want to go from Battery to NFC field for the source of power, and then go from the NFC field to Battery power. 

We got the transition from NFC field to Battery power working, but we can't get the transition from Battery to NFC field to work... The voltage drops too much and triggers a Brown out... 

We added 2x220nF capacitors on PIO03 and PIO07.

The oscilloscope screenshot shows the voltage dropping when transitioning from 3.3V to NFC field. 

Ch1: PIO0_3 voltage  -   Ch3: GPIO set when forcing VNFC

I have attached the snippet of code in the Execute loop.  It controls the GPIO (which should be at 1 for 60ms, then changes back to 0):

We would hope that there is a way to transition from the Battery to NFC field without triggering a BOD. Can you please confirm? And guide us on how to do this?

[driesmoors]

Hi,

• The scope plot shows a lot of noise. Is this caused by the measurement setup?
• The code snippet only shows a very limited portion of the code, and it is difficult conclude anything based on this.

A brown-out is easily reached when running on NFC.Did you try to reduce the load to the absolute minimum? Or are you talking about a reset?

My best recommendation is to try to avoid this trick, and run on battery continuously.

Kind regards,
Dries.

[weidong_sun]

Hi Pivic,

1. When the current is not enough, the power supply voltage will drop.
Therefore, the situation you are encountering is caused by insufficient power supply current.
2. About using NFC FILED to supply power to NHS3100
(1)
In fact, it is difficult for you to use the filed of the reader antenna to provide power to the NHS3100. As long as you check the NHS3100 datasheet, you can know the current required by the NHS3100 when it is running. Please see: Table 17. Static characteristics.
(2)
Assuming that the filed of the NFC reader antenna can provide power to the NHS3100, the NFC reader antenna must be specially designed, but we do not have a similar solution to provide customers.

Have a nice day!

B.R,

weidong