While a little late to this thread, I have been playing with lora and loraWAN over my break and thought this may be of interest here.
My loraWAN setup is based on the SX1303 915M pi hat on a pi 3b+
My end nodes are the Lora-E5 breakout boards.
I wanted to learn how it all works, so wanted to create my own system end to end.
Once I got the gateway up and running, I simply wrote a bit of server software to listen to the uplink/downlink UDP ports that the gateway was setup to use. the pi hat software simply creates a json packet for each different type of packets it gets and will forward that to the configured UDP IP:Port (Note: the gateway is designed to be behind nat without port forward, so you need to wait for it to send you the UDP packets then respond to the src IP/Port in the UDP header.
Once I was getting the UDP json packets, I then got the payload decryption working as well as the “mic” (short cmac). At this point I could now receive loraWAN packets from any of my test nodes.
Sending data back took a bit longer to get working as the “codr” was 4/6 not the 4/5 as in the uplink. It also took me a while to work out that the downlink packets are inversed. Once that was working, it was just getting the reply to work at the correct time; Class A has 2 short RX windows.
Note: all my code is just proof of concept so I could learn, but do have a stand alone loraWAN setup based on that gateway and can have two way Class A - LBP working.
Let me know if you would like more information or help in working anything out.
Hi @Michael99645 - welcome to the forums. Thanks for taking the time to give a high-level view of your project. LoRaWAN is an intimidating topic to approach and it sounds like your implementation is a great, flexible comms layer that will help other curious makers get started.
Consider submitting your project! It’s a great way to capture the details of your build for others to reference (and the could even be a store credit in it for you )
Question. I have udp status updates coming from the gateway, but I cant seem to have it receive or forward any packets. Will the module pickup regular LoRa packets and forward, or do they need to go through the entire LoRaWAN protocol and such. I am use an RM95X module to transmit, which has a sx1276 chip on it. I was hoping to publish out any ol message on the RM95X and have the gateway pick it up.
While I have never tested trying to get normal/debug packets sent via a gateway, I would expect it could inspect the packet format (needs testing)
That said, the node would need to ensure, at the very least its transmitting with all the correct settings.
e.g. Frequency/Channel, Spread Factor and Bandwidth and CODR/Error Correction.
With my node (LoRa-E5, STM32WE5), I could not see an easy way to send a packet without being an loraWAN mode.
I would need to spend some time to go back and review the gateway source code to confirm what the gateway for the Pi is doing to confirm.
My thoughts around trying to get non loraWAN i.e Lora raw packets out would be to just use a node on an ESP32 and just TX/RX as lora with a WiFi connection to the network to send packets to my server. i.e. the gateway is really to get loraWAN packets and send to the IoT networks.
The sx1302/3 data sheet says it is for decoding LoRa modulated signals. I feel like the MCU on board is filtering them out if they are not LoRaWAN. Do you know of a default packet that I could hardcode into the node that would make its way through the gateway?
Had a starting look today to see if we can work this out.
I had one of my end nodes send a packet using the API provided for loraWAN. The command was to send a simple “test msg” string.
The format of the data sent is the same as when I send data back and fully build the packet by hand (ignoring what they gateway does with it)
The loraWAN Packet
80 93AD2050 80 01 00 08 CF8B3D8F7FE11B5F FBE01AFB
80 - MAC Header as needed
93AD2050 - Dev Addr LE so it really was 5020AD93
80 - fctl
01 - Fcnt
00 - fopts (could be more then one byte if not 00)
08 - fport - really only imported to the uplink decoding at an app level.
CF8B3D8F7FE11B5F : Encrypted “test msg” text.
FBE01AFB - mic
this packet does get sent to my server software via the gateway.
My node does not give me low level access, just the AT api, but does have a test mode.
What should happen, is that message should then be encoded into a lower level packet.
That would then need to be sent on a frequency, spread factor, bandwidth and codr (error correction rate) as needed.
My understanding is the gateway should not care about the packet from above, so as its not forwarding in my test mode, I am thinking its missing something in the preamble, PHY Header and CRC or the outer CRC.
(or the error coding which should be 4/5 for uplink) is incorrect in test mode
OK, so now I am 100% it can be done. I set my Spread Factor (SF) in test mode to 6, which sets the Phy header to implicit (forced in the standard) and my test payload (from above) was forward via the gateway as expected.
So, not Im just down to setting the PHY header by hand to allow higher SF
In addition to the posts above, some more reading has found that the “phy header” should be transmitted for codr/fec of 4/8.
So when SF is 6 and that is NOT sent the packets get through. even a very simple packet with just text “hello world”.
The challenge I have with my node is I can control that as such. But my node did have a config option for Public LoRaWAN: ON/OFF. when ON, my simple test packet gets though no matter what SF I use. when Off (since I cant set it direclty, yet) on SF6 works.
So where I am at:
You can have a basic lora TX with SF6, then any data you like and the gateway will forward.
If you can set the CODR/FCC to 4/8 for the header, then set the data len and rate etc, and TX the payload in what ever CODR/FCC you want, then that should work.
If you cant control the CODR/FCC, then use SF 6, then send any data you like.
What should happen is the gateway should forward that payload base64 encoded to your UDP port. unbase64 that and you should a have the data sent. Of course there is no loraWAN header unless you add that yourself. And no MIC or encryption unless you do that yourself.
So that should get you started to have a node send a basic packet via the gateway to your application.
Awesome dive into this board and LoRaWAN as a whole!
Very keen to see this one wrapped up and we’d love to see it published on our Projects page!
PS: I’ve split your topic off from the product since this definitely deserves to be celebrated on its own, let me know if you’d like any changes to be made!
)
