Last month I started working on a project to control GPIO pins on a device (relatively) very far away using LoRa technology. Most of the showstopper problems seem to have been resolved. Well, at least getting the RadioHead code working on the M5Stack. This blog entry continues on that topic...

TL;DR
  • VisualMicro Arduino projects in Visual Studio, using 32u4 (see also Adafruit 32u4) and M5Stack - both over LoRa.
  • M5Stack RSSI is a solid RSSI strength of 10 points worse than the exact same code on 32u4 which has the exact same RA-02 AI-Thinker LoRa device.
  • Recall from previous blog, LoRa RST and IRQ are reversed. (RST is actually GPIO36 input only; unusable). Otherwise it would have been: Beep = LoRa reset. 
  • M5Stack Speaker (GPIO25) is shared with LoRa Interrupt. (beep = interrupt?)
  • The M5Stack display shares the NSS pin with the LoRa module. (poke registers with care!)
  • The receiver and transmitter need to be configured EXACTLY the same for best range (more than just the same frequency); but this was not the problem with our poor RSSI
  • My LoRa-GPIO project and required RadioHead and M5Stack libraries merged to master on GitHub
  • When updating library (include) code, Visual Studio apparently does not look at file dates and may use previous compiled code; clean project after library changes.
The latest working (although not very pretty) Very Remote Lora-GPIO  Control and Monitoring Project code has been merged onto my master branch.

I've merged my M5Stack development branch back to my RadioHead master branch . This was a "Squash and Merge". Normally I like to keep the history... but as the RadioHead owners prefer a single patch file, perhaps this will be better. Time will tell. History is still in the branch.

I've submitted a PR to Adafruit at their request, as well as well as sent a patch file to Mike at ReadioHead . Ok, this is weekend and evening working, certainly not some of my best polished work. I need to go back and clean things up.

My M5Stack library fork is, and has been up to date on the master branch. (no branches)

The main LoRa-GPIO solution contains several projects as noted in the GitHub readme . These are all Arduino-style projects using the really awesome VisualMicro add-in for Visual Studio.

As a side note, while working on this - I found what appears to be GitHub branch-to-branch compares not working properly .  (if it *does* work properly and I'm simply not doing it correctly, please let me know)

I've been reading through the ARRL Ham Radio License manual. I don't know if I will actually get a ham license, but wow - what a great book this is to cover the essentials of what you need to know for RF communications (such as the LoRa for this project). Although I had a ton of classes in college covering a wide variety of electronics, electromagnetism, communications, even an entire class on antenna theory... this ARRL book contains a lot of relatively straightforward, every-day language on the practical essentials of radio frequency communication - all in one place. The ARRL web site also has some excellent resources. Ok, there's also pretty much NO math, NO theory: Just useful facts. So this is certainly not a book for how or why or how to apply to new problem. Still, it is a quite good book. Highly recommended & would make a great gift for someone new to the field.

So on to the testing... now that I have the RadioHead drivers working, I actually went back to the M5Stack example code (Sandeep drivers renamed M5LoRa). Recall that I have the RadioHead drivers on a remote 32u4 sending LoRa packets. Here's the sample code for the M5Stack receiver (Arduino: File - Examples - M5Stack - Modules - LoRa - LoRaReceiver) : 




#include 

#include 




#define LORA_CS_PIN   5


#define LORA_RST_PIN  26


#define LORA_IRQ_PIN  36




void setup() {


  


  M5.begin();




  // override the default CS, reset, and IRQ pins (optional)


  LoRa.setPins(LORA_CS_PIN, LORA_RST_PIN, LORA_IRQ_PIN); // set CS, reset, IRQ pin


  Serial.println("LoRa Receiver");


  M5.Lcd.println("LoRa Receiver");




  // frequency in Hz (433E6, 866E6, 915E6)


  if (!LoRa.begin(433E6)) {


    Serial.println("Starting LoRa failed!");


    M5.Lcd.println("Starting LoRa failed!");


    while (1);


  }




  // LoRa.setSyncWord(0x69);


  Serial.println("LoRa init succeeded.");


  M5.Lcd.println("LoRa init succeeded.");


}




void loop() {


  // try to parse packet


  int packetSize = LoRa.parsePacket();


  if (packetSize) {


    // received a packet


    Serial.print("Received packet: \"");


    M5.Lcd.print("Received packet: \"");




    // read packet


    while (LoRa.available()) {


      char ch = (char)LoRa.read();


      Serial.print(ch);


      M5.Lcd.print(ch);


    }




    // print RSSI of packet


    Serial.print("\" with RSSI ");


    Serial.println(LoRa.packetRssi());


    M5.Lcd.print("\" with RSSI ");


    M5.Lcd.println(LoRa.packetRssi());


  }


}

This code writes to  both the M5Stack display as well as the serial port. The display is cool as I don't need to remember to disconnect the serial port when reprogramming. HOWEVER: You may recall from my previous blog that the M5Stack display *and* LoRa module share the NSS (slave select) pin. That simply sounds dangerous (and indeed I observed some display oddities), so I put M5Stack LoRa to sleep when writing to the display.

The shocking thing here is that there's up to a difference of TEN in RSSI values as compared to using the RadioHead drivers. (RSSI 36 vs 26). As this is a log scale, that's a 10x difference in power! Now - this is not to say that the Sandeep library has a problem just because it is polling rather than using interrupts. It is a matter of default configuration. I picked apart the RadioHead control register libraries and added a note about the matching importance:


When printing the register values from the Sandeep (M5LoRa) library, (move the readRegister from the private to public section)... 


    Serial.print("0x");
    Serial.print(LoRa.readRegister((uint8_t )0x1d),HEX);
    Serial.print(", 0x");
    Serial.print(LoRa.readRegister((uint8_t )0x1e),HEX);
    Serial.print(", 0x");
    Serial.print(LoRa.readRegister((uint8_t )0x26),HEX);


There's a SINGLE BIT different (CRC not enabled!):  0x72, 0x70, 0x4 - alas that didn't seem to make much of a substantial difference in RSSI values. I supposed I had expected different error coding, spreading factor, or some other obvious difference.

I confirmed the running values of RadioHead cinfig registers are also 0x72, 0x70, 0x4 - but the RSSI is typically -25 whereas the Sandeep (M5Lora) drivers report an RSSI of typically -35!

So the next thing is: how to each of them calculate RSSI?


Well, the Sandeep / M5Lora library does this: 


int LoRaClass::packetRssi()
{
  return (readRegister(REG_PKT_RSSI_VALUE) - (_frequency < 868E6 ? 164 : 157));
}
float LoRaClass::packetSnr()
{
  return ((int8_t)readRegister(REG_PKT_SNR_VALUE)) * 0.25;
}

But the RadioHead library does this: 

// Remember the last signal to noise ratio, LORA mode
// Per page 111, SX1276/77/78/79 datasheet
_lastSNR = (int8_t)spiRead(RH_RF95_REG_19_PKT_SNR_VALUE) / 4;
// Remember the RSSI of this packet, LORA mode
// this is according to the doc, but is it really correct?
// weakest receiveable signals are reported RSSI at about -66
_lastRssi = spiRead(RH_RF95_REG_1A_PKT_RSSI_VALUE);
// Adjust the RSSI, datasheet page 87
if (_lastSNR < 0)
 _lastRssi = _lastRssi + _lastSNR;
else
 _lastRssi = (int)_lastRssi * 16 / 15;
if (_usingHFport)
 _lastRssi -= 157;
else
 _lastRssi -= 164;


Grr... So ok, the difference in RSSI appears to be simply a different calculation.  The real test is: how far away can the units be and still communicate? I'm still happy I have the RadioHead libraries working. In my opinion is is clearly the superior code.

So reference check: after all the code changes, let's try same units: 32u4 to 32u4. Cleaned project, full rebuild. RSSI value is -19 or -20! Rechecking the M5Stack, RSSI is -27.  So even with the same codebase and same calcs, the M5Stack LoRa has a poorer RSSI value. Using an external battery power  source and the value improves to RSSI = -24.

So, as mentioned about - I've been reading about real world antennas, so perhaps the M5Stack antenna has an issue. Well, I tried that as well, replacing the internal antenna with one of those external antennas - identical to the one on the 32u4. Still there's a discrepancy in RSSI values between the two devices.

What else? Ok, so there's a speaker in the M5Stack. Poking around with that, defined in:

libraries\M5Stack\src\utility\Config.h

there's a declaration:

// BEEP PIN
#define SPEAKER_PIN 25

Ah yes, GPIO25, our friend. The LoRa interrupt pin.  (sigh)

So perhaps all the extras in the M5Stack are indeed causing a problem. I tried to disable a few things  such as the speaker init, but no luck. I do however, have another Console (without display) app that is specifically targeted for the 32u4, but with the magic of simply changing platforms in the IDE, can be recompiled and sent to the M5Stack!  RSSI about that same at -27 (ranging from -23 to -29).  Replace with the exact same code on the 32u4 and the RSSI is a full 10 points better at -17.  (10x improvement in signal strength!).

I tried another M5Stack unit with a different LoRa module. Same result.

So at this point, I really believe it is a hardware issue. I've been unable to get a copy of the schematic for the M5Stack LoRa module, However the 32u4 has a pin connection diagram here .

As soon as hardware is questioned - the first thing to do is of course add some capacitors! I added a 10uF and a 10pf cap directly to the power input to the RA-02.


In the pic, you can see I fished a new, external antenna along with the new caps. And ya, I got a little close to the side of the M5 Lora module.

Additionally I added a shield (aluminum foil sandwiched between two layers of clear packing tape) to both sides of the LoRa module. After all - there is an ESP32 microprocessor buzzing away just on the other side of the PCB!



The first field test was a relative success! I more than doubled the original range! Ok, so I didn't actually test after each change, so I don't know exactly which was the most effective in extending the range.

Note the Semtech site has a bunch of LoRa resources, including this cool LoRa calculator (I will include in my GitHub repository in the docs container, in case the link to Semtech ever breaks.


Note that I am currently transmitting at 125kHz. Lowering this increases range! Lower this to about 15.6kHz and you get another 10db in "link performance". (in theory).

Overall I am quite happy with the result. Ok, I'm not seeing multi-kilometer ranges. But that's also line-of-sight. My transmitter is on the kitchen table - with the entire garage between it and the M5Stack receiver. Next test will be from line of site.

The super exciting thing is I have a prototype from the kind folks at M5Stack arriving in the mail soon for the next potential version of the LoRa module. I am quite interested in seeing how well it performs.

Stay tuned for my next blog  where I work on the prototype V2 LoRa modules with its own embedded ATMEGA328.


Resources, Inspiration, Credits, and Other Links:



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