Feature/lf: add IDTECK PSK1 tag emulation and T55xx clone

[matteoscrugli]

lf: add IDTECK PSK1 tag emulation and T55xx clone

TL;DR

This PR adds IDTECK (a 125kHz PSK1 card format) to the supported LF protocols, covering tag emulation and T55xx cloning. Tested end-to-end against a real IDTECK reader.

Why this was worth implementing

The Chameleon Ultra already supports a handful of LF protocols (EM410x, HID Prox, ioProx, Viking, PAC), all of them ASK or FSK modulations. IDTECK belongs to the PSK1 family, which on first inspection seemed out of reach: the firmware comment in lf_sense_enable noted that the tag-mode antenna taps are envelope-only, which rules out carrier phase-lock and makes coherent demodulation (the approach Proxmark3 uses) unavailable.

The insight that made this PR possible: PSK1 in practice is a differential encoding. What the reader decodes are 180° phase transitions between consecutive bits, not absolute phase. Other LF tooling (Flipper Zero, for example) chooses to phase-lock anyway for deterministic bit timing, typically by clocking a timer off the reader's carrier via a GPIO, a solution that presupposes a dedicated carrier-sense pin. The Chameleon Ultra's tag-mode front-end does not expose such a tap to the MCU, so that path isn't available; but given that PSK1 is differential, strict phase-lock turns out to be a convenience rather than a requirement. A free-running subcarrier generated from HFXO (±40 ppm) stays well within the PLL tolerance of consumer-grade readers, because the drift between one bit and the next is below 3°.

In other words: we can emit PSK1 from the same LF_MOD → load-modulation path the Chameleon already uses for FSK protocols, by simply flipping the PWM polarity at bit transitions, with no carrier sync, no active RF driving, and no hardware modifications.

What this PR does

Shared PSK1 helper in utils/psk1.{c,h}

The subcarrier generator is factored into a reusable helper: given a frame (MSB-first bytes) and a bit count, it fills a nrf_pwm_values_wave_form_t buffer with PSK1-encoded entries. The helper lives in utils/psk1.{c,h} so future PSK1 protocols (Indala, Keri, NexWatch, ...) can plug in without reimplementing the timing and differential-encoding logic.

PWM base clock selector

The 16µs subcarrier period (carrier/2 = 62.5 kHz) requires a counter_top below 3 at the legacy 125kHz PWM base used by ASK/FSK protocols, which is out of spec for the nRF52 PWM peripheral. Rather than rescaling every existing protocol, pwm_init now selects the base clock from the currently-loaded tag type:

cfg.base_clock = IS_PSK1_TYPE(m_tag_type) ? NRF_PWM_CLK_1MHz : NRF_PWM_CLK_125kHz;

IS_PSK1_TYPE() is a macro in tag_base_type.h; today it matches only TAG_TYPE_IDTECK, but extends trivially to other PSK1 types in future PRs. Legacy protocols are untouched, so there is zero regression risk on EM410x, HID Prox, ioProx, Viking, PAC.

The comment in lf_sense_enable that previously implied PSK was out of reach is updated to reflect the actual constraint (no coherent demod) without overstating the limit for differential encodings.

IDTECK protocol in protocols/idteck.{c,h}

The IDTECK frame layout (32-bit fixed preamble 0x4944544B "IDTK" + 32-bit card payload consisting of a checksum byte and a byte-reversed 24-bit card number) matches what the Proxmark3 client expects, so we emit byte-for-byte what cmdlfidteck.c decodes. The idteck_t55xx_writer produces the block layout for cloning onto a T55xx tag using T5577_MODULATION_PSK1 | T5577_BITRATE_RF_32.

Command layer and CLI

Three new DATA_CMD_* codes, three firmware handlers, and CLI commands:

Command	Effect
lf idteck econfig -s <slot> --id <hex>	Set the emulated 64-bit frame on a slot
lf idteck econfig -s <slot>	Read it back, showing preamble, payload, decoded card number and checksum status
lf idteck write --id <hex>	Clone the frame to a T55xx tag in reader mode
lf clone -t idteck --id <hex>	Same write via the unified clone command
hw slot list	Now renders Frame: and Card ID: lines for IDTECK slots

The --id argument accepts either 16 hex characters (the full 64-bit frame) or 8 hex (the 32-bit payload, with the preamble auto-prepended for the user's convenience).

The CLI emits a non-blocking informational note when the payload checksum does not match the value computed from the card number, since some readers validate it and some do not. This turns out to matter for a common variant of IDTECK cards in the wild whose checksum byte differs from the simple sum-of-bytes formula.

As with the other per-protocol T55xx writers (write_em410x_to_t55xx, write_hidprox_to_t55xx, etc.), write_idteck_to_t55xx lives in lf_reader_main.c and is therefore only compiled on Chameleon Ultra; the corresponding cmd_processor_idteck_write_to_t55xx is wrapped in #if defined(PROJECT_CHAMELEON_ULTRA) to match the existing convention. The IDTECK emulation path (set/get emu id, slot integration) is available on both Ultra and Lite.

Not included (intentionally)

• IDTECK read: the emulation ADC path samples at 125kHz after an envelope-detection analog front-end, which is insufficient for PSK demodulation via coherent sampling. A dedicated edge-timing decoder on LF_OA_OUT is feasible purely in software, reusing the GPIOTE+TIMER edge-capture infrastructure already in place for the Viking reader, not unlike what comparator-plus-input-capture LF tools do. It's left as a follow-up PR to keep review size manageable.
• Indala / Keri / NexWatch: the utils/psk1 helper and IS_PSK1_TYPE() macro are designed to absorb these with a one-file-per-protocol pattern, but adding them here would inflate the PR. Follow-up PRs, one per protocol.

How it was tested

• Emulation against a consumer IDTECK reader: the Chameleon was accepted cleanly, reader reacts identically to a real card.
• T55xx clone: a blank T5577 fob programmed via lf idteck write works on the same reader as expected.
• Non-regression on other LF protocols: before switching to IDTECK, other slots already configured with EM410x cards continued to work against their respective readers; cycling via the physical button between an IDTECK slot (1MHz PWM base) and legacy-protocol slots (125kHz PWM base) shows pwm_init correctly switches the base clock in both directions, with emulation of the pre-existing cards unchanged.
• Persistence: using hw dfu + a reflash of the same firmware image as a clean cold-boot proxy (FDS preserved), the slot configuration survives intact, with tag type, emulated frame and nick name all readable via lf idteck econfig after reboot.
• CLI edge cases: 8-hex and 16-hex inputs both work (with and without the auto-prepended preamble), malformed hex is rejected with a clean error, missing --id on write is caught by the required-argument validator, and checksum-mismatch frames still go through with a clear warning.
• Firmware builds clean at every commit on both targets: the split into 5 commits is bisectable; each step compiles to a working image in isolation on Chameleon Ultra and Lite alike.

Commit structure

Intentionally split into logical commits (same style as PR #367 for ioProx):

1. feat(lf): add shared PSK1 wave-form helper for tag emulation: the reusable subcarrier generator, alone. Compiles but has no caller yet.
2. feat(lf): add IDTECK tag emulation (PSK1 RF/32): the protocol file, the PWM base-clock switch, the tag-emulation handler map wiring, and the T5577 config constant.
3. feat(lf): integrate IDTECK into firmware command and T55xx write paths: DATA_CMD_*, app_cmd.c handlers, write_idteck_to_t55xx. After this the firmware is functional end-to-end from the host protocol point of view.
4. feat(cli): add lf idteck subgroup and extend lf clone with idteck type: the Python CLI layer and hw slot list rendering.
5. docs(changelog): add IDTECK LF protocol entry.

Happy to answer any questions during review, especially around the base-clock isolation choice and the decision to defer read support.

[github-actions]

Built artifacts for commit a30cabb

Firmware

• Ultra APP DFU Package
• Ultra binaries
• Lite APP DFU Package
• Lite binaries

Client

• Linux
• macOS
• Windows