Configuring a Pico and Lora P2P

1

Hi There,
I have a Pico connected to a Lora SX126X module and a second Pico W connected to another SX126x module. I have them talking to each other using Lora with a library I found here.

The library appears really well written.

I’m just running the Ping example to start with and it seems to be working.

However I’m not sure what I should change to be compliant with Australian rules.

This page Australia
Has the following details

For AU915, we use Frequency Sub Band 2, also known as channels 8-15, or 916.8MHz through to 918.2MHz.

So do I simply change the freq=923 to something inbetween 916.8 and 918.2 say 917 as it’s roughly in the middle.

Configuration section from the ping example

# LoRa
sx.begin(freq=923, bw=500.0, sf=12, cr=8, syncWord=0x12,
         power=-5, currentLimit=60.0, preambleLength=8,
         implicit=False, implicitLen=0xFF,
         crcOn=True, txIq=False, rxIq=False,
         tcxoVoltage=1.7, useRegulatorLDO=False, blocking=True)

Thanks
David

3 Likes
2

Hi David,

Great question!

It looks like you’ve fallen into the trap of LoRa vs LoRaWAN.
Since your devices are communicating outside of the LoRaWAN stack (i.e. not connected to a gateway). you should be good to send packets.

HOWEVER, since you are on the airwaves you still have to comply with ISM regulations (let me preface, I’m no lawyer and haven’t thoroughly studied these regulations).
This document outlines the usable frequencies for IoT applications and the maximum allowed power output, to be polite its best to setup P2P devices outside of local LoRaWAN frequencies.

PS: you can check local gateways with https://ttnmapper.org/

Keen to see your project done! You should send it through to Core to go on the projects page once you’ve finished it :slight_smile:

2 Likes
3

Hi Liam,
I have read through that PDF and nothing leapt out at me saying that I shouldn’t pic something between 915 - 928 Mhz. I also checked out that Lora Wan map and there is nothing within 300km of me so I’m not likely to interfere during testing. :slight_smile:
I’m in the country in the NSW Northern Rivers area. Buying a ~$500 LoraWan router would be ridiculous for my project.
I’m not quite sure why I should be “polite” and choose some other frequency in fact I probably can’t choose another valid one legally or the devices are not capable of doing that anyway. Even with the prospect that LoraWan will enter my neighbourhood over time I doubt my application will cause any problems.
It’s a remote gate sensor that will send a signal when the gate is opened. At most 4-6 times a day.
I’m also considering sending some heart beat style status notifications every few hours. It also seems I’m using these modules as intended.

I have been thinking about sending in a project document to Core Electronics for publication as this seems like an interesting use of the technology.
Thanks for your input.
David

2 Likes
4

Hi David,

Between 915-928 MHz is perfect, agree on the LoRaWAN router, definitely not necessary for your project (if ever you need to manage upwards of 50 or so nodes it might be nice to have but definitely out of scope).

Great to see a heartbeat signal included and yeah the due diligence of looking out for regulations and asking these questions is great!

Please do! It sounds like an amazing project and we’d + other Makers would love to see it :smiley:
Liam

2 Likes
5

Hi David. That’s a nice project you’ve got there.
I’m also trying to get a simple peer-to-peer LoRa link going.
I was wondering if you could help me. I’m trying to use the ehong-tl driver.
It looks really good.
Problem is, when I run the firmware (to transmit, on a Pico 2W with the latest LoRa hat - that actually connects underneath the pico, using Thonny) it only gets as far as sx126x.reset() returning the error code:
ERR_CHIP_NOT_FOUND

It’s like the Pico’s RP2040 is not actually talking to the SX1262 chip.
I’m new to Pico (and generally Pi). I’m aware of raspi-config / dtoverlay stuff with Pi.
Is there anything I should do before running the sx1262 code in order to get the SPI/reset/IRQ/data signals connected between the 2 chips on a Pico?
(I’m expecting you’ll say no but hoping you’ll say yes!)

6

Hi Neil,
Sounds like you are having fun.
I’m a little confused by all the part numbers so not really sure what you are trying to get to work together.
I did end up sending a document to Core describing the completed project with links to GitHub where I posted my code so you should hunt that down if your hardware is similar to mine.
In the beginning I found a ping test in the example code that was on another site, I think it was wave share from memory. That code is in my project.
Make your hardware connections as simple as possible with just enough stuff to do the ping test. It literally sends the word “ping” from one device to the other and then the receiver replies with “pong”
Once you get that to work add things one at a time and test test test.
I have a simple debug routine in my code that I can include in all my projects.
It outputs each variable to the screen then adds a line to a text file so you can see exactly what is happening and where things go wrong or at least how far it gets. I included a DebugLevel variable so once completed I could just set it to 0 and turn it off. That way if I needed the debug code again it’s all still there.

I also recall I was getting strange errors that made no sense and the solution was to add garbage collections to my code. Seems micro python isn’t deallocating memory or you simply need to do it manually.

I had fun mucking around with data encryption and ended up exceeding the maximum string length :cowboy_hat_face:. Turns out that’s 255 characters.
I hope this gives you some ideas to narrow the field with your project.
Do post again with your progress.
David.

7

I also went through the process of trying to find a good frequency. I’m sending a lot of burst data at a very regular rate, and in my situation can’t afford too much loss or interference.

So, I fired up a cheap SDR (Software Defined Radio) and checked the spectrum. I live rurally and was really surprised with how busy (and loud) some frequencies were. Especially the standard ‘out of the box’ ones. I’m pretty sure that my smart meter was pumping out the dB’s every minute, as well as the local water infrastructure facility, 1km away.

I was able to find a sweat spot with almost no traffic over the course of the day. Using this improved by my error free throughput substantially.

These are the settings I use. Effective Data Rate: 3.1 kbps, sensitivity -127dBm

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)

Using this configuration, 70 bytes are sent and 24 received without issue every 500ms over a distance of about 500m.

5 Likes
8

Hi Mark,
That’s very interesting. I never thought much about busy frequencies and haven’t experienced any trouble with transmission yet. I assumed my smart metre operates on the mobile phone network. The transmissions on my BBQ monitor will be on demand and once or twice a day at most. The hand held device sends out the word “Volts” and the bbq device responds with a number.
How did you figure out what the other transmissions were from?
My other very similar project sits on my front gate and lets me know when someone opens it. I went crazy with features just because I was having fun. The craziest being automatic time synchronisation data encryption. It was fun but I ended up exceeding the maximum number of characters which is about 255 from memory.
Good luck with your project.
David

2 Likes
9

How did you figure out what the other transmissions were from?

I guessed about the water facility. The smart meter was easier as I just moved closer and could see the increase in signal strength. I can’t recall the frequency but it was close to what I was using and explained to me my occassional dropouts which seemed to be exactly at 60 second intervals when they occured. I could be wrong. I have no idea where all the other traffic comes from, we don’t really have any close neighbours. Some was bursty, some continuous.

My other reason was to not interfere with other systems, as I’m sending a lot of data when its running.

Good luck with your project.

Thanks David. It’s an autonomous metal detector, using a pulse induction technique. The idea is that I let Roverling, autonomously, under GPS guidance search a predefined area. It sends live readings of location and ground signal characteristics via LoRa to my desktop for further real time processing where I have more grunt. This is why I need very reliable comms. I don’t want to miss out on that small nugget of gold :slight_smile:

It’s first outdoor integration test is just pending weather…

IMG_1217
IMG_12171920×1440 304 KB

The craziest being automatic time synchronisation data encryption.

Unfortunately I had to drop encryption in this systm because I used a PyBoard which doesn’t support that module, I checked with the Micro Python forum. However my Pico-W just ran encryption out of the box and I assumed that all ports had that module built in. Seems that port for boards that support Wi-Fi have it enabled, which makes sense.

3 Likes
10

That looks like a great project.
I found some generic python code to do the encryption. I think it was just a fixed shared key so if someone stole the device I would need to change the keys. I didn’t time it so 500ms cycle time my be a thing.
I also did a Mars Rover that I never went live with. It involves letting the internet loose in my house.
Anyone can drive it like a rover from anywhere in the world. All at once! I’m curious to see what happens
It has a full Raspberry Pi.

3 Likes
11

Hi Mark. The only real way to identify potential interfering signals is much what you have done with the best quality spectrum analyser you can find. Difference is you need a directional antenna built for the frequency band in question. Tedious but to other real way around it. Easier if the frequencies are licensed as the licence details will be recorded. but if you are in a non licensed band (which most of what you are doing would be) it makes it that much harder.

Quite a few years ago I had to investigate potential interfering microwave frequencies in the Djakarta area of Indonesia. This entailed a 1.2M parabolic dish, a long length of about 40mm Diameter Andrews Co-ax cable and a few Indonesian riggers to take the thing up a tower and wave it around 360º around the top. Signal strength and approximate direction logged for later analysis and investigation.
The trouble is in this part of the world just because the powers that be allocate you a frequency(s) does not mean you are the sole user. Frequency slot piracy is rife, particularly at VHF. Potential users tend to just look around, find a quiet spot then go ahead and use it. Licence??? What is that. makes for a pretty chaotic situation.
Cheers Bob

2 Likes