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 NFC RfID - Rain RFiD combo solution running the application firmware from app_demo_dpu_tloggerucode
- The Sensor Board running the application firmware from app_demo_dpahu_sensormonitor
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 8 LSB bits of the 4th 16-bit word are always 0. There are just 7 bytes in the 4 16-bit words that carry the NFC ID.
- The status information includes a version indicator
'T'
and a bitmask of 3 bytes AABBCCh
. They are written by the ARM as [byte #8] CCh
[byte #9] BBh
[byte #10] AAh
[byte #11] 'T' == 54h
thus ending up in the 16-bit words as: [word #4] BBCCh
[word #5] 54AAh
The interpretation of the byte sequence is described in the diagram below:
- 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
This is to be grouped as
04:E8:81:00:08:06:3D 00 000F 5400
which gives
- as NFC ID, and
- as status.
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.