ERP 1 V1.

EnOcean Radio Protocol 1

November 9, 2020

EnOcean GmbH Phone +49.89.67 34 689-0 Subject to modifications

Kolpingring 18a Fax +49.89.67 34 689-50 EnOcean Radio Protocol 1 V1.2
82041 Oberhaching [email protected] November 9, 2020 8:45 AM
Germany www.enocean.com Page 1/16
SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

REVISION HISTORY
The following major modifications and improvements have been made to the first version of
this document:

No Major Changes
1.0 Document created
1.1 Renaming from ERP to ERP1
1.2 Added physical layer

Published by EnOcean GmbH, Kolpingring 18a, 82041 Oberhaching, Germany

www.enocean.com, [email protected], phone ++49 (89) 6734 6890

© EnOcean GmbH
All Rights Reserved

Important!

This information describes the type of component and shall not be considered as assured
characteristics. No responsibility is assumed for possible omissions or inaccuracies. Circuitry
and specifications are subject to change without notice. For the latest product specifica-
tions, refer to the EnOcean website: http://www.enocean.com.
As far as patents or other rights of third parties are concerned, liability is only assumed for
modules, not for the described applications, processes and circuits.
EnOcean does not assume responsibility for use of modules described and limits its liability
to the replacement of modules determined to be defective due to workmanship. Devices or
systems containing RF components must meet the essential requirements of the local legal
authorities.
The modules must not be used in any relation with equipment that supports, directly or
indirectly, human health or life or with applications that can result in danger for people,
animals or real value.
Components of the modules are considered and should be disposed of as hazardous waste.
Local government regulations are to be observed.
Packing: Please use the recycling operators known to you.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 2/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

TABLE OF CONTENT

1 Introduction.................................................................................................... 4
2 Data unit description ........................................................................................ 5
3 Layer 1 – physical layer .................................................................................... 6
1.1 Carrier Frequency.................................................................................... 6
1.2 TX power ............................................................................................... 6
1.3 Sensitivity .............................................................................................. 6
1.4 Modulation ............................................................................................. 7
1.5 Modulation Depth .................................................................................... 7
1.6 Data Rate .............................................................................................. 7
1.7 Coding/ Packet Length determination ......................................................... 7
1.8 Preamble ............................................................................................... 9
1.9 Start of Frame ........................................................................................ 9
1.10 duation of a bit ....................................................................................... 9
1.11 Pre Preamble Emission ........................................................................... 10
1.12 Complete Frame Example ....................................................................... 10
4 Layer 2 – data link layer ................................................................................. 11
4.1 Introduction ......................................................................................... 11
4.2 Subtelegram timing ............................................................................... 11
4.3 Data integrity ....................................................................................... 13
4.3.1 General ............................................................................................... 13
4.3.2 The 8 bit summation hash function algorithm ............................................. 13
4.3.3 The 8 bit Cyclic Redundancy Check (CRC) hash function algorithm ................ 13
4.4 Listen before talk .................................................................................. 14
4.4.1 General ............................................................................................... 14
5 Layer 3 – network layer .................................................................................. 14
5.1 Introduction ......................................................................................... 14
5.2 Repeater.............................................................................................. 14
5.2.1 General ............................................................................................... 14
5.2.2 Time response for collision avoidance ....................................................... 14
5.2.3 Bits of repeater level in the status byte ..................................................... 15
5.3 Addressing ........................................................................................... 15
5.3.1 General ............................................................................................... 15
5.3.2 Encapsulation ....................................................................................... 16

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 3/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

1 Introduction

This document is the cover document of EnOcean Radio Protocol (ERP). The follow-
ing table summarizes the ERP protocol in OSI layers. This document gives partial
information about the Physical Layer, Data Link Layer and Network Layer.

Layer Services Data Units

EnOcean Equipment Profiles (EEP)

Application (API) DATA
RPC/RMCC handling

Radio Telegram Processing

Presentation DATA
Encryption

Session --- not used --- --

Smart Ack TELEGRAM/

Transport
Remote Management MESSAGE

Addressing telegrams
(ADT Encapsulation/Decapsulation)
Network Switch telegram conversion TELEGRAM
(choice/status processing)
Repeating (status processing)

Subtelegram Structure
Control Sum Calculation
Data Link Layer SUBTELEGRAM
Subtelegram Timing
Listen before talk

Encoding/Decoding (inverse bits)

Physical BITS / FRAME
Radio reception/transmission

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 4/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

2 Data unit description

The communication protocol is packet based and the data units can be of three dif-
ferent types:

 Frame
 Subtelegram
 Telegram
A frame is the representation of the encoded data on the physical layer. It includes
control and synchronization information for the receiver. A frame is transmitted as a
bit by bit serial sequence. A subtelegram is the result of a decoding process, in
which this control (PRE, SOF, INV and EOF) and synchronization information are re-
moved from the frame. The reverse mechanism to get a frame from a subtelegram is
the encoding process.

The subtelegrams are handled in the data link layer. The ERP protocol is designed to
work mostly as a unidirectional protocol without handshaking. To ensure transmis-
sion reliability three identical subtelegrams are transmitted within a certain time
range. Each transmitted subtelegram is an atomic unit and contains all the infor-
mation the composed telegram contains. The data structure of a subtelegram is
shown in

Figure 1.

1 1…X 4 1 1 byte
RORG DATA TXID STATUS HASH

Figure 1 – Structure of a subtelegram

The universal fields are:

 RORG/CHOICE – identifies the subtelegram type

 DATA – the payload of the transmitted subtelegram
 TXID/SourceID – identifies the transmitter, each having a unique 4 byte identity
 STATUS – identifies if the subtelegram is transmitted from a repeater and
the type of integrity control mechanism used. This field is not present in a switch
telegram.
 HASH/Checksum – data integrity check value of all the bytes
 The length of the subtelegram is not transmitted in the subtelegram structure.
The length is determined by counting the number of bytes starting with RORG and
ending with HASH.
 The maximal valid total length for ERP1 telegrams is 21bytes.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 5/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

3 Layer 1 – physical layer

ERP1 was the first radio protocol developed by EnOcean back in 2001 and employed at
868.3MHz. 2012 it was recognized as standard Fehler! Verweisquelle konnte nicht ge-
funden werden..

These are the key parameter of the physical layer of the ERP1.

Parameter Min Typ Max Unit

Carrier Frequency 868.214 868.3 868.386 MHz
TX power 6 dBm
Sensitivity (@ 0.1% Packet Error Ra- -93 dBm
te)
Modulation ASK
Modulation Depth 20 36 dB
Data Rate 124.875 125 125.125 kbps
Coding 8/12
Packet length determination By EOF
Preamble 8 bit
Start of Frame (SOF) 4 bit
Duration of a Bit (measured 6dBc)1 7.5 8 8.5 µs
Pre Preamble Emission 8 48 µs

In the next chapters detailed explanations are given for the key parameters.

1.1 Carrier Frequency

A receiver must be able to receive transmitters that emit within the given frequency range.

1.2 TX power
A transmitter must be able to transmit at least 6dBm (up to 14dBm are allowed) and be
still compliant to the requirements of the EN300220 with a 0dBi antenna.
The following measurements shall be carried out with a pseudo random noise sequence
being permanently emitted. The limits for the emissions are:
 867.8…868.0MHz -30dBm with 1kHz Resolution Bandwidth (RBW)2
 868.6…868.8MHz -30dBm with 1kHz RBW
 867.6…867.8MHz -36dBm with 1kHz RBW
 868.8…869.0MHz -36dBm with 1kHz RBW
 867.0…867.6MHz -36dBm with 10kHz RBW
 869.0…869.6MHz -36dBm with 10kHz RBW
 862.0…867.0MHz -36dBm with 100kHz RBW
 869.6…974.6MHz -36dBm with 100kHz RBW
The TX power is the measured peak power of the transmission.

1.3 Sensitivity
The sensitivity shall be measured with typical transmitter parameters and a single packet
that contains 10 bytes of data. This is equivalent to one byte telegram type, 4 bytes ID, 4

1
This value includes data rate deviations
2
Video bandwidth shall be 3 times higher than resolution bandwidth.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 6/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

bytes data and one byte checksum. Only one of 1000 packets shall be lost at the sensitivity
limit.
Degradation of the sensitivity is allowed at minimum and maximum parameters.

1.4 Modulation
The modulations is ASK. OOK will not work due to bandwidth restrictions in the used chan-
nel.

1.5 Modulation Depth

The modulated signal must have modulation depth between the minimum and a maximum
modulation depth. This is due to AGC compatibility.
The following picture shows how modulation depth is measured.

20…
36d
B

1.6 Data Rate

Receivers must be able to tolerate up to 5% data rate tolerance in the received signal. This
is necessary to receive older transmitter.
If anyhow possible, new transmitter shall have significant lower data rate errors.

1.7 Coding/ Packet Length determination

The protocol is inverted on the air interface: A one is transmitted as low power a zero is
transmitted as high power.

The ERP1 used an 8 to 12 coding scheme. 8 bits are coded into 12 bits. This is mainly to
reduce the DC content of the transmitted signal.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 7/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 8/16

 SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

unencoded bit bit bit bit4 bit bit bit bit0

7 6 5 3 2 1
Descripti- Inver- Inver- Sync/EOF
on se se
encoded bit bit bit !bit5 bit bit bit !bit2 bit bit Syn !Syn
7 6 5 4 3 2 1 0 c c

The Sync/EOF field determines if another byte will follow. If the Sync-sequence is “01” an-
other byte will follow, if the Sync-sequence is “10” this was the last byte to be transmitted.
The Sync Sequence is called End of Frame (EOF) if it is “10”.

1.8 Preamble
The preamble length is 8 bits, starting with a one (10101010). Thus the first bit has low
power.

1.9 Start of Frame

The start of frame is 4 bits long. There are two variants deployed. Both variants shall be
recognized with the same receiver without reconfiguration.

4µs 8µs 12µs 16µs 20µs 24µs 28µs 32µs

Variant 13 1 0 1
Variant 2 1 0 1
New transmitters shall use variant 2 only.

1.10 duation of a bit

Please note that a receiver shall be able to receive transmitters that exceed this timing to a
certain amount4.

The following picture shows the transient emission of a transmitter. The bit timing shall be
measured at the locations given in this picture (6dBc).
The bit timing must not be exceeded!

3
Uses a Code violation
4
Recommendation: >±2µs

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 9/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

6dB

7.5… 7.5… 7.5… 7.5… 7.5…

8.5µ 8.5µ 8.5µ 8.5µ 8.5µ
s s s s s

1.11 Pre Preamble Emission

There must be an emission before the preamble. The power during this emission shall not
exceed the power of a “1”.

1.12 Complete Frame Example

With SOF variant 1:

With SOF variant 2:

Screenshot from spectrum analyzer in zero-span-mode:

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 10/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

4 Layer 2 – data link layer

4.1 Introduction
In the data link layer the transmitted data are one or more subtelegrams. The struc-
ture of a subtelegram is shown in 2.

4.2 Subtelegram timing

The subtelegram timing aims to avoid telegram collisions from different transmitters.
Each subtelegram is transmitted in a different time range. The limits of the subtele-
gram timing are determined by the TX and RX maturity times. The maturity times
specifies the length of the time range within which the transmission of all subtele-
grams has to be completed and received. The values of the TX and RX maturity
times are specified in Table 1 below.

A complete telegram consists of a maximum of 3 subtelegrams. The transmission of

the start of the first subtelegram and the end of the last subtelegram by the trans-
mitter shall not exceed the TX maturity time.

Repeaters have a different subtelegram timing range than the original transmitter.
For the receiver, the time between receiving the end of the first subtelegram re-
ceived and the end of the last subtelegram shall not exceed the RX maturity time
also when repeaters are involved.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 11/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

The LBT technique (see 4.4) makes it possible to avoid collision by controlling the
subtelegram transmission timing, but it cannot completely guarantee the avoidance
of a collision.

Table 1: Maturity time parameters

Description Parameter
Maximum TX maturity time 40 ms

RX maturity time 100 ms

To schedule the subtelegram transmission the TX maturity time is divided into 4

groups; each of them with 10 time slots of the size 1 ms. The numeration of the time
slots starts with 0 and ends with 39.

sd time ranges
Time ranges

1 2 3 4

ms 0 5 10 15 20 25 30 35 40

Figure 2 – TX Maturity Time divided into four 10 ms time ranges

These 4 ranges (see Figure 2) will be used for sending a maximum of 3 subtele-
grams. The scheduling determines in what range what subtelegram number is al-
lowed to be sent. To avoid collisions when using repeaters, the subtelegram timing
of original and repeated telegrams differs depending only on the status of the re-
peated subtelegram and not on the configured level of the repeater. Table 2 defines
in which time range, which is determined by the numbered time slots, each subtele-
gram may be transmitted.

Table 2: Allocation of time slots to the different subtelegrams

Status of telegram 1 st subtelegram 2 nd sub telegram 3 rd sub telegram

Original 0 1...9 20...39

Level 1 repeated 10...19 20...29

Level 2 repeated 0...9 20...29

All subtelegrams will be transmitted within these time ranges. A second or third sub-
telegram transmission may only start if the previous subtelegram transmission has
been completed. There is no specified minimum pause between subtelegrams. The
transmitter and repeater is free to use any time slot within each time range.

The transmission start of the first subtelegram of an original transmitter starts the
time counting for the transmitter. The completion of the first subtelegram received

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 12/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

(which due to disturbance is not always the first one from the transmitter) starts the
counting in the receiver or the repeater.

If the wireless channel is occupied by the transmission of other transmitters, the LBT
functionality can delay the transmission until the end of t he TX maturity time is
reached.

4.3 Data integrity

4.3.1 General
In order to check that a subtelegram has arrived intact, a hash of the telegram is calculated be-
fore transmission and attached to the subtelegram ( field HASH). The attached hash value is not
protected and thus only serves to detect transmission failures – not protection against malicious
intent. The verification is done by the device receiving the telegram, i.e. , a receiving device or a
repeater. There are two public algorithms. They are 8 bits long. One is summation based and
one uses an 8-bit long Cyclic Redundancy Check (CRC) algorithm.

If the verification of the intactness of the received subtelegram fails, the subtelegram is ignored.

The STATUS byte indicates which hash function is used. This is su mmarised in Table 3 below.

Table 3: Identification of the hash function used in the telegram

Characteristics Width Used by telegram types

8bit Checksum 8 bit any type of telegram when STATUS bit 27 = 0
8bit CRC 8 bit any type of telegram when STATUS bit 27 = 1

4.3.2 The 8 bit summation hash function algorithm

This clause describes the 8-bit checksum algorithm. The result of the calculation has the length
of 8 bits. It is calculated by the transmitter before transmission and by the receiver after receiv-
ing the subtelegram.

The algorithm is as follows:

 The sum of the value of each byte in the subtelegram except the hash value field is evaluat-
ed ignoring overflow, i.e. all bits beyond the byte are ignored. This one byte (8 bits) sum val-
ue is the hash of the 8-bit algorithm.
4.3.3 The 8 bit Cyclic Redundancy Check (CRC) hash function algorithm
This hash function is based on the Cyclic Redundancy Check alg orithm providing a hash value
of length one byte.

The algorithm starts with the first byte of the subtelegram (RORG) and calculates the remainder
of the division (modulo 2) by the generator polynomial x 8 + x 2 + x + 1 of the product x 8 multiplied
by the first byte of the subtelegram.

The result of this calculation is XORed with the next byte in the subtelegram and again the re-
mainder of the division is calculated as above.

This procedure is repeated until the last byte of the subtelegram excluding HASH is reached.
The remainder of the final division is used as hash value.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 13/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

4.4 Listen before talk

4.4.1 General
Listen before talk (LBT) is a technique used in wireless communications whereby a
wireless transmitter or repeater first senses its wireless environment before starting
a transmission. The aim is to avoid collisions with other senders. It is an optional
feature of the transmitting device.

Prior to transmitting a subtelegram, the transmitting device checks, whether there is

an ongoing transmission in the air. If this is the case the transmission is suspended
for the delay of a random time range. After this delay the transmitter check is re-
peated. If no ongoing telegram transmission is detected, the subtelegram is trans-
mitted. In case the calculated random delay would lead to the violation of the TX
maturity time, the subtelegram transmission is sent irrespective of any other trans-
missions.

It is recommended to implement and use LBT before each subtelegram transmission,

but it is not required. Some transmitting devices cannot support this feature as for
example self powered products.

5 Layer 3 – network layer

5.1 Introduction
Three aspects of the repeating and addressing is described in this section.

5.2 Repeater
5.2.1 General
Repeaters are necessary when the distance between sender and receiver is too large
to establish an adequate wireless connection. For bigger distances it is possible to
place a maximum of two repeaters in a row. The job of the repeater is to receive the
telegram from the sender or another repeater and send it again, so that the receiver
of the message can get it. But before it is resent the repeater modifies the STATUS
byte of the telegram. To limit the amount of repeated telegrams in an environment
with more repeaters we differ between two repeater levels:

 Level 1 Repeaters repeat only received original subtelegrams.

 Level 2 Repeaters repeat only received original or once repeated subtelegrams.
If a level 2 repeater receives an original and also an once repeated subtelegram
originating from the same transmitter, it will only repeat once with 3 subtelegrams.
5.2.2 Time response for collision avoidance
When there are repeaters in a system it is particularly important to avoid collisions.
When a subtelegram is sent from a transmitter, it is thus necessary that the repeater
does not repeat his received subtelegrams at the same time as another subtelegram
from the original sender or a following repeater is transmitted.

Therefore a special subtelegram timing for repeaters is defined, which depends on

the received subtelegram repeater level. This is described in detail in 4.2 above.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 14/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

5.2.3 Bits of repeater level in the status byte

The STATUS field is used for a repeater to differ between subtelegrams from a
transmitting device from those from a repeater, The bits 2 0 to 2 3 in the status field
byte of each subtelegram shows the number of repeater hops of the telegram. The
Table 4 shows the possible combinations:

Table 4: STATUS byte with repeater level bits

Repeater level bits Description

2 3
2 2
2 1
2 0

0 0 0 0 Original sender

0 0 0 1 Subtelegram was repeated 1 time

0 0 1 0 Subtelegram was repeated 2 times

1 1 1 1 Telegram shall not be repeated

The Table 5 shows, how the repeater level bits have to be modified in the repeated
sub telegram:

Table 5: Repeating bits in STATUS byte

Repeater Received subtelegram status Repeated subtelegram status

0000 = original subtelegram received 0001 = subtelegram is once repeated

0001 = once repeated subtelegram received Subtelegram will not be repeated!

Level 1
0010 = twice repeated subtelegram received Subtelegram will not be repeated!

1111 = subtelegram shall not be repeated Subtelegram will not be repeated!

0000 = original subtelegram received 0001 = subtelegram is once repeated

0001 = once repeated subtelegram received 0010 = subtelegram is twice repeated

Level 2
0010 = twice repeated subtelegram received Subtelegram will not be repeated!

0011 = subtelegram shall not be repeated Subtelegram will not be repeated!

If a repeater receives subtelegrams of a telegram from a transmitter or a repeater,

the status byte of the 3 repeated subtelegrams and the decision, whether the sub-
telegram is to be repeated, depends on the first received subtelegram according to
Table 5.

5.3 Addressing
5.3.1 General
Addressing of telegrams is an essential feature for bidirectional communication. It is
designed to enable future incorporation of additional features.

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 15/16

SPECIFICATION V1.2

ENOCEAN RADIO PROTOCOL 1

5.3.2 Encapsulation
The addressing of a telegram is performed by using an encapsulation mechanism.
Encapsulated telegrams are recognized in the telegram type field (RORG) by the val-
ue 0xA6. The encapsulated field contains the original telegram that has to be ad-
dressed. The field destination identity DESTID of length four bytes is inserted pr e-
ceding the field TXID, the transmitting identity.

Below is an example of how a telegram with destination identity DESTID 0xF1F2F3F4

would be encapsulated. Note that the value of the field DESTID is only an example:

7 6 5 4 3 2 1 0
0 0xA6
1 RORG
2
3
7 6 5 4 3 2 1 0 DATA
4
0 RORG
5
1
6
2
DATA 7 DESTID –
3
8 0xF1F2F3F4
4
9
5
10
6
TXID 11
7 TXID
12
8
13
9 STATUS
14 STATUS
10 HASH
15 HASH

Figure 3 – An example of encapsulation

© 2010 EnOcean | www.enocean.com EnOcean Radio Protocol 1 V1.2 | Page 16/16