Project Files of RFM69HCW Library for Proteus V1.1 (433 MHz FSK + Arduino)

RFM69HCW RF TRANSCEIVER MODULE (HopeRF, Semtech SX1231H, 315 / 433 / 868 / 915 MHz) LIBRARY FOR PROTEUS - V1.1
Designed by The Engineering Projects
www.TheEngineeringProjects.com

IMPORTANT LINKS
Article (read it first - pictures, step by step, every feature explained):
  https://www.theengineeringprojects.com/2026/09/rfm69hcw-proteus-library.html
Report a bug or suggest a feature (our forum):
  https://www.theengineeringprojects.com/forum/category/rfm69hcw-proteus-library
The demo uses our TEP Serial Monitor Advance (included) instead of Proteus's
Virtual Terminal - its own article:
  https://www.theengineeringprojects.com/2026/10/serial-monitor-advance-proteus-library.html
Support us (the libraries are free):
  https://www.theengineeringprojects.com/donate

FILE STRUCTURE
RFM69-TEP-v1.1/
|-- Proteus Library Files/
|   |-- ArduinoV3TEP.IDX                                  0.8 KB   its index -> LIBRARY folder
|   |-- ArduinoV3TEP.LIB                                 95.6 KB   TEP Arduino UNO (demo) -> LIBRARY folder
|   |-- TEPRFM69.LIB                                    122.6 KB   RFM69HCW Simple + Advance (2 devices) -> LIBRARY folder
|   |-- TEPSERIALMON.LIB                                 11.1 KB   TEP Serial Monitor Advance -> LIBRARY folder
|-- Proteus Model Files/
|   |-- TEPRFM69.DLL                                    392.0 KB   RFM69HCW model -> MODELS folder
|   |-- TEPSERIALMON.DLL                                978.0 KB   Serial Monitor model -> MODELS folder
|-- Proteus Simulation/
|   |-- RFM69_Gateway.hex                                45.4 KB   UNO 2 (gateway, node 1, v1.1)
|   |-- RFM69_Node.hex                                   51.5 KB   UNO 1 (node 2, v1.1)
|   |-- RFM69-ArduinoUnoV3.pdsprj                        18.6 KB   demo: UNO 1 + RFM69HCW Simple, UNO 2 + Advance
|   |-- TEPRFM69.DLL                                    392.0 KB   copy of the model so the demo runs as is
|   |-- TEPSERIALMON.DLL                                978.0 KB   copy of the monitor model
|-- Arduino Code/
|   |-- RFM69_Gateway/RFM69_Gateway.ino                  10.2 KB   sketch (source of the .hex)
|   |-- RFM69_Node/RFM69_Node.ino                        12.2 KB   sketch (source of the .hex)
|   |-- libraries/RFM69_LowPowerLab/                    162.2 KB   LowPowerLab RFM69 1.6.0 + RFM69_ATC (GPL-3.0, License.txt), 10 files
|-- README.txt                                          ~36.4 KB   this file
Total: 3.23 MB (unzipped). The C++ source code of the model is not included.

WHAT IS IT?
A simulation model of the HopeRF RFM69HCW sub-1 GHz radio module (the small square
16 x 16 mm board with the Semtech SX1231H chip, sold for 315 / 433 / 868 / 915 MHz) for
Proteus 8. Your Arduino talks to it over SPI exactly like to the real module: the
register map, the operating modes with their start-up times (ModeReady, TxReady,
RxReady), the IRQ flags and DIO0, the 66-byte FIFO, the packet engine (preamble, sync
word = the LowPowerLab network ID, length, address, CRC), AES-128 with key matching,
the live RSSI used by carrier sense, PA0 / PA1 / PA1 + PA2 with the +20 dBm registers,
the temperature sensor and the active-HIGH RESET pin. It runs the unmodified
LowPowerLab RFM69 library (RFM69 and RFM69_ATC). Every TEP RFM69 in a design shares one
simulated air: radios on the same frequency, bit rate, network ID and AES key talk to
each other when the link budget allows - you choose the DISTANCE between the radios
(10 m ... 10 km) and the model works out the level (your TX power, the path loss at your
frequency, the receiver's sensitivity at its bit rate).
The part looks like the real RFM69HCW: a square green module with 16 castellated pads
(their names printed, ANT at the top-left), the black HopeRF RF69 / SX1231H chip, the
silver 32 MHz crystal, the two SOT-23 parts and the small parts of the RF matching network,
the big name RFM69HCW - and the yellow quarter-wave wire antenna on its ANT pad, like on
Adafruit's breakout. The 8 Proteus pins sit in a strip below it. While the simulation runs
the wire, the ANT pad and the RF trace glow orange while the module transmits and green
while it receives (a bright segment runs up / down the wire), radio waves above the wire
ripple out (sending) or in (receiving) - with ACKs the node glows orange for its message
and then green for the ACK, the gateway green and then orange for the ACK it sends back -
and three LEDs show what happens: PWR (red, lit while VCC is there), TX (orange, blinks for
every packet sent) and RX (green, blinks for every packet received). The LEDs are a TEP
addition - the real module has no LEDs.

TWO DEVICES IN ONE LIBRARY (search "RFM69" in Pick Devices):
  RFM69HCW Simple    device RFM69TEP     "RFM69HCW RF Transceiver Module - Simple"
                     On-Sheet Panel: the control panel is drawn on the schematic next
                     to the module (the v1.0 panel): mode, frequency, FSK / OOK, bit
                     rate, network ID, CRC, AES, TX power and PA, SENT / RECEIVED /
                     TOO WEAK, the last packet with the LowPowerLab header decoded and
                     its RSSI, the DISTANCE buttons and the link-budget verdict (OK /
                     TOO WEAK). The red X in the panel header closes it, the PANEL button
                     on the board opens it again. Your v1.0 designs keep working with this
                     device.
  RFM69HCW Advance   device RFM69ADVTEP  "RFM69HCW RF Transceiver Module - Advance"
                     Pop-Up Panel: only the module board on the schematic; at Run a TEP
                     pop-up window opens - the same look as the TEP Serial Monitor (move
                     it by its header, resize it, minimise it). The tabs Radio and Test sit
                     in the header; the gear and ? icons open Settings and Help; the
                     palette icon switches the theme:
                       Radio     the mode banner, RADIO (frequency + band, bit rate +
                                 FSK / OOK + deviation, TX power + PA, sensitivity, RX
                                 bandwidth, mode + DIO0 - what your sketch wrote), PACKET
                                 FORMAT AND SECURITY (network ID / sync word, preamble,
                                 packet length, CRC, AES on / off with a key fingerprint,
                                 the LowPowerLab node IDs), ACKS AND AUTO POWER (ACK
                                 requests, ACKs back, retries, messages without an ACK, the
                                 last ACK's round trip, RFM69_ATC: the RSSI the other node
                                 reports), TRAFFIC (sent / received, too weak / CRC, the
                                 mismatches: other network / bit rate / frequency / AES key,
                                 the last packet) and DISTANCE (the eight buttons, the level
                                 at that distance, OK / TOO WEAK, how far these settings
                                 reach)
                       Test      four test tools, all measured on the model: Link test,
                                 Throughput, Scan, Registers (see THE TEST TOOLS below)
                       Settings  theme (TEP Dark / Light), text size, open at Run, window
                                 size - remembered for your Windows user
                       Help      Help & Support like the TEP Serial Monitor: report a bug,
                                 suggest a feature, article, user guide, updates, donate,
                                 website, forum; Copy diagnostics (radio, registers,
                                 traffic, ACKs, test results, the other radios) for a bug
                                 report
                     The OPEN PANEL button on the board opens the window again after you
                     close it.
Both devices use the same model (TEPRFM69.DLL), and Simple and Advance modules in one
design talk to each other.

NEW IN V1.1
* Two devices: RFM69HCW Simple (the panel on the sheet, close / open) and RFM69HCW
  Advance (pop-up window with the radio page, four test tools, settings and help) - see
  above.
* Board: redrawn like the real HopeRF RFM69HCW - the square green module with its 16
  castellated pads and their names, the chip, the 32.000 MHz crystal, the SOT-23 parts,
  the matching network, the big name, and the yellow quarter-wave wire antenna on the ANT
  pad (v1.0: a wide navy board with a small green module on it). The 8 Proteus pins stay
  where v1.0 had them, so the wiring of a v1.0 design fits. The wire, the ANT pad and the
  RF trace glow orange while the module sends and green while it receives, radio waves
  above the wire; new LEDs PWR / TX / RX in a row (a TEP addition - the real module has
  none): PWR lights with VCC, TX blinks for every packet sent, RX for every packet
  received (each blink held 0.3 / 0.4 s so you see it); a PANEL / OPEN PANEL button and a
  SIMPLE / ADVANCE badge. The Simple panel sits a little higher, beside the taller board,
  and its two long lines (the link budget, the hint) are a little smaller so they fit (a
  v1.0 design keeps its v1.0 places and sizes).
* Model: the radio records what the test tools show - every message it sends with its
  tries (sendWithRetry() resending the same packet is ONE message with tries 2 / 3), the
  ACK that came back and after how many ms (or why it did not come: too weak ...), the TX
  power of each try (RFM69_ATC changes it) and the RSSI an ATC ACK reports; every packet
  it hears with the outcome (received / CRC error / too weak / other network / other bit
  rate / other frequency / AES key mismatch / not listening / too late / filtered / busy)
  and whether it sent the ACK back; the Arduino's SPI commands; the activity on all bands.
  The Simulation Log now also explains a packet on another network ID, bit rate or
  frequency, an AES key mismatch, a message without an ACK and ATC at work.
  Fixed: an unpowered RFM69 in a design where another radio transmits could stall the
  simulation (v1.0). The DISTANCE buttons, the link budget and everything else of v1.0
  are unchanged.
* The demo uses the TEP Serial Monitor Advance instead of Virtual Terminals - one monitor
  per Arduino (U3 = UNO 1, U4 = UNO 2) with quick buttons - and shows both styles: UNO 1
  (the node) with RFM69HCW Simple, UNO 2 (the gateway) with RFM69HCW Advance.
* The demo sketches (v1.1) keep every v1.0 output line, use RFM69_ATC (the node turns its
  power down until the gateway hears -80 dBm - watch the gateway's RSSI fall from -65 to
  -80 dBm), add Serial Monitor commands (SEND, PING, STATUS, POWER, ATC, RATE, FREQ, NET,
  KEY, HELP; AUTO on the node) and a link line every 10 s; the node now listens between
  its messages, so the gateway can SEND / PING it too.
* Version 1.1 everywhere; the C++ source code of the model is no longer included.

TEST STATUS
v1.1 was tested in Proteus 8.5 SP0 (7 Oct 2026) with this demo: it loads and runs, both
Serial Monitors and U2's pop-up open (no caption row), U3 prints "TEP RFM69HCW Node Demo
v1.1" and every message gets its ACK; RFM69_ATC turns the node down - U4's RSSI fell by
1 dB per message (-65 -> -73 dBm while watched); PING on U3 "ACK from node 1 after 5.8
ms, RSSI -65 dBm", on U4 "ACK from node 2 after 5.6 ms"; POWER 20 -> "Power +20 dBm (ATC
off)" and U4 back at -65 dBm; SEND Hello node 2 on U4 -> U3 "[1] Hello node 2   RSSI -65
dBm   - ACK sent"; STATUS; DISTANCE 2 km -> the panel "-104 dBm, 55.6 kbps NEEDS -103
dBm -> TOO WEAK" and U3 "... no ACK"; RATE 4.8 on both -> "4.8 kbps NEEDS -114 dBm ->
OK" and "ACK received, RSSI -104 dBm" at 2 km; the red X and PANEL; and the Link test
(10 / 10, -65.2 dBm, the gateway's ACK 1129 us after the request), Throughput (122.3
packets/s, 3.91 kB/s, 8176 us per packet, 50 / 50, the bit-rate table), Scan (U1 on
433.920 MHz, -65 dBm), Registers (live; U1 PARTNER (LISTENING); NET 101 on U3 -> "OTHER
NETWORK ID" and no ACK, NET 100 restores it), Settings and Help (all 8 cards with the
live article / forum links) and Close + OPEN PANEL all passed.
v1.0 was tested in Proteus 8.5 SP0 (29 Sep 2026) with the v1.0 demo: the gateway printed
every "[2] Hello #n" with RSSI -65 dBm at 100 m, the node counted one ACK for every
message (SENT 21 / RECEIVED 21), 3 km gave TOO WEAK (the node retried), 500 m -86 dBm,
and Stop + Run started cleanly.
PC tests of v1.1: 961 automatic checks on a PC: 45 with the UNMODIFIED LowPowerLab RFM69
library driving two chip models bit by bit over SPI (the v1.0 tests, unchanged); 50 on
the v1.1 chip features (the message / packet records with tries, ACKs, round trips and
the ATC RSSI, the mismatch outcomes, the SPI log, the frequency scan, the partner check,
the air time, the throughput bench); 151 on the complete Proteus model (the 21 of v1.0
unchanged + both devices, the red X and PANEL, OPEN PANEL, a v1.0 design, the wire glow,
the PWR / TX / RX LEDs, the pop-up window without a caption row, its pages, the four tools
with measured numbers, the mismatches the model detects, Help links, diagnostics, the
unpowered-radio fix); 63 with the two REAL v1.1 demo sketches running on two simulated
UNOs at once (every v1.0 line, ATC dialling the power down and back up, the commands,
PING both ways, RATE / FREQ / NET / KEY on one node and then both, the link line); 652 on
the rendered pop-up windows and boards (every page fits in TEP Dark and Light, at Large
text and 150 % DPI; every tool's hint lines fit; the header line fits beside the tabs in
every state).

INSTALLATION (about 2 minutes)
1. Close Proteus. Extract the WHOLE ZIP to a normal folder (e.g. Desktop).
2. Copy everything in "Proteus Library Files" (TEPRFM69.LIB with both devices,
   TEPSERIALMON.LIB and the TEP Arduino UNO V3 library ArduinoV3TEP.LIB / .IDX used by
   the demo) to the LIBRARY folder of Proteus, for example:
     C:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\LIBRARY
   (on some PCs: C:\ProgramData\Labcenter Electronics\Proteus 8 Professional\
   LIBRARY - use the folder that already holds Proteus's own .LIB files).
3. Copy TEPRFM69.DLL and TEPSERIALMON.DLL from "Proteus Model Files" to the MODELS
   folder (...\Proteus 8 Professional\MODELS).
4. Updating from v1.0: replace TEPRFM69.LIB (delete any TEPRFM69.IDX) and TEPRFM69.DLL.
   A v1.0 design keeps its v1.0 symbol: it runs with the new model (the v1.0 panel and
   its DISTANCE buttons, without the v1.1 board parts and the red X) - re-pick the part
   to get the v1.1 symbol.
5. Start Proteus. In Pick Devices (P) search "RFM69": you get the Simple and the Advance
   device (category Peripherals > Wireless).

RUN THE DEMO
"Proteus Simulation\RFM69-ArduinoUnoV3.pdsprj" - keep the two .hex files and the two
DLLs beside the project.
  UNO 1 (ARD1): RFM69_Node.hex (node 2), RFM69HCW Simple (U1) and Serial Monitor U3.
  UNO 2 (ARD2): RFM69_Gateway.hex (node 1), RFM69HCW Advance (U2) and Serial Monitor U4.
  1. Press Run. Both monitor windows open (9600 baud) and so does U2's pop-up. U3 shows
     "Sending "Hello #0" ... ACK received, RSSI -65 dBm" every 2 s, U4 "[2] Hello #0
     RSSI -65 dBm   - ACK sent". RFM69_ATC is on in the node: watch U4's RSSI fall by
     about 1 dB per message until the gateway hears -80 dBm (+5 dBm at the node) - the
     node's link line every 10 s says "power +5 dBm, the gateway hears -80 dBm". The wire
     antennas flash orange / green, the TX / RX LEDs blink.
  2. U3 quick buttons: PING (the ACK round trip with the UNO's SPI time - 5.8 ms in
     Proteus), STATUS, POWER 20 (full power, ATC off - U4 shows -65 dBm again) and ATC -80 (back to
     automatic power). U4 quick buttons: PING (the node ACKs it), STATUS, SEND Hello node
     2 (U3 prints "[1] Hello node 2 ... - ACK sent"), HELP. Type your own: SEND <text>,
     RATE 4.8 (then on the other monitor too), FREQ 434.5 (both), NET 101 (both), KEY
     sampleEncryptKey (both - exactly 16 characters), KEY OFF, AUTO OFF / ON (U3).
  3. Click 2 km on U1's panel (or on U2's Radio page): at 55.6 kbps the link ends at about
     1.9 km - the node prints "no ACK" and retries; with ATC on it raises its power after
     every failed try, but even +20 dBm gives only -104 dBm at 2 km (55.6 kbps needs -103).
     Type RATE 4.8 on both monitors: 4.8 kbps reaches 2 km (it needs -114 dBm). Back to
     100 m and RATE 55.5. Close U1's panel with its red X, open it with PANEL.
  4. U2 (Advance): open the Test tab:
       Link test: 10 packets, Run test - the next 10 packets U2 hears with their level,
         the ACK it sent back (how fast) and the node's TX power as a line of dots (ATC);
         click 2 km during the test and watch the bars turn red and the retries appear.
       Throughput: bit rate, payload, ACK on / off, Run test.
       Scan: 5 s, Run test - every sender and its frequency, the band views.
       Registers: what the sketch wrote, its SPI commands, U1 as its partner (type NET 101
         on U3 and U1 becomes OTHER NETWORK ID).
  5. Close U2's window and open it again with OPEN PANEL on the board.
Closed a monitor window? Click OPEN MONITOR on the monitor part.

WIRING (SPI, the same on both UNOs - the LowPowerLab wiring)
  RFM69 VCC -> supply (+5 V in the simulation - a real module needs 3.3 V!), GND -> GND,
  SCK -> D13, MISO -> D12, MOSI -> D11, NSS -> D10 (SS), DIO0 -> D2 (INT0 - the library's
  receive interrupt), RST -> D9.
  In the sketch: RFM69_ATC radio; (NSS D10, DIO0 D2), radio.initialize(RF69_433MHZ,
  NODEID, NETWORKID); radio.setHighPower(); (RFM69HCW!)
  Serial Monitor RXD <- Arduino D1 (TX), Serial Monitor TXD -> Arduino D0 (RX), Serial
  Monitor GND -> ground. RXD2 is not needed for SPI radios: the monitor's second input
  watches a serial line, and the RFM69 has none (it talks SPI). Serial.begin(9600) in the
  sketches.
Pin order in Proteus: VCC GND SCK MISO MOSI NSS RST DIO0. The bare RFM69HCW has 16 castellated
pads (the board shows them: ANT GND DIO3 DIO4 3.3V DIO0 DIO1 DIO2 / GND DIO5 RESET NSS SCK
MOSI MISO GND); breakouts (Adafruit, SparkFun) print their own order - check yours.
RST is active HIGH, as on the real module: left open or low, the radio runs. The demos
pulse it (HIGH 10 ms, LOW 10 ms) before initialize().
Important for the RFM69HCW / RFM69HW: call radio.setHighPower() after initialize().
Without it the library uses PA0, which the HCW does not connect to the antenna - the model
then sends almost nothing, and the Simulation Log says so.
REAL HARDWARE:
 * Supply 1.8 - 3.6 V: feed VCC from 3.3 V, never from 5 V. At +20 dBm the module draws
   about 130 mA in TX - more than an UNO's 3.3 V pin gives: use a 3.3 V regulator and a
   10 uF + 100 nF capacitor near the module.
 * The RFM69HCW's pins are NOT 5 V tolerant: on a 5 V Arduino UNO / Nano / Mega put a
   level shifter (e.g. TXS0108E or 74HC4050, or resistor dividers on SCK, MOSI, NSS and
   RST) between the board and the module; MISO and DIO0 (3.3 V out) are read fine by a
   5 V AVR. 3.3 V boards (ESP32, ESP8266, Arduino Pro Mini 3.3 V, Moteino) connect
   directly. Breakouts like Adafruit's have the level shifting and the regulator on board.
 * Antenna: a module is built for ONE band - an RFM69HCW-433 works badly at 868 / 915
   MHz. The simplest antenna is a quarter-wave wire on the ANT pad: 16.4 cm at 433 MHz,
   8.2 cm at 868 MHz, 7.8 cm at 915 MHz, kept straight and away from metal; never transmit
   without an antenna at +20 dBm.
 * Legal bands and duty cycle: use only the frequencies and powers allowed where you live.
   Europe (ERC/REC 70-03): 433.05 - 434.79 MHz at 10 mW with up to 10 % duty cycle,
   868.0 - 868.6 MHz at 25 mW with up to 1 %; USA (FCC part 15): 902 - 928 MHz. The
   RFM69HCW's +20 dBm (100 mW) is more than the EU 433 / 868 MHz limits - turn it down
   (setPowerDBm) or let RFM69_ATC do it. The Throughput tool shows your sketch's duty cycle.

HOW THE RADIOS TALK (the model)
A packet arrives when the receiver is powered, in RX (ready in time: before the last
preamble byte), on the same frequency (within its RX bandwidth), FSK / OOK, bit rate
(within 10 %), DC-free coding, sync word (the LowPowerLab network ID is the second sync
byte) and length mode - and the link budget is OK: level = TX power (PA1 + PA2 with the
+20 dBm registers: +20 dBm with setHighPower()) - path loss (free space up to 1 m, then
exponent 3: 55 dB at 10 m, 85 dB at 100 m, 115 dB at 1 km at 433 MHz; 6 dB more at
868 MHz) - the LNA setting, against the sensitivity at the bit rate (-118 dBm at 1.2 kbps,
-114 at 4.8, -105 at 38.4, -103 at the library's 55.5, -97 at 250 kbps; OOK 2 dB worse).
The link uses the LARGER of the two radios' DISTANCE settings. Within 1.5 dB of the
sensitivity the CRC fails. AES: with different keys, or AES on one side only, the message
decrypts to garbage (the library then drops it). The demo (+20 dBm, 55.5 kbps): -65 dBm at
100 m (38 dB margin); it reaches about 1.9 km, at 4.8 kbps about 4.2 km.
ACKs (the LowPowerLab protocol): sendWithRetry() sends a packet with "ACK requested", the
other node's sketch answers with sendACK() (it must call receiveDone() often); without an
ACK within 30 ms it sends the same packet again, up to 2 retries. In the model an ACK
comes back about 2.4 ms after the request (the 3 ms frame, the gateway's interrupt and
FIFO read, 200 us to switch to TX, the 1.6 ms ACK frame); a real UNO adds its SPI time -
the demo's PING measured 5.8 ms in Proteus. RFM69_ATC: with enableAutoPower(target) the node
asks for the RSSI in every ACK and moves its power level one step at a time towards the
target (after a failed try one step up).

THE TEST TOOLS (RFM69HCW Advance, Test tab) - what they really do
Every tool runs on the live model with your sketch and shows one "Good for:" line plus
one line on how it measures.
  Link test   Good for: seeing how far your link reaches, how many retries it needs and
              how ATC sets the power.
              Records the next 10, 20 or 50 messages THIS radio sends or packets it
              hears (the sketch's real traffic): a message with its tries, its ACK (at
              once / after retries / none - and why the ACK did not arrive) and the round
              trip; a heard packet with its outcome (received / CRC error / too weak / other
              network / other bit rate / other frequency / AES key mismatch / not listening)
              and whether this radio sent the ACK back (and how fast). One bar per packet
              (the level), the retry count on top, the sender's TX power as a line of dots -
              watch RFM69_ATC turn it down. The DISTANCE buttons are on the tool, so you can
              move the radios while it runs. Then the newest message to scale (its tries,
              the waits, the ACK) and the link budget of your TX power at 1.2 / 4.8 / 55.5 /
              250 kbps for every distance. Measured (the model, 100 m): every message ACKed
              at the first try, the ACK 2.4 ms after the request; at 2 km: too weak, 3
              tries, no ACK; ATC: +20 -> +5 dBm in 16 messages. In Proteus with the demo
              (U2): 10 / 10 at -65.2 dBm, the gateway's ACK 1129 us after the request.
              No packet for 15 s stops it.
  Throughput  Good for: choosing the bit rate, packet size and ACKs, and checking the
              433 MHz 10 % duty cycle.
              Two model radios in a private test air (your design never hears them), at
              this radio's DISTANCE, frequency and TX power, send 50 LowPowerLab frames
              back to back like the library's send() (STANDBY, FIFO, TX: 200 us,
              PacketSent) - with ACK on the other radio answers at once and the next frame
              waits for the ACK: measured packets / s, payload bytes / s, the time per packet
              split into the switch, the frame and the ACK, plus a table of all bit rates
              (1.2 / 4.8 / 19.2 / 55.5 / 250 kbps) with and without the ACK, the frame's air
              time, the range and how many frames per hour the EU 433 MHz 10 % duty cycle
              allows. Measured (100 m, 32 bytes): 55.5 kbps with ACK 122.3 packets/s (3.9
              kB/s, 8176 us = 200 + 6192 + 1784 us), without 15
…