Author Topic: LoRaWAN and LoRa  (Read 1074 times)

ecliptic

  • NewMember
  • *
  • Posts: 22
  • Country: us
LoRaWAN and LoRa
« on: September 09, 2019, 03:46:12 PM »
Hi all,

I'm trying to understand when to really use a LoRaWAN vs. just plain LoRa.  I've read through some other articles, but I can't really find a sort of T-Chart of pros/cons of LoRaWAN vs. implementing your own LoRa stack.  For instance, I'm not even sure if you can implement a LoRaWAN gateway unless you have the proper hardware (specific chipset from SEMTECH + a powerful processor - Pi and up).

Does anyone on here have any practical experience?  I've deployed my prototype product which uses LoRa, and I've been fairly happy with it; however, I did have to implement my own communication workflow.  I also used the RadioHead library as a way to communicate with the physical layer.  I also developed my own cloud backend using AWS and a gateway.

It almost feels like the LoRaWAN is some magical beast that gives you cloud access, takes care of the communication workflow (you just need to keep your packet sizes under 64 bytes), and possibly makes FCC certification easier (for your application)... but I also feel like LoRa is so stinkin' simple.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: LoRaWAN and LoRa
« Reply #1 on: September 10, 2019, 10:19:37 AM »
From my humble understanding, with LoRaWAN/TTN you're constrained to certain settings/channels/spreading factors/bandwidth etc. This is admittedly a good thing since all these settings are optimized, tested, and within the legal parameters in each region.

But you depend on someone else's gateway, or having to deploy and maintain one yourself. I saw one such commercial gateway once and all its hardware and it was not cheap at all, it has to be elevated to work well, has some serious antennas, not as simple thing as just whipping a Moteino with a RFM95 + monopole on your porch. I think these gateways also need to be able to run up to 8 channels in parallel. I am sure they can be made on your own.
Then there is the backend dependency of the network, which relies on the internet and their servers/cloud/whatnot to get your packet from a gateway to where it needs to go. LoRa is slower than FSK (bitrates) due to the way it chirps, so add to that the delays of relaying your packets through these networks, if that is relevant to your use case.

Up to you to decide if the benefits outweigh these limitations. If you're on your own, your code and hardware define your limits, no strings attached.

ecliptic

  • NewMember
  • *
  • Posts: 22
  • Country: us
Re: LoRaWAN and LoRa
« Reply #2 on: September 10, 2019, 09:33:52 PM »
Thanks Felix for the always great information.  I had a feeling the hardware was expensive, and I personally would like to have control of the cloud.

Quote
I think these gateways also need to be able to run up to 8 channels in parallel.

I've looked at Semtech's preferred gateway chips (https://www.semtech.com/products/wireless-rf/lora-gateways/sx1301 for instance), and those chips are definitely expensive.  Not to mention, I would think the main processor needs to be beefy to in order to process the data from that many channels simultaneously.

I may look a little further into LoRaWAN's backend offering, but so far their hardware is really expensive.. but then again so was z-wave.  Again... thank you so much!

ecliptic

  • NewMember
  • *
  • Posts: 22
  • Country: us
Re: LoRaWAN and LoRa
« Reply #3 on: February 19, 2020, 09:17:40 AM »
I just wanted to follow-up on my post.  I moved to TTN (The Things Network) and LoRaWAN for my particular project.  So far, LoRaWAN has actually worked out well especially since TTN now has their own cheap gateway available in the US ($80).  The downsides of LoRaWAN:

1) Device code much more complex than just fire/forget.  Fortunately, there are libraries that facilitate it (frequency hopping, Adaptive Data Rate - https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate.html); however, it's definitely not your standard RFM library code. 

2) As Felix mentioned, you are restricted to specific radio configurations and data throughput (see TTN's Fair Use Policy https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy-guidelines/1300).  Not a bad thing though.

3) Complexity.  As Felix mentioned, it's a jungle of complexity going from your Radio node to an endpoint; however, TTN does make this fairly easy via Integrations.

Having said all of that, I had already coded and designed my own hardware gateway, AWS backend, and mobile app for my project.  I'm a software engineer, not a hardware engineer, so moving the gateway support to an already established software/hardware implementation (TTN) was a big deal.

I probably wouldn't suggest LoRaWAN for most hobbyists nor simple(ish) projects (point-to-point); however, if you want to focus more on delivering an application and less on networking, then it's certainly a feasible option.