Ok thanks.
NB: I am aware I need to reduce the frequency. It was only for a fist test/simulation with a very small payload to understand the power consumption.
I believe that if you are using the MKRWAN library and the arduino firmware your attempts to send data at periods of less that 120 seconds will fail. This is hard coded and you can’t get round it but the dummy write in the library will dump your data.
The library is has a lot of blocking code delays and does not handle unexpected data or delays in connection requests well. Hopefully this will be addressed as the product matures.
There are a number of Arduino MKRWAN restrictions imposed that are not well documented but if you have a specific query I will try look at it but I am no expert on the firmware or the library.
I am not certain about ADR but if I force the datarate I get no responses from the network with anything other than setting 0…this may be just a poor signal as I am a 7km from my nearest gateways and in a rural location. I will add a local gateway soon and this should help diagnose network related issues better.
Is anyone aware if there is much effort going on to improve the library or document the firmware? Information seems hard to come by.
On the battery front I am using a 400mAh 3.2v lithium and charging it from a small solar cell. In other words I have scavanged an external LED home lamp case and push the output through a charge circuit, dc-dc booster and simple regulator. The device works away reliably but I have to top up the charge using the USB connector when working indoors.
Hope this helps,
JohnB
I successfully send at SF7 too, likely is the distance from the gateway. However, I read somewhere that ADR is not really working.
I have two MKRWANs running next to each other and I am using the MKRWAN library.
In the code I have
modem.setADR(true);
modem.dataRate(5);
First one is connected on SF9BW125, the second on SF7BW125.
I recently added the ArduinoLowPower.h to reduce the power consumption (time will show if that really helps)
Suendermarkus: this demonstrates ADR is functioning, thanks.
Another issue: I never received a downlink (which I simulated through TTN). I suspect the gateway could be responsible too, but the dual channel software I am using is reported as able to send downlinks.
The LoraSendReceive example seems to implement RX1 (sort of), but since TTN seems to send on RX2, SF9, I tried also to modify the timing to meet different windows, but no luck (and also both, changing datarate for RX2). Anyone has at least a single positive experience? By the way, sending confirmed uplinks never succeed even if messages successfully reach the gateway (symptom of the same issue?).
…not necessarily.
To know for sure that ADR is working one should see the settings improve (in EU868: data rate increasing, so SF decreasing). What @suendermarkus is seeing is the opposite, which does not prove much. For EU868, DR5 equals SF7, so assuming EU868 those nodes were set up to use the best data rate, but still one ended up using a worse setting, SF9. Maybe ADR caused this long after the node joined. But when using OTAA, if no Join Accept is received, then a node will at some point also worsen its settings and try again. Such changes during OTAA are not related to ADR, in which the server tells the node to change its settings.
In other words: the increase in SF might just be the result of failing OTAA attempts. One form of prove that ADR is working would be that a node, after being connected at some data rate, at some point in time ends up using a better data rate.
That’s likely caused by the settings used for your uplink; TTN prefers RX1.
As an aside, just to be sure you know: if OTAA is working for you, then that proves that at least some downlinks are working. You can see in TTN Console which data rate was used for the successful OTAA. Even though the RX1 and RX2 settings for OTAA Join Accepts are much longer (5 and 6 seconds versus 1 and 2 seconds), “regular” downlinks should then probably also work for that data rate. First of all make sure you see the downlink in the Traffic page of your gateway in TTN Console.
1 Like
Thank you Arjan, I was understanding wrongly ADR (still new to LoRa).
This is interesting. First of all, I am using ABP because in my first attempts OTAA was not functioning. However, initially I was using the Telkamp packet forwarder that does not support downlinks, while now I use the (adapted) Dual Channel version by Boksem. Tomorrow I will retry with OTAA, just to be sure.
Anyway, on the gateway log I see this coming from TTN when I schedule a downlink from the Applications page (in this case, 1 byte payload):
From SERVER router.eu.thethings.network, port TBD
{“txpk”:{“imme”:false,“tmst”:780438310,“freq”:869.525,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“ipol”:true,“size”:14,“ncrc”:true,“data”:“YPARASYgCAABVV9SQPw=”}}
RX2 indeed. (That frequency is not used for uplinks, so this can only be RX2. Compare the value of "tmst":780438310 to the one in the uplink; the difference is the time in microseconds, so that should be 2,000,000 for RX2.)
So I guess the uplink was using SF10 or worse?
LoRaWAN 
(The LoRa radio modulation has no concept of ADR. The network protocol LoRaWAN does.)
1 Like
Thanks again Arjan (however: LoRa and descendants 
).
I checked timestamps and it’s 2 seconds after Tx.
I tested OTAA and it never joins. Actually, it seems to never send to gateway, although since the gw is single channel (actually on 868.3), maybe one join attempt is not sufficient (I tried with 5 sequential without success).
Uplink is SF12 (I am/was interested in distance, although I tested also other SFs).
From reading this thread am I to conclude that the MKRWAN libraries restrict LoRa functionality? Should I consider another board for my project?
Honestly, as a newbie more interested in applications than in soldering, I bought an MKR WAN hoping to have everything ready. However, I soon learned that not everything is plug-and-play when looking at details (I was able to setup a basic RPi gateway in a couple of hours and a working node soon after starting from zero Arduino/RPi knowledge, but after a month no downlinks yet, for example).
There is much more documentation for LMIC-based solutions, and the official forum for MKR WAN 1300 is sleepy (maybe not many buyers yet). I am sure the hardware is more than adequate, but the library seems not sufficiently mature (not limiting, but also not supporting much). I expect it to enhance in the future, but in the meantime I am ready to try other roads.
Likely LMIC could be used for MKR WAN too, but I was not yet able to use it.
2 Likes
MKR WAN can not be used with Lmic unless you add a Lora radio like RFM95 to replace the Murata Lora module
1 Like
Really no way to directly access the SX1276 inside the Murata? Thanks.
Well, you can always replace the firmware which is on the STM32L0
(I believe this is what @onehorse/@GrumpyOldPizza are doing on their devices: they run everything in the Murata MCU)
Now I don’t think the Arduino is that bad…
- I don’t have any issue with downlinks on my side
- ADR is a special thing, but it kind of works: if the first packet is sent with a confirmation request, it will adjust the datarate for the following packets. It is somewhat limited as the datarate won’t be adjusted afterwards…
- It is also quite stable: I have one running since 215 days sending a packet every 5 minutes (>60000 packets) and it never resets.
2 Likes
There is a way on the MKR WAN 1300 to somehow … half way to access the SX1276 directly. Basically they have something in firmware, where SPI accesses are half way bridged. But that is a less than stellar approach.
And yes, you could replace the firmware on the STM32L0 there … Should not be that tricky … Looks like Arduino has 4 GPIOs connected between SAMD and STM32L0 plus RESET & BOOT.
60000 packets - amazing!!! 
How are you powering your board if I may ask?
are you using the LoraSendReceive example? and at which SF? thanks.
Thank you, half good news . However, I would rather prefer to use the original library, if everything is really functioning.
No wizardry here: the MKRWAN board was the first LoRa node I bought at the beginning of the year. I programmed it to send some payload every 5 minutes to test my gateways at first, then I decided to leave it plugged in to check stability. It is still running today.
But there is nothing special done on the power management side: it does not sleep, and it is simply powered through the USB port by a cell phone “charger”.
The LoraSendReceive example works fine. I stared from there and made some changes for various tests, but I always use the same skeleton. SF doesn’t matter (my gateways are in the same room).
I believe the issue here is your gateway.
1 Like
Thanks, this morning I did some tests with SF7 and SF9.
AT SF7 downlinks work: they are sent at the same frequency as the uplink. This is good.
At SF9, like at SF12, TTN sends at 869.525, and my node is not receiving. I expect the gateway be part of the problem, but the LoraSendReceive example seems not made for RX2 (unless there is an extra wait time at lower level).
BTW, in case one don’t know…
(I don’t think it is well documented – at least I haven’t found)
The latest MKRWAN library is on GitHub.
It is the exact same library you get in the Arduino IDE if you accept the library updates.
One of the examples is called MKRWANFWUpdate_standalone and allows you to bring the firmware of the Murata chip the the latest available one which is currently 1.1.6.
So if yours reports and older version, use this sketch to upgrade.
If you are curious about the firmware itself, it is available as well on GitHub!
It is interesting to see which AT commands are implemented – for testing I made a quick sketch which passes directly AT commands to the modem, so it sometimes helps to better understand how it works.
Also the MKRWAN.h library can easily be extended to support additional AT commands.
1 Like