Heltec PingPong more complex than TTGO PingPong

#1

I am want to use some of my CubeCell boards to talk to my TTGO board.

I can’t find any examples of Cube using Lora.h

board = ttgo-lora32-v21
SX1276[868/915Mhz]

The TTGO Lora PingPong config is configured like this using the Lora.h lib:

#include <SPI.h>
#include <LoRa.h>
#include <Wire.h>  
#include "images.h"
#include <Arduino.h>
#include "SSD1306.h" 

#define SCK     5    // GPIO5  -- SX1276's SCK
#define MISO    19   // GPIO19 -- SX1276's MISO
#define MOSI    27   // GPIO27 -- SX1276's MOSI
#define SS      18   // GPIO18 -- SX1276's CS
#define RST     23   // GPIO14 -- SX1276's RESET
#define DI0     33   // GPIO26 -- SX1276's IRQ(Interrupt Request)
#define BAND  915E6
#define RADIO_TYPE SX1276

  SPI.begin(SCK,MISO,MOSI,SS);
  LoRa.setPins(SS,RST,DI0);

The Heltec PingPong is configured using the LoraWan.h lib:

#include "LoRaWan_APP.h"
#include "Arduino.h"

#ifndef LoraWan_RGB
#define LoraWan_RGB 0
#endif

#define RF_FREQUENCY                                915000000 // Hz

#define TX_OUTPUT_POWER                             5        // dBm

#define LORA_BANDWIDTH                              0         // [0: 125 kHz,
                                                              //  1: 250 kHz,
                                                              //  2: 500 kHz,
                                                              //  3: Reserved]
#define LORA_SPREADING_FACTOR                       7         // [SF7..SF12]
#define LORA_CODINGRATE                             1         // [1: 4/5,
                                                              //  2: 4/6,
                                                              //  3: 4/7,
                                                              //  4: 4/8]
#define LORA_PREAMBLE_LENGTH                        8         // Same for Tx and Rx
#define LORA_SYMBOL_TIMEOUT                         0         // Symbols
#define LORA_FIX_LENGTH_PAYLOAD_ON                  false
#define LORA_IQ_INVERSION_ON                        false


#define RX_TIMEOUT_VALUE                            1000
#define BUFFER_SIZE                                 30 // Define the payload size here
#2

The [Sandeep Mistry] LoRa[.h] library doesn’t support the SX1262 LoRa Node chip in the CubeCell.

The problem with communications between an SX1276 running the LoRa library and an SX1262 running the [Heltec] Radio (LoRa_APP or LoRaWan_APP) library is usually the SyncWord setting (see here for settings that have been used successfully in similar situations).

#3

Thank you @UniquePete.

I reviewed your website a month ago and it is pretty incredible. So impressed with the thorough documentation of your systems.

I will re-read that page.

#4

Reading your excellent review of different module talking together, I am…still trying to understand.

So going one level up to LoraWan, does that equalize all boards so they can talk to each other?
I know this might have been a less than smart question.

Should I be going about this another way? Or board families just shouldn’t talk to each other unless one is at your level?

#5

LoRa works below LoRaWAN, so you have to have LoRa working before you get to LoRaWAN and, for the most part, it’s the LoRa Node chips, not the host processors, that you are getting to work together. In most cases discussed here, that’ll simply be a matter of getting the different Semtech chips configured appropriately. And it’s not necessarily a matter of using the same libraries on all modules, although it does simplify matters if you have a single library that supports the LoRa Node chips, be they the same or different, that you are using.

As you will have noticed, the [Sandeep Mistry] LoRa and [Heltec] Radio libraries are quite different in their respective approaches, but both are implementations of the LoRa protocol and, once the configuration parameters have been sorted out, individual nodes are entirely agnostic with regard to the code running on another communicating node.

#6

Seems like the RadioLib library has been updated for the SX1262 chip. Maybe I should focus on using that as it supports many or all Lora Chips?

#7

One library that rules them all sounds like a good plan to me. That certainly should simplify code portability and maintenance.