We have a private network and want to replace our gateway hat with rak2245, but there is a problem. Our firmware on the raspberry pi has lots of tasks and computations and it has been written in the current firmware. Now we just want rak2245 to send some commands and receive the sensors data. Is there any source code for this simple and easy job?(We don’t want this code handle MQTT connections, queuing, or any things else)
Guys, I’m not professional at LoRa and have some problems around connection between rak2245 hat and raspberry pi 4. So I would be grateful if someone could help me. Our project includes lots of actuators and sensors that do not have power limitations (I think its class C of LoRa). We just want a firmware (source code) to send commands from gateway to end nodes (sx1278) and receive acknowledges. We do not communicate with TTN, ChirpStack, or anything else. Is there any example or codes to start working and customize it?
While technically possible, that’s not really the how the hardware is intended to be used or a purpose for which it is marketed. The intended idea is that you’d use it with a LoRaWAN server stack (even the optional one running on the gateway’s computer), which would accomplish those things in the way that LoRaWAN does them, rather than in some custom way. Whatever custom thing you ultimately do with the data would receive and send it through the (local or remote) LoRaWAN server, not directly.
We do not communicate with TTN, ChirpStack, or anything else.
If you’re not going to use a LoRaWAN server stack, then you’re going to have to design and create your own solution that does those things, and interacts over local or remote network sockets with the “packet forwarder” component that manages the gateway radio (concentrator card) itself, the same way that a remote or on-gateway network server would interact with the packet forwarder.
Is there any example or codes to start working and customize it?
Most published non-LoRaWAN examples are more of a peer-to-peer type of architecture and so would use a simpler node radio on both ends, rather than a node radio talking to a gateway radio - but most of those examples are too simple to scale to real usage.
What you want to do is possible, but it’s going to require a lot of custom engineering, since you’re rejecting the existing LoRaWAN solution that the available open source engineering work products implement.
LoRaWAN is far from perfect, but if you’re going to do something else, then you’re going to have to come up with your own solutions for the same problems that LoRaWAN solves with its particular set of design tradeoffs. The starting point would be gaining enough in-depth knowledge of LoRaWAN to be aware of the problems that a radio scheme has to solve.
Consider putting a stock install on a new SD card, enabling the on-gateway Chirpstack server, and getting your end-devices (nodes) speaking LoRaWAN. At the least it will gain you some experience of the design tradeoffs of LoRaWAN.
If as in your previous message you already had some sort of solution, maybe what you need to do is look into what was running (backup the card first!!!) and identify the difference between the packet forwarder and its configuration which might have to change slightly when using a different concentrator card, vs whatever network server or other custom software components were exchanging raw packets with the packet forwarder, which you could hopefully move over with few changes.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.