The ERP2 protocol is designed to transfer information between EnOcean devices using the radio interface.
More information about the ERP2 can be found in the EnOcean Radio Protocol.pdf, see References.

Telegram received/sent from the AIR are encapsulated according to the EnOcean Radio Protocol. For easier handling/accessing of radio telegrams the Dolphin API uses one orthogonal data structure for all telegram types.

ERP2 telegram structure

A radio telegram contains the following fields:

1 byte LENGTH - Indicates the amount of bytes of the telegram, not including the length itself
1 byte HEADER - Bits 7..5: ORIGINTATOR-ID/DESTINATION-ID length. Bit4: Presence of extended header field. Bits 3..0: R-ORG code
(optional) 1 byte EXTENDED HEADER. Bits 7..4: Repeater counter Bits 3..0: Length of optional data.
(optional) 1 byte EXTENDED TELEGRAM TYPE. Indicate R-ORGs above the codes in HEADER. Present if HEADER field bits 3..0 are 1111
X bytes ORIGINATOR-ID. Sender ID
(optional) X bytes DESTINATION-ID. Receiver to whom the telegram is intended.
X bytes DATA - Telegram payload.
(optional) X bytes OPTIONAL DATA - Optional information related the telegram itself
1 byte CRC - controlling checksum

Note:: The DATA + OPTIONAL DATA fields can transport a maximum of 36 bytes for telegrams without DESTINATION-ID. For telegrams with DESTINATION-ID the maximum DATA + OPTIONAL DATA length is 32 bytes. If the application requires the sending of longer information, then two or more telegrams must be used.; Telegrams that don't include DESTINATION-ID are considered to be broadcasts. To send a telegram to a specific device write the value of that device in the DESTINATION-ID field.; The CRC is handled internally by the API functions. The application does not have to calculate the CRC.; Secure telegrams are covered under Security; For more information how the repeater works see Repeater.