jpmeijers / RN2483-Arduino-Library

Arduino C++ code to communicate with a Microchip RN2483 module
Apache License 2.0
84 stars 60 forks source link

Library seems to fail when sending > 11 bytes of data #78

Open kevin192291 opened 4 years ago

kevin192291 commented 4 years ago

I can't seem to get anything over 11 bytes of data to send. When I write: myLora.txBytes(txBuffer, sizeof(txBuffer)); if txBuffer is > 11 bytes, it will return 0 and take almost no time to process. I have also made sure to have callend the end() function on my software serial device.

Any ideas as to why this happens? Btw, I am using an esp32 and the rn2903 is running from hardware serial.

paulw517 commented 3 years ago

Kevin192291, I have been struggling with ESP32 DEV module and RN2903 LoRa P2P Radio’s on HardwareSerial, could we communicate about your success?

Paul Wilkie wipaulmar3@aol.com

TD-er commented 3 years ago

When sending fails after a specific number of bytes, then it seems like there is a timing issue.

Are you sure the baud rate is set correct? The default baud rate for this chip is 57600 bps. The autobaud is a bit tricky, as you must pull a pin low and then immediately send a specific bit pattern with the desired baud rate.

For example set the serial to 600 bps and write 0x00 then switch to the desired baud rate and write 0x55.

But to avoid issues with the baud rate, first try the default baud rate and make sure the start and stop bits are set correct. For example there is also a mode with "1.5" stop bit, which takes 1.5 times the normal length of a bit period.

kevin192291 commented 3 years ago

I see, I have removed the auto baud from my initialization code. I was already setting the serial port to 57600, here is what I have:

uint8_t txBuffer[17];

void setup()
{
  // Open serial communications and wait for port to open:
  Serial.begin(115200); //serial port to computer
  Serial2.begin(57600); //serial port to radio

  Serial.println("Startup");
  initialize_radio();
  Serial.println("Radio Initialized Complete");
}

void initialize_radio()
{
  //reset rn2483
  pinMode(LORA_RESET, OUTPUT);
  digitalWrite(LORA_RESET, LOW);
  delay(100);
  digitalWrite(LORA_RESET, HIGH);
  delay(100); //wait for the RN2xx3's startup message
  Serial2.flush();

  //check communication with radio
  String hweui = myLora.hweui();
  while(hweui.length() != 16)
  {
    Serial.println("Communication with RN2xx3 unsuccessful. Power cycle the board.");
    Serial.println(hweui);
    delay(1500);
    hweui = myLora.hweui();
  }

  //print out the HWEUI so that we can register it via ttnctl
  Serial.println("When using OTAA, register this DevEUI: ");
  Serial.println(myLora.hweui());
  Serial.println("RN2xx3 firmware version:");
  Serial.println(myLora.sysver());

  //configure your keys and join the network
  Serial.println("Trying to join TTN");
  bool join_result = false;

  /*
   * OTAA: initOTAA(String AppEUI, String AppKey);
   * If you are using OTAA, paste the example code from the TTN console here:
   */
  const char *appEui = "omitted!";
  const char *appKey = "even more omitted!!!";
  join_result = myLora.initOTAA(appEui, appKey);

  while(!join_result)
  {
    connectAttempts++;
    if(connectAttempts > 4) {
      ESP.restart();
    }
    Serial.println("Unable to join. Are your keys correct, and do you have TTN coverage?");
    delay(1000); //delay a minute before retry
    join_result = myLora.init();
  }
  Serial.println("Successfully joined TTN");

}

and later on in the loop I have:

int result = myLora.txBytes(txBuffer, sizeof(txBuffer)); however, by changing the txBuffer array to 7 elements instead of 17 it will work, like so int result = myLora.txBytes(txBuffer, 7); It will also work if i change the actual size of the array up top too.

TD-er commented 3 years ago

See this part of the library: https://github.com/jpmeijers/RN2483-Arduino-Library/blob/9a66cf836482294e371aaae7712f44c7bd0b0990/src/rn2xx3.cpp#L332-L344

Can you change the buffer allocation to something like this:

char msgBuffer[size*2 + 1] = {0};

Just to make sure the buffer is allocated with zeroes (and thus automatically zero-terminated) before it is converted to a String object.

kevin192291 commented 3 years ago

Just made the update the update to both the library with the same results, it seems to be exactly the same. then after that I tried adding the zero to the end of my array and no luck with that as well (uint8_t txBuffer[17] = {0};) Then just to double check, I added a txBytes call right after the ttn connection like so: uint8_t txStartupBuffer[11] = {1,2,3,4,5,6,7,8,9,10,11}; //(at the top) ... delay(1000); //delay a minute before retry join_result = myLora.init(); } Serial.println("Successfully joined TTN"); myLora.txBytes(txStartupBuffer, sizeof(txStartupBuffer)); //Works perfectly!!! delay(1000); myLora.txBytes(txBuffer, sizeof(txBuffer)); //nothing

I am not sure if this will be useful, but here is the json from the successful 11 bytes sent:

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
  "end_device_ids": {
    "device_id": "esp32device",
    "application_ids": {
      "application_id": "name"
    },
    "dev_eui": "0004A30B00EB24FF",
    "join_eui": "70B3D57ED0030779",
    "dev_addr": "01CC43D4"
  },
  "correlation_ids": [
    "as:up:01ECT6RQFGZCGM6G8406PDM9MK",
    "gs:conn:01ECSXYWE82DWGES72FSKMRZ8W",
    "gs:uplink:01ECT6RQ925Y7XC3CM98MFKAJA",
    "ns:uplink:01ECT6RQ93GN32KFHRTQ05SQH9",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01ECT6RQ93PDN5YRZHGQANJWB1"
  ],
  "received_at": "2020-07-09T16:33:03.984948336Z",
  "uplink_message": {
    "session_key_id": "AXM0bENROmfCTicMG1OXWg==",
    "f_port": 1,
    "frm_payload": "AQIDBAUGBwgJCgs=",
    "decoded_payload": {
      "f_port": 1,
      "raw": [
        1,
        2,
        3,
        4,
        5,
        6,
        7,
        8,
        9,
        10,
        11
      ]
    },
    "rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "kevinsgateway"
        },
        "time": "2020-07-09T16:33:04Z",
        "timestamp": 1104820108,
        "rssi": -109,
        "snr": -14.5,
        "uplink_token": "ChEKDwoNa2V2aW5zZ2F0ZXdheRCM7+iOBA=="
      }
    ],
    "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 10
        }
      },
      "coding_rate": "4/5",
      "frequency": "905300000",
      "timestamp": 1104820108
    },
    "received_at": "2020-07-09T16:33:03.779542903Z"
  }
}
kevin192291 commented 3 years ago

I just realized, I tested a working device, and on messages that do sent, I get the value: data_rate_index just above, "coding_rate" here is an example of a working version using thethingnetwork.h library:

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
  "end_device_ids": {
    "device_id": "the-things-uno",
    "application_ids": {
      "application_id": "name"
    },
    "dev_eui": "omitted",
    "join_eui": "omitted",
    "dev_addr": "omitted"
  },
  "correlation_ids": [
    "as:up:01ECVHWGMRXRQ21N3WRVWC86T9",
    "gs:conn:01ECVA4459S8CFAZ7ZXKR9TZCF",
    "gs:uplink:01ECVHWGEB5XARN05BN2F36P8J",
    "ns:uplink:01ECVHWGEB9A9WBQ1KA1MD2ARS",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01ECVHWGEB9TWA26CKRSS51QCG"
  ],
  "received_at": "2020-07-10T05:06:36.824709377Z",
  "uplink_message": {
    "session_key_id": "AXM3HaWvCjLNPERuod8eWw==",
    "f_port": 1,
    "f_cnt": 2,
    "frm_payload": "AGQI3wwHAVUAAAAAGK0I/QYY",
    "decoded_payload": {
      "f_port": 1,
      "raw": [
        0,
        100,
        8,
        223,
        12,
        7,
        1,
        85,
        0,
        0,
        0,
        0,
        24,
        173,
        8,
        253,
        6,
        24
      ]
    },
    "rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "kevinsgateway"
        },
        "time": "2020-07-10T05:06:36Z",
        "timestamp": 376066731,
        "rssi": -54,
        "snr": 11,
        "uplink_token": "ChEKDwoNa2V2aW5zZ2F0ZXdheRCrpamzAQ=="
      }
    ],
    "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 7
        }
      },
      "data_rate_index": 3,     <----------------------------That is not there when using RN2xx3 library!!!
      "coding_rate": "4/5",
      "frequency": "904100000",
      "timestamp": 376066731
    },
    "received_at": "2020-07-10T05:06:36.619778535Z"
  }
}
kevin192291 commented 3 years ago

I added this to the bottom of the txBytes method:

String dataToTx = String(msgBuffer);
  _debug.print("string: ");
  _debug.println(dataToTx);
  _debug.print("string length");
  _debug.println(dataToTx.length());
  _debug.print("string Data Sizeof");
  _debug.println(sizeof(dataToTx));
  return txCommand("mac tx uncnf 1 ", dataToTx, false);

Here is my output:

string: 000000000000000000000000000000000000000D
string length40
string Data Sizeof12
Library Pre from txCommand says:
12

it appears to me that after String dataToTx(msgBuffer); the output size is always 12... Not sure why yet.

Mark-Wills commented 3 years ago

This looks correct. sizeof is returning the size of the type (a string object) which would be done at compile time. It is not returning the length of your string within your string object because sizeof does not know how to inspect your object to extract the string.

Regards

Mark

On Wed, 15 Jul 2020, 05:42 Kevin, notifications@github.com wrote:

I added this to the bottom of the txBytes method:

String dataToTx = String(msgBuffer); _debug.print("string: "); _debug.println(dataToTx); _debug.print("string length"); _debug.println(dataToTx.length()); _debug.print("string Data Sizeof"); _debug.println(sizeof(dataToTx)); return txCommand("mac tx uncnf 1 ", dataToTx, false);

Here is my output:

string: 000000000000000000000000000000000000000D string length40 string Data Sizeof12 Library Pre from txCommand says: 12

it appears to me that after String dataToTx(msgBuffer); the output size is always 12... Not sure why yet.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jpmeijers/RN2483-Arduino-Library/issues/78#issuecomment-658541865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFAGDCUBWMKRVECZ27RLUCTR3UXS7ANCNFSM4OU4RZKQ .

kevin192291 commented 3 years ago

Is there a way for me to lower the spread factor with this library?

TD-er commented 3 years ago

Is there a way for me to lower the spread factor with this library?

The data rate (DR, see setdr) reflects the spreading factor. For EU settings: dr = 12 - sf for sf>= 7 && sf <=12.

For US settings: dr = 10 - sf

Make sure to only set the data rate for dr >= 0 && dr <= 5.