Python RFID Reader Library Guide

NFC and HF RFID with nfcpy — reading, writing and the PC/SC ecosystem

Every Python RFID project begins with the same quiet humbling: you buy a cheap USB reader, plug it in, write your first few lines of code, and then spend the rest of the afternoon convincing the operating system to let Python anywhere near the device. The reading was always the easy part. For NFC and 13.56 MHz HF RFID development, nfcpy is the most popular and best-supported Python library. It covers NFC Forum Type 1-5 tags, supports the most common USB NFC readers and exposes a clean, Pythonic API. This section surveys nfcpy and the PC/SC-compatible reader ecosystem it works with.

• nfcpy library overview: open-source Python library (https://github.com/nfcpy/nfcpy) supporting NFC communication with Type 1 (Topaz), Type 2 (NTAG, MIFARE Ultralight), Type 3 (FeliCa), Type 4 (MIFARE DESFire via ISO 7816-4 APDUs) and Type 5 (ISO 15693) tags. Provides tag discovery, NDEF read/write, card emulation and peer-to-peer NFC. Runs on Linux, macOS and Windows (with appropriate USB driver setup).
• Supported NFC readers: ACR122U (the most common USB NFC reader, ~US$25-35), Sony RC-S380/P and RC-S380/S, SCL3711 (ACS legacy), PN532 (via USB, UART or SPI breakout boards). ACR122U is the recommended starting point for nfcpy development because of its low cost, wide availability and broad library support. For FeliCa-heavy projects, RC-S380 gives better FeliCa performance.
• Getting started with nfcpy. `pip install nfcpy`, connect a supported USB reader, run `python -m nfc` to verify reader detection. A basic read example is under 15 lines of Python: open a clf (contactless frontend), call `clf.connect(rdwr={'on-connect': ...})` with an on-connect callback, inspect the returned Tag object, read NDEF content via `tag.ndef.records`. Writing is similarly straightforward with the NDEF message construction API.
• NDEF record handling: nfcpy ships a companion `ndeflib` package providing Python classes for the major NDEF record types (URI, Text, Smart Poster, vCard, Wi-Fi Simple Configuration, Bluetooth Simple Pairing). Building an NDEF message is a matter of composing record objects and assigning to `tag.ndef.records`, which triggers the write on session close.
• nfcpy limitations: doesn't provide direct MIFARE Classic Crypto1 access (use pyscard or libnfc for MIFARE Classic); may require specific udev rules on Linux to give the user access to USB readers without root; some NFC Forum Type 4 tags require careful APDU sequencing which nfcpy partially abstracts. For advanced MIFARE DESFire work, pyscard or custom APDU libraries are usually preferable.
• Common use cases: consumer NFC app prototyping (build a custom URL/vCard programmer for your Google Review or business card programme), NDEF content validation (batch-scan programmed tags to verify encoding), research projects (signal analysis, Tag Forum compliance testing), classroom teaching and maker projects. Pairs especially well with Proud Tek NTAG 213/215/216 stickers as the cheap, universally compatible tag target.
• Python version and platform support. nfcpy 1.0 dropped Python 2 and ships under EUPL on GitHub; the latest documented release as of May 2026 is `1.0.4` per nfcpy.readthedocs.io. Pin `nfcpy>=1.0,<2.0` in requirements.txt; the companion `ndeflib` package is installed automatically. Linux is the best-supported platform; macOS works with libusb installed via Homebrew; Windows requires Zadig to install WinUSB drivers for the NFC reader (driver replacement is required to bypass the built-in ACS/Sony driver). Docker containers need `--device=/dev/bus/usb` passthrough and the matching udev rules on the host.
• Integration with Flask/FastAPI webhooks. A common deployment pattern wraps nfcpy in a systemd service that posts tag reads to an internal HTTP endpoint. Example: nfcpy on-connect callback calls `requests.post('http://localhost:8000/rfid/event', json={'uid': tag.identifier.hex(), 'ndef': [str(r) for r in tag.ndef.records]})`, and a FastAPI backend receives the event and routes to downstream systems. Keeps reader I/O isolated from business logic and gives Ops a clean service boundary.

Smart-card APDUs with pyscard — MIFARE DESFire, JavaCard, HID iCLASS SE integration

For smart-card-class RFID programmes (MIFARE DESFire, JavaCard-based credentials, HID iCLASS SE) the PC/SC (Personal Computer/Smart Card) framework provides the standard integration layer. pyscard is the Python wrapper for PC/SC and is the go-to library for APDU-based RFID work on any PC/SC-compatible reader.

• pyscard library: Python wrapper for PC/SC (Windows winscard.dll, Linux/macOS pcsc-lite). Install via `pip install pyscard`. Works with any PC/SC-compliant reader: ACR122U, Identiv uTrust, HID Omnikey 5022/5325/5427, SCM Microsystems SCL01xx, Feitian FBB-10. Provides low-level APDU exchange with `connection.transmit(apdu)` returning response and SW1/SW2 status bytes.
• PC/SC versus native USB access. PC/SC abstracts the reader at the OS level, so your Python code is reader-agnostic as long as the reader has a PC/SC driver installed. nfcpy bypasses PC/SC on some reader families for better NFC-specific behavior; pyscard goes through PC/SC for maximum reader-hardware flexibility. For smart-card-class integrations (DESFire, JavaCard), PC/SC is the natural fit.
• MIFARE DESFire EV1/EV2/EV3 programming with pyscard. DESFire uses ISO 7816-4 APDUs for authentication (AES/3DES), application creation, file creation and encrypted reads/writes. Community libraries like `py-nxp-desfire`, `nfcpy-desfire`, and `nfcpy/pyscard-desfire` wrap the raw APDU exchange with DESFire-aware abstractions. Production access-control development typically uses these wrappers rather than hand-coding APDUs.
• JavaCard communication: for programmes using JavaCard-based credentials (PIV, CAC, EMV payment cards, government eID), pyscard is the integration layer. The SELECT applet, GET_DATA / GET_CHALLENGE, and applet-specific APDUs all flow through `connection.transmit`. Python-JavaCard development enables smart-card emulation testing, credential issuance pipelines, and cross-referencing for government / corporate security programmes.
• HID iCLASS and iCLASS SE. HID's smart-card-class credentials talk over PC/SC with HID OMNIKEY readers. pyscard provides the communication layer; HID-specific APDUs and key-management require either HID's SDK or community-researched protocol knowledge. Useful for access-control research and integration testing.
• EMV contactless reading: for research and education purposes, pyscard can read public EMV data (PAN, expiration, cardholder name) from contactless credit cards via standard EMV ATR and GPO APDUs. Useful for fintech prototyping; not for production payment processing (which requires EMVCo certification and specialized terminals).

Raspberry Pi and microcontroller RFID — MFRC522, PN532, SPI/I2C/UART RFID modules

For embedded and maker projects running on Raspberry Pi, Arduino, ESP32 or RP2040-class boards, a different class of RFID library applies: libraries that talk directly to MFRC522 or PN532 RFID chips over SPI, I2C or UART. These libraries power thousands of DIY RFID projects and are the foundation of low-cost RFID prototyping.

• MFRC522 module on Raspberry Pi. The RC522 module (NXP MFRC522 chip on a breakout board, under US$5 on AliExpress) reads MIFARE Classic and NTAG tags at close range over SPI. Python library `mfrc522` (https://github.com/pimylifeup/MFRC522-python) provides tag UID reading, MIFARE Classic authenticate/read/write and NTAG basic interactions. A working RFID door-lock or presence-detection prototype takes an afternoon.
• PN532 module — the NXP PN532 is a more capable NFC transceiver than MFRC522, supporting NFC Forum Type 1-5 tags, card emulation and peer-to-peer. Python libraries include `Adafruit-CircuitPython-PN532` (for CircuitPython on RP2040, ESP32) and `py532lib` (for Raspberry Pi Linux). PN532 is the preferred chip for NFC-focused embedded projects because of its richer feature set.
• CircuitPython NFC: Adafruit's CircuitPython ecosystem supports NFC development on microcontroller boards (RP2040, ESP32, nRF52, SAMD51). Libraries `adafruit_pn532` and `adafruit_st25dv` give embedded Python developers NDEF-level APIs on constrained hardware. Useful for battery-powered NFC peripherals, wearable NFC devices and educational workshops.
• Raspberry Pi RFID project patterns. Access control (RFID-triggered door lock via relay), attendance tracking (log tag UIDs to SQLite, export to CSV), inventory prototyping (scan-and-count with ~1 meter range limitation), museum kiosks (tap a tag, display content), learning-language flashcards (tag-triggered audio), home automation (tag-triggered HomeAssistant scenes via MQTT publish).
• Limitations of MFRC522/PN532 for UHF. These chips are 13.56 MHz HF/NFC readers and cannot read UHF RFID. For UHF (860-960 MHz) on Raspberry Pi, options include USB UHF readers with serial protocols (Chafon CF-RU5106, Yanzeo R784) accessed via pyserial, or small-form-factor UHF modules (M6e-Nano from ThingMagic, Chainway R4 Lite) with their own Python SDKs.
• Hardware integration tips: antennas matter: MFRC522 reads only within ~1-3 cm, PN532 up to ~5-8 cm, so positioning is critical. Power supply stability matters for reliable reads (noisy USB power on Pi can cause intermittent failures). SPI bus speed affects read latency. Libraries handle most of this but project debugging often reduces to electrical hardware issues rather than software.

UHF RFID with sllurp, python-mercuryapi and vendor SDKs

For UHF RFID (the 860-960 MHz enterprise and industrial frequency band used for retail apparel, pallet-level logistics, manufacturing and warehouse inventory) Python libraries talk to fixed readers over TCP/IP (LLRP) or to specialized readers over vendor-specific SDKs. This section covers the Python UHF stack.

• sllurp: the premier Python LLRP client (https://github.com/sllurp/sllurp). Implements the LLRP binary protocol over TCP, connecting to Impinj Speedway, Zebra FX7500/FX9600, ThingMagic Sargas and any LLRP-compliant reader. Supports full ROSpec/AccessSpec lifecycle, report callbacks, tag filtering and reader configuration. Install via `pip install sllurp`. Connecting to a reader and streaming tag reads is under 30 lines of Python.
• python-mercuryapi: Python wrapper for JADAK/ThingMagic Mercury API, supporting M6e, Nano, Sargas, Izar and embedded modules. Not a pure-Python library (it's a binding to ThingMagic's native library) but provides full Mercury API feature access including multi-protocol support (Gen2, ISO 18000-6B, ISO 11784/85) and ThingMagic-specific features (TMR transponder counting, region-of-interest commands). Useful when the Mercury API features outweigh the pure-Python preference.
• Impinj Octane SDK Python bindings. Community-maintained Python bindings for Impinj Octane SDK; official Python support is limited. For Impinj-specific features (Autopilot, chip-model-specific behavior, IoT Interface / MQTT), the official Java/C# SDKs are more mature. Python integration typically routes through sllurp or via Impinj's REST/MQTT API on R700/R720 smart readers.
• Chainway handheld Android-Python bridges. Chainway UHF handheld readers run Android with Java/Kotlin SDKs. For Python projects on handhelds, developers typically use pyjnius or similar bridges to invoke the Chainway Java SDK from Python running on the handheld. Alternatively, the handheld can publish tag events over TCP/WebSocket to a Python server.
• Serial UHF readers: budget Chinese UHF readers (Chafon, Yanzeo, JLT) use proprietary serial command protocols over USB or RS-232. Community Python libraries (`uhf-rfid`, `chafon-reader-python`) abstract these protocols; pyserial handles the raw serial layer. Useful for low-cost UHF prototyping but with limited feature depth compared to LLRP-based readers.
• REST/MQTT UHF integration. Modern smart readers (Impinj R700/R720, Zebra FXR90 with recent firmware) publish tag events over MQTT and expose configuration via REST. Python integration uses paho-mqtt for MQTT subscription and requests for REST configuration, bypassing LLRP entirely. This is the preferred pattern for cloud-native UHF RFID architectures in 2024-2026.
• RAIN Communication Interface (RCI). The RAIN Alliance maintains the RAIN Communication Interface Guideline as a vendor-neutral simplified-command surface for RAIN UHF readers. The current published version is RCI v4 (released under Apache License 2.0 on the RAIN Alliance site), with crypto and sensor support and multi-tag detection added; v5 is in active development. RCI is positioned as a complement to LLRP rather than a replacement and is implemented in Python today via reader-vendor SDKs that wrap RCI behind their own clients (JADAK, others). Treat any 'RCI is the new LLRP' marketing claim sceptically and verify which RCI version a specific reader firmware actually implements before committing to it as the primary control plane.
• Performance envelope: sllurp on a modern x86 server sustains 3,000-6,000 tag reads per second per reader before the Python GIL becomes the bottleneck. For higher throughput, split reader callbacks into a C extension (Cython) or move tag filtering to the reader (ROSpec `C1G2TagInventoryMask`) so Python only sees unique, filtered reads. Impinj's ItemSense and Zebra's FX Connect do reader-side filtering; RAIN Alliance RCI exposes similar capabilities as a vendor-neutral guideline.

Low-level NFC control with libnfc bindings and custom protocol work

For projects that need lower-level NFC control than nfcpy provides (research into NFC air-interface timing, MIFARE Classic key recovery, custom NFC Forum protocol extensions, or access to hardware features nfcpy doesn't expose) libnfc and its Python bindings are the next layer of abstraction.

• libnfc C library: mature open-source C library (http://www.libnfc.org) providing low-level NFC-A / NFC-B / NFC-F / ISO 15693 control. Supports a wide range of USB, serial and custom-interfaced NFC readers. More powerful than nfcpy but also more complex, with a lower-level API.
• Python bindings: `pyscard-libnfc`, `libnfc-python`, and custom ctypes wrappers give Python access to libnfc. Use when nfcpy doesn't expose the feature you need: raw polling configurations, custom modulation timing, proprietary chip command sets, or unusual reader hardware.
• MIFARE Classic research: libnfc's nfc-mfclassic and related tools are widely used in MIFARE Classic research (Crypto1 weakness demonstration, key recovery, cloning). Python bindings give researchers scripting access to these capabilities. Legally, MIFARE Classic programming is generally allowed for owned-credential research; be careful about systems you don't own (public transit systems, others' access control).
• Custom protocol development: for NFC Forum protocol extensions, new tag types, or protocol-layer research, libnfc's low-level APIs let Python scripts generate custom NFC modulation sequences and parse responses. Useful in academic RFID security research and vendor-specific protocol reverse engineering.
• Embedded Linux integration: libnfc runs on Raspberry Pi and embedded Linux platforms, providing a consistent API across desktop and embedded targets. Python projects can deploy from Mac/Linux development machines to Pi-based production devices using the same libnfc-based code.
• When to choose libnfc over nfcpy. (1) you need access to reader-specific low-level features, (2) you're doing NFC research requiring deep protocol access, (3) you need to support an unusual NFC reader not in nfcpy's driver list, (4) you're integrating with existing C/C++ NFC codebases. For standard NDEF read/write development, nfcpy is easier and more Pythonic; libnfc is the power-user option.

Code patterns and project architecture for production Python RFID systems

Python is excellent for RFID prototyping but deploying RFID-driven systems to production requires attention to concurrency, reliability and operational concerns that go beyond basic library usage. This section covers the patterns that take Python RFID projects from demo to production.

• Asynchronous tag processing: for event-driven patterns (sllurp callbacks, MQTT subscriptions, nfcpy connect loops), use asyncio or threading to decouple tag processing from I/O. A typical architecture: a reader thread receives tag events, a bounded queue buffers events, a processing thread (or asyncio task) handles business logic and persistence. This scales to 500-2000 events per second on commodity hardware.
• Retry and reconnection logic. Readers disconnect (network partition, reader restart, firmware update), tags drop out of the field, and transient errors are common. Production Python RFID code wraps reader connections in retry loops with exponential backoff, uses supervisor patterns (e.g., systemd service with Restart=always) and logs disconnection events for operations teams.
• Tag deduplication and rate-limiting. The same tag often appears in many consecutive reads. Application logic typically filters to "first read in a window" (e.g., first read per tag per 10 seconds) or "persistence-in-zone detected" (tag seen for N consecutive reads before event fires). This reduces downstream processing load and handles noisy RF environments naturally.
• Persistence and queue durability. Persist tag events to a durable store (SQLite for small projects, PostgreSQL / MongoDB for mid-scale, Kafka / Kinesis for cloud-scale) before acknowledging to the reader. This survives application crashes and enables replay / reconciliation. For edge deployments, local SQLite with periodic cloud sync is a common pattern.
• Secrets and credential management. Reader credentials, TLS certificates, cloud-service API keys must not be hardcoded. Use environment variables, .env files (excluded from git), HashiCorp Vault or cloud-provider secret managers (AWS Secrets Manager, Azure Key Vault). Python's `python-dotenv` and `python-keyring` simplify local dev; cloud SDKs handle production.
• Logging, monitoring and observability. Structured logging (structlog, loguru) with tag events, reader status and errors feeds monitoring platforms (Prometheus, Grafana, Datadog, Splunk). Per-reader metrics (read rate, error rate, uptime) and per-tag-pattern metrics (unique tags per minute, duplicate rate) help operations teams detect issues proactively. Opentelemetry is useful for distributed tracing across RFID event pipelines.
• Testing RFID code without hardware. Unit tests mock the reader library (sllurp, nfcpy) to verify application logic without physical hardware. Integration tests run against a physical reader in a test environment. Fixtures generating synthetic tag event streams enable load testing and edge-case validation. Proud Tek can provide Python-friendly sample tag fixtures for customers building test infrastructure.

Concrete Python code snippets — copy-paste starting points

The fastest way to onboard onto any of these libraries is to start from a working end-to-end script and modify it. This section collects the minimum-viable Python snippets for the most common RFID tasks (NFC tag reading/writing with nfcpy, LLRP tag streaming with sllurp, MIFARE DESFire APDU exchange with pyscard, and MFRC522 on Raspberry Pi) as copy-paste starting points.

• nfcpy: NDEF read (tag UID + URL record): `import nfc; import ndef; def on_connect(tag): print('UID:', tag.identifier.hex()); if tag.ndef: [print(r) for r in tag.ndef.records]; return True; with nfc.ContactlessFrontend('usb') as clf: clf.connect(rdwr={'on-connect': on_connect})`. Run it, tap an NTAG, the script prints the UID and any NDEF records. Swap `'usb'` for `'tty:/dev/ttyUSB0'` for serial readers.
• nfcpy: NDEF URL write: `import nfc; import ndef; def on_connect(tag): record = ndef.UriRecord('https://proudtek.com/tag/abc123'); tag.ndef.records = [record]; print('Written'); return True; with nfc.ContactlessFrontend('usb') as clf: clf.connect(rdwr={'on-connect': on_connect})`. Tap a writable NTAG; the on_connect callback assigns a new record list which nfcpy writes on session close.
• sllurp: stream tag reads from an LLRP reader: `from sllurp.llrp import LLRPReaderConfig, LLRPReaderClient, LLRP_DEFAULT_PORT; config = LLRPReaderConfig({'antennas':[1,2,3,4],'tx_power':0,'report_every_n_tags':1,'tag_content_selector':{'EnableROSpecID':False,'EnableSpecIndex':False,'EnableInventoryParameterSpecID':False,'EnableAntennaID':True,'EnableChannelIndex':False,'EnablePeakRSSI':True,'EnableFirstSeenTimestamp':True,'EnableLastSeenTimestamp':True,'EnableTagSeenCount':True,'EnableAccessSpecID':False}}); client = LLRPReaderClient('192.168.1.50', LLRP_DEFAULT_PORT, config); client.add_tag_report_callback(lambda reader, tags: [print(t['EPC-96'].hex(), t['PeakRSSI']) for t in tags]); client.connect()`. The keys above are exactly the ones documented in the sllurp README; TID and User-memory reads require a separate AccessSpec C1G2Read OpSpec, not a tag_content_selector flag.
• pyscard: MIFARE DESFire Select Application APDU: `from smartcard.System import readers; r = readers()[0].createConnection(); r.connect(); SELECT_AID = [0x90, 0x5A, 0x00, 0x00, 0x03, 0x33, 0x22, 0x11, 0x00]; resp, sw1, sw2 = r.transmit(SELECT_AID); print(f'{sw1:02X}{sw2:02X}', bytes(resp).hex()); assert (sw1, sw2) == (0x91, 0x00)`. Status word 0x9100 confirms the application selected; further APDUs (AuthenticateEV2First 0x71, ReadData 0xAD) follow the same pattern.
• pyscard: MIFARE Classic read block 4 with default key: `AUTH = [0xFF, 0x86, 0x00, 0x00, 0x05, 0x01, 0x00, 0x04, 0x60, 0x00]; LOAD_KEY = [0xFF, 0x82, 0x00, 0x00, 0x06] + [0xFF]*6; READ = [0xFF, 0xB0, 0x00, 0x04, 0x10]; r.transmit(LOAD_KEY); r.transmit(AUTH); data, sw1, sw2 = r.transmit(READ); print(bytes(data).hex())`. ACR122U pseudo-APDU set. Other readers use slightly different command prefixes.
• MFRC522 on Raspberry Pi. Read UID: `from mfrc522 import SimpleMFRC522; reader = SimpleMFRC522(); id, text = reader.read(); print('UID:', id, 'Text:', text)`. Wire MFRC522 module: SDA→GPIO8(CE0), SCK→GPIO11, MOSI→GPIO10, MISO→GPIO9, IRQ→unused, GND→GND, RST→GPIO25, 3.3V→3.3V. Enable SPI in raspi-config; install with `pip install mfrc522 spidev RPi.GPIO`.
• Asyncio wrapper for event-driven nfcpy. Wrapping nfcpy's synchronous `clf.connect()` in asyncio uses `loop.run_in_executor(None, clf.connect, ...)`. A production pattern: a reader coroutine pushes tag events into an `asyncio.Queue`, multiple consumer coroutines (database writer, webhook poster, logger) process events concurrently. Handles 500-2000 events/sec on a Raspberry Pi 4, 5000+/sec on a modern x86 server.
• Testing without hardware: mock nfcpy/sllurp/pyscard in pytest using `unittest.mock.patch`: `with patch('nfc.ContactlessFrontend') as mock_clf: mock_clf.return_value.connect.side_effect = lambda **kwargs: kwargs['rdwr']['on-connect'](MagicMock(identifier=b'\x04\x12\x34', ndef=MagicMock(records=[ndef.UriRecord('https://x.com')])))`. Pair with a synthetic tag-event generator that replays recorded captures during CI runs.

Proud Tek Python-developer sample kits and production tag supply

Python developers building RFID projects need tags that work cleanly with their library of choice: standard-compliant chips, well-documented memory layouts, and sample content suited to library testing. Proud Tek's developer sample kits and production tag supply are designed to fit into Python workflows from prototype through production.

• Python-developer sample kits. Assorted NFC stickers (NTAG 213/215/216), MIFARE cards (Classic 1K, DESFire EV3), ISO 15693 tags (ICODE SLIX) and UHF RFID inlays (Impinj Monza or M700-series). Typical kit: 50-200 tags across chip families, shipped with a TID-to-EPC mapping CSV for UHF tags and chip-family documentation (memory maps, default keys, NDEF pre-encoding status).
• Pre-encoded sample tags. For customers whose Python projects will parse specific NDEF content patterns (URL redirects, vCards, custom MIME types, GS1 EPC schemes), Proud Tek can pre-encode sample tags at production time with the target content. Developers can then skip the encoding step during prototyping and focus on read-path library work.
• TID-to-EPC mapping files. UHF RFID production runs include a CSV mapping chip TID (unique manufactured serial) to encoded EPC, which imports directly into sllurp tag-dictionary initialization, Impinj Octane tag databases or custom Python tag-resolution caches. Eliminates the need for customers to run encoding-verification passes during development.
• Volume scaling: Python-developer pilots typically start with 100-500 tags per chip family; production scales to 10k-1M+ tags depending on use case. Proud Tek's production capacity spans small batches for makers and research through enterprise-scale runs for consumer marketing programmes. Per-unit pricing improves significantly above 10k units per chip family.
• Chip-family selection advice. NTAG 213 is the default for general Python NFC development (cheapest, most universal); NTAG 216 for larger-memory projects; NTAG 424 DNA for authentication research; MIFARE Classic for access-control prototyping (aware of Crypto1 vulnerabilities); DESFire EV3 for modern encrypted access; Impinj M700 for UHF-library development. Proud Tek's application-engineering team advises on chip selection based on the specific Python library and use case.
• Community and open-source support. Proud Tek maintains technical documentation covering chip memory maps, default MIFARE Classic keys (for developers recovering community-known keys to read unlocked tags), NTAG counter behavior and UHF filter-value assignments. Documentation is designed to import cleanly into Python project READMEs and test fixtures. For researchers and educators, we provide documentation use under fair-use terms for open-source RFID projects.
• Engagement for production transitions. Python projects that outgrow prototyping phase often need a scaled tag-supply plan, per-tag unique encoding, production QA processes and chip-family decisions that affect multi-year TCO. Proud Tek's engagement model handles this transition: technical discovery call, sample-kit evaluation, pre-production encoding specification, small production run (1k-10k units) for pilot, full production (10k-1M+) once pilot passes, with ongoing supply matched to customer forecasting.
• Shipping and lead times. Sample kits ship from Shenzhen via DHL/FedEx express, typically landing in US/EU within 5-7 business days after payment confirmation. Production runs (10k-1M+) run 3-5 weeks lead time depending on chip availability (Impinj M700 chips have tight supply in 2025-2026; NTAG 213/215/216 are readily available). Pre-encoding adds 1-2 weeks per million tags when per-tag unique URLs or EPCs are required. Proud Tek can also dropship from US or EU warehouses for customers who need faster delivery and can commit to a consolidated forecast.

Debugging and common gotchas — Python RFID project failure modes

Python RFID projects fail in recognizable ways, and the failure is almost never where you first look. You will suspect the library; it will turn out to be a USB permission, a detuned antenna, or a tag lying too flat against the coil. Most failures are hardware or configuration issues rather than library bugs. This section collects the most common debugging scenarios and their resolutions, based on the issues we see most often in customer pilot programmes.

• Reader not detected: on Linux, check `lsusb` for the reader's USB ID; if present but inaccessible, add a udev rule granting user access (e.g., `SUBSYSTEM=="usb",ATTRS{idVendor}=="072f",ATTRS{idProduct}=="2200",MODE="0666"` for ACR122U) and `udevadm control --reload-rules`. On macOS, no permissions issue but the reader must not be claimed by another process (macOS's built-in CCID driver can intercept PC/SC readers. Kext override may be needed). On Windows, use Zadig to install WinUSB for nfcpy, or leave stock ACS drivers for pyscard.
• Intermittent read failures at close range. Counterintuitive but common: placing the tag directly on the reader coil can cause the antenna to detune and reads fail. Move the tag 3-10 mm above the coil surface. Metal surfaces near the coil also detune; use on-metal-rated tags (ferrite-backed) for metal-heavy deployments.
• MIFARE Classic authentication fails with default key. The chip has been written with custom sector keys. Try keys in order: FFFFFFFFFFFF (factory blank), A0A1A2A3A4A5 (NFC Forum MAD sector), 000000000000 (sometimes used). For sectors still failing, either the keys are truly custom (out of scope for ethical recovery) or the tag is locked. Do not attempt to brute-force keys on tags you don't own.
• UHF tag reads drop off at expected range. Antenna polarization mismatch is the most common cause. Linear-polarized antennas need the tag parallel to the antenna's E-field direction; circular-polarized antennas are more tolerant but have ~3 dB lower effective radiated power. Check antenna datasheet for polarization and cable loss; a 6 m coax run can lose 2-3 dB at 915 MHz.
• sllurp disconnects after N minutes. LLRP readers have KeepAlive timers; Impinj defaults to 10-second intervals. If your Python script doesn't handle KeepAliveAck, the reader closes the connection. sllurp handles this automatically if you use `LLRPReaderClient` with default settings, but custom ROSpec configurations may override the KeepAlive behavior. Verify in ROSpec XML.
• NDEF parsing errors on valid-looking tags. NTAG chips ship with OTP (one-time programmable) lock bits set to factory state, but some pre-encoded tags have proprietary TLVs before the NDEF TLV (e.g., Lock TLV 0x01, Memory TLV 0x02). nfcpy's default parser handles standard TLVs but custom TLVs may confuse it. Read the raw memory with `tag.read(page)` to diagnose.

FAQ