I’m trying to use the First Configuration example for the MKRWAN library. However, every time I input the APPEUI and APPKEY from the Things Network I get “Something went wrong; are you indoor? Move near a window and retry”
Is there a particular format I need to enter these keys in? It doesnt mention anything within the example.
My gateway seems to be picking it up, but on the application page there is nothing. The same message still repeats.
I also noticed the spreading factor is 12 when it should be 9.
I’ve now managed to get the MKRWAN 1310 to connect to the things network. I did this by using the three parameter version of “modem.joinOTAA” instead of the two parameter version. However, I have now encountered a new issue with message sending.
String msg = "hello";
int err;
modem.beginPacket();
modem.write(msg);
modem.endPacket(true);
if (err > 0) {
Serial.println("Message Sent Correctly!");
}else {
Serial.println("Error Sending Message");
}
delay(20000);
Every time I try to send a message with this code, it doesn’t work. In the TTN application console, I can see a confirmed uplink, but not the message.
The spreading factor also seems to change from 12 to 7 constantly.
Several issues wth what you say - firstly please avoid using confirmed uplinks - the TTN FUP limits you to 10 downlinks per day inc e.g. join accepts etc. and in reality you should think in terms of max 1 per week or even 1 per month! (Ideally once in its life - when 1st joining and retaining state thereafter!). The GW is deaf to uplinks each time you send a downlink (as happens with a confirm ack). 2nd It looks like you are very close wrt node to GW distance - move atleast 5m, pref 10m away and ideally with an absorber such as a wall inbetween - RSSI at -36 - -39dbm mean most likely you are shouting in the ears of both devices and signals are apt to be corrupted and mishandled. Aim for RSSI <<-50dbm, pref <-65dbm. Moving from SF12 to SF7 is not suprising in such circumstances (if ADR enabled device will quickly move to lower SF is starting higher) and the lower the SF the better wrt time on air (congestions) and battery life (RF energy consumption) and is A Good Thing™ 
You also seem to be TXing too often (back off time between send attempts to stay within regs and DC limits if applicabe in your territory and within FUP for uplinks (max 30sec/day) and to give GW time to breathe and pass messages too and fro (Acks, MAC commands etc.)
Please do not post pictures when text can be copied & pasted over please. Please see guidelines
Why do you think the DevAddr should be confidential?
Apart from the grievous error of sending text, if the message is received, it’s there somewhere, click the Forward uplink data message line and look for frm_payload in the JSON on the right.
BTW, once every 20 seconds is 7.4x more than FUP at SF7 and 189.9x more at SF12.
Right now, I’m using the code below to join the things network. Are you saying not to do this? If so, how else am I meant to connect to TTN?
int connected;
connected = modem.joinOTAA(appEUI, appKey, devEUI);
if(!connected) {
Serial.println("Failed to Connect!");
}else {
Serial.println("Successful Connection!");
}
I will make the adjustments you have recommended and get back to you.
I have found the frm_payload, but it isnt decoded. Usually, it would show the hex payload in the stream. I can’t see this. I am using a payload formatter to decode the payload.
function Decoder(bytes, port) {
var result = "";
for (var i = 0; i < bytes.length; i++) {
result += String.fromCharCode(parseInt(bytes[i]));
}
return { payload: result, };
}
"mac_payload": {
"f_hdr": {
"dev_addr": "260B04D6",
"f_ctrl": {
"adr": true
},
"f_cnt": 1
},
"frm_payload": "eCZw2aKhhgTYfrvF",
"full_f_cnt": 1
This is what I can see.
That is the pre-decryption payload - you need to:
and not the "Successfully processed … " line.
What payload formatter are you using to decode the payload?
It may well show the hex payload if you turn off confirmed uplinks - I can’t remember, I can’t remember when I last looked at confirmed uplinks so I can’t remember how the console log changes when you do.
Your OTAA connect is OK, the one without the DevEUI uses the Murata module DevEUI which Arduino generate from the STM32L073Z serial number. Depending on which firmware depends on whether it comes with the official Arduino EUI prefix or is an officially unofficial generated one. Which is what the FirstConfiguration sketch is for. Or you can use a TTN generated one with the three parameters. @Jeff-UK was referring to the blitzing of the FUP with all those confirmed uplinks, not the connection method.
I’ve edited my previous message to include the payload formatter. Its the one used in the Arduino example. How would I go about turning off confirmed uplinks, I can find recommendations to do it, but not where to do it.
In terms of the Forward uplink data message line, this is the output I’m given.
{
"name": "as.up.data.forward",
"time": "2022-01-10T19:24:02.676668591Z",
"identifiers": [
{
"device_ids": {
"device_id": "",
"application_ids": {
"application_id": "temperature-sensor-shield"
}
}
},
{
"device_ids": {
"device_id": "",
"application_ids": {
"application_id": "temperature-sensor-shield"
},
"dev_eui": "",
"join_eui": "0000000000000000",
"dev_addr": ""
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
"end_device_ids": {
"device_id": "",
"application_ids": {
"application_id": "temperature-sensor-shield"
},
"dev_eui": "",
"join_eui": "0000000000000000",
"dev_addr": ""
},
"correlation_ids": [
"as:up:01FS2Q53QFS0ZE8B4KXWWR6Y65",
"gs:conn:01FS28DNQHX6W2ZTKEDTCD5DA9",
"gs:up:host:01FS28DNQSYFZX0MRRS9V2A2YN",
"gs:uplink:01FS2Q53H0GH27YZK20P74SX4G",
"ns:uplink:01FS2Q53H2SMYNF3R651GQZFGX",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FS2Q53H2X3P18GYX75A30H16",
"rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FS2Q53QE9FG4V2YTX7C86B3S"
],
"received_at": "2022-01-10T19:24:02.671817589Z",
"uplink_message": {
"session_key_id": "AX5FZv1bfcRSnU+pv2EY8Q==",
"f_cnt": 15,
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "river-monitor-gateway-lps8",
"eui": "A8404120BDF04150"
},
"time": "2022-01-10T19:24:02.425964Z",
"timestamp": 2565804731,
"rssi": -59,
"channel_rssi": -59,
"snr": 10,
"uplink_token": "CigKJgoacml2ZXItbW9uaXRvci1nYXRld2F5LWxwczgSCKhAQSC98EFQELulvMcJGgwI0o/yjgYQ6IvJ3QEg+NSEr9bBAyoMCNKP8o4GEODjjssB",
"channel_index": 1
}
],
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7
}
},
"coding_rate": "4/5",
"frequency": "868300000",
"timestamp": 2565804731,
"time": "2022-01-10T19:24:02.425964Z"
},
"received_at": "2022-01-10T19:24:02.466122664Z",
"confirmed": true,
"consumed_airtime": "0.061696s",
"version_ids": {
"brand_id": "arduino",
"model_id": "mkr-wan-1310",
"hardware_version": "1.0",
"firmware_version": "1.2.0",
"band_id": "EU_863_870"
},
"network_ids": {
"net_id": "000013",
"tenant_id": "ttn",
"cluster_id": "ttn-eu1"
}
}
},
"correlation_ids": [
"as:up:01FS2Q53QFS0ZE8B4KXWWR6Y65",
"gs:conn:01FS28DNQHX6W2ZTKEDTCD5DA9",
"gs:up:host:01FS28DNQSYFZX0MRRS9V2A2YN",
"gs:uplink:01FS2Q53H0GH27YZK20P74SX4G",
"ns:uplink:01FS2Q53H2SMYNF3R651GQZFGX",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FS2Q53H2X3P18GYX75A30H16",
"rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FS2Q53QE9FG4V2YTX7C86B3S"
],
"origin": "ip-10-100-7-39.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ",
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01FS2Q53QMGAN6PDDTA80HHWZ9"
}
I can’t see any form of payload within this one. I still have the modem.endpacket(true) function returning as not successful.
I’ve uploaded the full code just incase there are any blatant errors.
#include <MKRWAN_v2.h>
LoRaModem modem;
String appEUI = "0000000000000000";
String devEUI = "";
String appKey = "";
void setup() {
Serial.begin(115200);
Serial.println("Device Started");
if(!modem.begin(EU868)) {
Serial.println("Failed to Start");
while(1) {}
};
int connected;
connected = modem.joinOTAA(appEUI, appKey, devEUI);
if(!connected) {
Serial.println("Failed to Connect!");
}else {
Serial.println("Successful Connection!");
}
}
void loop() {
String msg = "hello";
int err;
modem.beginPacket();
modem.print(msg);
err = modem.endPacket(true);
if (err > 0) {
Serial.println("Message Sent Correctly!");
}else {
Serial.println("Error");
}
delay(40000);
}
and
and
Is this the wrong library to use?
the “err = modem.endPacket(true);” is used in the MKRWAN example.
What is wrong with the delay(40000)?
I’m just trying to get it to work the first time around, then I will apply the proper methods recommended. The First Configuration example did not send a message either.
Because you have already been told:
And specifically
Going from 20 sec to 40 sec is essentially ignoring given advice…
Apologies, I’m just trying to get an example working. I will not have it plugged in longer than 2 minutes. I have now changed this to 240000 milliseconds to comply with FUP.
The example I’m using from the MKRWAN library is First Configuration. Going back to the original issue, the message doesn’t send and doesn’t show up in any payload format in the JSON. In the serial monitor, the function “err = modem.endPacket(true);” comes back as 0, which means packet unsuccessful.
I am wondering why Descartes has pointed this out as an issue.
@descartes pointed out this issue because if you look at the library, you’ll see what the true means in that line and why both me & @Jeff-UK are raising eyebrows about it.
BTW, v2 is still marked as in beta - so you are using a v1 firmware Murata module with a v2 library. So you may well be sending but the library can’t tell from the response.
We’ve traversed Arduino/LMIC, LMIC-node and are on to MKR WAN. What is your overall objective here, maybe there is a better way to get to your end point.
COTS?
Ok, this function is a bit weird. I get what you mean now. It should return 1, but still doesn’t.
The end goal is placing end nodes down a river to measure water level. I’m trying to get a good library to use that isn’t done for me.
Erm, no, the function should return the length of the payload that was transmitted.
Whereas I’m asking what the true indicates.
I don’t think endPacket does this. “Returns an int: 1 if the packet was sent successfully, 0 if there was an error”
If the parameter is true, wouldn’t it always be successful?
The return value is unrelated to the parameter and it’s the parameter we are concerned with.
And the return value isn’t any of the things mentioned on that link anyway, which maybe should be highlighted by the link not mentioning a parameter for endPacket …