Investigating 32u4 to M5Stack LoRa poor range issues; Background information & initial tool setup.

Well, after my last post regarding the fascinating world of FPGA programming, I really thought this next post would continue on that topic. I really want to try out Luke's tiny FPGA board . Alas I've encountered another issue on a project that warrants sharing and someplace for me to keep my notes.


TL;DR

  • Misc details and notes on LoRa
  • VisualMicro ESP32 USB Debugging caused by new driver version
  • NESDR issue with SDR software and driver install
  • LoRa Range issue still unresolved, stay tuned for part 2


Late last year, I finally decided to buy a couple of " DIYmall LoRa32u4 LORA RA-02 Module Development Board Long Range Communication 1KM LiPo Atmega328 SX1278 with IPEX Antenna for Arduino" devices when Amazon had one of their "Lightening Deal of the Day" sales. Not to be confused with LoRaWAN - these are simple serial-type broadcast devices but with very long range. Getting them to talk to each other was ridiculously easy mainly thanks to the great Adafruit Feather 32u4 with LoRa Radio Module  tutorial and sample code.

Perhaps there's some software to do LoRaWAN with these (if anyone knows, let me know ) - however I don't have any service providers nearby and the gateways are expensive.

edit 2/18/18: here's a video on creating a LoRa gateway:


By the time my LoRa modules arrived, I had forgotten the title explicitly called out the "RA-02 Module". In hindsight, I'm surprised the Adafruit code worked at all, given their description naming their LoRa device as a  Adafruit Feather 32u4 LoRa (RFM9x).  Apparently the RA-02 and RF95 libraries are "close enough" - as my 32u4 appears to have the exact same RA-02 module as used on the M5Stack LoRa module. (I wonder what, exactly is on the Adafruit device?)

Which reminds me: be sure to check the frequency of the respective LoRa devices: they need to match not only each other, but also be allowed in respective county of use!

  (source: RF Wireless World )

After having the proof of concept working with the two 32u4 devices (RadioHead RFM95 libraries)  - which I was able to show them working hundreds of meters apart through very obstructed signal path and certainly not a straight line-of-site (e.g. hill, buildings, trees, etc)... I thought it would be cool to have a display module on one end, controlling the GPIO's on the other.

Some time ago, I had ordered an ESP32-based M5Stack so I decided to use this for a "console" along with their LoRa Module to talk to a very remote 32u4. Seems simple enough in concept, eh? Ha! Nothing is ever as easy as is is supposed to be.

First, the M5Stack core library uses different Sandeep Mistry LoRa drivers. (see also github) Thinking that "LoRa is LoRa", I assumed that they would work together. Indeed the workbench test was a complete success the first time .

However, the first real field test was a disaster. Taking the dog for a walk with an M5Stack connected to USB battery pack in hand, I expected to be tweeting success far from home. I was barely out of WiFi range across the street when the M5Stack stopped receiving messages from the 32u4. Certainly a long way from kilometer LONG Ra nge.

As it turns out, KongDuino recently left a rather interesting blog review of the M5Stack and LoRa modules . It would seem that I'm not the only one with LoRa range problems. If it was easy, it wouldn't be any fun - right?

Note that the 32u4 devices use so little power, that the Anker portable power supply turns off after a few minutes - perhaps thinking nothing is actually connected. Perhaps a USB hub or something might help for a road trip with it.

I've posted my code on GitHub under a project called LoRa-GPIO . This is a pitiful hack of sample code, but an otherwise operational proof of concept of the 32u4 transmitting a signal for the M5Stack to receive and display.

So to investigate the range issues, we'll need some tools such as break-point debugging and signal analysis.

Note for anyone using VisualMicro for development (like me). If any problems are encountered debugging the ESP32, be sure to check the CP210x USB driver version - particularly just after Windows Updates. There's apparently a known problem with recent drivers not working, Simply select (or install as needed) an older version to fix:



Ok, so anytime there's a signal transmission issue at hand, it is helpful to have some visualization tools. I have the inexpensive Nooelec Smart SDR on hand.

See Using SDR Sharp Quick Start Guide. Download Windows SDR Package from https://airspy.com/download/  Need to disable new security feature that prohibits unsigned drivers .

bcdedit /set testsigning on

Reboot. To turn off: 
bcdedit /set testsigning off

Even running zadig as administrator, I was unable to change drivers. So ok, I guess I needed to download new driver installer from the Nooelec Getting Started .  Windows is brutal; it completely removed the prior SDR drivers I had installed and working. Grr,,,

SDR Sharp had complained about the Visual Studio 2015 C++ runtime not being able to be installed (I have Visual Studio 2017 installed)... so rather than fuss with that, I installed the CubicSDR 0.2.2 software also located at the bottom of the Nooelec Getting Started with NESDR page.

Note there's an entire CubicSDR web site, and the most recent version appears to be v0.2.3 released in January of this year (2018) complete with source code on GitHub .

Once finally installed, the LoRa signal can be visualized:


So, ok.. I've fussed with Visual Studio debugging, SDR software install, and typing up all these notes and most of the day has flown by. No progress today on the actual problem of poor LoRa range. Clearly a part two is due and coming soon ...










Copyright (c) gojimmypi all rights reserved. Blogger Image Move Cleaned: 5/3/2021 1:35:53 PM