Repository navigation
spec: chip count / chip index at page 0x0D byte 3 (v2.2) - #26
Merged
Merged
Conversation
The byte was reserved and always 0x00. It now carries the number of TigerTag chips on the spool (high nibble) and which one this chip is (low nibble), so a reader that scans one chip of a twin tag knows another chip is waiting and can collect its UID. 0x00 stays "unknown", so every chip already written remains valid.
This was referenced Oct 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Page
0x0D, byte 3 (offset+39) was reserved (0x00). It now tells a reader how many TigerTag chips the spool carries and which one it just read:0unknown ·1single chip ·2twin tag · …150unknown ·1first chip ·2second chip · …Examples:
0x00unknown ·0x11single chip ·0x21/0x22twin tag, chip 1 / 2.Why
The shared Timestamp (section 2.9) says which chips belong together, but not how many there are. With this byte, a reader that scans one chip of a twin-tagged spool knows another one is waiting and can ask for it to collect the missing UID; the index tells it whether it re-read the same chip or the other one.
Compatibility
0x00here → reads as "unknown", stays valid, no migration.0x0Dis written once at manufacturing (Color 2), unlike0x17which Tiger Scale rewrites — the value can't be clobbered by a scale firmware unaware of it.Changes
README.md: memory-map table, compact offset map, new section 2.11, cross-reference from 2.9, version history and badge → v2.2.llms.txt: version, offset map, short encoding note.assets/chip_layout.svg: thersvcell of page0x0Dbecomes Chips.Sample code/parse_tigertag.py: parses/writes the byte (chip_info,chip_count,chip_index), exposes it into_dict()and the summary. Round-trip tested for0x00,0x11,0x21,0x22.tools/docs_check.pypasses.Follow-ups (other repos)
+39as reserved.Images/TigerTag Mapping RFID NXP213.png(raster, not referenced by the README) still shows page0x0Dbyte 3 as reserved.