Afternoon folks. I’ve recently been reading up on LoRa/LoRaWAN/TTN for a project and seem to be going about in circles a little bit. There is a piece of hardware I planned on looking at that contained a Microchip RN2483A on it. The datasheet says that it has a On-Board LoRaWAN Protocol Stack.
I am looking to do some sensor comms in an open outdoor space with max distances of ~500m (with an eye towards 3km+ down the road). The transceiver module is paired with an ATmega for the sensor processing. In an ideal world (if I am understanding things properly), I have a bunch of these end nodes scattered about, a gateway to collect the data, and TTN is a sort of back end to access and massage the data. That seems somewhat clear to me. What I don’t understand is, if I have two of these pieces of hardware with the micro/transceivers on them, is it possible to do testing and dummy up some comms to do evaluation? Or do I need to grab a gateway (which was a cost I didn’t want to put out until I knew things would work) and tie it into TTN? And as a follow-on, if I don’t need the gateway, would I still be able to leverage TTN with just the two endpoint nodes?
Thats possible yes, there are Arduino libraries that will allow you to easily carry out functional or range tests on your hardware or antennas. For testing this can be a much simpler approach than the TTN node\gateway model.
However, once your hardware is sorted, using TTN which does requires a gateway of yours (or someone elses) is probably the easiest way to get your sensor data on-line so that you can review it at your lesiure from anywhere in the World.
While the RN2483 is meant to be used with LoRaWAN via the on-board stack, there are apparently people who have had moderate success doing peer-to-peer things with it:
I have not tried or even viewed this code!
Beware that this may be enough different from LoRaWAN that it does not give you a very good picture of what using LoRaWAN would be like… in theory the air capabilities are similar, but you may not end up with the same air settings, and you’ll not be taking many LoRaWAN limitations into account…
LoRa is a radio modulation technology. LoRaWAN is a wide area network communication protocol that uses LoRa for the wireless radio connection between gateways and nodes (end devices). TTN (The Things Network) is a public network that uses the LoRaWAN protocol.
LoRa radio tranceiver chips only handle the LoRa modulation but they don’t handle the LoRaWAN communication protocol. The LoRaWAN protocol needs to be handled by a microcontroller. The part of the microcontroller firmware that handles the LoRaWAN protocol is called a LoRaWAN protocol stack.
The RN2483 combines a microcontroller with a LoRa tranceiver chip in a single module. The main function of its microcontroller is to implement the LoRaWAN protocol, communicate with the LoRa tranceiver and provide a serial interface for communication with a host microcontroller. Latter is the one that runs the application.
The RN2483 is normally used with an additional microcontroller that runs the application. The RN2483 acts as a subsystem that handles all the LoRaWAN specifics.
The microcontroller running the application communicates with the RN2483 via a serial port (UART) interface with so called ‘AT commands’.
It is also very common to use a single microcontroller with a LoRa tranceiver chip (module) where the microcontroller runs both the application and the LoRaWAN stack. The microcontroller communicates with the LoRa tranceiver via a SPI interface.
Libraries that provide a LoRaWAN protocol stack are available for many popular microcontrollers.
The most basic LoRa setup to communicate between two devices is to use a LoRa point to point connection. But this will require you to provide your own non-standard(ised) communication layer (not LoRaWAN). There exist libraries for the Arduino framework to implement this.
Point to point is not suitable when the number of nodes increases. Point to point also does not provide a central messaging backbone like TTN does.
To use TTN requires (coverage of) at least one gateway. If there is coverage of existing TTN gateway(s) in your area already then these can (and will) be used by your nodes. If not then you will have to provide your own gateway.
@LoRaTracker Thank you. It feels like I should just go with a gateway as it will save me time and hassles in the end, I was just trying to save a few dollars and a little bit of heartburn up front . Maybe I should just suck it up and do it.
@cslorabox Interesting link, thanks. It probably ends up being more hassle than its worth to try to go some complete other route as I read your guys’ responses. I am considering picking up a used Gateway as a compromise.
@bluejedi Perfectly well written, thank you. That is exactly the write up I was looking for to explain it all in one place!!! I think I just need to get some hardware in and start playing with it and just start trying to use TTN up front maybe. It just seems like a large curve at first.
I guess I should ask. Is there a favorite inexpensive, easy to use Gateway that is preferred? I only need a handful of devices to be able to talk to it right now.
If your eventual goal is LoRaWAN, indeed it is. That said, while off topic here I think the possibility of other non-LoRaWAN schemes which could use cheap node radios on both ends is something that could benefit from exploration for certain small circumstances. But it is not what TTN or this forum are about.
The common budget approach is to get an SPI-based LoRa concentrator card with an SX1301 or Sx1308 chip and put it on a Raspberry Pi. (Don’t get USB, don’t get something that tries to use node radios to pretend rather than an SX130x) Unlike some other methods, that has no compromises in terms of radio capability or access to debug at all levels. Where it is less than wonderful is that when considering a gateway to put in the field for actual use, a pi isn’t a very robust platform (SD cards are for vacation pictures, not embedded systems) and working out a solid heat sinking and enclosure situation may take original effort.
And the main SX1301 or SX1302 chip in a gateway concentrator does get hot! Opened up concentrator card that was sporting an impressive heatsink the other day, and discovered there was no heat spreader inside - the heatsink was sinking the thin shield cover, but there was an air gap between that and the chip that actually gets hot(!)
OK, thank you for the feedback. What do you guys think of something like the RAK7246 ?
I believe that I ended up on their site because of reading something on here. Certainly seems like a reasonable box with minimal steps to get up and running.
I have one on my desk. It’s worth the extra $$ from a TT Indoor Gateway as you get full access to all parts of it - you can change the antenna easily and you can see all the OS & software workings as it’s basically RaspiOS + software on a Pi Zero, so debugging a device you can see what the gateway is actually hearing.
And yes, if you read the instructions before you install, so you understand the steps, it is easy to get up & running with TTN. At worst, you re-image the SD card and run it again!
. Maybe I should just suck it up and do it.