RFID Presence, Technical Detail & Flow
System architecture, the presence-state machine, data model, and attendance-window logic for the RFID + camera-correlated classroom presence project.
Technical Detail & Flow
System Architecture & Data Flow
How the RFID and camera signals get correlated into an attendance record, for readers who want the mechanism and not just the pitch.
System Architecture
Two independent event sources, RFID and camera, feed a correlation engine that is also aware of the bell schedule and per-period enrollment.
flowchart TD
BS[Bell Schedule] --> CP[Class / Period]
CP --> REG["Registration:
Student + Face + Computer + RFID Tag"]
REG --> RFID["RFID System
Front door / Back door / Room"]
REG --> CAM["Camera System
Spatial presence, face-scanning system"]
RFID --> CORR[Correlation / Intelligence Engine]
CAM --> CORR
CP -. expected enrollment .-> CORR
BS -. attendance window .-> CORR
CORR --> PRES[Attendance / Presence State]
Attendance Window Logic
The bell schedule doesn't just define start and end times for tardy math. It defines a window during which reads count as attendance at all.
sequenceDiagram
participant Bell as Bell Schedule
participant Win as Attendance Window
participant Door as Door Sensors (RFID)
participant Cam as Camera System
participant Eng as Correlation Engine
Bell->>Win: Period starts -> window opens
loop While window is open
Door->>Eng: tag read (device event)
Cam->>Eng: face/spatial event (student event)
Eng->>Eng: correlate device + student signals
end
Bell->>Win: Period ends -> window closes
Note over Eng: Any tag/camera event outside the window is logged but NOT counted as attendance
Presence State Model
Two independent signals, device via RFID and student via camera, get correlated into one of these states per student per period.
stateDiagram-v2
[*] --> ABSENT
ABSENT --> PRESENT: device + student seen in window
ABSENT --> TARDY: first seen after grace period
PRESENT --> DEVICE_PRESENT_STUDENT_AWAY: student signal drops
DEVICE_PRESENT_STUDENT_AWAY --> PRESENT: student signal returns
PRESENT --> LEFT_EARLY: both signals stop before window close
PRESENT --> DEVICE_ABSENT_STUDENT_PRESENT: device signal drops, student still seen
TARDY --> PRESENT: settles once both signals confirmed
[*] --> DEVICE_ONLY_NO_CONSENT: device seen, camera opted out
[*] --> TAMPER_DETECTED: tag reports tamper
[*] --> IGNORED_OUT_OF_WINDOW: read outside attendance window
| State | Device (RFID) | Student (Camera) | Meaning |
|---|---|---|---|
| PRESENT | seen | seen | Normal attendance |
| TARDY | first seen after window open plus grace period | seen | Arrived late |
| DEVICE_ONLY_NO_CONSENT | seen | opted out | Student declined face scanning by policy. Presence is based on the device signal alone and is not flagged as anomalous or incomplete. |
| DEVICE_PRESENT_STUDENT_AWAY | seen | not currently seen | Bathroom or temporary-exit scenario. Not counted as absent or left early. |
| LEFT_EARLY | seen, then both signals stop before window close | stopped before window close | Exited before period ended |
| DEVICE_ABSENT_STUDENT_PRESENT | not seen | seen | Student present without their registered device. Flagged for manual review (forgot laptop, borrowed one, or tag failure). |
| ABSENT | not seen | not seen | No signal at all during the window |
| TAMPER_DETECTED | tag reports tamper/invalid | n/a | Tag physically compromised. Excluded from attendance and flagged for tag reissue. |
| IGNORED_OUT_OF_WINDOW | seen | n/a | Read occurred outside the attendance window. Logged, not counted. |
Registration & Tag Lifecycle
flowchart LR
A[New student enrolled] --> B["Registration:
capture Face ID,
assign Computer,
issue RFID Tag"]
B --> C[Tag: ACTIVE]
C -->|Tag lost or damaged| D[Tag: RETIRED]
C -->|Tamper signal received| E[Tag: TAMPERED]
D --> F[Reissue new tag]
E --> F
F --> C
C -->|Student unenrolled/graduated| G["Tag: RETIRED
Computer unlinked"]
Data the system needs to persist
No code yet for the full model. This is the entity list, not a schema.
- Students: id, name, enrolled periods
- Periods: id, name, start time, end time, expected enrollment
- Computers: id, assigned student
- RFID Tags: UID, linked computer, status (active/tampered/retired), issue date
- Registrations: student, face ID, computer, and tag, the four-way binding
- Doors: id, room, side (front/back)
- RFID Events: tag UID, door, timestamp
- Camera Events: student (via face match), timestamp, spatial zone; stub interface into the face-scanning system
- Attendance Windows: derived per period from the bell schedule
- Presence Records: computed state per student per period, the output of the correlation engine
Current Software Stack (Phase 1)
- Reader board: CrowPi, single scan pad, 13.56MHz MIFARE Classic tags. Contact-tap, not the UHF doorway design above.
- Backend: Flask dev server. Production deployment and migration off the dev server is a Phase 2 item.
- Database: SQLite. Migrating to a production database with a backup strategy is a Phase 2 item.
- Frontend: rough dashboard, being replaced with a roster and admin view in Phase 2.
The full RFID and camera architecture above is the target design the team is building toward. The current running system implements only the leftmost slice of it: RFID read, log, dashboard, with no camera correlation yet. See Phases for how the gap closes.
Open Technical Questions
- Bag-orientation reliability: a tagged laptop inside a closed backpack has no guaranteed tag-to-reader orientation, and UHF read reliability drops off-axis. Not yet solved. See Project Summary for candidate antenna designs that address this directly.
- Camera system interface: what the face-scanning system exposes (API, event stream, or file) still needs to be defined, including how it reports a student who has opted out.
- Tag mounting standard: a single mounting spot on the laptop (for example, the underside near a plastic vent) so tag type (on-metal versus standard) can be standardized across devices.