Project archive

Entry 07 / Embedded hardware

Stockroom RFID check-in prototype.

A read is an observation. A check-in is a decision.

Planned · not started
  • RFID reader module
  • KiCad
  • C / C++
  • Python
  • Fault injection

PROPOSED ARCHITECTURE / RFID

  1. 01READERRaw observation
  2. 02PARSEIdentify item
  3. 03DECIDEAccept / reject
  4. 04STORELog & confirm

DEFINE → IMPLEMENT → VERIFY → DOCUMENT

01 / The work

A read is an observation. A check-in is a decision.

At USPA, I work with RFID inventory workflows and help isolate device, application, and data problems. This independent project would let me explore those interfaces in a system I can document openly. It has not been commissioned or deployed by USPA.

01

Define each step in an event

Keep the reader response, parsed identifier, check-in decision, saved event, and acknowledgement separate. A repeated reader report should not automatically create a second check-in.

02

Select the reader before designing the interface

The selected module will determine supply requirements, logic levels, connections, and command framing. This project uses an external reader; it does not claim the design of an RF front end or antenna.

03

Choose the identifier deliberately

EPC identifies the associated object. TID describes the tag chip and may include a chip serial number. Document which identifier the prototype uses and how a synthetic item record is associated with it.

04

Make recovery visible

Use status indicators and an event log to distinguish received, accepted, saved, and failed states. Test interrupted communication and storage before drawing conclusions about reliability.

Proposed validation / no tests run yet

How I plan to test it.

  1. 01

    Exercise valid responses, duplicates, truncation, malformed fields, timeouts, and reconnection with a mock reader.

  2. 02

    Verify one accepted event per item and check-in session under a written duplicate policy.

  3. 03

    Interrupt power or communication around storage and check whether saved and unsaved events are accurately distinguished.

  4. 04

    After assembly, verify supply behavior and serial communication with the selected reader.

  5. 05

    Report physical trials with distance, orientation, tag-group conditions, and counts of reads and misses.

Technical references

GS1: EPC and tag-identification questions

Next steps / Still ahead

What I want to document next.

  1. 01Choose the reader and write an electrical/interface requirements sheet.
  2. 02Create synthetic events and mock-reader tests before building the controller.
  3. 03Keep software behavior tests separate from physical read-performance trials.
Continue exploringDiscrete operational amplifier