Pico-LoRa-SX1262 Pico-W Interference

Support
1

After my own extensive testing, I have come to the conclusion that you SHOULD NOT use a Pico-W module with this LoRa module WITHOUT separation. This little board is my LoRa to MQTT gateway (via WiFi) for the Roverling project.

IMG_1091
IMG_10911920Ɨ1440 355 KB

Wired like this, communication is good for 500+ meters line of site. With Roverling inside a large metal shed, and the base station 80m away inside and at the back of a timber structure, we get around -105dBm RSSI and an SNR of around -3dB. Excellent results.

Now, if instead you just stuck the LoRa module on top of the Pico-W, as it is designed to operate, and leave everything else the same, you will get a 10 to 20 dB drop in SNR as you start to go below -70dBm RSSI. This is only happens with the WiFi variant, if I use a plain old RP2040 Zero, good results again.

This is a massive difference, the Pico-W must generate so much noise as to swamp low level signals entirely. I would suggest, separate modules as far as possible, and to be sure Iā€™ve even stuck a shield in between.

Important to note that the noise doesnā€™t impact transmitted signal from base station and in either configuration the RSSI and SNR measure the same at the remote end.

mark

3 Likes
2

Possibly the close proximity of the WiFi antenna to the LoRa antenna is causing the swamping.
If the WiFi chip on the Pico is inactive it should not interfere.
The frequency bands are far enough apart but the RF outputs would interfere with each other.

Maybe you have the chip turned off, and I am wrong here.
But good to note the Pico W is not the best choice when using the LoRa board.

Cheers
Jim

1 Like
3

Possibly the close proximity of the WiFi antenna to the LoRa antenna is causing the swamping.

100% correct, separation is key. Even checked RF outputs using an SDR spectrum analyzer. As expected no crossover, as you stated channels are more than far enough apart.

The solution looks ugly, but once you print a caseā€¦

IMG_1092
IMG_10921556Ɨ2021 379 KB

2 Likes
4

Awesome troubleshooting, Mark!

Iā€™ll update the LoRa module product page with this info so others can benefit from your excellent work.

5

Hi Gents, is there a way to disable the wifi module on the pico? Iā€™ve just finished putting together a long distance remote control but have noticed the signal has diminished significantly (the lora and pico are pretty well situated back to back). Otherwise I might have to replace with the non-wifi version. Thanks

1 Like
6

Hey Brett,

This works for me.

import network
wlan = network.WLAN(network.STA_IF)
ap_if = network.WLAN(network.AP_IF)
wlan.active(False)
ap_if.active(False)
wlan.deinit()
3 Likes
7

Although I have found that I can get away with having both Wi-Fi and LoRa modules on the same board with less than 10cm spacing between RF components. Iā€™m using a high gain antenna for WiFi which reduces LoRa SNR by 10dB whilst the onboard PCB trace antenna registers a 3dB reduction on the LilyGo T-PicoC3 (RP2040 + ESP32-C3, running ESP-AT).

It also helps heaps if I schedule my telemetry so that Iā€™m transmitting LoRa and W-iFi UDP at staggered times. My receive LoRa SNR at the vehicle end, is only diminished by a few dB with this configuration. It has no impact on base station SNR or RSSI.

IMG_1215
IMG_12151920Ɨ1440 374 KB

5 Likes
8

Thanks Mark, I appreciate your help, will give that a go. Itā€™s for a farmer who wants to activate his front gate from 3kā€™s away so itā€™d be good to give it a good test and get reasonable coverage before I head out there (outback Qld). Cheers

2 Likes
9

Okay, a bit of an update, unfortunately my range hasnā€™t had much improvement. Iā€™m only getting around 100 metres with line of sight, something is definitely amiss here. I started looking at changing the power level but the command in the command specs doesnā€™t seem to do much, in fact if I enter in manually it stops tx, if anyone has any thoughts Iā€™d love to hear them. Iā€™m using a pico pi with Lora E5 module at both ends, possibly I have a lora module playing up or one of the antennas is letting me down as Iā€™m sure I had much better range with the flexi uFl antennas that I used for prototyping. Basic code for testing and trying to set the tx level are:

from machine import UART, Pin
uart1 = UART(1, baudrate=9600, tx=Pin(4), rx=Pin(5))
uart1.write(ā€˜at+mode=test\nā€™)
uart1.write(ā€˜at+test=rfcfg,915,SF12,125,12,15,22,ON,OFF,OFF\nā€™)
uart1.write(ā€˜at+test=txlrpkt,ā€œ01ā€\nā€™)

Thanks in advance, Brett

another update: I just noticed if I add the rfcfg command to the loop then it accepts it - hopefully thatā€™s increased the power - back out for more testing :slight_smile:

10

Hi Brett

might be asking a bit much.
Cheers Bob

11

He lets my Son and I go out there to play so am happy to give it a try, plus Iā€™m learning new things :slight_smile:

12

Hi Brett
Good. You will I am sure (learn new things).
Cheers Bob

1 Like
13

Not sure about 3km, but this config works for me, tested to 3.1kbps @ 500m

Each doubling of the bandwidth correlates to almost 3dB less link budget
Each unit increase in SF correlates to about 2.5dB extra link budget

So if you donā€™t have much to transmit and want better range, lower B/W as much as possible and increase SF. It might help improve your sensitivity substantially.

################################################################################
# LoRa Telemetry to Gateway, Commands from Gateway
#
# Power set to 22 normally - reduce to 0 for inside testing
# Limit outgoing packet size to 70 bytes and return/command packet to 32 bytes   
# Effective Data Rate: 3.1 kbps, sensitivity -127dBm
# Each doubling of the bandwidth correlates to almost 3dB less link budget
# Each unit increase in SF correlates to about 2.5dB extra link budget

PB12 = Pin('B12')
PB13 = Pin('B13')
PB14 = Pin('B14')
PB15 = Pin('B15')
PB9 = Pin('B9')    #LORA_DI01
PB8 = Pin('B8')    #LORA_RESET
PC4 = Pin('C4')    #LORA_BUSY

LoRa = SX1262(spi_bus=2, clk=PB13, mosi=PB15, miso=PB14, cs=PB12, irq=PB9, rst=PB8, gpio=PC4) 
LoRa.begin(freq=920.25, bw=125, sf=8, cr=5, syncWord=0x12, power=22, currentLimit=140.0, 
    preambleLength=8,implicit=False, implicitLen=0xFF, crcOn=True, txIq=True, rxIq=True,
    tcxoVoltage=1.7, useRegulatorLDO=True, blocking=True)
14

Thanks Mark, good points to know, every little bit will help (btw, it looks more like 1.5klms so fingers crossed). My biggest hurdle was setting the RF Config, it wouldnā€™t accept it straight after the line to put it into Test mode, nor both when placed in the loop. I ended up using a bit of my code plus what the Core guys had for their test script, plus your Wlan disabling code. I didnā€™t realise that it was defaulting to 868k with SF7 and 14dbm after setting it to test mode, I wonā€™t count my chickens just yet but itā€™s looking promising.

Thanks again for your help, let me know if you ever need anything welded up/fabricated, what I donā€™t know about coding I make up for with welding skills, well try to :slight_smile:

Final TX code:

P2P Transmitter

Transmit test data direct to another Makerverse LoRa Breakout

from machine import UART, Pin
from utime import sleep_ms
import network
wlan = network.WLAN(network.STA_IF)
ap_if = network.WLAN(network.AP_IF)
wlan.active(False)
ap_if.active(False)
wlan.deinit()

sleep_ms(2000)
uart = UART(1, baudrate=9600, tx=Pin(4), rx=Pin(5),timeout=1000)
switch1 = Pin(20, Pin.IN, Pin.PULL_DOWN)
led = Pin(19, Pin.OUT)

def receive_uart():
ā€˜ā€™ā€˜Polls the uart until all data is dequeuedā€™ā€˜ā€™
rxData=bytes()
while uart.any()>0:
rxData += uart.read(1)
sleep_ms(2)
return rxData.decode(ā€˜utf-8ā€™)

def send_AT(command):
ā€˜ā€™ā€˜Wraps the ā€œcommandā€ string with AT+ and \r\nā€™ā€˜ā€™
buffer = ā€˜ATā€™ + command + ā€˜\r\nā€™
uart.write(buffer)

sleep_ms(300)

uart.readline()

def echo():
while uart.any() > 0:
rxData = uart.readline()
print(rxData.decode(ā€˜utf-8ā€™))

send_AT(ā€˜+MODE=TESTā€™)
send_AT(ā€˜+test=rfcfg,920.25,SF12,125,12,15,22,ON,OFF,OFF\nā€™)

while True:

if switch1.value() == 1:
    #send_AT('+test=?\n') # for checking RF config
    send_AT('+test=txlrpkt,"01"\n')  # send 01
    echo() # show debug data from LoRa-E5 module
    led.value(1) # turn led on when button is pressed
elif switch1.value() == 0:
    #send_AT('+test=txlrpkt,"00"\n')  # send 00
    led.value(0)
sleep_ms(2)

echo() # show debug data from LoRa-E5 module



print("")
sleep_ms(200)
1 Like
15

Okay, Iā€™ve seen the error of my ways, I just needed a 300ms delay between AT commands, youā€™d think an old comms tech would know better :wink:

2 Likes
16

Would adding an ethernet hat to a non pico-w fix this problem?
as in still using Lora, but still have connectivity for my mqtt traffic?

2 Likes
17

Hi Craig,

It definitely would for static projects in the home, but Mark has all of this mounted to a rover: https://core-electronics.com.au/projects/roverling-mk2/

Liam

1 Like
18

Hi Liam,
That makes sense for Marks projectā€¦
I was curious about alternatives for my static setup which is suffering the same issue with interferenceā€¦
Craig.

1 Like
19

Hey Mark, is there anything particular I need to consider when increasing the SF value? I notice when going from SF9 to 10 I had to increase the sleep timer at the other end, Iā€™m guessing thatā€™s to allow the buffer extra time to collect packets due to the increased time on air. Anything else to consider? I managed to get 865 metres using SF9 in suburbia (clear line of sight), so set it to SF10 for out at the property but am only getting a range of about 500 metres.

Thanks,

Brett

20

Hi Brett. Mark
Would you kindly help out someone who has been out of the business for quite a while and has not kept up with abbreviations.

What exactly is this ā€œSFā€ value (9 and 10 quoted).

I am just interested. When it comes to the RF side of things some strange things can happen, particularly in the 900MHz to iGHz range. That is the area used for ā€œTropposcatterā€ and the particular characteristics can be both helpful and detrimental.

Thanks
Cheers Bob