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?
Thanks.
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
modem.write(byte);
however how would you send an array? as it seems to be only 1 byte in size allowed? maybe i am doing something wrong
Hi
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)modem.read();
}
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(" ");
}
Serial.println();
From this part I tried something but this doesn’t work. You see what i’m trying to do?
char cont = Serial.read();
Serial.println(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.
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);
}
(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.)
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.
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.