I’m currently setting up a project and need to get a LoRaWAN Gateway so i can connect my Arduino-UNO to send data to another Arduino-UNO.
I read that Dragino LG01/02 are not LoRaWAN gateways and should not be used. However, when i tried to explore TTN and add a gateway, i was able to select Dragino LG01/02. Does this mean i can still use these gateways but only for personal use like my project?
If i cannot do that then i would need to get the TTIG and use it for my project. But i realised Singapore doesn’t sell them.
Support for such single/dual packet forwarders is deprecated. (Please!) Do not use one on TNN as this may be disruptive for other users. There are old guides around that show how thay can be connected but sadly the internet hates sensorship so not possible to remove such info Just because something can be done does not mean it should be
If keen on Dragino than I have had decent experience with their LPS8 LoRaWAN GW - available at reasonable cost with both wifi and wired enet connection option…TTIG is WiFi only…not sure if latter available for your local frequency plan - check 1st as it is a reasonable option and lowest cost LoRaWAN GW, though there can be other issues (search/read Forum!!!) - agan I use many of them . Once you step up a bit higher on $price there are a raft of other viable options in the ~$130-$250 range based on either original SX1301 or later SX1302. Former tends to have slighly better spec for wider temp range and more industrial/telco systems vs latter for lower spec ‘consumer’ deployments… I use GW’s based on both.
Before choosing consider your use case and applications/needs and what type of system connection & packet forwarder you want to deploy (UDP/other, Poly-Packet/MP/Basic Station), backhaul connection types, indoor/outdoor/hybrid (indoor unit with outdoor antenna provision) etc. and choose accordingly.
That’s not really a very typical or likely to work well use case for LoRaWAN and TTN, which are designed for data consumers that use a subscription mechanism over the Internet to receive the data collected from the radio nodes. The form of LoRaWAN currently implemented at TTN is not really designed to push data back down (“downlink”) to a different node.
Transferring data from one Arduino to another might be a use case for direct point to point LoRa however.
The LG02 is not really a LoRaWAN gateway, but rather more a node or a point to point setup doing a bad job of impersonating one.
An additional issue is that the Arduino UNO is a bit constrained in the processor’s memory resources to implement LoRaWAN - it can be done, but it’s not a good choice as you’ll spend a lot of effort dealing with limitations.
The TTIG is not perfect either…
You really need to first clarify what you are trying to do so that it becomes clearer if LoRaWAN or point to point LoRa is potentially a fit, then select suitable hardware.
For LoRaWAN that would probably be a more capable “super Arduino” (eg, something with a Cortex M0 chip and lots of memory rather than an ATmega) with a node class radio, and then a more traditional gateway consisting of an SX1301 or SX1308 concentrator and an embedded Linux host. Note that only this, and really only this connected to the TTN server infrastructure, is on topic on this particular forum.
For point to point LoRa it would probably be two “super Arduino” node solutions each with its own directly controllable node class radio.
Thanks for the insights. I will look into LPS8 and TTIG in that case. As I’m doing a school project, I have a budget constraint. Getting a gateway will over shot my budget so I try not to exceed too much.
I had done up a point-to-point Lora using 2 Arduino Uno with Lora shields. Just transmission of sensor data. Now trying to transmit that data using LoRaWAN
TTN does not support downlink to a different node?? OMG haha.
As @kersing notes, TTN does provide a downlink, but as you want to have a node send data to the node you will need some scripting in the middle to pickup a nodes transmission (aka uplink) and submit a request for it to be downlinked to the other node. Feasible but a bit cumbersome. And the downlink limit of 10 a day may be too low for your application.
It’s more than just a daily limit, in the form of LoRaWAN (class A) implemented by TTN, a downlink can only be sent in direct response to an uplink from the targeted node.
Thus you can’t have nodes that are merely consumers, they would have to “poll” for downlinks, either explicitly or implicitly as part of submitting their own measurements.
You could implement something that moved a tiny amount of data between nodes, with long time latency, by very infrequently queuing a downlink request to share what the other nodes have said, which would attempt to be sent the next time the target node uplinks.
But this is really not what the form of LoRaWAN implemented by TTN is designed to be used for.
Given your use case and budget constraints it may make more sense to stick with point to point LoRa or even devise your own peer to peer type of network (a lot easier if your nodes have mains power).
Otherwise, if you are going to get a LoRaWAN gateway and connect it to TTN, it would make more sense to try to get it as a persistently installed resource for your school, rather than as an expense unique to your project.
Just because something can be done does not mean it should be 