arduino-libraries / mkrwan Goto Github PK

Hello everyone,

First things first: Arduino MKRWAN 1300, firmware just updated to ARD-078 1.1.9, and MKRWAN library 1.0.10 .

For me ABP join using bare "First configuration" example fails, while OTAA 1.0 works nicely.
Is it just me or that happens to you too?

Hi,
Which SF does the library support ? Is it possible to modify it ?
Thanks for your help.

It appears that there is no documentation on or about the firmware that goes onto the STM32L0 inside the Murata module.
The binary blob is in the standalone-updater example, but not the source.

Including the complete source inside this library would likely not be the right place for it.
But it should still be made public somewhere and linked to in the documentation.

If the firmware is only the AT_slave example from the STM32+SemTech stack LoRa software package, then at least that should be documented, for completeness and clarity.
But it is unclear if any patches are added on top of that distribution.

The LoraSendAndReceive example sketch uses the minPollInterval() function but I can't seem to find any documentation for this function.

modem.minPollInterval(60);
// NOTE: independently by this setting the modem will
// not allow to send more than one message every 2 minutes,
// this is enforced by firmware and can not be changed.

This only sets the pollInterval variable if I read the source correctly so why does the example set it to 60 seconds when the comment underneath states it can't be less than 2 minutes? Shouldn't it be minimum 120 seconds?

Thank you!

I have noticed an anomaly with the MKRWAN library that prevents the application from receiving a downlink payload.

When sending a downlink to a MKR WAN device, I can see the downlink queued by the server. I configured the device to confirm the downlink and I see the ACK in the server log. This occurs when the SAMD21 is sleeping or awake which makes sense since the LoRa stack is running on the Murata module.

When the SAMD21 wakes from sleep and checks the receive buffer using available(), there is nothing in the receive buffer. That is, a call to available() returns 0. If I replace the call to deepsleep() with a delay() to prevent the application from sleeping, the call to available() indicates there is something in the buffer and I can read it out.

Which device coordinates the data transfer between the SAMD21 and the Murata module?

This is probably more a question than a problem.

I have on several occasions noticed that when I attempt to sent a packet, I receive an error with the call to modem.endpacket(). I prepare and send the packet as follows:

modem.beginPacket(); modem.write( (uint8_t *) &sensorPayload, sizeof(sensorPayload)); err = modem.endPacket(false); if (err > 0) { ...

I have noticed that sometimes endPacket() returns an error. Often the next time (about 10 seconds later) the loop tries to send a packet it goes through. On several occasions though, I have noticed that I get into a loop where the endPacket() always returns an error and the packet is never sent. I have noticed this behaviour occasionally when the device has not joined the network. At other times, it appears that the device joined the network but still will not send a packet.

I am struggling to understand why that would happen.

Would is be appropriate that beginPacket() be preceded first by a check to connected() to confirm that the device is still connected? Can the module "loose" its' join status from time to time?

Hi,
I'm testing the library with ABP and unconfirmed frames.
After a frame is successfully sent (say frame A), if one tries to send another one (say frame B) before the duty-cycle allows it, modem.endPacket(false) returns no error, but the frame is not actually sent. Subsequent calls return error (rightly so) until the duty-cycle is available again.
It looks like frame B is queued and, when modem.endPacket(false) returns no error for another frame (say frame C), what is actually sent is the previously queued frame B.

It looks like modem.endPacket(false) return no error if there is no other frame waiting to be sent even though this frame won't be sent.

If this is the intended behaviour (I hope not), is there a way to know if a frame has actually been sent and not only queued? And a way to remove queued but unsent frames?

Otherwise there would be no way to know what frame is actually sent...

Thanks!

Is it possible with the mkr wan to send and receive a message with size more than 64 bytes??

Hi,
I think there's an issue with the modem.write(payload) function.
If we consider payload=123456, in hex payload=1E240.
But when I take a look on my server where the payloads are stored. The value of the payload is: 40E201.
How can we fix that ?
Thanks for your help.

Hello, I've been working with the MKRWAN1300 and evaluating the sleep performance. I believe I have successfully achieved sleep. However the sleep current is 1.16mA. Is it possible to achieve a sleep current with the MKRWAN1300 of less than 1.16mA?

I have found community reports for other SAMD21 products that achieve a lower sleep current. However, I have not found a report that confirms a sleep current less than 1.16mA for the MKRWAN1300 is achievable.

My hardware configuration is 3.3V power is applied to the Vbatt input. USB is disconnected. A0 (DAC output) is connected to A1 (ADC input).

At the moment I suspect a bug in the MKRWAN firmware preventing the Murata device from sleeping properly but I haven't found anything yet.

Wiring.c in the Arduino library was updated to remove initialization of the IO as floating inputs. I have attached my sketch below for reference.

#include <Arduino.h>
#include <ArduinoLog.h>
#include <ArduinoLowPower.h>
#include <MKRWAN.h>
#include <ZeroRegs.h>
#include <RTCZero.h>
#include "arduino_secrets.h"

#define SLEEP_PERIOD ( (uint32_t) 5000 )

// ADC configuration
#define extSensorPin PIN_A1
#define extSensorEnablePin 1

LoRaModem modem;
static uint32_t msgCount = 0;
bool regsShown = false;
// RTCZero rtc;

// Uncomment if using the Murata chip as a module
// LoRaModem modem(Serial1);

// Please enter your sensitive data in the Secret tab or arduino_secrets.h
String appEui = SECRET_APP_EUI;
String appKey = SECRET_APP_KEY;

void blink( int numBlink = 1, unsigned int speed = 200 ) {
  int i;
  while ( numBlink-- ) {
    digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
    delay(speed);                       // wait
    digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
    delay(speed);                       // wait
  }
}

void printTimeStamp(Print* _logOutput) {
  char c[12];
  int m = sprintf(c, "%10lu ", millis());
  _logOutput->print(c);
}

void printNewline(Print* _logOutput) {
  _logOutput->print('\n');
}

void reboot() {
  NVIC_SystemReset();
  while(1) ;
}

void pinStr( uint32_t ulPin, unsigned strength) // works like pinMode(), but to set drive strength
{
  // Handle the case the pin isn't usable as PIO
  if ( g_APinDescription[ulPin].ulPinType == PIO_NOT_A_PIN )
  {
    return ;
  }
  if(strength) strength = 1;      // set drive strength to either 0 or 1 copied
  PORT->Group[g_APinDescription[ulPin].ulPort].PINCFG[g_APinDescription[ulPin].ulPin].bit.DRVSTR = strength ;
}

void InitIO() {
  //  Note:  wiring.c initializes all GPIO as inputs with no pull ups ... it has been modified to eliminate this

  // Configure digital pins used by the application
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(extSensorPin, OUTPUT);
  pinStr(extSensorPin, 1);
  digitalWrite(extSensorEnablePin, LOW);

  // Configure the ADC
  analogReadResolution(12);
  analogWriteResolution(12);
  analogReference(AR_INTERNAL1V65);
}

void alarmEvent() {
// RTC alarm wake interrupt callback
// do nothing
}

void setup() {
  Log.begin(LOG_LEVEL_VERBOSE, &Serial, true);

  InitIO();

  Serial.begin(115200);
  int waitForSerial = 5;
  while (!Serial && !Serial.available() && waitForSerial ) {
    delay(2000);
    blink(2);
    waitForSerial--;
  }
  Log.notice(F("Start" CR));

  // initialize the RTC - need to do this or the sleep function is unreliable after reset
  // rtc.begin(false);
  LowPower.attachInterruptWakeup(RTC_ALARM_WAKEUP, alarmEvent, CHANGE);

//  Log.notice(F("Reset modem ..." CR));
//  modem.restart();  // This does not work for some reason
  Log.notice(F("Initialize modem ..." CR));
  if (!modem.begin(US915_HYBRID)) {
    Log.error(F("Failed to start module, rebooting MKRWAN in 1 seconds ..." CR));
    delay(1000);
    reboot();
  };
  Log.notice(F("Your module version is: %s" CR), modem.version().c_str());
  Log.notice(F("Your device EUI is: %s" CR), modem.deviceEUI().c_str());

  int connected = modem.connected();
  if ( !connected ) {
    int joinFailed = 0;
    while ( !connected && joinFailed < 10 ) {
      connected = modem.joinOTAA(appEui, appKey);
      if (!connected) {
        Log.notice(F("LoRaWAN network not joined, retry join in 60 seconds ..." CR));
        blink(1);
        delay(60000);
        joinFailed++;
      }    
    }
  }
  if ( connected ) {
    Log.notice(F("LoRaWAN network joined" CR));
    modem.setPort(10);
    modem.dataRate(3);
    modem.setADR(true);
    blink(3);
  }
}

void loop() {
  blink(3);
  Log.notice(F("Wake" CR));

  // Dump SAMD21 registers
  if ( Serial ) {
    if (! regsShown ) {
      ZeroRegOptions opts = { Serial, false };
      printZeroRegs(opts);
      regsShown = true;
    } 
  } else {
      regsShown = false;
  }

  digitalWrite(extSensorEnablePin, HIGH);
  analogWrite(PIN_A0, 1024);  // apply voltage to DAC to test analog input
  delay(10);
  int extSensor = analogRead(extSensorPin);
  digitalWrite(extSensorEnablePin, LOW);
  int err;
  String msg = "Sleep Test:" + String(msgCount) + ":" + String(extSensor);
  modem.beginPacket();
  modem.print(msg);
  err = modem.endPacket(true);
  if (err > 0) {
    Log.notice(F("LoRa message sent: %l, vwc = 0x%x" CR), msgCount, extSensor);
    msgCount++;
    blink(2);
  } else {
    Log.notice(F("LoRa error sending message: %l, vwc = 0x%x" CR), msgCount, extSensor);
    blink(1);
  }

  delay(1000);
  blink(3);
  LowPower.deepSleep(SLEEP_PERIOD);
}

Has someone been able to configure the mkr wan 1300 using the MKRWAN library on the us915 band? I'm not able to see any packet going through the gateway (This is configured with the 915E6 band as well) whereas if using the 868 band I can.
What kind of gateway and single_channel_packet are you using?
Is there any place with a detailed explanation and examples of the AT commands for the MURATA module? f.e when setting AT+BAND= , what should be this value? 915E6 or 8/9 according to the <MKRWAN.h>?

I'm trying to perform a range test using the US band, but I am not able to set SF=12, it caps at SF=10. Now, I'm following this table for the DR configuration, and I'm using the modem.dataRate(8) call.

DataRate Modulation SF BW bit/s
0 LoRa 10 125 980
1 LoRa 9 125 1'760
2 LoRa 8 125 3'125
3 LoRa 7 125 5'470
4 LoRa 8 500 12'500
8 LoRa 12 500 980
9 LoRa 11 500 1'760
10 LoRa 10 500 3'900
11 LoRa 9 500 7'000
12 LoRa 8 500 12'500
13 LoRa 7 500 21'900

There are multiple issues, such as DR is reset back to dr=0 every time, and that the only way to modify the dr is by enabling the ADR capability which is still don't understand why.

Has anyone had successfully set SF=12 in the US band?

There is no way how to find out port number of downlink message.

If I understand it correctly, port number is returned by modem (https://github.com/arduino/mkrwan1300-fw/blob/master/Projects/Multi/Applications/LoRa/AT_Slave/src/at.c#L848) but this information is not used by library (https://github.com/arduino-libraries/MKRWAN/blob/master/src/MKRWAN.h#L793).

I have 20 arduino MKR1300

I am updating 3 arduino mkr1300 with example of "MKRWANFWUpdate_standalone"

https://github.com/arduino-libraries/MKRWAN/tree/master/examples/MKRWANFWUpdate_standalone

but update does not finish in 3 arduino MKR1300, other devices ok update

The modem.restart() function does not return. It appears to hang on:

sendAT(GF("+REBOOT"));

Version: 1.02
Device: Arduino MKR WAN 1300
Code: FirstConfiguration.ino example

The FirstConfiguration example does not work when using ABP.

After some debugging, I found out that the set(DEV_ADDR, devAddr); in joinABP returns false always. Going a little deeper: the AT+DEVADDR=XXXX command times out in the waitResponse. After inspecting code from STM32 Cube Expansion LoRaWan I tried using AT+DADDR but got the same result.

OTAA works great.

Hi,
First Configuration sketch doesn't work on fw 1.1.4. Whatever the value you set to appKey and appEui the int "connected" will be equal to 1, even if you're not connected. Same problem when using ABP instead of OTAA.

Hi! I'm making test with the arduino mkr 1300 + TTN, and the downlink not work, the ttn application data by node show me than the payload bytes was sent (downlink) but in the monitor serial (arduino) not receive nothing... the uplink works I'm sending data every 5 minutes.

Note1: I have upgrade to firmware 1.1.9 with the example in the repository: MKRWANFWUpdate_standalone.
Note2: The downlink payload are bytes and I am sending 5 bytes.
Note3: The uplink are 5 bytes and I'm using joinOTAA.
Note4: I am setting the port, I'm using port 2.
Note5: I have tested with dateRate(0) and dateRate(5).

I hope to can somebody help me.
Regards

setFCU() and setFCD accept 16bits values.
Why are 32bits values not supported?
Thanks!

Is it possible to push a new release to Arduino manager with the Firmware update fix? d994574

I can confirm the behaviour reported by vahisa in https://forum.arduino.cc/index.php?topic=536628.0,
The modem.read() method do not work with 0x00 payload.

The sleep() method is not implemented (There is no AT+SLEEP command defined in the firmware)...

So, after trying to set up (without success) the mkrwan with a single channel gateway I am asking if someone has been able to do that?
Currently the mkr fw doesn't have the option (like the uno's) to disable channels, I would like the mkr to send data just on the 902.3 Mhz channel not the rest.

I have attempted to use the setBaud() function provided in the library. I wasn't able to change the baud rate and when I looked further into the mkrwan1300-fw library, I could not find the corresponding "+UART=" AT command. So I suspect this command is being ignored by the murata module.

Can anyone else confirm if this is the case?

I have two arduino MKRWAN 1300, and want to send & receive by point to point. One board I loaded DumbModemLoRaSender, the other board I loaded LoRaReceiver. But, the receiver can't get anything. Please give me help, thanks.

I think I have found an situation where there is ambiguity in waitResponse(). This method is used to parse the AT response from the modem. It defaults to parse for r1=LORA_OK ("+OK") or r2=LORA_ERROR ("+ERR"). There appears to be provision to add additional checks (r3, r4, r5).

The following line is typical of the parsing method used:

A problem arises because the modem can return seven types of error message as shown here:

https://github.com/arduino/mkrwan1300-fw/blob/63787fe5ed8bd07119caba20d2065a26004b2261/Projects/Multi/Applications/LoRa/AT_Slave/src/command.c#L83-L93

Because the parsing method uses the .endswith() string method, and the string is checked with every new character, any error message will match the first "+ERR" and therefore, you cannot add additional error codes when you call waitResponse().

I think this needs to be fixed. It seems to me that the string comparison should be done only after the entire response is received from the modem?

I upgraded the library in Arduino IDE to 1.03 release.
At the end of firmware update, when is checked the firmware version (modem->version()) the version shown is "ARD-078 1.1.4 " instead of 1.1.5.

I'm having exactly this problem described here: http://forum.arduino.cc/index.php?topic=536628.0

Can't send any payload containing 00 byte inside. The device gets stuck. If the payload does not contain any 00 then all works extremly fine.

Don't know if already reported here, if it is a problem of MKRWAN library or modem problem...

Board: MKR WAN 1300

Sometimes you have different devices reporting to the same application different data. The TTN backend allows you to tell one from the other in the decoder based on the application port the message has been sent to.

The current implementation of the MKRWAN does not allow to set the application port. In the STM32 firmware, it is weirdly handled in the lora_send method as a prefix in the message buffer. But MKRWAN uses the UTX and CTX entry points that bypass that check. This results in a random application port depending on what is on the memory location the appport variable points to.

I have added the option to specify the application port by using SEND entry point in the sendMessage method along with CFM to set the confirmation flag. Sadly, the method bound to SEND in the STM32 firmware (at_Send) does not "follow" the stream as the CTX or UTX do (at_SendV2 or at_SendV2Confirmed) so I have to pass the message as a string and this fails when the buffer has a byte 0.

I have pushed my tentative code here: xoseperez@cb94498 but I think this should be fixed in the STM32 firmware.

I need to know if someone could send more than 11 bytes in ABP mode? I could not send more than 11 bytes

I have a really weird problem with the Arduino MKR 1300 and the use of the RTCzero library. Simply put when I use both of them the data does not get sent and I have no idea why. The alarms when not trying to send data work normally and the modem.print(msg) also works normally when I am not using the RTC library.

The code looks like this:

    #include <EmonLib.h>
    #include <RTCZero.h>
    #include <MKRWAN.h>
    
    
    EnergyMonitor emon1;
    EnergyMonitor emon2;
    EnergyMonitor emon3;
    RTCZero rtc;
    LoRaModem modem;
    
    String appEui = "1234567891011121";
    String appKey = "ffffffffffffffffffffffffffffffff";
    
    /* INITIAL_TIME */
    const byte seconds = 0;
    const byte minutes = 0;
    const byte hours = 0;
    const byte day = 17;
    const byte month = 12;
    const byte year = 18;
    
    
    byte second_alarm = 0;
    byte minute_alarm = 0;
    byte hour_alarm = 0;
    byte INTERVAL = 60;
    int SEND_LOOP = 2;
    
    int totalKW;
    int time_running = 0;
    
    void setup()
    {
      Serial.begin(115200);
      if (!modem.begin(EU868)) {
        Serial.println("Failed to start module");
        while (1) {}
      };
      Serial.print("Your module version is: ");
      Serial.println(modem.version());
      Serial.print("Your device EUI is: ");
      Serial.println(modem.deviceEUI());
    
      Serial.println("Connecting");
      int connected = modem.joinOTAA(appEui, appKey);
      if (!connected) {
        Serial.println("Something went wrong; are you indoor? Move near a window and retry");
        while (1) {}
      }
      Serial.println("Connected");
    
      // Set poll interval to 60 secs.
      modem.minPollInterval(60);
    
      analogReadResolution(9);
      emon1.current(1, 53);
      emon2.current(2, 53);
      emon3.current(3, 53);
      time_running = 0;
    
      rtc.begin(); // initialize RTC
    
      rtc.setAlarmTime(hour_alarm, minute_alarm, second_alarm);
      rtc.enableAlarm(rtc.MATCH_HHMMSS);
      rtc.attachInterrupt(ISR);
    
      // Set the time
      rtc.setHours(hours);
      rtc.setMinutes(minutes);
      rtc.setSeconds(seconds);
    
      // Set the date
      rtc.setDay(day);
      rtc.setMonth(month);
      rtc.setYear(year);
    
    
    }
    
    void loop()
    {
    }
    
    void ISR() {
    
      int totalWatt = 0;
      unsigned long delay_send = 0;
      int sending = 0;
    
      double Irms1 = emon1.calcIrms(600);
      if (Irms1 < 0.3) Irms1 = 0;
      double Watt1 = Irms1 * 230;
    
      double Irms2 = emon2.calcIrms(600);
      if (Irms2 < 0.3) Irms2 = 0;
      double Watt2 = Irms2 * 230;
    
      double Irms3 = emon3.calcIrms(600);
      if (Irms3 < 0.3) Irms3 = 0;
      double Watt3 = Irms3 * 230;
    
      totalWatt = Watt1 + Watt2 + Watt3;
      totalKW = totalKW + totalWatt / 1000;
      Serial.println(time_running);
    
      sendDataChecker();
      setAlarm();
      time_running = time_running + 1;
    }
    
    void sendDataChecker() {
      if (time_running == SEND_LOOP) { 
        double IrmsTotal = Irms1 + Irms2 + Irms3;
        String msg = "{\"id\":\"avac_aud1\",\"kW\":" + String(totalKW) + ", \"current\":" + String(IrmsTotal) + "}";
        int err;
        Serial.println("Ready to Send");
        modem.beginPacket();
        modem.print(msg);
        err = modem.endPacket(true);
        Serial.println("Sent1");
        if (err > 0) {
          //message sent correctly
          Serial.println("Sent");
          time_running = 0;
          totalKW = 0;
        } else {
          Serial.println("ERR");
          time_running = 0;
        }
      }
    }
    
    void setAlarm() {
      second_alarm += INTERVAL;
      if (second_alarm >= 60) {
        minute_alarm++;
        second_alarm = 0;
      }
      if (minute_alarm >= 60) {
        hour_alarm++;
        minute_alarm = 0;
      }
      if (hour_alarm >= 24) {
        hour_alarm = 0;
      }
    
      rtc.setAlarmTime(hour_alarm, minute_alarm, second_alarm);
    }

And here's the output:

    Connected
    0
    1
    18:13:33.158 -> Ready to Send

Doesn't go beyond that and the data doesn't get sent. I realize this isn't really stack overflow or the best place to ask these kind of questions but I can't find an answer anywhere else. The code seems fine, it's just that the data won't send when using RTC.

I was testing LoraSendAndReceive sketch with MKR 1300 WAN as node and a PyCom LoPy as "nano gateway" with The Things Network.
Pycom "nanogateway" / TTN can occur in "join accept" downlink timing problems, so it happened also in my tests with MKR 1300 WAN.
I was expecting the join requests to stop after 3 retries, but it doesn't happened.

Today I rested that configuration and, after launching the LoraSendAndREceive sketch, having the error about joining, left it plugged and logged what it was doing. The radio module in about 2 and half hours sent more than 90 join requests to TTN.

I don't think is not how was designed, or at least should not be like that otherwise.
It could be useful to expose the number of retries in Arduino library and also a way to stop radio module request send activity.

I am pretty sure that the Murata module has AT command support for this, but it does not seem to be an available choice in the Arduino sketches. If I look at the MKRWAN.h library, it would seem to be lacking as well. This feature would allow most of us using US915 mode to select a sub band of 8 channels out of 64. Most mid-price gateways such as Multitech and Laird work this way.
Thanks for the community support.

Does

static const char ARDUINO_FW_VERSION[] = "ARD-078 1.1.7";

Need to be updated to "ARD-078 1.1.8" ?

I am using an MKR WAN 1300 board.
According to the reference: https://www.arduino.cc/reference/en/language/functions/analog-io/analogwrite/

After a call to analogWrite(), the pin will generate a steady square wave of the specified duty cycle until the next call to analogWrite() (or a call to digitalRead() or digitalWrite()) on the same pin.

In my case, when I use analogWrite it ignores my subsequent digitalWrite.

Here is my test case. It does not turn off my LED, which I have attached to pin 5.

void setup() {
  // put your setup code here, to run once:
  pinMode(5, OUTPUT);

  analogWrite(5, 10);
  delay(5000);
  digitalWrite(5, LOW);
}

void loop() {
  // put your main code here, to run repeatedly:

}

The join request has a timeout of 60 seconds:

  bool join() {
    sendAT(GF("+JOIN"));
    if (waitResponse(60000L, "+EVENT=1,1") != 1) {
      return false;
    }
    return true;
  }

Is there a reason it is so long? This causes a problem when using a watchdog. The maximum timeout for the watchdog is 16 seconds. So, if the network join request is sent and the node doesn't join, the watchdog times out and reboots.

Can I safety reduce the timeout to something around 10 seconds?

Adaptative Data Rate allows the device to modulate SF and BW depending on the signal strength from the gateway. This usually means better packet reception and/or less time on air, thus allowing for more packets per hour/day. This method could be added to the public section of the library.

  bool setADR(bool adr) {
    sendAT(GF("+ADR="), adr);
    if (waitResponse() != 1) {
      return false;
    }
    return true;
  }

It will also be useful to be able to set DR, FCU and get FCU, FCD, RSSI and SNR. Is there a way to get the actual DR used to transmit (SF/BW combination)? This way we could calculate the true time on air for the transmission and schedule the next one within the fair access policy for TTN (30s/day).

The LoraSendAndReceive uses available() to check if there is a response after send a packet, is there any reason parsePacket() is not used in the example?

I've build a single channel lora gateway. So my problem is that the Arduino MKR 1300 iterates over the different channels that can be found here(https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html). Is there a way to set a channel?

Hello,
I notice the sleep function sending the SLEEP AT command but it doesn't seems to work. Is there any documentation about the sleep/idle/low power part ?

Thanks

I pulled the 1.1.8 version today and attempted to upgrade the firmware. I received the following error during the verify (compile) phase:

Verifying... /Users/stevenslupsky/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: MKRWANFWUpdate_standalone.ino.elf section .data' will not fit in region RAM' /Users/stevenslupsky/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack /Users/stevenslupsky/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: region RAM' overflowed by 46632 bytes
collect2: error: ld returned 1 exit status
exit status 1
[Error] Exit with code=1`

Hi @sandeepmistry

It is device and library support Class C?

thanks

Hi,
My question is how far the transmission distance between two MKRWAN boards (only point to point). I tested them about 250 to 300m, is that right ? The receiver got RSSI about -52 to -62 with a side-by-side sender. It says that LoRa can transmit data far far away, even more than 2km. Why arduino MKRWAN not ? Is there anything wrong with my code setting ?
Thanks.

I have a setup consisting of a Dragino LoRa HAT on a Raspberry PI 3b+, and two Arudino MKR WAN 1300 devices. After installing and running the dual_chan_pkt_fwd software, the gateway was successfully registered and connected to TTN. Sending messages from the Arduinos are the problem. Running the example scripts for the MKR WAN devices, with the data rate set to 5(SF7) and the ADR set, allowed me to send data to TTN through the Dragino HAT. This is a single channel Gateway. So the messages were all sent on SF7. However, the data passed through the hat is often corrupted. I believe that this is due to the frequency hopping of the MKRWAN. My devices are the only LoRa devices in the area, and there is no obstructions between the devices. Even sending “Hello” to TTN returned strange values in the payload. However, it would work in irregular intervals.
After looking deeper into the issue, I tried communicating on the simple LoRa network, without any LoRaWAN stuff, just using the arduino-LoRa library on SF7 and BW125. I noticed that the Arduinos could chat easily between each other. But they struggled to communicate with the Dragino device. This is the output of RPI receiving data from the arduino. The sent message is “hello” plus a counter.
However, I am unsure how to fix this issue. All devices are communicating at 868.1MHz at SF7. Or it could be that the Arduino is changing its transmission frequency in a form of frequency hopping. Has anyone experienced anything similar to this and would be able to offer advice? Is there a way of setting the transmission frequency on the MKRWAN to prevent this frequency hopping?
I had a look at the issues in the repositories, and am beginning to understand the limitations of the products I have acquired. But most of the issues of using the MKRWAN with a single channel gw was closed last year. I hope that these issues have been solved since them.

While debugging a problem where I observed that from time to time a packet is not sent, I believe I uncovered an issue with the connected() method.

To address the packet not sending issue, I retry resending the packet and if that fails several times, I restart the modem by calling begin() again. begin() asserts a reset pin on the murata module which I assume is a hard reset. After the begin() (and corresponding reset), connected() is called to check the join status. However, I have noticed that the connected() method is not a reliable means of determining join status. Rather, this function appears to return true if there is room in the receive buffer, or, if not, then the join status from the last join. Since the join status after a module reset is not reset, if the module was joined before reset, it will return true.

Along the way, I found a private method getJoinStatus(). This method polls the module for its join status. I think this is likely more reliable than using the connected() method.

I propose that the getJoinStatus() method should be made public. Also, I think the network_joined variable should be reset when begin() is called.

Last, what is the purpose of the call to available() in the connected() method? Should this be removed?

Hello eveyone,

Arduino MKRWAN 1300: ARD-078 1.1.9
MKRWAN: 1.0.10

I see that with set TX power method "power", trying every possible combination of mode and level it actually always returns false. Tried both after and even before activation, same.
I was following the ISSUE #46 and the "volatile" status of the library caught my attention and actually I got lost in the end.
Now what should I think about this?

• expected behaviour as library is going to be rewritten?
• don't worry about the "false" as it is actually working anyway?
• don't care about that method as it's no more maintained and will explode in few seconds?
• well, shouldn't return "false", so there's something wrong?
• whatever else?

Please, shed some light on my way, thanks.

This function isn't documented: bool power(_rf_mode mode, uint8_t index) and the arguments aren't named very good. The mode argument I can understand, but what is index? Is it the transmit power? Between what values can it change?

I am not sure if this is a bug yet.

While experimenting with the example code, I noticed that the port number changes from time to time. I have not figured out why it changes yet. I have seen it change when you reset the MKRWAN1300. I have also seen what I think is just a random change. That is, several hours after an uplink I sent another uplink and the port number changed on the new uplink.

I've seen uplinks using port number 2, 4 and 6. Looking further into this, I cannot find the API for setting the port number for an uplink.