ok not that much magic then, but thanks anyway, really shows that board is stable!
I’d like to continue using it provided I am able to manage to get the power consumption under control, LiMC seems to be more efficient here, however, more long term tests needed to find out.
Hi! I have this gateway and I’m trying to send a message from an mkr1300.My problem is that when I run the code in Arduino from the mkr to connect to the gateway, I can’t get a connection in all the sending…In some of them have errors, in other say me that I’m in door and I have to go outside and in other have a correct connection with the same code…Someone have made proofs of connection?? Is it possible the problem could be the radios or channels in the gateway?
Hi
we are having some issues with the MKR1300 -
We have I2S sensor - and send data to TTN every couple of minutes)
we have unpredictable freezes of both our test devices after 12 -48 hours) - we still don’t understand why! (they dont seem to freeze at the same timeframe)
any suggestions?
Did you try without any sensor attached?
Hi, time to share the results from my first long running tests over the last couple of months.
I had two MRKWAN1300 running with the MKRWAN library plus the ArduinoLowPower Library to put them to SLEEP after sending, and then they had the sensor libraries on.
They were both powered by 2 AAA (not AA) standard Duracell batteries.
The question I tried to answer for myself was: how far would I get?
Based on the result I take it, I2C sensors are more efficient in terms of power consumption. To be honest I did not do much checking yet around the DHT22, maybe there’s a way to tune its power consumption.
Note: I saw that some people are doing great research about the power consumption of the board on a hardware level (MKRWAN1300 high current in sleep mode), really curious to see if a V2 is going to be launched soon.
Now, to answer the question above: in best case assuming a reasonable scenario where the device is sending max. 140 messages per day it would - mathematically - run for about 3 month. Not too bad, but if it was double I would be more satisfied 
Nice results, however how often they were sending during the test? Because with the consumption issues discovered, likely 3 months cannot be reached even just sleeping (1.16 mAh minimum).
On the Arduino store, the MKR WAN has now ABX00017-B code, with that -B seemingly identifying some new version. However there is no official announcement (at least, I did not find it).
They sent every 3-5 minutes, I can’t reduce that further without violating the fair use policy. And agree, is a first experience and my assumption was just a mathematical calculation. Final confirmation can only be given after testing with 100% real life conditions.
I am waiting as well to hear more about the new model, would like to test one of those.
I was meaning the opposite: If you send 16000 packets in more than one month, the sleep consumption will likely consume the battery before (assuming ~ 800mAh). Waiting for the new version too (for curiosity, I am also playing with other platforms).
In the meantime, as I mentioned in the other thread, at the cost of TPL5110 and FRAM breakouts boards you can reduce the sleep current to almost nothing…
($10 with Adafruit breakouts, probably less with Asian boards)
Obviously it would be nice to get low power out of the box, but if you already have these boards, either use them for a non-low-power project or “upgrade” them…
I saw your post in the other thread, nice solution. I don’t know the TPL5110 at all, but if I understand well, it simply cuts the power of your MKR for a certain amount of time?
If so, don’t you need to join the network again and again after each “wake-up”?
Yes, the Texas Instrument TPL5110 is an Ultra Low Power Timer. During sleep, it takes less than 50nA. It powers the MkrWan after some time, when done the MkrWan tells the TPL5110 which cut the power again.
No, that’s where the FRAM come in action!
The first time (or when the reset button is pressed) the node joins in OTAA and saves the session keys and the frame counters into the FRAM module.
After that, for each power cycle, it just restores the session previously saved so you don’t need to re-join again (Technically it does an ABP join to initialize the module, but that doesn’t translate in any packet).
You just need to ensure your nodes run firmware 1.1.7, as this version contains the patches I submitted for saving/restoring session keys and frame counters.
I have 2 nodes running with this setup since several weeks now and so far it looks quite stable.
(I’ll push my code to Github over the week-end in case someone is interested)
Just in case you did not: you also need to save the OTAA network settings, such as typically the RX2 configuration. And when using ADR, you might also want to store the data rate and transmission power. See also OTAA best practice: how to not join every time? for some more.
I don’t use ADR as it is problematic on this device (only works with confirmed packets, which I don’t want to do), but I do save transmission power which can be changed with downstream command.
However I am not saving anything else than the session keys and frame counters, so I need to dig a bit to retrieve additional network settings.
Thanks for the heads up.
I would be interested.
Slightly off topic, but I have a AA LiFePO4 powered node in build progress here. Its based on a ATmega1284P and has a TPL5010 as a wakeup timer and watchdog. Sleep current is 0.2uA, it has a FRAM, so I was thinking of using it as a TTN node.
Yes. If we had low current sleep we would not need all that.
As side effect it helps me with another project where the sensor drains too much current as well, so the TPL5510 also powers down the sensor, that’s an easy solution for that problem…
Hi @Amedee. I saw your comment regarding ADR being problematic. What sort of problems have you encountered? I have it on by default at the moment and wondering what I should be looking out for. I am sending unconfirmed uplinks.
Also, is there anything special I need to do to get the downlinks working? I recently started testing some code that sends a downlink message (simple string message). I do not appear to be receiving the downlink. The loop() does the following:
periodically wake up every 5 seconds,
if it is time to send an uplink (every 2 min), sample the sensors and send the uplink payload
check for a downlink message (every time is wakes up - 5 sec), if there is a downlink available, read it and dump it out the serial port
go back to sleep
Since I do not control the LoRa module sleep, I am assuming it handles the necessary RX1 and RX2 windows for downlink messages when it sends the uplink. I am using Loraserver and I can see that the downlink is queued by the server when it receives an uplink.
At the moment, I am not sure why I do not appear to receive the downlink.
From what I can see, unless you send a confirmed uplink it never does ADR…
I tried different scenarios, waited long enough, … I never see my Data Rate changing if I send unconfirmed uplinks…
Maybe sending a confirmed uplink from time to time (e.g. every 20 uplinks) would trigger ADR, I haven’t tested that – for what I do, I don’t really need ADR, I use Data Rate 5 (SF7/BW125).
For the downlink, maybe you first need to check the LaRaSendAndReive example sketch. That one should work.
Then in your sketch, check what happens when you don’t sleep.
I don’t know what happens with the Murata chip when the SAMD enters sleep.
In principle you only need to to check for downlink just after an uplink. The problem is when you send unconfirmed uplinks you don’t really know when the send is finished, so you don’t known when to look for downlink…
In my case I must ensure the send is finished, as I cut the power with the TPL5110, so what I do is to wait for the uplink counter to be incremented, then I check for downlink, then I sleep.
It is probably not bullet proof, but it seems to work.
I think ADR must be doing something. I have noticed that the transmit power is changing. When I first boot and join the network, peak current consumption is about 120mA. After several uplinks, we noticed that the peak current consumption starts to decline. Is settles somewhere about 45mA. I am not sure this is ADR but I inferring the change in current consumption is a result of a change in tx power.
My understanding the the murata firmware handles all the sleep functionality associated with the LoRa connection. So, I do not think sleeping the SAMD21 affects that. I did notice earlier today there were a bunch of ACK’s in the live log. That makes sense because I have data confirmation turned on for the downlink. So, it appears I am getting confirmation of the downlink which means the device must be getting the data. Hmmm.
Update: I changed the deepsleep() to a delay() and now the message is getting to my app. Not sure yet where it is being lost. The murata chip appears to receive the message because it gets acknowledged. But something prevents the message from getting to my app when the SAMD21 sleeps.
