Energy Harvesting not available when RF is sleep or disabled

[REdmo.1]

In the ST25DV data sheet, I read:

"Energy harvesting can be set even if ST25DVxxx is in RF disabled or RF Sleep mode, or in Low power mode. In all these cases, ST25DVxxx will deliver power on V_EH pin if RF field is present."

However this is not what I am seeing.

If energy is being harvested to power the MCU and it sets either RF_DISABLE or RF_SLEEP in RF_MNGT_Dyn via i2c ,the energy harvesting output disappears and the system dies.

Is this an error in the data sheet or is there a way to disable/delay enabling RF communications whilst maintaining Energy Harvesting?

I suppose that the possibility exists that the phone is switching off the field when RF communications are disabled, but this amounts to the same thing.

I want to be able to delay RF communications until the MCU has written the NDEF record to the EEPROM, i.e. I want to power up from harvested energy with RF communications initially disabled.

Thanks,

Richard

[REdmo.1]

I'm starting to wonder if this is in fact phone behaviour. How would I find out more about how phones control their NFC fields to detect and power NFC tags?

Perhaps the phone only raises the strength of its NFC field sufficiently to enable energy harvesting if it can communicate with the tag. Perhaps it is necessary for the phone to have successfully read whatever it reads plus any NDEF records before it raises the field strength. Perhaps it reduces the field strength if RF communications with the tag are disabled causing the the tag to power down. There's a lot I don't know about phones and it seems I need to know it. How might I find out?

This tends to suggest that setting any of the bits in RF_MNGT would effectively "brick" the NFC tag. From that point forward, the phone can no longer access the tag over RF and since there is no power on the tag (since there is no communication), neither can the MCU over i2c.

My challenge is that I want to populate a URI NDEF record BEFORE the phone reads it in order to transfer sensor data to the cloud. [My previous plan was only to enable RF communication AFTER the NDEF record had been written by the MCU to the ST25DV. There is no app on the phone.]

How do those sensor systems communicate their data to the cloud?

[Ulysses HERNIOSUS]

Hi Richard,

a phone will typically perform a polling loop with field on, send some commands (typically going through NFC-A, NFC-B, NFC-F and NFC-V defined in NFCForum Digital and Activity spec) and if nothing is found turn off the field again. This whole procedure will probably last something in the ~50 to 100ms range. A tag according to standard is expected to be able to answer after ~5ms.

As all phones that I know go through the other technologies first which will buy you some 30+ms but likely not enough for you to write a complete NDEF and enable RF.

My tag colleagues will be able to comment on approaches for your use case.

Best Regards, Ulysses

[REdmo.1]

Thanks for this - it makes sense.

I'm not quite clear exactly what is meant by "nothing is found" and "answer" but the gist is clear.

I would have imagined that the scheme whereby an "intelligent" tag with a sensor constructs a URI NDEF record to pass sensor values to the cloud might be a popular solution. But I haven't found a way to make it work nicely yet.

At the moment, the best I can think of is to have the RF field initially enabled in the ST25DV and then to use harvested energy to power the MCU to write the NDEF record. If the MCU then set bits in RF_MNGT_Dyn to disable RF, I find that the phone removes the field, the RF state reverts to that specified by RF_MNGT i.e. on and the process starts again, but this time with the sensor data already in the NDEF record. The tag is effectively triggering a reboot.

This is just about ok for the proof of concept demonstrator I am building, but you can see the obvious problems with it

1. how does the cloud know which NDEF records are valid and which not => I'm currently adding a incremented "sequence" parameter in the NDEF record - yuk!
2. after the restart, the MCU will start writing the sensor values again so the tag needs to be removed quickly form the field after the second "bing-****" => potential corruption

Using a URI NDEF seems like a nice way to use a phone as a conduit between a sensor tag and the cloud, but I haven't yet found a nice way to do it. Has anyone else?

Thanks,

Richard

[JL. Lebon]

Hello,

I think what you are trying to do is explained in detail in the application note AN5439 https://www.st.com/content/ccc/resource/technical/document/application_note/group1/fa/bc/7d/fc/e1/d9/4f/83/DM00682138/files/DM00682138.pdf/jcr:content/translations/en.DM00682138.pdf

It explains and give examples of dynamic NDEF using the ST25DV.

I confirm that your analysis is correct: in RF Sleep mode, as the tag is not answering to the Inventory command send by the phone to discover the tag, most of the phone will shutdown the RF field (for several hundred ms before trying again).

This means you cannot "buy" time to update your NDEF file before the phone reads it (as the next command after the inventory is to read the CC file and the NDEF file) as you will lost the EH power.

You just have a short window of about ~30ms to update your NDEF file.

Hope the application note can help you in your project.

Best regards.

[REdmo.1]

Hi JL,

Many thanks for this application note. I will read it and respond.

Richard

[REdmo.1]

Hi JL,

This Application Note is brilliant. There is so much in it that relates directly to our application....stuff I had to find out the hard way, but now can read about....still reading...

Very grateful,

Richard

[JL. Lebon]

Thank you, I'm glad it helps you! 😀

[REdmo.1]

From the excellent application note, it does seem that it is not physically possible for our microcontroller (STM8L151) to update the lengthy NDEF record before the phone reads the EEPROM. I had hoped there might be a way to tell the phone that the tag was present (and for it to provide a continuous field to enable energy harvesting) yet find a way to stop it reading the NDEF records "just yet". Seemingly not.

I also haven't found a way to coax the phone to re-read the NDEF records without "removing the tag from the field".

The scheme I am currently using in the demonstration is to employ two "sessions". I have found that the phone can be induced to initiate a second session and re-read the NDEF if the tag disables RF dynamically. [Is there a tidier way for the tag to force the phone to re-read the NDEF?]

1. At the start of the first session the phone reads a stale URI NDEF record from the tag. The webservice uses a sequence number in the URI record to know that the NDEF record is stale and responds with html to tell the user to continue to hold the tag next to the phone.

2. The energy harvested is used to power the microcontroller which updates the NDEF record (though its a nightmare trying to do it in a way that doesn't cause a conflict with the phone).

3. The microcontroller then sets bits in RG_MNGT_Dyn to disable RF communications. The phone loses contact with tag, the phone removes the NFC field and both the ST25DV and the microcontroller are powered down.

4. The ST25DV behaviour is now determined by RG_MNGT and so the phone detects the tag. It provides an NFC field and it reads the data that was just recently written by the microcontroller in the first session. Conveniently, the phone makes a sound which can be interpreted to mean that the updated NDEF record has been read.

A scheme involving sequence numbers and checksums allows the webservice to detect stale and corrupt messages respectively.

This scheme seems to be working for a demonstration. More analysis is needed to see if it is robust enough to roll out for a product.

Or is there a better way to achieve what I am trying to achieve?

[JL. Lebon]

Hello Richard,

Your solution is smart!

As you understood, the main issue is that if the tag doesn't answer to the inventory command, it is considered lost and the field is shut down.

We do have the RF_DISABLE mode that answers an error to any command. But unfortunately it doesn't answer the inventory command either since the ISO15693 standard doesn't allow it.

But it may be possible to do something with this RF_DISABLE mode...

Indeed, any error answered during the NDEF read by the phone cancels this NDEF reading. But an error doesn't make the phone cut the field. After an error, the tag is still considered to be present and the phone will periodically checking the tag's presence by sending periodical Inventory commands (every few 100ms depending on phones).

So, the idea would be to set the tag in RF_DISABLE mode right after the first inventory.

That way, next command would fail and the phone would stop reading the NDEF. You would then have until the next Inventory command to update the NDEF from I2C (a few 100 ms).

After this, the next Inventory would not be answered as the tag is still in RF_DISABLE state: and the phone would cut the RF field and start the discovery process again, reading the new NDEF.

Detecting the first Inventory command is the tricky part.

You would need to detect the field rising interrupt and then the first RF_ACTIVITY interrupt triggered by the first inventory command.

On this RF_ACTIVITY interrupt, you would have a few ms (no more than 5ms I guess) to set the tag in RF_DISABLE mode by writing RF_MNGT_Dyn from I2C (the ISR has to read the IT_STS register and write the RF_MNGT_Dyn register very quickly) . This is tricky on timing...

To debug all those timings, I recommend you to use a scope with a probe on SDA/SCL, a probe on VEH and a small one-loop wire "antenna" on the antenna of the tag, connected to a probe as well, to monitor the RF field (this is the way the screenshots of the AN have been made)..

Sorry if this this idea does not work or help you, It is just quick thinking 😁

Best regards.