I have a RAK4630 communicating to another RAK4630 using LoRa P2P … everything works fine
#ifndef __LORA_RADIO_H__
#define __LORA_RADIO_H__
#ifndef LORA_SPREADING_FACTOR
/*********
* The larger spreading factors therefore give more range, the trade off is that higher
* spreading factor packets take longer to transmit.
***************************************************************************/
#define LORA_SPREADING_FACTOR 7 // [SF7..SF12]
#define LORA_BANDWIDTH 0 // [0: 125 kHz, 1: 250 kHz, 2: 500 kHz, 3: Reserved]
/**
* supported by the Semtech chip
* 7.8Khz, 10.4Khz, 15.6Khz, 20.8Khz, 31.25Khz, 41.7Khz, 62.5Khz, 125Khz, 250Khz, 500Khz.
* A low bandwidth signal, such as 7.8Khz will give the best (longest distance) performance
*/
#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 TX_OUTPUT_POWER 22
#define TX_TIMEOUT_VALUE 500
#define RX_TIMEOUT_VALUE 500
#endif // !LORA_SPREADING_FACTOR
#endif // __LORA_RADIO_H__
We need to also receive comms from other units; the particular unit however in this case is a Seeeduino Xiao
, connected to an Adafruit RFM9x Lora Radio
breakout board.
The RFM9x uses the following simple sketch
#include <Arduino.h>
#include <SPI.h>
#include <RH_RF95.h>
#define RFM95_CS 7
#define RFM95_INT 6
#define LORA_frequency 868.3
RH_RF95 rf95(RFM95_CS, RFM95_INT);
void setup()
{
Serial.begin(115200);
delay(100);
uint32_t timestamp = millis();
while(millis() - timestamp < 2000)
;
Serial.println("LoRa radio TX Test");
while (!rf95.init()) { Serial.println("LoRa radio init failed"); delay(1000); }
while (!rf95.setFrequency(LORA_frequency))
{
Serial.print("Setting Freq to: "); Serial.print(LORA_frequency); Serial.println(" failed"); delay(1000);
}
rf95.setTxPower(20);
rf95.setPayloadCRC(false);
rf95.setModeTx();
}
int packetnum = 0; // packet counter, we increment per xmission
void loop()
{
char message[24] = { 0 };
snprintf(message, 24, "Hello World # %d", packetnum++);
Serial.printf("Sending [%u] %s on ", strlen(message), message); Serial.println(LORA_frequency);
rf95.send((uint8_t *)message, strlen(message));
Serial.println("\tWaiting for packet to complete...");
rf95.waitPacketSent();
delay(1000);
}
This sketch reports sending data between the lengths of 15 and 17 (messages 0-999):
Sending [15] Hello World # 8 on 868.30
Waiting for packet to complete...
Sending [15] Hello World # 9 on 868.30
Waiting for packet to complete...
Sending [16] Hello World # 10 on 868.30
Waiting for packet to complete...
Sending [16] Hello World # 11 on 868.30
Waiting for packet to complete...
Sending [16] Hello World # 12 on 868.30
Waiting for packet to complete...
Sending [16] Hello World # 13 on 868.30
Waiting for packet to complete...
however upon receiving the messages, the RAK reports that the message size is between 19 and 21 respectively, and this is a log of what was received:
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Waiting to receive on 868300000
::Received(868300000Hz) [21] [ÿÿ]
Surely it cannot be the case that we need to use the same LoRa transceiver at both ends? LoRa is just a radio signal, right? So any LoRa decoder listening on the same frequency should be able to decode the message, right?