M0 and RF Gateways as LoRa serial ports

[precisionbrewing]

Hi,

First - thanks for the awesome products. I am building automation into a commercial nano brewery, have been tried out a number of LoRa items to pass messages. I am trying to use a M0 RF95/915 and an RF Gateway RF95/915 as remote serial ports to run terminal commands between RPi control systems.

I have been able to to do two test steps:
A. Use two generic Arduino Dues as serial passthroughs for a terminal with getty, using the TX/RX pins, and
B. Use the M0 and RFGM4 to pass text messages between both serial consoles, including the Arduino UI, the screen command, and python serial reads.

However, when I try to use them directly as serial ports using getty, I get nothing. And, when I strip the serial passthrough code down to what I think are the essentials for clean serial passthru, I start missing newlines and other non printable characters in the serial console output.

If there is a LPL example of clean serial passthru with LoRa, or even an RF69 example that is close, I would appreciate seeing it. I am a decent python programmer, but Arduino/c++ and some of the code the Radiohead library relies on is new to me. Thanks.

Code Select Expand

#include <SPI.h>
#include <RH_RF95.h>

//Moetino0
RH_RF95 rf95(A2, 9);
//RFGateway
//RH_RF95 rf95(20, 18);

int LED = 13; //Status LED is on pin 13
float frequency = 921.2;

byte sendLen;
char buffer[256];


void setup() {  
  Serial.begin(9600);
  while (!Serial) ;
  if (!rf95.init())
    Serial.println("init failed");
  else { Serial.print("init OK - ");
  }
  rf95.setTxPower(4, false);
  rf95.setFrequency(frequency);
  Serial.println("Setup done...");
}

void loop()
{
  if (rf95.available())
  {
    uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];
    uint8_t len = sizeof(buf);
    if (rf95.recv(buf, &len)) {
      digitalWrite(LED, HIGH);
      Serial.write((char*)buf);
      digitalWrite(LED, LOW);
    }
    else{Serial.println(". .");}
    memset(buf, '\0', sizeof(buf)); 
  }

  
  if (Serial.available() > 0) {
    char txtMsg[255] = "default";
    readSerial(txtMsg);  
    sprintf(buffer, "%s", txtMsg);
    sendLen = strlen(buffer);
    rf95.send((uint8_t *) buffer, sendLen);
    rf95.waitPacketSent();
  }
}


int readSerial(char result[]) {
  int i = 0;
  while (1) {
    while (Serial.available() > 0) {
      char inChar = Serial.read();
      if (inChar == '\n') {
        result[i] = '\0';
        Serial.flush();
        return 0;
      }
      if (inChar != '\r') {
        result[i] = inChar;
        i++;
      }
    }
  }
}

[Felix]

Awesome, automation-everything is THE thing these days 

I would just start in the Examples section of both libraries.
My RFM69 library I know best and use extensively, so I would point you to the gateway examples, there are a few of those.
The PiGateway example is interesting because it adds queuing/buffering and requests support for reaching sleepy nodes when they come back. Putty should work great to see the incoming traffic.
Same for the RadioHead libray, it has pass through examples.

[precisionbrewing]

Hi,

Thanks for pointing me there. I had seen the RF69 libraries before and they look really close to what I might need. The Radiohead Gateway example makes some use of Serial() inside RF_95 that throws a compile error for me, which is why I did the customized example (cribbed from your forum, in fact   and though your Gateway example looks great, I am worried that it won't map over to the RF95/96.

I also got one of your RF69s and am interested in non-LoRa for some other projects, but it seemed like sticking with LoRa (through brick walls and multiple floors) would be wise. Do you think the RF69 example close enough it's worth trying to modify it for the LoRa M0?

[Felix]

Definitely worth trying the RFM69.
It can perform amazing, try it with monopoles, it might just do great.
Or you can grab some dipoles to go with it, I also offer some coax and matching SMA's just make sure you mate male/female versions properly.
FWIW I have a patched version of the RFM95 library on this page, you may want to try that. And make sure you compile for the specific Moteino board you're using, steps for setting that up are in the guide.

[Antony]

I'm unable to verify or upload any sketch to my RF Gateway M4 with LoRa 95. I'm trying to upload rf95_encrypted_server (patched from radiohead) with my two other moteino R6 as client nodes.

What I tried so far:
I first followed the gateway M4 library and board steps from the lowpowerlab installation guide here, lowpowerlab and arduino libraries: https://lowpowerlab.com/shop/product/196

Board and libraries indeed showed up in my Arduino IDE, so then I tried to load rf95_encrypted_server (radiohead patched version from Felix's guide page https://lowpowerlab.com/guide/moteino/lora-support/ ) but compile errors, so not even to the stage of flashing lights on the gateway.

I also looked through RangeTest_Gateway.ino in the RFM69_LowPowerLab/Examples/RangeTest_Gateway, but that is for the different rfm69 transmitter and doesn't use the Radiohead libraries for the rf95.

I also tried precisionbrewer's code example of April 22.

I read through post https://lowpowerlab.com/forum/coding-questions/rfgateway-m4-issue-with-radiohead-library/msg28965/#msg28965, but I'm already using the patched version of the radiohead library that Felix modfiied.

I cannot even verify and load the blink sketch to my gateway M4 so I am obviously missing something major.

For reference, I have 2 moteino R6 with LoRa 95 working fine both as client and server using the radiohead ecrypted server/client libraries, which I connect and program using ftdi. As soon as I remove the FTDI cable from the usb slot, and replace that usb cable with the RF gateway, before I have even tried to validate, the arduino IDE prints: ~/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/arm-none-eabi-ar: error while loading shared libraries: libfl.so.2: cannot open shared object file: No such file or directory

When I look at the physical RF Gateway M4 which is in the RaspberryPi usb slot, no lights come on when I push it in or out making me think that I'm not loading the correct header files (pinout for tx/rx or general purpose LED)?

[Felix]

Antony,
First you need to make sure you have the Moteino SAMD Boards package installed so you can compile for Moteino SAMD boards. You can find a guide for that here.
Choose the stock BLINK sketch in the IDE examples, and compile it for Tools>Boards>RFGateway, then load it to the board. If the board is unresponsive for whatever reason, and fails to reset into bootloader and receive the upload, double click the RST button to ensure the board goes into bootloader and can accept an upload, then pick the new serial port in the IDE that matches the bootloader, and try uploading again.
Once that works, then you're ready to compile your rf95 sketches for RFGateway. Obviously the RFGateway should have an RFM95 on it.

[Antony]

Felix,
Thanks for replying...also thanks for making awesome products...I love my moteinos and I'm enjoying the LoRa radios. Yes, the RF Gateway M4 has a LoRa radio attached (purchased it last week).

I had followed that guide, but double-checked anyway, and I have both the SAMD boards packages:
LowPowerLab SAMD Boards (requires Arduino SAMD Boards 1.8.11) version 1.6.3 installed
and I have Arduino SAMD Boards (23-bits ARM Cortex-M0+) version 1.8.13 installed

Double-clicking the rst button on RF Gateway, which I had not done before, did cause the green light on the RF Gateway turn on and stay on, and on my rPi it opened as a media.

The active port is: "/dev/ttyACM0 (RFGateway M4)"

I closed and re-opened the Arduino IDE. I tried loading Blink both with the green light on the RF Gateway, as well as clicking rst button once more to turn off the green light, yet I still get the same Error compiling for board RFGateway M4 (I tried Blink, Bare minimum)

/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/arm-none-eabi-ar: error while loading shared libraries: libfl.so.2: cannot open shared object file: No such file or directory

[Felix]

Hmm that error does not look familiar, but it's some core problem with the IDE and/or some package.
Maybe try reinstalling everything or try this on a different PC?

[Antony]

update: after reinstalling the IDE including deleting .arduino15 file and reinstalling board drivers and libraries, that didn't fix it (same error)
But after lots of googling, I found I needed libfl-dev package on my rPi (not sure why others weren't getting this error as this is a new rPi 4 model B), which allowed the code to verify and compile, and when I uploaded blink, the Gateway is blinking...yay!

but after each upload completes, the rPi opens an error dialog "No ojbect for D-Bus interface" and I get a dropdown message saying the Gateway was removed without ejecting first.

Do you get an eject message/D-bus message as expected behavior every time after uploading sketches to the RF Gateway M4?

[Felix]

Never seen or heard of those errors.
Maybe time to try doing this on a real computer?

[Antony]

  I'd mark this main thread as [solved] but can only mark my contribution...

I successfully uploaded the rf95_encrypted_server and the RF Gateway M4 is talking happily through its LoRa with my LoRa Moteinos.

A bit more research outside of LowPowerLabs shows these errors aren't uncommon for similar architecture boards, so happy to share for when others get the same errors and worry they might brick their rPi. The Adafruit feather has the same three files, named identically to those on the RF Gateway M4, including bootloader, so digging around Adafruit, I found this:

"To flash something new, simply drag any UF2 onto the drive. After the file is finished copying, the bootloader will automatically restart. This usually causes a warning about an unsafe eject of the drive. However, its not a problem. The bootloader knows when everything is copied successfully."

more about it here at the link https://learn.adafruit.com/adafruit-feather-m0-express-designed-for-circuit-python-circuitpython/uf2-bootloader-details

For others out there who persevere without a real computer and want to connect Felix's RF Gateway M4 to an rPi 4 Model B, hopefully this forum thread will help.

Thanks for your help Felix, for now, it's all good 

[Felix]

I never tried to develop stuff on the rPi, it's probably not the best way to spend time and debugging IMO.
Compiling is one thing, and can get a bit more complex the first time especially if you run into any trouble, but then it's a breeze.
Using the UF2 is pure joy, just drag & drop, but the caveat is you need to know what that UF2 is exactly or you can end up with wrong firmware so good records and file names are a must when using UF2 firmware files.