PROT-ADDR-CMD-REP-BITS format in OpenBK7231T, Tasmota, ESPHome, Arduino IRremote, LIRC explained

User question

PROT-ADDR-CMD-REP-BITS

Artificial Intelligence Response

Direct answer to the question

• “PROT-ADDR-CMD-REP-BITS” is a five-field mnemonic that describes every item you must supply (or extract) when encoding or decoding an Infra-Red (IR) remote-control frame.
• Key points:
  • PROT – the IR protocol (NEC, Sony SIRC, RC5, etc.).
  • ADDR – the device address (system / sub-device).
  • CMD – the function code (power, volume-up …).
  • REP – repeat indicator / repeat count for long key-presses.
  • BITS – number of data bits in the payload (or entire frame, protocol-dependent).

Detailed problem analysis

1. Field-by-field breakdown
   • PROT (Protocol)
   – Defines carrier frequency (typically 36–40 kHz), mark/space timings, frame layout, bit encoding (PWM, bi-phase, etc.).
   – Example tables:
   ‑ NEC: 38 kHz, pulse-distance, 32 data bits.
   ‑ Sony SIRC: 40 kHz, PWM, 12/15/20 bits.
   ‑ RC5: 36 kHz, Manchester, 14 bits incl. toggle.

   • ADDR (Address)
   – Identifies the target appliance or product family.
   – Size varies (e.g. 5 bits in RC5, 8 bits + inverse in NEC, 16 bits in Samsung).

   • CMD (Command)
   – Encodes the user function. Same bit-width rules as ADDR.
   – Often followed by its 1-complement (NEC, Samsung) or protected by a toggle bit (RC5/RC6).

   • REP (Repeat)
   – Boolean or counter.
   – Most consumer remotes send one full frame, then – while the key is held – a protocol-defined repeat frame every 108 ms (NEC) or 45 ms (Sony).
   – Libraries expose this as “numberOfRepeats” (IRremote 4.x) or a dedicated “sendRepeat” method.

   • BITS (Bit count)
   – Tells the encoder/decoder how many payload bits to expect so that the frame can be packed correctly.
   – Mandatory for variable-length protocols (Sony, Pronto, Kaseikyo).

2. How libraries map the mnemonic

Environment	Typical call	Mapping to PROT-ADDR-CMD-REP-BITS
Arduino IRremote ≥4.0	irsend.sendNEC(addr, cmd, reps);	PROT = NEC; ADDR = addr; CMD = cmd; REP = reps; BITS implicit (32)
ESPHome	remote_transmitter.transmit_nec:	YAML keys address, command, repeat; bit length inferred
Linux LIRC / irsend	button entry in lircd.conf	Protocol section sets PROT/BITS; 0xAA55 etc. encodes ADDR+CMD; repeats handled by driver
OpenBK/Tasmota “IRSend”	IRSend <proto> <hexvalue> <bits> [reps]	First token = PROT, second token is ADDR + CMD packed, third token = BITS, optional REP

3. Typical frame composition examples

NEC standard (32 bits):

[ADDR 8][~ADDR 8][CMD 8][~CMD 8]

Sony 15-bit:

[CMD 7][ADDR 8]

RC6‐0‐16 (Philips):

[Leader][Start 1][Mode 3][Trailer 1][Toggle 1][ADDR 8][CMD 8]

Current information and trends

• Library evolution: Arduino-IRremote 4.3+ now offers per-protocol convenience wrappers; no need to hand-compose 32-bit words anymore.
• Home-automation firmware (Tasmota 14, ESPHome 2024.5) automatically learns and stores PROT/ADDR/CMD, exposing them via MQTT/HA.
• Consumer devices are slowly transitioning to CEC over HDMI or RF4CE/BLE, but IR with the above structure remains ubiquitous, especially for cost-sensitive appliances.

Supporting explanations and details

Practical capture-and-replay workflow:

1. Attach TSOP48xx (demodulated IR receiver) to MCU.
2. Run a “dump” sketch (e.g., IRrecvDumpV2). You will see a line such as
   Protocol=NEC, Address=0x20DF, Command=0x10EF, Bits=32.
3. Map to mnemonic: PROT=NEC, ADDR=0x20DF, CMD=0x10EF, REP=0, BITS=32.
4. Re-emit with irsend.sendNEC(0x20DF, 0x10EF, 0);

Repeat frames: For a held key you can do:

irsend.sendNEC(0x20DF, 0x10EF, 0); // initial
delay(110);
irsend.sendNEC(0, 0, 1); // NEC repeat code – only header & gap

Ethical and legal aspects

• Most IR command sets are not proprietary secrets, but some manufacturers treat the codes as part of their intellectual property. Use for personal integration is normally tolerated; redistribute only where licences allow.
• Avoid blasting high-power IR LEDs directly into people’s eyes; adhere to IEC 60825 safety limits.
• Never automate critical medical or security devices without fail-safe interlocks; IR is open-air and spoofable.

Practical guidelines

• Verify carrier frequency: mismatched frequencies (>2 kHz error) drop range dramatically.
• Keep LED current pulses <100 mA (20–25 mA average) and limit duty cycle to <35 %.
• Always measure bursts with an IR demodulator, not a bare photodiode, to include AGC behaviours.
• In LIRC, ensure flags SPACE_ENC|CONST_LENGTH match the selected PROT.

Possible disclaimers or additional notes

• Some protocols (Denon, Kaseikyo/Panasonic) embed address bits inside what libraries call “command” – consult datasheets.
• Air-conditioning remotes send state-frames >100 bits; they still map logically to PROT-ADDR-CMD-BITS but often have no concept of “repeat”.
• Certain modern TVs use encrypted or rolling codes over IR; not reproducible with hobby libraries.

Suggestions for further research

• Study the UEI (Universal Electronics) “EFC” conversion tables; they present an alternative mnemonic (Setup-Device-OBC).
• Investigate RF4CE and BLE-HID replacements; understand how address/command fields migrate to higher-layer packets.
• Analyse AGC behaviour of modern IR receivers versus legacy modules; optimise mark/space tolerances.

Brief summary

“PROT-ADDR-CMD-REP-BITS” is simply a compact way to list the five critical parameters that define an IR remote-control frame: which protocol, which device, what action, how many repeats, and how many bits. Knowing this structure lets engineers capture, document, and faithfully reproduce virtually any IR command using Arduino IRremote, ESPHome, LIRC, or similar tool-chains, while recognising protocol-specific nuances such as inverted bytes or toggle bits.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.