NHS31xx UCode-I2C EPC coding
NHS31xx UCode-I2C EPC coding

Introduction

When an NHS31xx IC is combined with the UCode-I2C IC, using either the I2C HW block or the bit-banging module i2cbbm, the current status of an ongoing monitoring session can eb communicated through the EPC code stored in the UCode-I2C chip. Currently, two boards make use of this:

The decomposition of the EPC code into the different types of information is described here.

Note
Only the 12-byte EPC code is adapted. The UCode-I2c also sports a User Memory bank, but the current demo firmware applications do not make use of this. A production application can use this to store extra fixed or slowly-changing information such as the first n excursions, or statistical information of the captured data, and so on.
Warning
  • The ICs have not been designed with mutual compatibility in mind. The UCode-I2C chip cannot activate both interfaces - UHF and I2C - at the same time; and the NHS3100 chip cannot be started by the UCode-I2C chip. Full bi-directional communication is therefore not possible when the power-off mode is to be used.
    When the NHS3100 IC only uses active, sleep, Deep sleep, and deep power down modes, it is possible to have the IC wake up each time new data is written by an UHF reader in the UCode-I2C chip. Technically, this makes it possible to set up a bi-directional communication channel. In practice, this is not feasible. Apart from throughput times being very low, there is no possibility for a proper synchronization mechanism. Each synchronization error necessitates a complete communication restart from both sides, due to the way the UCode-I2C handles simultaneous read/write access via the I2C interface and the wireless UHF interface. As a result, a full data readout implementation would provide, at best, a slow, error prone, and unstable operation.
  • When the status changes, the EPC code cannot be updated for as long as the label is present in the UHF field. The NHS3100 IC will postpone updating the EPC code when it detects the unavailability of the I2C bus: it will try again during the next active period of the chip. The exact timing of an update is thus dependent on the location of the label - near a UHF gate or not - and on the measurement interval of the monitoring session on the NHS3100 chip.
  • Both UHF reader and NHS3100 can use the non-volatile memory of the UCode-I2C chip to convey information, each at distinct moments when each side can have exclusive access to the IC.
    • Typical information that could be conveyed from tag to host: label information, status reports, specific statistical information, the first n excursions, ...
    • Typical information that could be conveyed from host to tag: handover data including timestamp, owner IDs, geolocation data, ...

EPC breakdown

The 12 bytes EPC code are divided in two blocks: the first block of 8 bytes conveys the NFC ID; the second block conveys the status information.

The interpretation of the byte sequence is described in the diagram below:

dot_inline_dotgraph_1.png


Note
A valid sequence must have:
  • 00h at position #3 LSB
  • 54h at position #5 MSB
The status is to be interpreted as a bitmask, containing all the events that occurred. The status events that are no longer applicable may still be set; in case of conflicting information, the highest bit set indicates the correct current status. All possible events are listed in UCODE_EVENT_T.

Example

An EPC code read out by a UHF reader may read

04E8810008063D00000F5400

This is to be grouped as

04:E8:81:00:08:06:3D 00 000F 5400

which gives

The four bits set in the status can be looked up in UCODE_EVENT_T. In this case, UCODE_EVENT_PRISTINE, UCODE_EVENT_CONFIGURED and UCODE_EVENT_STARTING are to be ignored; the current status is UCODE_EVENT_LOGGING.