Arduino MKR WAN 1300

Hey @Amedee , I was looking at your solution on Github as you mentioned here: Arduino MKR WAN 1300.
It looks like you were doing the same aproach as I am. Don’t you have problems with the channels used? In my case if the device doesn’t receive the ADRACKReq MAC command from the NS, having the available channels it will randomize a channel (over all 64 there are on the AU915 plan) for every message. If a I have only 2 8-channels gateways near me (my actual situation!) only 25% of the messages are received.
When I run an OTAA join, the NS will send a downlink with the ADRACKReq MAC command informing the available channels (which was configured on my loraserver). But when I reboot the end device and retrieve the key from memory then perform a ABP join, it is not aware of what are the available channels, and by default, will pick any channel to send each message. Don’t you have this kind of problem? Do you know if it is possible to force the NS to send the channel availability to the device? Do you know if it’s possible to directly mask the channels on the MKRWAN1300?


Yes, my solution is not complete…
It works well with EU868 because the channels are fixed… (I still should change the downlink channel config for higher SF though as TTN is non standard)

I’m afraid you will have to hack the firmware to get/set channel config

Yes, that’s my current problem @Amedee !
MKRWAN’s modem doesn’t has an AT command to get / set the channel. The Murata’s firmware has the AT+CHMASK to do so, but Arduino doesn’t implemented it. So, my solution to do the OTAA join once and then use ABP join on the next ones can’t be successfully used 'cause it will start losing a lot of packets due to sending on channels that has no gateways listening to!

Does anyone has a solution for it, to be used on the US915 or AU915 channel plan?

Is there any way to set the frequency to 868.1 Mhz only? Since the gateway I’m using is only able to receive from that frequency…

Since the LoRaWAN chip is certified, in principle is not possible - the standard asks for at least 3 frequencies.

Can’t find it, but is there any LiPo/solar shield for this one?
I know that the initial board version is not really low power (yet)…

Hi, I have just started playing with my MKR1300 lorawan unit and the example which is great and simple only sends its payload as Ascii String. i want to send my payload as bytes to save on airtime, can anyone advise on the commands to use , i tried to go through the Library but there are private commands. any help or guidance would be awesome.

ok so it seems if you use the following command you can send bytes
however how would you send an array? as it seems to be only 1 byte in size allowed? maybe i am doing something wrong :frowning:

modem.write(payload,sizeof(payload)); // send data as bytes

this is the correct command :slight_smile:

Correct, @MotionTronic.
The code I’ve been using is pretty much like this:

void loRaSend(uint8_t *msg, uint8_t size)
    int err;

    tLastLoRaSend = millis(); //Keep track of timing
    modem.write(msg, size);
    err = modem.endPacket(false);

    if (err > 0)        
        Serial.println("LoRa send error!");

Sorry for not answering you on time. Glad you solved it, already. :+1:

1 Like

Has the current Github for the MkrWan library you’re submitted patches?

I’m using the MKR1310 and consider saving the values in the onboard SPI-flash.

I would save the counters only every 100 or even 1000 msg’s. With a reset I would add 100 or 1000 to the stored uplink counter. As far as I understand it’s no problem that the uplink counter has a gap which is lower that 16k.


I have build a ttn network based project. I can send to the things network which will send it over http to a php file and then to a database. But when I send a message back it gets back the whole way to the arduino but i don’t know how I can do something with that data. In the lora send and recieve tutorial you can only read out messages in your serial monitor. How can I transform that incomming message to a function. For example put a led on and off.

here is my recieving part of the code:

  if (!modem.available()) {
    Serial.println("No downlink message received at this time.");

  char rcv[64];
  int i = 0;
  while (modem.available()) {
    rcv[i++] = (char);

  Serial.println("Received: ");
  for (unsigned int j = 0; j < i; j++) {
    Serial.print(rcv[j] >> 4, HEX);
    Serial.print(rcv[j] & 0xF, HEX);
    Serial.print(" ");

From this part I tried something but this doesn’t work. You see what i’m trying to do?

  char cont =;
  if(cont == 'exact message I send from ttn'){
    digitalWrite(flitser, HIGH);
    digitalWrite(sirene, HIGH);

It looks like you copied this from another forum? If yes: any responses there yet? Please add a link here, and keep the two places in sync… (Also, please see How do I format my forum post? [HowTo])

Some hints for now:

This is where the LoRaWAN downlink data is handled:

…but the following just expects new input. And also expects that from the serial port that you use to connect the device with your computer, not from the LoRaWAN downlink:

Even more, the above seems to expect some text. Don’t send text, neither in uplinks, nor in downlinks.

Instead, schedule a downlink for a single byte, being 8 bits that allow for 8 bitwise flags, and
see Arduino’s bitRead.

And as for controlling things through LoRaWAN: that’s not a typical use case.

this is the link to the other forum. no responses jet :cry: :

I will keep this updated forum updated.

I think I understand. But is it possible to activate something from a payload from the things network?

It’s technically possible, as you can do whatever you want after receiving a downlink. But especially given the pin names like “siren” you probably want something different: How can i remotely control a siren?

That said, unstested, it could be as simple as:

if (i > 0) {
  // Parse 8 boolean flags from single byte, using bitwise AND with
  // patterns such as B00000001, B00000010, ..., B10000000:
  bool flag0 = (rcv[0] & 1<<0) > 0;
  bool flag1 = (rcv[0] & 1<<1) > 0;
  bool flag2 = (rcv[0] & 1<<2) > 0;
  // or:
  bool flag3 = (rcv[0] & B00001000) > 0;
  bool flag4 = (rcv[0] & B00010000) > 0;
  bool flag5 = (rcv[0] & B00100000) > 0;
  // or:
  bool flag6 = (bitRead(rcv[0], 6) == 1);
  bool flag7 = (bitRead(rcv[0], 7) == 1);

  // Not a recommended LoRaWAN use case
  digitalWrite(flash, flag0 ? HIGH : LOW);
  digitalWrite(siren, flag1 ? HIGH : LOW);

See Working with bytes.

(As for your earlier if(cont == 'exact message I send from ttn') note that LoRaWAN application data is encrypted, so you don’t need to be afraid that just anyone can send a downlink to your device.)

I fixed the problem. was quite simple, but didn’t know how to do it

while (modem.available()) {
rcv = (byte);

Serial.println("Received: ");

if(rcv == 116){
digitalWrite(flitser, LOW);
digitalWrite(sirene, LOW);

so I read what the recieved number is and if that is the same in a byte format you can trigger the parts

For future readers, note that the following will not work if one schedules multiple bytes for a downlink, as only the last byte from a downlink will be preserved:

For those cases (and for less confusing code) the example in the documentation, which reads all bytes into an array, is to be preferred.

I can’t figure out how to send sensor data in the right format.

My sensor data is collected to a string containing for example: “1a3249e12459”, 12 bytes total.

It should appear in TTN as “1a3249e12459”. How should I do it?

I have tried with modem.write() and with modem.print(), but the results are not want I want:

981300200c0000000c000000 // modem.write(msg);
316133323439653132343539 // modem.print(msg);


the print one is in hexa, a simple HEX to ASCII decoder will do the trick
i use that one for example:

Not really, because, because wasteful encodings of data as printable characters should never be transmitted in the first place.

OP’s mistake is when they say

That should not be treated as a string but a buffer.

As a buffer (0x1a, 0x32, 0x49, 0xe1, 0x24, 0x59) it is 6 bytes, and perhaps a reasonable payload (though with care it how it was originally packed it could probably be smaller).

But the quoted string is actually 12 bytes, and utterly unacceptable for transmission, since it only contains at most 6 bytes of actual meaning.

1 Like