Instructions for Use
Preparation Before Starting
- ESP32-S3-LR1121-ePaper-2.9 development board.
- A USB Type-C cable that supports data transfer, and a computer.
- ESP32-S3-LR1121-ePaper-2.9 Example Programs.
- Wireless communication: Prepare an antenna that matches the board's frequency band. LoRa point-to-point communication also requires another device with the same parameters; LoRaWAN requires a gateway, a network server, and device credentials.
- Storage card read/write: Prepare a FAT32-format TF card.
For first-time use, follow the sequence below:
- Connect to the computer with a Type-C data cable to power the development board.
- Configure the environment and download the program according to Working with Arduino and Working with ESP-IDF.
- Run examples 01, 02, and 03 in sequence to check the RGB LED, I2C devices, and e-paper display.
- Run the fuel gauge, RTC, wireless, TF, and deep sleep examples as needed. For the configuration and running behavior of each example, see the corresponding development tutorial.
Power Supply and Battery
USB Type-C is used for 5 V power supply and program download. The battery connector is an MX1.25 2PIN reverse connector, which can connect a 3.7 V lithium battery and supports charging and battery power supply.
Before connecting or removing the battery, disconnect the external power supply. Before connecting, confirm the connector wire order and polarity; do not judge polarity based on wire color or similar connectors.
GPIO38 controls the shared power domain for the e-paper, LR1121, RGB LED, and TF. Before turning off the power, stop these peripherals and bus access first; it is not equivalent to the board's main power switch. The VBUS, VBAT, and ESP_3V3 of the 14PIN expansion interface are different power nets; do not short them to each other.
The AXP2602 is a fuel gauge; the displayed SOC is an estimate of the state of charge, and the chip temperature is also not equivalent to the ambient temperature. The onboard current sampling resistor R16 is 10 mΩ, and the examples are configured according to this value.
Button Operations
| Button | Basic Function | Operation in Comprehensive Example 09 |
|---|---|---|
| BOOT / GPIO0 | Download mode selection | Double-press to sleep when awake; single-press to wake up during deep sleep |
| KEY / GPIO1 | Programmable input | Send one frame of LoRa data for each stable press |
| RESET / EN | Reset the main controller | Restart the program |
The sleep and send operations above apply to comprehensive example 09; operate other examples according to their corresponding tutorials. While comprehensive example 09 is running, a single press of BOOT does not enter sleep; if a button is already held down at startup, release it first before performing the next operation.
BOOT is also a boot configuration pin. Holding BOOT during reset enters download mode, while a short press of BOOT during deep sleep is used for wake-up.
If automatic download fails, follow the Manually Entering Download Mode instructions.
E-Paper Display
The e-paper is 2.9 inches, with a resolution of 296 × 128, and supports four-level grayscale display. The current examples display a black-and-white text interface by default.
In the Arduino library, only WAVESHARE_EPAPER_290 is enabled; for ESP-IDF, select the esp32_s3_lr1121_epaper_2_9 board definition provided with the repository.
The common display examples perform a full refresh on the first frame, after which the driver manages full-screen fast refreshes and periodically inserts full refreshes to clean up ghosting. FAST is full-screen fast refresh, and PARTIAL is partial refresh; the two are different. After waking up from deep sleep, the screen is reinitialized and does not retain the fast refresh count from the previous run.
ESP-IDF example 03 provides two modes: functional display and screen clearing. In clear screen mode, the screen is fully refreshed to pure white and then put to sleep; to restore the text interface, you need to reselect "Functional" in menuconfig, compile, and download. Pressing RESET will not switch the mode.
The screen text examples use the Terminus Bold 8 × 14 ASCII dot matrix font, which does not include a Chinese font library. Displaying Chinese requires separately preparing font data and rendering adaptation.
Wireless Communication
The HF version operates in the 850–930 MHz band, and the LF version operates in the 410–510 MHz band. Before transmitting, connect an antenna that matches the RF version and operating band, and confirm the frequencies and power permitted for use in your area.
The EU868, 868 MHz, and transmit power in the examples are program configurations. The LF version cannot use the default 868 MHz configuration; modify the wireless parameters according to the hardware band and local regulations. LoRaWAN also requires synchronized configuration of the gateway and network server.
LoRa Point-to-Point
- Connect matching antennas to both devices.
- Configure the frequency, bandwidth, spreading factor, coding rate, sync word, and preamble of example 06 to be consistent, then download the program.
- Check the serial port and screen to confirm that the peer's PING/PONG is received and that the receive count continues to increase.
Point-to-point communication does not require a LoRaWAN gateway. Successful initialization alone does not mean that communication with the peer has been established.
LoRaWAN
LoRaWAN requires a gateway and a network server. The region, MAC version, activation method, credentials, and receive parameters of the device and the server need to be consistent.
| Example | Working Method | Configuration Focus |
|---|---|---|
| 10 | Class A, OTAA over-the-air activation | JoinEUI, DevEUI, AppKey, NwkKey, and server MAC version |
| 11 | Class A, ABP preconfigured session | DevAddr, session keys for the corresponding MAC version, and frame counters |
| 12 | Class C after OTAA | Enable Class C on the server and match the RX2 / RXC parameters |
| 13 | Static Class C multicast | Independent unicast identity for each device, and the same multicast address, group keys, frequency, and data rate |
Arduino example 11 uses the four independent session keys of LoRaWAN 1.1; ESP-IDF example 11 uses LoRaWAN 1.0.x by default and has an additional 1.1 option. When switching frameworks, recheck the key fields according to the corresponding tutorial.
ESP-IDF examples 10 and 12 use standard EU868 multi-channel by default; examples 11 and 13 retain the 868.1 MHz / DR3 single-channel test configuration. The single-channel configuration requires matching synchronization between the gateway and server and cannot be treated as a general multi-channel configuration. The Arduino examples directly use RadioLib's region objects; the specific settings are subject to the corresponding source code.
Replace the credential placeholder values with the device parameters assigned by the server, and save them in a local configuration file. When CONFIG ERROR or CONFIG REQUIRED appears, complete the parameter configuration first. Do not include real keys in screenshots, logs, or public projects.
The examples save the session and frame counters; do not clear NVS or Preferences on every startup. When a session reset is needed, the state of the device and the network server also need to be handled in sync.
During Class C continuous reception, you cannot enter deep sleep that stops reception. Static multicast is also not equivalent to full FUOTA over-the-air firmware upgrade: the current examples do not provide remote group creation, fragment reassembly, or the upgrade installation process.
TF Card Usage
- After powering off, insert a FAT32-format TF card.
- Download and run example 07, and open the serial monitor.
- Check the card capacity, mount, read/write, and unmount status in the serial port and on the e-paper, confirm that it finally displays
SD PASSorSD FAIL, and verify the serial portFINALresult.
The two frameworks use different test files:
| Framework | Test File on the Card |
|---|---|
| ESP-IDF | /ws_sd/test.txt |
| Arduino | /waveshare_sd_test/roundtrip.txt |
The program writes, reads back, verifies, and deletes the corresponding test file. It does not format the card or overwrite existing files with the same name. A reset or power loss during the test may leave the file behind; after confirming its purpose, manually rename or delete it. If FINAL: FAIL appears, check the preceding error logs.
After unmounting, refresh the final result, then let the screen sleep and turn off the shared power supply; the e-paper retains the result screen. If the display fails, the TF test still continues; the serial port DISPLAY and FINAL report the display and TF test results respectively. The Arduino unmount status is displayed as Unmount: done; its interface does not return whether unmounting succeeded.
ESP-IDF example 07 also requires generating the Board Manager board-level code first, and supports long file names up to 255 characters by default.
Comprehensive example 09 performs only read-only detection and does not execute the file write process of example 07.
Deep Sleep and Wake-Up
Deep Sleep Example 08
Arduino and ESP-IDF example 08 both wake up after 600 seconds (10 minutes) by default, and can also be woken up early by briefly pressing BOOT. Release BOOT before entering sleep; after waking up, the program reinitializes the peripherals and enters the sleep process again.
Both examples first put the LR1121, e-paper, and detected AXP2602 to sleep, then isolate the wireless pins, turn off and hold off the GPIO38 shared power supply, and finally put the main controller into deep sleep.
- Arduino: Modify
kWakeupSecondsin08_deep_sleep.ino. After a normal shutdown, it outputsradio pins isolated; shared power held offandstart deep sleep; ifSLEEP abortedappears, the program will not enter sleep; troubleshoot and press RESET to retry. - ESP-IDF: Modify
WAKEUP_TIME_SECinmain/main.cpp. Check theLR1121 Sleep accepted before power off, fuel gauge status, andstart deep sleeplogs, and check the wake-up cause after waking up.
If the AXP2602 is not detected, the example prompts and continues running; at this point, the fuel gauge cannot be considered to have entered sleep. The two frameworks use different drivers, and the sleep current needs to be measured separately.
Comprehensive Example 09
While running, double-press BOOT to enter sleep; during deep sleep, briefly press BOOT to wake up. This example does not enable timed wake-up, and re-runs the self-test after waking up.
Comprehensive example 09 also stops Wi-Fi, BLE, and running tasks, unmounts the TF, and then completes peripheral sleep and shared power shutdown. If shutdown fails, check the serial error; a state in which shutdown has not completed cannot be regarded as normal sleep.
Power Consumption and Serial Port
The sleep power consumption is about 36.5 μW. The test conditions are a 3 V power supply, running the deep sleep program with all peripheral power supplies turned off.
The USB serial port may disconnect during deep sleep; after waking up, you need to reselect the port. When comparing power consumption, keep the power input, voltage, program, and peripheral state consistent.