![]() * Fix protobuf structs handling (#4140) * Fix protobuf structs handling * Log instead of assert --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * BLE based logging (#4146) * WIP log characteristic * Bluetooth logging plumbing * Characteristic * Callback * Check for nullptr * Esp32 bluetooth impl * Formatting * Add thread name and log level * Add settings guard * Remove comments * Field name * Fixes esp32 * Open it up * Whoops * Move va_end past our logic * Use `upload_protocol = esptool` as with the other heltec devices instead of `esp-builtin` (#4151) * Standardize lat/lon position logs (#4156) * Standardize lat/lon position logs * Missed sone and condensed logs * [create-pull-request] automated change (#4157) Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> * Pause BLE logging during want_config flow (#4162) * Update NimBLE to 1.4.2 (#4163) * Implement replies for all telemetry types based on variant tag (#4164) * Implement replies for all telemetry types based on variant tag * Remove check for `ignoreRequest`: modules can set this, don't need to check --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * Esptool is better * Explicitly set characteristic * fix INA3221 sensor (#4168) - pass wire to begin() - remove redundant setAddr() (already set in header) * Show compass on waypoint frame; clear when waypoint deleted (#4116) * Clear expired or deleted waypoint frame * Return 0 to CallbackObserver * Add a missing comment * Draw compass for waypoint frame * Display our own waypoints * [create-pull-request] automated change (#4171) Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> * Add semihosting support for nrf52 devices (#4137) * Turn off vscode cmake prompt - we don't use cmake on meshtastic * Add rak4631_dap variant for debugging with NanoDAP debug probe device. * The rak device can also run freertos (which is underneath nrf52 arduino) * Add semihosting support for nrf52840 devices Initial platformio.ini file only supports rak4630 Default to non TCP for the semihosting log output for now... Fixes https://github.com/meshtastic/firmware/issues/4135 * fix my botched merge - keep board_level = extra flag for rak3631_dbg --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * [create-pull-request] automated change (#4174) Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> * Display alerts (#4170) * Move static functions into Screen.h, show compass during calibration * Move to _fontHeight macro to avoid collision * Move some alert functions to new alert handler * Catch missed reboot code * ESP32 fixes * Bump esp8266-oled-ssd1306 * Fixes for when a device has no screen * Use new startAlert(char*) helper class * Add EINK bits back to alert handling * Add noop class for no-display devices --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * Send file system manifest up on want_config (#4176) * Send file system manifest up on want_config * Platform specific methods * Helps to actually make the change * Clear * tell vscode, if formatting, use whatever our trunk formatter wants (#4186) without this flag if the user has set some other formatter (clang) in their user level settings, it will be looking in the wrong directory for the clang options (we want the options in .trunk/clang) Note: formatOnSave is true in master, which means a bunch of our older files are non compliant and if you edit them it will generate lots of formatting related diffs. I guess I'll start letting that happen with my future commits ;-). * fix the build - would loop forever if there were no files to send (#4188) * Show owner.short_name on boot (and E-Ink sleep screen) (#4134) * Show owner.short_name on boot and sleep screen (on e-ink) * Update Screen.cpp - new line for short_name Boot screen short_name now below the region setting. Looks better on small screens. * Draw short_name on right --------- Co-authored-by: Thomas Göttgens <tgoettgens@gmail.com> Co-authored-by: todd-herbert <herbert.todd@gmail.com> Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * nrf52 soft device will watchdog if you use ICE while BT on... (#4189) so have debugger disable bluetooth. * correct xiao_ble build preventing sx1262 init (#4191) * Force a compile time failur if FromRadio or ToRadio get larger than (#4190) a BLE packet size. We are actually very close to this threshold so important to make sure we don't accidentally pass it. * Clear vector after complete config state (#4194) * Clear after complete config * Don't collect . entries * Log file name and size * [create-pull-request] automated change (#4200) Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> * Make the logs Colorful! (#4199) * Squash needlessly static functions (#4183) * Trim extra vprintf and filter for unprintable characters * Deprecate Router Client role (and make it Client) (#4201) * [create-pull-request] automated change (#4205) Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> * Move waypoint (#4202) * Move waypoint screen draw into the waypoint module * Get the observer set up for the waypoint screen draw * Static squashing: screen dimensions Macros moved back to Screen.cpp, as a band-aid until we eventually move all those static functions into the Screen class. * Move getCompassDiam into Screen class (supress compiler warnings) At this stage, the method is still static, because it's used by drawNodeInfo, which has no tidy reference to our screen instance. This is probably just another band-aid until these static functions all move. * Use new getCompassDiam function in AccelerometerThread * Properly gate display code in WaypointModule --------- Co-authored-by: Todd Herbert <herbert.todd@gmail.com> * Fix flakey phone api transition from file manifest to complete (#4209) * Try fix flakey phone api transition from file manifest to complete * Skip * enable colors in platformio serial monitor (#4217) * When talking via serial, encapsulate log messages in protobufs if necessary (#4187) * clean up RedirectablePrint::log so it doesn't have three very different implementations inline. * remove NoopPrint - it is no longer needed * when talking to API clients via serial, don't turn off log msgs instead encapsuate them * fix the build - would loop forever if there were no files to send * don't use Segger code if not talking to a Segger debugger * when encapsulating logs, make sure the strings always has nul terminators * nrf52 soft device will watchdog if you use ICE while BT on... so have debugger disable bluetooth. * Important to not print debug messages while writing to the toPhone scratch buffer * don't include newlines if encapsulating log records as protobufs --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * [create-pull-request] automated change (#4218) Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> * Fix SHT41 support (#4222) * Add SHT41 Serial to I2c Detection Code On the Seeed Wio-WM1110 Dev Kit board, the SHT41 chip was being incorrectly detected as SHT31. This patch adds the necessary serial number for the SHT41 chip to be correctly detected. fixes meshtastic/firmware#4221 * Add missing sensor read for SHT41 * Typo fix in logs - mhz - MHz (#4225) As reported by karamo, a few different places in our logs had incorrect capitalization of MHz. fixes meshtastic/firmware#4126 * New new BLE logging characteristic with LogRecord protos (#4220) * New UUID * New log radio characteristic with LogRecord protobuf * LogRecord * Merge derp * How did you get there * Trunk * Fix length * Remove assert * minor cleanup proposal (#4169) * MESHTASTIC_EXCLUDE_WIFI and HAS_WIFI cleanup... Our code was checking HAS_WIFI and the new MESHTASTIC_EXCLUDE_WIFI flags in various places (even though EXCLUDE_WIFI forces HAS_WIFI to 0). Instead just check HAS_WIFI, only use EXCLUDE_WIFI inside configuration.h * cleanup: use HAS_NETWORKING instead of HAS_WIFI || HAS_ETHERNET We already had HAS_NETWORKING as flag in MQTT to mean 'we have tcpip'. Generallize that and move it into configuration.h so that we can use it elsewhere. * Use #pragma once, because supported by gcc and all modern compilers instead of #ifdef DOTHFILE_H etc... --------- Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz> * Add PowerMon support (#4155) * Turn off vscode cmake prompt - we don't use cmake on meshtastic * Add rak4631_dap variant for debugging with NanoDAP debug probe device. * The rak device can also run freertos (which is underneath nrf52 arduino) * Add semihosting support for nrf52840 devices Initial platformio.ini file only supports rak4630 Default to non TCP for the semihosting log output for now... Fixes https://github.com/meshtastic/firmware/issues/4135 * powermon WIP (for https://github.com/meshtastic/firmware/issues/4136 ) * oops - mean't to mark the _dbg variant as an 'extra' board. * powermon wip * Make serial port on wio-sdk-wm1110 board work By disabling the (inaccessible) adafruit USB * Instrument (radiolib only for now) lora for powermon per https://github.com/meshtastic/firmware/issues/4136 * powermon gps support https://github.com/meshtastic/firmware/issues/4136 * Add CPU deep and light sleep powermon states https://github.com/meshtastic/firmware/issues/4136 * Change the board/swversion bootstring so it is a new "structured" log msg. * powermon wip * add example script for getting esp S3 debugging working Not yet used but I didn't want these nasty tricks to get lost yet. * Add PowerMon reporting for screen and bluetooth pwr. * make power.powermon_enables config setting work. * update to latest protobufs * fix bogus shellcheck warning * make powermon optional (but default enabled because tiny and no runtime impact) * tell vscode, if formatting, use whatever our trunk formatter wants without this flag if the user has set some other formatter (clang) in their user level settings, it will be looking in the wrong directory for the clang options (we want the options in .trunk/clang) Note: formatOnSave is true in master, which means a bunch of our older files are non compliant and if you edit them it will generate lots of formatting related diffs. I guess I'll start letting that happen with my future commits ;-). * add PowerStress module * nrf52 arduino is built upon freertos, so let platformio debug it * don't accidentally try to Segger ICE if we are using another ICE * clean up RedirectablePrint::log so it doesn't have three very different implementations inline. * remove NoopPrint - it is no longer needed * when talking to API clients via serial, don't turn off log msgs instead encapsuate them * fix the build - would loop forever if there were no files to send * don't use Segger code if not talking to a Segger debugger * when encapsulating logs, make sure the strings always has nul terminators * nrf52 soft device will watchdog if you use ICE while BT on... so have debugger disable bluetooth. * Important to not print debug messages while writing to the toPhone scratch buffer * don't include newlines if encapsulating log records as protobufs * update to latest protobufs (needed for powermon goo) * PowerStress WIP * fix linter warning * Cleanup buffer * Merge hex for wm1110 target(s) * Only sdk * Sudo * Fix exclude macros (#4233) * fix MESHTASTIC_EXCLUDE_BLUETOOTH * fix HAS_SCREEN=0 * fix MESHTASTIC_EXCLUDE_GPS * fix typo in build-nrf52.sh (#4231) chmod is the command, '+x' is the argument. * Tidy Wireless Paper variant files (#4238) * Quick tidy of pins_arduino.h Matches requests made at https://github.com/meshtastic/firmware/pull/4226#discussion_r1664183480) * Tidy variant.h * Change deprecated ADC attenuation parameter From 11dB to 12dB. Resolves compiler warning. Allegly, no impact on function: `This is deprecated, it behaves the same as `ADC_ATTEN_DB_12` * Updated raspbian CI to update apt repository ahead of libbluetooth. (#4243) * Fix BLE logging on nrf52 (#4244) * allow ble logrecords to be fetched either by NOTIFY or INDICATE ble types This allows 'lossless' log reading. If client has requested INDICATE (rather than NOTIFY) each log record emitted via log() will have to fetched by the client device before the meshtastic node can continue. * Fix serious problem with nrf52 BLE logging. When doing notifies of LogRecords it is important to use the binary write routines - writing using the 'string' write won't work. Because protobufs can contain \0 nuls inside of them which if being parsed as a string will cause only a portion of the protobuf to be sent. I noticed this because some log messages were not getting through. --------- Co-authored-by: Ben Meadors <benmmeadors@gmail.com> * Fix build when HAS_NETWORKING is false on nrf52 (#4237) (tested on a rak4631 by setting HAS_ETHERNET false when shrinking image) * If `toPhoneQueue` is full, still increment `fromNum` to avoid client never getting packets (#4246) * Update to SoftDevice 7.3.0 for wio-sdk-wm1110 and wio-tracker-wm1110 (#4248) * Update variant.h * Update wio-tracker-wm1110.json * Update wio-sdk-wm1110.json * Update platformio.ini * Update platformio.ini * Add files via upload * Add files via upload * Update variant.h --------- Co-authored-by: Mike <mikhael.skvortsov@gmail.com> Co-authored-by: Ben Meadors <benmmeadors@gmail.com> Co-authored-by: Mike G <mkgin@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: thebentern <9000580+thebentern@users.noreply.github.com> Co-authored-by: GUVWAF <78759985+GUVWAF@users.noreply.github.com> Co-authored-by: Warren Guy <5602790+warrenguy@users.noreply.github.com> Co-authored-by: todd-herbert <herbert.todd@gmail.com> Co-authored-by: geeksville <kevinh@geeksville.com> Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz> Co-authored-by: Alexander <156134901+Dorn8010@users.noreply.github.com> Co-authored-by: Thomas Göttgens <tgoettgens@gmail.com> Co-authored-by: quimnut <github@dopegoat.com> Co-authored-by: Manuel <71137295+mverch67@users.noreply.github.com> Co-authored-by: Agent Blu, 006 <blu006@ucr.edu> Co-authored-by: Mark Trevor Birss <markbirss@gmail.com> |
||
---|---|---|
.. | ||
platformio.ini | ||
README.md | ||
variant.cpp | ||
variant.h | ||
xiao_ble.sh | ||
xiao_nrf52840_ble_bootloader-0.7.0-22-g277a0c8_s140_7.3.0.zip | ||
xiao-ble-internal-format.uf2 |
Xiao BLE/BLE Sense + Ebyte E22-900M30S
A step-by-step guide for macOS and Linux
Introduction
This guide will walk you through everything needed to get the Xiao BLE (or BLE Sense) running Meshtastic using an Ebyte E22-900M30S LoRa module. The combination of the E22 with an nRF52840 MCU is desirable because it allows for both very low idle (Rx) power draw and high transmit power. The Xiao BLE is a small but surprisingly well-appointed nRF52840 board, with enough GPIO for most Meshtastic applications and a built-in LiPo charger. The E22, on the other hand, is a famously inscrutable and mysterious beast. It is one of the more readily available LoRa modules capable of transmitting at 30 dBm, and includes an LNA to boost its Rx sensitivity a few dB beyond that of the SX1262. However, its documentation is relatively sparse overall, and seems to merely hint at (or completely omit) several key details regarding its functionality. Thus, much of what follows is a synthesis of my observations and inferences over the course of many hours of trial and error.
Acknowledgement and friendly disclaimer
Huge thanks to those in the community who have forged the way with the E22, without whose hard work none of this would have been possible! (thebentern, riddick, rainer_vie, beegee-tokyo, geeksville, caveman99, Der_Bear, PlumRugOfDoom, BigCorvus, and many others.)
Please take the conclusions here as a tentative work in progress, representing my current (and fairly limited) understanding of the E22 when paired with this particular MCU. It is my hope that this guide will be helpful to others who are interested in trying a DIY Meshtastic build, and also be subject to revision by folks with more experience and better test equipment.
Obligatory liability disclaimer
This guide and all associated content is for informational purposes only. The information presented is intended for consumption only by persons having appropriate technical skill and judgement, to be used entirely at their own discretion and risk. The authors of this guide in no way provide any warranty, express or implied, toward the content herein, nor its correctness, safety, or suitability to any particular purpose. By following the instructions in this guide in part or in full, you assume all responsibility for all potential risks, including but not limited to fire, property damage, bodily injury, and death.
Note
These instructions assume you are running macOS or Linux, but it should be relatively easy to translate each command for Windows. (In this case, in step 2 below, each line of xiao_ble.sh
would also need to be converted to the equivalent Windows CLI command and run individually.)
1. Update Bootloader
The first thing you will need to do is update the Xiao BLE's bootloader. The stock bootloader is functionally very similar to the Adafruit nRF52 UF2 bootloader, but apparently not quite enough so to work with Meshtastic out of the box.
-
Connect the Xiao BLE to your computer via USB-C.
-
Install
adafruit-nrfutil
by following the instructions here. -
Open a terminal window and navigate to
firmware/variants/xiao_ble
(wherefirmware
is the directory into which you have cloned the Meshtastic firmware repo). -
Run the following command, replacing
/dev/cu.usbmodem2101
with the serial port your Xiao BLE is connected to:adafruit-nrfutil --verbose dfu serial --package xiao_nrf52840_ble_bootloader-0.7.0-22-g277a0c8_s140_7.3.0.zip --port /dev/cu.usbmodem2101 -b 115200 --singlebank --touch 1200
-
If all goes well, the Xiao BLE's red LED should start to pulse slowly, and you should see a new USB storage device called
XIAO-BOOT
appear underLocations
in Finder.
2. PlatformIO Environment Preparation
Before building Meshtastic for the Xiao BLE + E22, it is necessary to pull in SoftDevice 7.3.0 and its associated linker script (nrf52840_s140_v7.ld) from Seeed Studio's Arduino core. The xiao_ble.sh
script does this.
-
In your terminal window, run the following command:
sudo ./xiao_ble.sh
3. Build Meshtastic
At this point, you should be able to build the firmware successfully.
-
In VS Code, press
Command Shift P
to bring up the command palette. -
Search for and run the
Developer: Reload Window
command. -
Bring up the command palette again with
Command Shift P
. Search for and run thePlatformIO: Pick Project Environment
command. -
In the list of environments, select
env:xiao_ble
. PlatformIO may update itself for a minute or two, and should let you know once done. -
Return to the command palette once again (
Command Shift P
). Search for and run thePlatformIO: Build
command. -
PlatformIO will build the project. After a few minutes you should see a green
SUCCESS
message.
4. Wire the board
Connecting the E22 to the Xiao BLE is straightforward, but there are a few gotchas to be mindful of.
-
On the Xiao BLE:
-
Pins D4 and D5 are currently mapped to
PIN_WIRE_SDA
andPIN_WIRE_SCL
, respectively. If you are not using I²C and would like to free up pins D4 and D5 for use as GPIO,PIN_WIRE_SDA
andPIN_WIRE_SCL
can be reassigned to any two other unused pin numbers. -
Pins D6 and D7 were originally mapped to the TX and RX pins for serial interface 1 (
PIN_SERIAL1_RX
andPIN_SERIAL1_TX
) but are currently set to -1 invariant.h
. If you need to expose a serial interface, you can restore these pins and move e.g.SX126X_RXEN
to pin 4 or 5 (the opposite should work too).
-
-
On the E22:
-
There are two options for the E22's
TXEN
pin:-
It can be connected to the MCU on the pin defined as
SX126X_TXEN
invariant.h
. In this configuration, the MCU will control Tx/Rx switching "manually". As long asSX126X_TXEN
andSX126X_RXEN
are both defined invariant.h
(and neither is set toRADIOLIB_NC
),SX126xInterface.cpp
will initialize the E22 correctly for this mode. -
Alternately, it can be connected to the E22's
DIO2
pin only, with neitherTXEN
norDIO2
being connected to the MCU. In this configuration, the E22 will control Tx/Rx switching automatically. Invariant.h
, as long asSX126X_TXEN
is defined asRADIOLIB_NC
, andSX126X_RXEN
is defined and connected to the E22'sRXEN
pin, andE22_TXEN_CONNECTED_TO_DIO2
is defined,SX126xInterface.cpp
will initialize the E22 correctly for this mode. This configuration frees up a GPIO, and presents no drawbacks that I have found.
-
Note that any combination other than the two described above will likely result in unexpected behavior. In my testing, some of these other configurations appeared to "work" at first glance, but every one I tried had at least one of the following flaws: weak Tx power, extremely poor Rx sensitivity, or the E22 overheating because TXEN was never pulled low, causing its PA to stay on indefinitely.
-
Along the same lines, it is a good idea to check the E22's temperature frequently by lightly touching the shield. If you feel the shield getting hot (i.e. approaching uncomfortable to touch) near pins 1, 2, and 3, something is probably misconfigured; disconnect both the Xiao BLE and E22 from power and double check wiring and pin mapping.
-
-
Whether you opt to let the E22 control Rx and Tx or handle this manually, the E22's
RXEN
pin must always be connected to the MCU on the pin defined asSX126X_RXEN
invariant.h
.
-
Note
The default pin mapping in variant.h
uses 'automatic Tx/Rx switching' mode. If you wire your board for manual Rx/Tx switching, make sure to update variant.h
accordingly by commenting/uncommenting the necessary lines in the 'E22 Tx/Rx control options' section.
Example wiring for "E22 automatic Tx/Rx switching" mode:
MCU -> E22 connections
Xiao BLE pin | variant.h definition | E22 pin | Notes |
---|---|---|---|
D0 | SX126X_CS | 19 (NSS) | |
D1 | SX126X_DIO1 | 13 (DIO1) | |
D2 | SX126X_BUSY | 14 (BUSY) | |
D3 | SX126X_RESET | 15 (NRST) | |
D7 | SX126X_RXEN | 6 (RXEN) | These pins must still be connected, and SX126X_RXEN defined in variant.h , otherwise Rx sensitivity will be poor. |
D8 | PIN_SPI_SCK | 18 (SCK) | |
D9 | PIN_SPI_MISO | 16 (MISO) | |
D10 | PIN_SPI_MOSI | 17 (MOSI) |
E22 -> E22 connections:
E22 pin | E22 pin | Notes |
---|---|---|
TXEN | DIO2 | These must be physically connected for automatic Tx/Rx switching to work. |
Note
The schematic (xiao-ble-e22-schematic.png
) in the eagle-project
directory uses this wiring.
Example wiring for "Manual Tx/Rx switching" mode:
MCU -> E22 connections
Xiao BLE pin | variant.h definition | E22 pin | Notes |
---|---|---|---|
D0 | SX126X_CS | 19 (NSS) | |
D1 | SX126X_DIO1 | 13 (DIO1) | |
D2 | SX126X_BUSY | 14 (BUSY) | |
D3 | SX126X_RESET | 15 (NRST) | |
D6 | SX126X_TXEN | 7 (TXEN) | |
D7 | SX126X_RXEN | 6 (RXEN) | |
D8 | PIN_SPI_SCK | 18 (SCK) | |
D9 | PIN_SPI_MISO | 16 (MISO) | |
D10 | PIN_SPI_MOSI | 17 (MOSI) |
E22 -> E22 connections: (none)
5. Flash the firmware to the Xiao BLE
-
Double press the Xiao's
reset
button to put it in bootloader mode. -
In a terminal window, navigate to the Meshtastic firmware repo's root directory, and from there to
.pio/build/xiao_ble
. -
Convert the generated
.hex
file into a.uf2
file:../../../bin/uf2conv.py firmware.hex -c -o firmware.uf2 -f 0xADA52840
-
Copy the new
.uf2
file to the Xiao's mass storage volume:cp firmware.uf2 /Volumes/XIAO-BOOT
-
The Xiao's red LED will flash for several seconds as the firmware is copied.
-
Once the firmware is copied, to verify it is running, run the following command:
meshtastic --noproto
-
Then, press the Xiao's
reset
button again. You should see a lot of debug output logged in the terminal window.
6. Troubleshooting
-
If after flashing Meshtastic, the Xiao is bootlooped, look at the serial output (you can see this by running
meshtastic --noproto
with the device connected to your computer via USB).-
If you see that the SX1262 init result was -2, this likely indicates a wiring problem; double check your wiring and pin mapping in
variant.h
. -
If you see an error mentioning tinyFS, this may mean you need to reformat the Xiao's storage:
-
Double press the
reset
button to put the Xiao in bootloader mode. -
In a terminal window, navigate to the Meshtastic firmware repo's root directory, and from there to
variants/xiao_ble
. -
Run the following command:
cp xiao-ble-internal-format.uf2 /Volumes/XIAO-BOOT
-
The Xiao's red LED will flash briefly as the filesystem format firmware is copied.
-
Run the following command:
meshtastic --noproto
-
In the output of the above command, you should see a message saying "Formatting...done".
-
To flash Meshtastic again, repeat the steps in section 5 above.
-
-
If you don't see any specific error message, but the boot process is stuck or not proceeding as expected, this might also mean there is a conflict in
variant.h
. If you have made any changes to the pin mapping, ensure they do not result in a conflict. If all else fails, try reverting your changes and using the known-good configuration included here. -
The above might also mean something is wired incorrectly. Try reverting to one of the known-good example wirings in section 4.
-
-
If the E22 gets hot to the touch:
- The power amplifier is likely running continually. Disconnect it and the Xiao from power immediately, and double check wiring and pin mapping. In my experimentation this occurred in cases where TXEN was inadvertenly high (usually due to a pin mapping conflict).
7. Notes
-
There are several anecdotal recommendations regarding the Tx power the E22's internal SX1262 should be set to in order to achieve the advertised output of 30 dBm, ranging from 4 (per this article in the RadioLib github repo) to 22 (per this conversation from the Meshtastic Discord). When paired with the Xiao BLE in the configurations described above, I observed that the output is at its maximum when Tx power is set to 22.
-
To achieve its full output, the E22 should have a bypass capacitor from its 5V supply to ground. 100 µF works well.
-
The E22 will happily run on voltages lower than 5V, but the full output power will not be realized. For example, with a fully charged LiPo at 4.2V, Tx power appears to max out around 26-27 dBm.
8. Testing Methodology
During what became a fairly long trial-and-error process, I did a lot of careful testing of Tx power and Rx sensitivity. My methodology in these tests was as follows:
-
All tests were conducted between two nodes:
-
The Xiao BLE + E22 coupled with an Abracon ARRKP4065-S915A ceramic patch antenna
-
A RAK 5005/4631 coupled with a Laird MA9-5N antenna via a 4" U.FL to Type N pigtail.
-
No other nodes were powered up onsite or nearby.
-
-
Each node and its antenna was kept in exactly the same position and orientation throughout testing.
-
Other environmental factors (e.g. the location and resting position of my body in the room while testing) were controlled as carefully as possible.
-
Each test comprised at least five (and often ten) runs, after which the results were averaged.
-
All testing was done by sending single-character messages between nodes and observing the received RSSI reported in the message acknowledgement. Messages were sent one by one, waiting for each to be acknowledged or time out before sending the next.
-
The E22's Tx power was observed by sending messages from the RAK to the Xiao BLE + E22 and recording the received RSSI.
-
The opposite was done to observe the E22's Rx sensitivity: messages were sent from the Xiao BLE + E22 to the RAK, and the received RSSI was recorded.
While this cannot match the level of accuracy achievable with actual test equipment in a lab setting, it was nonetheless sufficient to demonstrate the (sometimes very large) differences in Tx power and Rx sensitivity between various configurations.