Different Lora board can't communicate between them

Hi,

I'm working on raw lora radio communication between different development boards. I'm working with 2 x TTGO T-beam, 2 x Heltec lora32 V2 and 2 x LoPy4 by Pycom, both based on an ESP32 plus a Semtech SX1276 lora modem.

Now, my goal is to create a listen-and-broadcast network between these nodes. The behaviour of each node is this: transmit data on raw lora (about 15 bytes), listen for incoming messages for 5 seconds, repeat.
Now, all the boards are set to SF7, BW 125 KHz and same code-rate and polarisation, but I can really understand why the Heltec/Pycom boards, which are almost the same, can't communicate with the TTGO. I mean, the TTGO boards see each self messages and "some messages" sent from the Pycom/Heltec boards, while the Pycom/Heltec can't receive almost any (3 over 100 messages only) messages form the TTGO boards. No problem instead, between the Heltec boards and the Pycom boards.
All the boards are inside a 5 x 5 meters room, placed at least at two or three meters of distance between them. I'm using the Arduino Examples code.

Do you have any idea of this strange behaviour?
Thank you!

Possibly code or settings differences and possibly faulty hardware.

You must have a pair of the same devices working well and very reliably, using example code with each as a TX and RX.

Then and only then, try one of the other devices.

srnet:
Possibly code or settings differences and possibly faulty hardware.

You must have a pair of the same devices working well and very reliably, using example code with each as a TX and RX.

Then and only then, try one of the other devices.

Thank you for your answer.

From TTGO board to TTGO board, using the RX and TX example I have no issue when they communicate, the same happen between the Pycom LoPy and Heltec LoRa32 boards, which, even if they are different boards communicate between them without issues and packets loss.

With the example provided by Arduino, the TTGO can listen some packets sent by the Pycom/Heltec lora boards. “Some” means that half of the packet or more get lost. While if I send Lora messages from one TTGO to the Pycom/Heltec boards, 98/99% of packets are lost.

I’m pretty sure that the settings (SF, frequency, coding rate and BW) are the same.

frankly spoken, you are doing something wrong - but we can’t see it as you have NOT posted any of your codes, nor any links to any devices.

Thank you for your answer. Ok, let me share the code running on my TTGO T-beam. I have two of them, but actually only one is up.

#include <LoRa.h>
#include "utilities.h"

int counter = 0;

// lora config
int lora_coding_demoninator = 5;
int lora_signal_bandwidth = 125E3;
int lora_spreading_factor = 7;
int lora_frequency = 868E6;

void setup()
{
    initBoard();
    // When the power is turned on, a delay is required.
    delay(1500);

    Serial.println("LoRa Sender");
    LoRa.setPins(RADIO_CS_PIN, RADIO_RST_PIN, RADIO_DI0_PIN);
    if (!LoRa.begin(868E6)) {
        Serial.println("Starting LoRa failed!");
        while (1);
    }
    LoRa.setCodingRate4(lora_coding_demoninator);
    LoRa.setSignalBandwidth(lora_signal_bandwidth);
    LoRa.setSpreadingFactor(lora_spreading_factor);
    LoRa.setFrequency(868E6);
    // register the receive callback
    LoRa.onReceive(onReceive);
}

void onReceive(int packetSize) {
  // received a packet
  Serial.print("Received packet '");

  // read packet
  for (int i = 0; i < packetSize; i++) {
    Serial.print((char)LoRa.read());
  }

  // print RSSI of packet
  Serial.print("' with RSSI ");
  Serial.println(LoRa.packetRssi());
  //Serial.println(LoRa.packetFrequencyError());
}

void loop()
{
    Serial.print("Sending packet: ");
    Serial.println(counter);

    // send packet
    LoRa.beginPacket();
    LoRa.print("TTGO ");
    LoRa.print(counter);
    LoRa.endPacket();

    // listen incoming packets
    LoRa.receive();

    counter++;

    delay(10000);
}

As you can see, the board initialise, send a Lora message and then listen incoming messages for ten seconds, repeating the loop.

Here instead we have the code of the Heltec Lora32 V2, which actually send a lora message every 10 seconds. This is the Arduino proposed Example for this board:

#include "heltec.h"
#define BAND    868E6  //you can set band here directly,e.g. 868E6,915E6

int counter = 0;

// lora config
int lora_coding_demoninator = 5;
int lora_signal_bandwidth = 125E3;
int lora_spreading_factor = 7;

void setup() {
  
  //WIFI Kit series V1 not support Vext control
  Heltec.begin(true /*DisplayEnable Enable*/, true /*Heltec.LoRa Disable*/, true /*Serial Enable*/, true /*PABOOST Enable*/, BAND /*long BAND*/);
  LoRa.setCodingRate4(lora_coding_demoninator);
  LoRa.setSignalBandwidth(lora_signal_bandwidth);
  LoRa.setSpreadingFactor(lora_spreading_factor); 
  
}

void loop() {
  Serial.print("Sending packet: ");
  Serial.println(counter);
  // send packet
  LoRa.beginPacket();
/*
* LoRa.setTxPower(txPower,RFOUT_pin);
* txPower -- 0 ~ 20
* RFOUT_pin could be RF_PACONFIG_PASELECT_PABOOST or RF_PACONFIG_PASELECT_RFO
*   - RF_PACONFIG_PASELECT_PABOOST -- LoRa single output via PABOOST, maximum output 20dBm
*   - RF_PACONFIG_PASELECT_RFO     -- LoRa single output via RFO_HF / RFO_LF, maximum output 14dBm
*/
  LoRa.setTxPower(14,RF_PACONFIG_PASELECT_PABOOST);
  LoRa.print("Lora32 ");
  LoRa.print(counter);
  LoRa.endPacket();
  
  counter++;
  digitalWrite(25, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(25, LOW);    // turn the LED off by making the voltage LOW
  delay(9000);                       // wait for a second
}

And then there is the code of the two Pycom LoPy boards, which is uPython. I share it, but these two boards have been used a lot in the last year, so they work as should.

count = 0


while True:
    lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, bandwidth=LoRa.BW_125KHZ, sf=7)
    # create a raw LoRa socket
    s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
    print("Sending Lora message")
    s.setblocking(True)
    message = 'LoPy '+ str(count)
    s.send(message)

    print("Listening on Lora...")
    # get any data received...
    t_end = time.time() + 10
    while time.time() <= t_end:
        #s.setblocking(False)
        msg = s.recv(64)
        if len(msg)>=2:
            print(msg)
            print(lora.stats())

    count = count + 1
    s.close()

As told before, no packets loss/communication issues between the two loPy boards and the Heltec board, while these three board can’t almost receive any packets from the TTGO board (just a message in a couple of hours, if i remember well). Also, the TTGO receive just some packets from the Pycom and Heltec boards, let’s say 50% of the packets sent, while all the messages sent from the second TTGO board are received correctly.

I also thought that the issue is due to too much packets collisions, but I’m using just five boards with a message period between each message of at least 10 seconds, which given SF7 and the small payload, should not be an issue at all. i also started the board in order to let them send messages without any overlap.

That’s all.

pagliuz95:
Thank you for your answer.

From TTGO board to TTGO board, using the RX and TX example I have no issue when they communicate, the same happen between the Pycom LoPy and Heltec LoRa32 boards, which, even if they are different boards communicate between them without issues and packets loss.

I'm pretty sure that the settings (SF, frequency, coding rate and BW) are the same.

Pretty sure only ?

Clearly either you have faulty hardware or the settings are not all the same.

The two other settings that need to match are the InvertIQ setting and the Syncword.
Dont assume that the different libraries you are using are all using the exact same defaults.

I mix Arduino ATMega, STM32, ESP32, Zero, DUE and Teensy devices, with my own LoRa library without issue, but then since its the same library I am confident all the settings are the same.

I was just testing an SX1278 on an ESP32CAM, this is the (optional) printout I can get at startup which actually reads back from the LoRa device how it has been setup and print the results;

SX1278_PABOOST,434000000hz,SF7,BW125000,CR4:5,LDRO_Off,SyncWord_0x12,IQNormal,Preamble_8
SX1278_PABOOST,SLEEP,Version_12,PacketMode_LoRa,Explicit,CRC_On,AGCauto_On,LNAgain_1,LNAboostHF_On,LNAboostLF_Off

Reg    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0x00  D0 81 1A 0B 00 52 6C 80 00 4F 09 2B 23 01 00 00 
0x10  00 00 00 00 00 00 00 00 10 00 00 00 00 72 74 64 
0x20  00 08 FF FF 00 00 04 00 00 00 00 00 00 50 14 40 
0x30  00 43 05 27 1C 0A 03 0A 42 12 52 1D 00 AF 00 00 
0x40  00 00 12 24 2D 00 03 00 04 23 00 09 05 84 32 2B

I don't understand the point of "mix and match".

If you want reliable communications, use identical, reliable parts.

jremington:
I don't understand the point of "mix and match".

If you want reliable communications, use identical, reliable parts.

As long as the LoRa devices are setup the same, it should, and is designed to be, of no consequence which microcontroller you use.

The Things Network (TTN) is an example of a 'reliable' system using LoRa, the nodes\sensors use many different microcontrollers and several different libraries. The Gateways use completly different setups and libraries. TTN would not be in any way practical if you had to use 'identical' parts.

What is unfortunate with some LoRa libraires is that they obscure the defaults they are using which can cause interoperability problems.

I agree that the microcontrollers are irrelevant, which is why I did not mention them.

The two other settings that need to match are the InvertIQ setting and the Syncword.
Dont assume that the different libraries you are using are all using the exact same defaults.

Both boards IQ is the same, otherwise I would not receive at least some messages. What I could be missing is the SyncWord, which is a parameter I didn't know. I'll look at it.

Yeah, I know I'm using different libraries but I checked them "in deep" in order to see if the main parameters are the same or not. Didn't find anything about the SycnWord, which I'm going to investigate.

Thanks for your suggestion.

I don't understand the point of "mix and match".

If you want reliable communications, use identical, reliable parts.

You are right, but the nodes of this "network" will have different role, that's why I need one or two TTGO with GPS

Ok, it was the different Syncword set by the library, but I still can't understand why some messages could be still received .... Anyway problem solved, I didn't know about this parameter

pagliuz95:
Ok, it was the different Syncword set by the library, but I still can’t understand why some messages could be still received … Anyway problem solved, I didn’t know about this parameter

Ah, if you play with LoRa long enough, you will discover that syncwords do not in reality behave as you might expect.

Dont be tempted to change them from the two standards, 0x12 and 0x34, moving away from these can cause interoperabitly issues with other LoRa devices such as the SX126x devices and\or a loss of sensitivity.

srnet:
Ah, if you play with LoRa long enough, you will discover that syncwords do not in reality behave as you might expect.

Dont be tempted to change them from the two standards, 0x12 and 0x34, moving away from these can cause interoperabitly issues with other LoRa devices such as the SX126x devices and\or a loss of sensitivity.

Ok, nice to know.

On the Heltec/Pycom board it was set by default to 0x12, while on the TTGO on 0x34