LoRaWAN, Dragino LG308 Gateway, and MicroPython - Quick Thoughts

Yesterday I had a chance to enjoy testing LoRaWAN with the owner of the M2M Shop who was kind enough to drive three hours down the seacoast to set up and test the Dragino LoRaWAN LG308 gateway operating on AS923MHz in Thailand.

Ahead of K. Somsak's visit, he had asked me to install Thonny, which is a Python IDE he uses to program his ESP32 LoRaWAN nodes.

Working with MicroPython was interesting. In contrast to the Arduino IDE, MicroPython runs on the devices and we can program the devices directly with Python without the need to compile, in contrast to Arduino devices, which are complied and uploaded (side-loaded) to the devices. It was also interesting to me that we could have many MicroPython programs in storage on the end-user devices, and both modify, and run these MicroPython programs as we wish, directly on the nodes.

On the net, you can read a number of "MicroPython versus the Arduino IDE" discussions. There are no shortage of them; and some can get quite heated in the style of "religious wars"; but I'm not interested in religion, religious wars, or getting "any". I found working with MicroPython enjoyable, just like I enjoy working with the Arduino IDE. The biggest difference for me is that I felt like beginners who do not have a long history of programming in many different programming languages, would find MicroPython much easier. At the end of the day, it's all "including libs" and "conditional logic" etc, so I do not have any real preference, MicroPython over Arduino C++ and the Arduino IDE; I like both. I will definitely work with MicroPython again in the near future, as well as the Arduino IDE.

K. Somsak, my guest from M2M Shop, is an ardent maker, and he likes to build "bare bones" LoRa nodes so they will consume as little power as possible. He had an entire box of LoRa nodes he has built (and brought many of them with him yesterday), but we mostly used this one (below) for "ping" testing with basic sensor data (temperature, humidity, relative barometric pressure, which is perhaps the most popular IoT node on the net, "the weather station" application.

We also set up one of his custom built single channel LoRaWAN gateways:

Unlike "the guy with the Swiss accent" on YouTube who goes for world distance records of over 200 km between a LoRa node and a gateway, LoRa "Wardriving" and TTN Mapping, we just wanted to see how well a LoRaWAN gateway performed under various urban conditions at the top of a condo (around 28 floors up from sea level) with a LoRaNode ; so we tested the following:

  • LoRaNode on Ground Level in the building
  • LoRaNode in the outside proximity of the building (walk around).
  • LoRaNode "deep" into underground parking (away from the entrance ramp).
  • Etc.....

We tested with Spread Factor (SF) 7 and SF12, from both the ocean side and city facing balconies.

We used The Things Network (TTN) for testing (sorry, need to reconfigure the site to permit more than five attachments in a post, which I will do later.).

The results were interesting, which I will quickly summarize here:

  • As expected, LoRa is really designed for line-of-sight, low power, communications. We had no problems sending "ping-type" messages to the gateway when in LOS.
  • Using SF 12, we could send pings from "deep" into underground parking to the LoRaWAN gateway with significant packet loss. so it "worked" but not reliability. However, we were only operating the gateway at around 60% the "legal limit" (which is 500mW) for unlicensed LoRa on the AS923 band in Thailand; but we were compensating a bit for this with a few more dB gain from a longer node antenna. With more gateway power, pushing the legal limit, it might be possible to make the link more reliable. However, in practice, I would prefer to put a WIFI node in underground parking and use "plain-ole" 802.11 LAN for this versus LoRa, which is really meant for long range, low power, LOS messaging.
  • LoRaWAN reminds me of some technologies I used to experiment with decades ago which I recall as "packet radio". I don't recall the frequencies of "packet radio" back on those days, but I definitely enjoyed programming (actually, just configuring SF and making minor changes on-the-fly to existing test programs) the ESP32 nodes with MicroPython and Thonny yesterday. I can certainly see how LoRa could be very useful for long range, low power, low bitrate date links. The issue with LoRa is the same issue I had with NB-IoT is that it requires LOS between the network nodes.
  • On the other hand, for my situations of wanting to use LoRa and / or NB-IoT for both (1) vehicle tracking and (2) underground parking monitoring, I could see that the LOS issue is a significant obstacle. For the second, I think "plain ole' WIFI" is the better choice; and for the first one, I still think 3/4/5G is a better choice because the network coverage by service providers is better. There are simply more customers for 3/4/5G devices, so naturally service providers will put more money into those networks. However, for applications which have good WAN LOS and require low power and long range, LoRa definitely has a potential niche.

The issue, of course, is that governments regulate the radio spectrum and they will always try to profit from the licensing of the frequency spectrum, if and/ or when it becomes profitable. Since unlicensed LoRa is only legal at low power, it seems unlikely that highly reliable commercial services will be sustainable, especially if commercial service provides can, via licensed services, provide a similar "long range" network services with higher power, legally.

So far, I have briefly tested an NB-Iot device as well as the LoRaWAN devices from yesterday in what we could call "the urban sprawl". My initial impression is these technologies are primarily "hobby technologies" similar to the "packet radio" I used to experiment with in my youthful days back in Tennessee. Of course, now we have Arduino and the Arduino IDE; and we have MicroPython; and we have much more interesting microprocessing chips and boards. However, at the end-of-the-day the "game is still the same"; and as always, commercial interests will always dominate, if there is money to be made. This is simply how it works in our "money-is-a-kind-of-god" world.

I'm still interested in getting a board like the Elecrow GSM/GPRS/EDGE SIM5360E 3G Shield for Arduino working and tested for rural vehicle tracking (my motorcycle). There are commercial devices for this in the market already, but I prefer a development board (for the Arduino). Unfortunately this week I received a defective Elecrow board which would not recognize a local 3/4G SIM card.

So, in the meantime, I think my next hobby project is to build an Arduino robot kit "tank", and take a short break from LoRa, NB-IoT, and 3/4G messaging / tracking for the moment.

Finally, and most importantly, a big THANK YOU, to K. Somsak of the M2MShop (GitHub) in Thailand for driving so far down the seacoast and for spending the day (a very enjoyable one) testing LoRa!

I plan to get back into LoRa in a few weeks, after building an Arduino "robot tank" from a kit, just for fun.

3 Likes