Awesome

loraE22

A MicroPython class for the Ebyte E22 Series LoRa modules

The supported EBYTE E22 modules are based on SEMTECH SX1262/SX1286 chipsets and are available for the 400 MHz (410.125...493.125) and 900 MHz (850.125...930.125) frequency ranges and provide 22 dBm max. TX power.

A simple UART interface is used to control the device.

EBYTE Datasheets:<br> E22-900T22D<br> E22-400T22D

The loraE22 class is based on the loraE32 class by effevee: https://github.com/effevee/loraE32

Warnings

Connect proper antenna before transmitting!

Before use, check your local regulations for using this frequency range. E.g. in most of Europe, the maximum allowed TX power is below the default value of 22 dBm! There might also be additional restrictions, e.g. restrictions on the duty cycle of your transmissions (that is the fraction of air time to the total time spanned during a period of using the device)!

NOTES

1. The E22 and E32 are different in many details -
   • commands
   • register layout
   • mode control
   • AUX signal timing (in Configuration mode, AUX cannot be used to detect completion of command/response sequence)
2. The E22 or E32 modules do not seem to be suitable for LoRaWAN communication (e.g. The Things Network)
3. See issue https://github.com/matthias-bs/loraE22/issues/6 for compatibility issues with newer (V2.1) E22 modules

Minimal NodeMCU-ESP32 hardware setup

See code for pin configuration.

Test code

Notes: The loraE22 test code differs from the E32 test code in terms of used UART and AUX pin! Furthermore, loraE22 uses 'normal mode', while loraE32 uses 'wakeup mode' in sendMessage().

Example: Bi-directional transmission between two nodes

Each node sends a message at a fixed interval containing an LED control value according to the state of a push button.

Afterwards it checks for received messages. If a message with LED control value is available, the LED is switched accordingly.

The transmission mode (address/channel config) for the local node and the peer node can be set as desired in the arrays addr and chan.

The code of node0.py and node1.py is identical except for the settings of the variables me and peer.

Range test setup

The LoRa transmitter sends a string containing its chip ID and a message sequence number at a fixed interval.

The LoRa receiver prints/logs <timestamp>,<latitude>,<longitude>,<altitude>,<rssi> at a pre-defined interval.

The receiver's position and a timestamp are decoded from NMEA messages received via UART from a GPS receiver. For this purpose, micropyGPS is used.

If available, incoming LoRa messages are received from the ebyteE22 LoRa transceiver module via another UART. If the messages expected from the LoRa transmitter could not be received for a certain time, an RSSI value of -255 dBm is assumed, indicating loss of the LoRa radio link.

The tuple <timestamp>,<latitude>,<longitude>,<altitude>,<rssi> is printed and optionally written to a log file only if a valid position is available.

If logging is enabled, a filename in the format log_<8_random_hex_digits_>.csv is created after power-on or reset. The log files are written to MicroPython's internal file system. Logging must be stopped explicitly by pressing a key, otherwise the file cannot be closed properly and will be corrupt/empty.

Two LEDs indicate the state of the GPS fix and the LoRa link, respectively.

Log files can be converted from CSV-format to a suitable format - such as GPX or KML - on the host later. See rssi_csv_to_kml.py - The KML output file provides the RSSI value as extended data to be displayed with the elevation plot in GoogleEarth. (Usage: rssi_csv_to_kml.py log_deadbeef.csv >log_deadbeef.kml)

Note: The plot just serves as an example - the logging interval should have been shorter and the logging strategy has been modified afterwards.