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.
I think I see the source of the problem. The murata module firmware calls at_Receive asynchronously when it receives a LoRa downlink:
static void LoraRxData(lora_AppData_t *AppData)
{
set_at_receive(AppData->Port, AppData->Buff, AppData->BuffSize);
at_Receive(NULL);
}
To fix this, we need an option that allows us to turn off the call to at_Receive() in the murata module and add a function to the MKRWAN API that allow us to call this function from our application. That way, when we sleep, we will not miss the asynchronous transmission of data from the module.
I opened an issue on Github.
Hi @Amedee I was going to try and compile the module firmware to address this issue. Do you have any pointers on how to do that? I have Eclipse installed (note, I am not familiar with Eclipse). I built the package but do not know how to create the fw.h to program the module.
Yes, I was suspecting something like that, just had no time to look at the code…
I really like this board, but the more I use it, the more I find the API and implementation a limiting factor for somewhat advanced usage…
I haven’t use Eclipse before either 
Nice editor, but quite complex at start.
I have a little script to generate the firmware file:
#!/bin/bash
FwBaseDir=~/Development/TTN/mkrwan1300-fw
FwVersion=Projects/Multi/Applications/LoRa/AT_Slave/inc/version.h
FwDir=Projects/Multi/Applications/LoRa/AT_Slave/SW4STM32/B-L072Z-LRWAN1/mlm32l07x01/Debug
Fw=mlm32l07x01.bin
MkrWanDir=~/Documents/Arduino/libraries/MKRWAN/examples/MKRWANFWUpdate_standalone
FwInclude=fw.h
cd "${FwBaseDir}/${FwDir}"
(
awk '/AT_VERSION_STRING/ { print "// Firmware version: ", $3 }' "${FwBaseDir}/${FwVersion}"
echo -n "const "
xxd -i "${Fw}"
) > "${MkrWanDir}/${FwInclude}"
(It is just a one liner – xxd – but as I forget easily I prefer to wrap in a script )
Yes, I agree. Seems to me like the developers do not yet grasp the importance of low power. I think this is a good product but still quite green. Would be cool if they would integrate a WiFi module with the LoRa module like the LoPy. I do not prefer the LoPy because you reboot the device every time you sleep so there is quite a bit of latency and power wasted doing that.
Thank you for the script! This answers a lot of questions … like where to look for the correct bin file!
What do you use to compile the source?