I am quite new to LORA and TTN. I was able to add gateways to TTN, at home and at work. And, I was able to establish communication using ESP32s. Data arrived, and I was able to establish regular data exchange. Like it!
Now I want to use a raspi and a waveshare LORA hat to create a node. However, the vendor does not supply any examples for running a node, and it seems noone else was trying so far AND posting examples on the internet. Or, I am looking for the wrong terms. Any help from you, guys? I gues adding the hardware is straigh forward, since it is a shield which plugs ontop the raspi pinheader. But how to make use of it in software? And how to run it using TTN - except the registration, which is clear to me.
One option would be to hand wire the PI radio card instead to something like an ARM-based Arduino and delegate the LoRaWAN task to that.
The Adafruit folks were working on a partial implementation of LoRaWAN in python, but it may be that it is transmit-only, in which case you’d have to operate it at a fairly low duty cycle or the fixed setting implicit in that would be considered a bit impolite.
In theory, with a mains-powered node you could just run the receiver for a much longer interval around the formal RX window and not worry about precise receive timing as much, but this tends to mean operating the receiver with a different approaching to discovering if it heard anything, so you’d have to invest some real time in learning how it works.
One of the things you’re discovering the hard way is that a lot of hobby board creators have thrown something together and shipped it often after only putting together a crude demonstration of sending a single raw LoRa packet - which is quite a bit short of having a working or useful LoRaWAN node.
In theory something with its own MCU to handle LoRaWAN (such as the STM32L in the RAK811 on that board) is a good way to do things.
In practice, it would depend how suitable the firmware of the RAK811 is, or if you can readily change it.
You probably want to research experiences with the RAK811 module as much as with the pi adapter. RAK also has their own forums.
Also consider if LoRaWAN is right for your pi project (or a pi right for your LoRaWAN project). A pi almost invariably means you need mains power. And LoRaWAN is an extremely narrow “pipe” compared to the sorts of networks a pi is usually connected to.
The plan right now is to evaluate the Lorawan stuff. We have some challenges presented by customers where Lorawan could solve things, maybe. I am open minded, and want to get a grip on it. So, a pile of different Lorwan stuff is occupying my desk right now and waiting for me to play around with it.
It may make sense to start a thread about potential applications. A lot of things that people come here wanting to do are pretty quickly ruled out as unsuitable once those with LoRaWAN familiarity look at the requirement.
ie, things you can’t do:
Send more than small infrequent packets up
Send more than even less frequent packets down
Send anything down in a timely manner
A few of those relax a little in a private LoRaWAN network which can be made to support things TTN does not, ie, with mains powered nodes you can use class C for downlink-on-demand. And you can potentially use other modes not really supported by TTN like multicast, or even other LoRa schemes than LoRaWAN in applications where a higher proportion of the traffic is downlink rather than uplink.
We are not sure which way to go, hence we call it evaluation. I am head R&D at a telematics software company. We are used to use GSM networks for our stuff, sending frequent data out of vehicles back home. However, for acquiring sensor data maybe once a day at more or less closed areas GSM is a money waste. Lorawan would do the job from a specs point of few. Sending a data packet containing about 20 bytes every 24 hours seems like Lorawan was made with exactly this in mind. Sometimes such sensors are near mains, sometimes not. This is why I am evaluating both raspis and esp32 running on battery. Right now TTN makes the evaluation easy, cheers to those guys. Later on, we would probably run own server stuff and not use public infrastructure - combined with special made hardware by one of our hardware suppliers. We will see, evaluation first.