Wio-E5-LE Lora P2P range issues

Hi,
I have written some code to send a short message from a Wio-E5-LE Mini to a Wio-E5-LE Devboard.
While everything is working, I can’t seem to get a good working distance between the units.

I am using the antennas that comes with the kits, and get a range of about 250 meters line of sight (one node inside my house though). This is about the same range that I can get with a simple ASK remote transmitter (the type for opening garage doors etc), so I know something is wrong here.

These are my settings

#define RF_FREQUENCY                                868000000 /* Hz */
#define TX_OUTPUT_POWER                             14        /* dBm */
#define LORA_BANDWIDTH                              0         /* [0: 125 kHz, 1: 250 kHz, 2: 500 kHz, 3: Reserved] */
#define LORA_SPREADING_FACTOR                       12        /* [SF7..SF12] */
#define LORA_CODINGRATE                             1         /* [1: 4/5, 2: 4/6, 3: 4/7, 4: 4/8] */
#define LORA_PREAMBLE_LENGTH                        8         /* Same for Tx and Rx */
#define LORA_SYMBOL_TIMEOUT                         5         /* Symbols */
#define LORA_FIX_LENGTH_PAYLOAD_ON                  false
#define LORA_IQ_INVERSION_ON                        false

If I have both units connected to my computer, with about 60cm between them, I get RSSI around -70dbm, and SNR 4db, which to me sounds quite bad, right?
I have a payload of 8 bytes.

I know I can perhaps tweak symbol timeout, and coding rate a bit more, but I like to understand why the RSSI is where it is, as a starter.
Unfortunately, I only have these two devices, so I can test if one happens to defect, but I get about the same rssi/snr values at both ends, so I am thinking they are ok. But what about the antennas, could it be that they are part of the problem??

Unfortunately, I did not check the devices with the AT firmware that came with them.

Hi there,

So those sound like an Issue, or could be the LIB’s you chose,… So go Check out this thread by the power Ninja @msfujino :ninja:
It’s got the Receipts…
24 km’ wow!

HTH
GL :slight_smile: PJ :v:

Yes, I have seen that thread, and it has similar setup, afaict, the main difference is that I’m using E5-LE, but I guess it should not make much of a difference, since @msfujino is using the same output power. Also 915mhz instead of 868, witch also should not make a big difference. Same antennas as well, I think.

I am using STM32 directly, I think it is easier to use than arduino, so I don’t have the Arduino build environment for STM32. But it I can’t pursue this problem any other way, maybe I’ll have to set it up, to see if my problem is related to FW rather than HW.

1 Like

Hi there,

Hmmm, yea I think he chose the other unit for his use case and testing.(lowest power on the Planet) :smile: But agree it should be better than what your getting , Something is OFF, I would start with the Transmitter power first try stepping it down and the back up. Also if you have an SDR laying around that would be helpful. LOL same as the $9 dongle for the BLE I now use for everything and couldn’t work without, talk about getting your monies worth. :face_with_open_eyes_and_hand_over_mouth:

What Libraries and BSP 's are you using and maybe some additional info on the DEV environment you have going.
Others will chime in that have a lot of good info here too.

HTH
GL :slight_smile: PJ :v:

Sure, I am using the STM32Cube 1.17.0 along with STM32Cube_FW_WL_V1.3.0, along with changes the of the stm32wlxx_nucleo_radio.h, which I am unsure of its origin. Anyway it contains the following to match the wio-e5 module ;

#define RADIO_CONF_RFO_LP_HP                     0U
#define RADIO_CONF_RFO_LP                        1U
#define RADIO_CONF_RFO_HP                        2U

#define RADIO_CONF_TCXO_NOT_SUPPORTED            0U
#define RADIO_CONF_TCXO_SUPPORTED                1U

#define RADIO_CONF_DCDC_NOT_SUPPORTED            0U
#define RADIO_CONF_DCDC_SUPPORTED                1U

#define RF_SW_CTRL1_PIN                          GPIO_PIN_4
#define RF_SW_CTRL1_GPIO_PORT                    GPIOA
#define RF_SW_CTRL1_GPIO_CLK_ENABLE()            __HAL_RCC_GPIOA_CLK_ENABLE()
#define RF_SW_RX_GPIO_CLK_DISABLE()              __HAL_RCC_GPIOA_CLK_DISABLE()

#define RF_SW_CTRL2_PIN                          GPIO_PIN_5
#define RF_SW_CTRL2_GPIO_PORT                    GPIOA
#define RF_SW_CTRL2_GPIO_CLK_ENABLE()            __HAL_RCC_GPIOA_CLK_ENABLE()
#define RF_SW_CTRL2_GPIO_CLK_DISABLE()           __HAL_RCC_GPIOA_CLK_DISABLE()

#define RF_TCXO_VCC_PIN                          GPIO_PIN_0
#define RF_TCXO_VCC_GPIO_PORT                    GPIOB
#define RF_TCXO_VCC_CLK_ENABLE()                 __HAL_RCC_GPIOB_CLK_ENABLE()
#define RF_TCXO_VCC_CLK_DISABLE()                __HAL_RCC_GPIOB_CLK_DISABLE()

Not really sure where the st radio stuff is from, but I guess it’s a mix of their own, using stuff from Semtech.

I do have a SDR, and also a Siglent spec, but not sure how I can use them in this? I don’t have too much rf experience for this kind of stuff (learning)…

I also have a Semtech SX1261MB2xAS mbed shield, that I guess I could wire up to something, to compare with. But I am not sure it is the place to start.

Reducing the tx power is simple, I guess I can do this on one side, while keeping the other as is. I tried the very short antenna that came with the Semtech shield on the WIO-E5-LE, and I get different result if I stick it on the WIO-E5-LE Mini vs the WIO-E5-LE Devboard; the Mini reacts worse, whereas with the full devboard is only slighte worse than with the big Seeed antennas. But maybe this is because the bigger devboard acts as a bigger ground plane. All in all, I think this test gives me the impression that the Seeed antennas are equally good/bad, so I think I can rule them out.

1 Like

So I found my issue, turned out to be the rx/tx switch configuration.
If someone has similar concerns about range vs rssi on the bench, I now get about -15 between two nodes and setup as specified above.

1 Like

can you say what the rx/tx switch configuration is? … what that means

There’s an external (to the stm32wl*) switch that the stack controls, which changes between rx/tx path, and I had it wrong in my code. But since the LoRa is so sensitive it kind of worked even without the switch.
Yesterday I had a walk, testing my range, and only at one place on the other side of a small hill, did I not get proper communication. Not that I did a long walk, only about 2km - I just resurrected from some kind of horrible flu, and it was -11 outside… :slight_smile:
Will take the bicycle the next time, to save time.

1 Like

I would love more info on the RADIO_CONF_RFO setting, I’m having a similar issue, I can’t get better than -31dBm between two modules sitting on the same bench.

I’m using this STM32WL_P2P_Verify_1 arduino example for the lora-e5-mini shared in the post PJ linked above.

Radiolib uses the following to configure the switch

STM32WLx radio = new STM32WLx_Module();
static const uint32_t rfswitch_pins[] = {PA4, PA5, RADIOLIB_NC, RADIOLIB_NC, RADIOLIB_NC};
static const Module::RfSwitchMode_t rfswitch_table[] = {
  {STM32WLx::MODE_IDLE,  {LOW,  LOW}},
  {STM32WLx::MODE_RX,    {HIGH, LOW}},
  {STM32WLx::MODE_TX_HP, {LOW, HIGH}},  // for LoRa-E5 mini
//  {STM32WLx::MODE_TX_LP, {HIGH, HIGH}},   // for LoRa-E5-LE mini
  END_OF_MODE_TABLE,
};

Any suggestions on what these settings mean and should be? I see there are different settings for the “LORA-E5-LE” version so I wonder if they mean modules labelled WIO-E5-LE.

Wio-E5-LE-HF and Wio-E5-HF are different modules and are clearly marked on the label (the letters are small and confusing). Select the MODE_TX_HP or MODE_TX_LP appropriate for the module to be used.

You may also refer to the following links

1 Like

We are using the Wio-E5 Wireless Module(link). We have tested different antennas, but we couldn’t achieve distances beyond 400 meters. How should the RX/TX switch configuration be adjusted as you mentioned? @vespaman

We have developed some form of P2P link with WIO-Lora-E5 modules. It is a dedicated pair in unidirectional, one doing Tx and one doing Rx Everything works out, but we cannot get range out of these devlces. Transmitting at -15dBm, we get good signal from using a Spectrum analyzer at 2m away, showing correct signal strength. At SF6, CR4/5, 250kHz, 865MHz, we cannot get more than 300m range. The antenna, is hand-tuned perfectly, with RL better than -15dB. At height, so no Fresnel zone issues etc.
Testing with direct connection (SMA-to-SMA), the RSSI reads -68dBm. Add a 40dB attenuator, we read -69dBm. change the attenuator to 50dB, and it reads -108dBm.
We have verified that we correctly controls PA4 and 5.
Any suggestion/experience with such bad receive sensitivity?

Is RF_SW switched correctly for transmitting and receiving?

We have verified that PA4/5 is send correctly. I even open up the shield and measure physically on the RF-MUX switch. Pin 4 is Low, Pin 6 is High.

I have a few questions.

  1. Are PA4 and PA5 used to control RF_SW?
  2. Is PA4=LOW and PA5=HIGH in receive mode?
  3. When in transmit mode, iss PA4=HIGH and PA5=LOW?
  4. What is the model number of the RF_SW used?

I don’t know if this will be helpful, but the following link discusses reception sensitivity and RF_SW.

I experimented with LoRa-E5 mini and it should be able to communicate over 20km in line of sight with a λ/2 antenna.

Hi there,

So Not sure if it relates to your issue , but while I was testing. Initially I was getting a ton of received packets, turned out I wasn’t the receiver thought it was though. You can see the test demo code posted on the other Lora Thread wio_sx1262_s3…
Check your code and see if your doing the transmit and receive too close together. try also Keying the receiver early. When I say that an SX1262 receiver picks up its own transmission, we’re really talking about leakage or self-interference that can happen when:

  • A LoRa transmitter (TX) is very close to the LoRa receiver (RX).
  • Or… they are the same module, switching between TX and RX quickly.
  • Or… they are on separate boards just a few feet (or inches) apart, during testing.

:satellite: How This Happens:

  1. High TX Power Output (e.g. 22 dBm):
  • The LoRa radio is blasting out RF energy.
  • If there’s no physical isolation or shielding, some of that energy can leak into the receiver’s front-end.
  1. The SX1262 module uses the same antenna port for TX and RX:
  • There’s a fast internal switch (TX/RX switch) inside the RF path.
  • Even when you’re in receive mode, residual energy from your own TX can still ring or reflect through the antenna and get picked up again.
  1. Minimal Time Delay Between TX and RX:
  • If you’re using startTransmit() followed by an immediate startReceive() (or even ISR receive), the residual energy from your own TX can cause artifacts in your receive path.

:construction: How This Affects Range Testing:

This self-interference can cause false positives or artificially inflated performance, such as:

Symptom Description
Super high RSSI values (e.g., -30 dBm) Might look like a great signal, but you’re really just “hearing yourself”.
Reliable PING/PONG at long ranges that suddenly fails at very close range That’s because TX signal overwhelms the RX. This is called RX desensitization.
PONG messages received even when HomeBase is off This usually means Rover is retransmitting or replaying stale packets due to internal noise or leftover interrupts.

:wrench: How To Prevent It:

  1. Increase distance between TX and RX during testing:
  • 2 meters is good indoors, >10 meters is better for outdoor testing.

  1. Use antenna separation or shielding:
  • If you’re doing bench tests, use metal shields or angle the antennas away from each other.
  1. Add a small delay before RX starts after TX:
  • Let the RF path settle. Even delay(100) ms can help in some cases.
  1. Lower TX power during close-proximity testing:
  • Use radio.setOutputPower(2); instead of 22.
  1. Validate received data:
  • Check for a matching UID or packet signature before replying.
  • I’m doing this from @msfujino with 0x1234ABCD—which is perfect.

The SX1262 is a great radio, but it’s not immune to RF realities. Being aware of TX-RX bleedover and how to mitigate it gives a more accurate range testing, and helps avoid being misled by “great” results that are really just self-interference. I went around in a circle initially even when the Home base was unplugged , Rover ws receiving packets…WHAT! :face_with_open_eyes_and_hand_over_mouth:

HTH
GL :slight_smile: PJ :v:

Well, am using Seeed Lora-E5 module. PA4/5 is per document. I do not know if it is using the same RF mux per SX1262. I assume it is similar. Also in Tx, output power is reasonably, so no reason it’s flipped.
Those long distance link is not helpful yet. We have RF expert on the team with all the necessary equipment. Path loss is well understood.

The RSSI is strange. SNR is negative!

The link is a uni-directional. Tx and Rx are separate module. Encryption is involved, validation is at decoded level too, so cross from non-related module will never happen. Rx module is always continuously receiving.

1 Like

Hi there,

Sounds very cool, You got a Picture of this Apparatus ? How close are they to each other? If you don’t mind…the pair on each end?

HTH
GL :slight_smile: PJ :v:

Can you measure RF power ? (radiated) Have you tried without Encryption ?
:+1:
I notice the OP was using this?;
#define RF_FREQUENCY 868000000 /* Hz */
Seems too close to the Cellular bands?

I’m using these : for example.

:white_check_mark: LoRa Configuration Parameters

Parameter Value Description
Frequency 915.0 MHz Standard for US ISM band (can be changed to 868.0 or 433.0 for EU/Asia)
Spreading Factor SF7 Faster transmission, shorter range
Bandwidth 125.0 kHz Good balance between range and speed
Coding Rate 4/5 (CR = 5) More error correction, increases reliability
Output Power 22 dBm Max power for SX1262 (can be adjusted via button)
Preamble Length Default (8) Could be increased for longer-range reliability (optional tweak)
Sync Word Default (0x12) Used to distinguish private networks (can be changed for custom use)

Not sure what picture you need. The inside of this Seeed module with it’s shield removed?

Yes we can measure power, both direct and radiated.

How close? We are talking about direct SMA to SMA without antenna, yet the RSSI read -68dBm, SNR says -8dB. Being direct, cellular is not a issue.
Preamble length is forced to 12 symbol, by the library.
Encryption is on payload, why would it affect RSSI?