When examples from this library are loaded, the boron either starts in safe mode and the code never runs, or it runs and instantly sends an SOS with red 10 blinks in between, indicating an assertion failure.
I have tried both the included examples, the encrypted and the datagram versions. Through removing certain parts of code, I believe I have found that the issue lies when running “rf95.init()” but I am unsure how to sidestep this as it is an integral part of the code.
I have included the libraries in the web IDE, it compiles without issue, and then I flash it via the CLI.
The pins I am using for the transciever are as follows:
I just tested version RF9X-RK version 0.0.5 on a Boron with Device OS 2.1.0 and it started up properly. The device got to breathing cyan and the following was printed in the serial monitor.
Serial monitor opened successfully:
LoRa Simple_Encrypted Server
Setup completed
If the Boron is going into safe mode, hold down the MODE button until the status LED blinks dark blue (listening mode) and enter the CLI command:
particle serial inspect
I tested example 1, encrypted server. Same pin configuration as the example in the library and what you have above.
I am successfully using the library on Device OS2.1.0...
@rickkas7 - Wasn't there something special/unique with pin A5 that you fixed for me in the library. I wonder if that is at play here somehow? Does this ring a bell? Maybe unrelated... but figured I'd mention it.
Thank you so much for the incredibly fast response, it’s really appreciated. My Device OS is 1.4 so that might be the problem, I’ll update it to 2.1 and double check and let you know!
My concern is that I also need to use a xenon with this that is just being used for the other point of the lora point to point. I understand that there is a problem with the xenons on going past 1.5.
For me it seemed to be an issue with the pins I was using. Regarding the flashing lights, I believe by default the board is configured to attempt an LTE connection on startup, so if that fails it doesn’t get to execute your own code from what I understood in the documentation. In order to test things without having to worry about that, I included a call to SYSTEM_MODE(MANUAL) in my initialization.
The code below is what I used to test a transmitter using the reliable datagram. It’s a combination of what was available from the Adafruit website’s arduino examples and @rickkas7 library code:
#include <RHReliableDatagram.h>
#include <RH_RF95.h>
#include <SPI.h>
#define CLIENT_ADDRESS 1
#define SERVER_ADDRESS 2
// /* Boron LTE */
#define RFM95_CS D8
#define RFM95_RST D7
#define RFM95_INT D6
#define RF95_FREQ 915.0
SYSTEM_MODE(MANUAL)
// Singleton instance of the radio driver
RH_RF95 driver(RFM95_CS, RFM95_INT);
float frequency = RF95_FREQ;
// Class to manage message delivery and receipt, using the driver declared above
RHReliableDatagram manager(driver, SERVER_ADDRESS);
void setup()
{
pinMode(RFM95_RST, OUTPUT);
digitalWrite(RFM95_RST, HIGH);
Serial.begin(115200);
delay(5000);
while (!Serial) { delay(1); }
Serial.println("Feather LoRa TX Test!");
// manual reset
digitalWrite(RFM95_RST, LOW);
delay(2000);
digitalWrite(RFM95_RST, HIGH);
delay(2000);
Serial.println("Going to init manager.");
while (!manager.init())
{
Serial.println("LoRa radio init failed");
Serial.println("Uncomment '#define SERIAL_DEBUG' in RH_RF95.cpp for detailed debug info");
while (1);
}
Serial.println("LoRa radio init OK!");
Serial.println("Manager init successful.");
Serial.println("Setting frequency.");
if (!driver.setFrequency(RF95_FREQ))
{
Serial.println("setFrequency failed");
while (1);
}
Serial.print("Set Freq to: "); Serial.println(RF95_FREQ);
Serial.println("Frequency set.");
}
int16_t packetnum = 0; // packet counter, we increment per xmission
void loop()
{
delay(1000); // Wait 1 second between transmits, could also 'sleep' here!
Serial.println("Transmitting..."); // Send a message to rf95_server
char radiopacket[20] = "Hello World # ";
itoa(packetnum++, radiopacket+13, 10);
Serial.print("Sending "); Serial.println(radiopacket);
radiopacket[19] = 0;
Serial.println("Sending...");
delay(10);
driver.send((uint8_t *)radiopacket, 20);
Serial.println("Waiting for packet to complete...");
delay(10);
driver.waitPacketSent();
// Now wait for a reply
uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];
uint8_t len = sizeof(buf);
Serial.println("Waiting for reply...");
if (driver.waitAvailableTimeout(1000))
{
if (driver.recv(buf, &len))
{
Serial.print("Got reply: ");
Serial.println((char*)buf);
Serial.print("RSSI: ");
Serial.println(driver.lastRssi(), DEC);
}
else
{
Serial.println("Receive failed");
}
}
else
{
Serial.println("No reply, is there a listener around?");
}
}
I tested a Boron running 1.5.2 and the 1-encrypted-server example with the default pin definitions in the example and what you have above.
I also tested a Xenon running 1.5.2 and the 2-encrypted-client example and they were able to exchange data successfully.
The Boron really doesn’t need to run 1.5.2 if you’re not using it as a mesh gateway. You can run a newer version of Device OS on the Boron and keep the Xenon back at 1.5.2, the latest it can run. Of course you need to flash the Xenon by USB if you are using it not in a mesh network.
LoRa Simple_Encrypted Server
Setup completed
Received: Hello World ! I'm happy if you can read me
Received: Hello World ! I'm happy if you can read me
Received: Hello World ! I'm happy if you can read me
Received: Hello World ! I'm happy if you can read me
Received: Hello World ! I'm happy if you can read me
Received: Hello World ! I'm happy if you can read me
Thank you so much for the immensely fast and detailed responses, the support here is incredible. I have been bashing my head into a wall for the past week trying to solve this so to see some potential solutions is incredible. I will try the things suggests here and report back.
Also, the fastest and easiest way to upgrade a standalone Xenon is to use the Chrome web browser on Mac, Linux, Windows 10, or Chromebook and Device Restore USB.
Actually, it’s the easiest way to upgrade or downgrade any device, but it’s especially useful on a standalone Xenon because without the cloud a standalone Xenon can’t update components OTA.
I ended up using the “particle update” function on the CLI so its not on 2.1 and the code now runs smoothly, thank you for your help. I will try the xenon in about a week and check that data can transfer is running smoothly.
For reference, if it doesn’t, would it be feasible to replace the xenon with an arduino uno or something similar to collect sensor data and send it point to point to the boron which can then handle all the cloud functionality??
There is a few different variants of it based on frequency and processor but generally speaking this will work just fine sending/receiving LoRa messages to your Boron + LoRa radio. What I really like about it is it's the same form factor and roughly the same GPIO pinout as the Boron making it a familiar hardware to work with or at least prototype with. Adafruit has a nice tutorial with examples as well. I've had good success with this hardware combination! Feel free to reach out again as you have more questions.