search

ElectronicCats / Beelan-LoRaWAN

A LoRaWAN library for compatible arduino board
https://www.beelan.mx
MIT License
195 stars 83 forks source link

Periodically repeated downlink #175

Closed BrendonBernardino closed 1 year ago

BrendonBernardino commented 1 year ago

ABP Mode, Class C When I receive downlink, periodically this message repeat itself, then after a few minutes I receive the same downlink. Any solution for this?

AndreaZGuz commented 1 year ago

Hi @BrendonBernardino!

I would like you to share with me some additional information to understand better the issue:

BrendonBernardino commented 1 year ago
AndreaZGuz commented 1 year ago

Hi @BrendonBernardino

Can you share your complete code to run a test on our side? And some screenshots showing the issue you described with repeated downlink?

BrendonBernardino commented 1 year ago

In this image below, I send the downlink message one single time (SOLARMOD), but like you ever seen the message repeat itself, no fixed interval between messages, just random. image

`

include

include

// #define LORA_NSS 18U // // #define LORA_DIO0 26U // // #define LORA_DIO1 35U // LORA PINS // #define LORA_DIO2 34U // // #define LORA_RST 14U // // #define LORA_MISO 19U // // #define LORA_MOSI 27U // SPI PINS // #define LORA_SCLK 5U //

define LORA_NSS 15U //

define LORA_DIO0 25U //

define LORA_DIO1 26U // LORA PINS

define LORA_DIO2 27U //

define LORA_RST 33U //

define LORA_MISO 12U //

define LORA_MOSI 13U // SPI PINS

define LORA_SCLK 14U //

define LORA_ON 32U

// sRFM_pins RFM_pins = { // .CS = SS, // .RST = RFM_RST, // .DIO0 = RFM_DIO0, // .DIO1 = RFM_DIO1, // .DIO2 = RFM_DIO2, // .DIO5 = RFM_DIO5 // };

//ABP Credentials const char devAddr = "00000011"; const char nwkSKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; const char *appSKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

const unsigned long interval = 10000; // 10 s interval to send message unsigned long previousMillis = 0; // will store last time message sent unsigned int counter = 0; // message counter

char myStr[50]; char outStr[255]; byte recvStatus = 0; uint8_t txcount = 0;

const sRFM_pins RFM_pins = { .CS = LORA_NSS, .RST = LORA_RST, .DIO0 = LORA_DIO0, .DIO1 = LORA_DIO1, .DIO2 = LORA_DIO2, .DIO5 = -1 };

void setup() { Serial.begin(115200); Serial.println("STARTING PROTOCOL");

gpio_config_t lora_on; lora_on.mode = GPIO_MODE_OUTPUT; lora_on.pin_bit_mask = (uint64_t)(1ULL << LORA_ON); lora_on.pull_down_en = GPIO_PULLDOWN_DISABLE; lora_on.pull_up_en = GPIO_PULLUP_ENABLE; lora_on.intr_type = GPIO_INTR_DISABLE;

gpio_config(&lora_on); gpio_set_level((gpio_num_t)LORA_ON, HIGH);

SPI.begin(LORA_SCLK, LORA_MISO, LORA_MOSI, LORA_NSS);

if(!lora.init()){ Serial.println("RFM95 not detected"); delay(5000); return; }

// Set LoRaWAN Class change CLASS_A or CLASS_C lora.setDeviceClass(CLASS_C);

// Set Data Rate lora.setDataRate(SF8BW125);

// set channel to random lora.setChannel(MULTI);

// Put ABP Key and DevAddress here lora.setNwkSKey(nwkSKey); lora.setAppSKey(appSKey); lora.setDevAddr(devAddr); sprintf(myStr, "Counter-%d", counter);

Serial.print("Sending: "); Serial.println(myStr);

lora.sendUplink(myStr, strlen(myStr), 0, 2); counter++; }

void loop() { // delay(100); if(millis() - previousMillis > interval) { sprintf(myStr, "Counter-%d", counter); 

Serial.print("Sending: ");
Serial.println(myStr);

previousMillis = millis();
lora.sendUplink(myStr, strlen(myStr), 0, 2);
counter++;

}

recvStatus = lora.readData(outStr);

if(recvStatus) { Serial.print("Recebido ---> "); Serial.println(outStr); }

lora.update(); } ` I tested a change in the file lorawan-arduino-rfm.cpp (update method), this fixed the trouble in my case:

image

BrendonBernardino commented 1 year ago

image image

AndreaZGuz commented 1 year ago

@BrendonBernardino

Thank you for the information. We will run some tests to confirm the behavior. As soon as we have news, we are informing you.

AndreaZGuz commented 1 year ago

Hi, @BrendonBernardino.

We performed some tests and the application is working properly with The Things Network, ABP class C. Of course, using the last revision of the library (2.0.4). We are trying to replicate it with Chirpstack. If you could help us confirm the following information:

  1. Which version of the library are you using?
  2. How are you sending the downlink to the node? Are you using the Queue section of the server?
  3. Did you modified any RX1/RX2 parameters on the server?
  4. Did you face any issues after you modified the lorawan-arduino-rfm.cpp file?
BrendonBernardino commented 1 year ago

[env:esp32dev] platform = espressif32 board = esp32dev framework = arduino upload_port = COM12 lib_deps = beelanmx/Beelan LoRaWAN@^2.4.0

  1. version 2.4.0
  2. yes, I'm using the queue section (Chirpstack, IoT Core)
  3. No
  4. No, it's working fine
AndreaZGuz commented 1 year ago

Hi, @BrendonBernardino !

Thanks for your reply. Fine, taking a look on the lorawan-arduino-rfm.cpp file, you commented the lines 438 - 441. These lines are related to transmission process. Some lines below, 446 - 453 the IF condition is repeated: if (Buffer_Rx.Counter != 0x00) { Rx_Status = NEW_RX; } But the condition is executed depending on the state of DIO0 pin. I would suggest you confirm this connection. If DIO0 is being read with a wrong state, that would be the reason the downlink message is being read twice.

BrendonBernardino commented 1 year ago

I understood, but I was use other lib - lmic (class A) -, with the same pin for DIO0 and I no have this issue.

AndreaZGuz commented 1 year ago

Hi @BrendonBernardino!

Thanks!

This section in your code sets the pins you will use as RFM pins on your esp32:

const sRFM_pins RFM_pins = {
.CS = LORA_NSS,
.RST = LORA_RST,
.DIO0 = LORA_DIO0,
.DIO1 = LORA_DIO1,
.DIO2 = LORA_DIO2,
.DIO5 = -1
};

Then, in this section:

gpio_config_t lora_on;
lora_on.mode = GPIO_MODE_OUTPUT;
lora_on.pin_bit_mask = (uint64_t)(1ULL << LORA_ON);
lora_on.pull_down_en = GPIO_PULLDOWN_DISABLE;
lora_on.pull_up_en = GPIO_PULLUP_ENABLE;
lora_on.intr_type = GPIO_INTR_DISABLE;

gpio_config(&lora_on);
gpio_set_level((gpio_num_t)LORA_ON, HIGH);

SPI.begin(LORA_SCLK, LORA_MISO, LORA_MOSI, LORA_NSS);

I noticed you declared the GPIO pins as pull_up outputs. Then, you set the pins to the HIGH state. By default, our library sets DIO0 as an input.

In addition, we tested the application using a BastWAN, whose DIO0 pin is not physically connected to +V, or 0V.

The facts above could be linked to this unexpected behavior in the downlink process (receiving and printing). Another point I suggest is to verify that the downlink is not still in the queue, in the Chirpstack's "Queue" section; this may cause a repeated downlink sent to the node.

BrendonBernardino commented 1 year ago

"gpio_config_t lora_on; lora_on.mode = GPIO_MODE_OUTPUT; lora_on.pin_bit_mask = (uint64_t)(1ULL << LORA_ON); lora_on.pull_down_en = GPIO_PULLDOWN_DISABLE; lora_on.pull_up_en = GPIO_PULLUP_ENABLE; lora_on.intr_type = GPIO_INTR_DISABLE;

gpio_config(&lora_on); gpio_set_level((gpio_num_t)LORA_ON, HIGH);

SPI.begin(LORA_SCLK, LORA_MISO, LORA_MOSI, LORA_NSS);"

in this section, what I do is set LORA_ON in Pull up and its state to HIGH, LORA_ON is the GPIO32, in my board have a mosfet that need be in HIGH for the Lora starts, that's why LORA_ON.

AndreaZGuz commented 1 year ago

Hi, @BrendonBernardino !

Thank you for clarifying. The tests we ran did not replicate this issue. It worked properly for us. Main differences:

However, we appreciate you sharing with us the way you solved the problem on our side. This feedback will help us to improve the performance of the library. We invite you to keep updated with new releases for this library and feel free to contact us again in case you face any other issue so we can help you with the troubleshooting process.