As much as I’d like to answer that, I’m waiting on an antenna 
will update when it arrives.
I assume that is for deployment use not for testing and that you have had an ant connected in some form for testing? Right?
It is highly recommended to not run a node (or GW) without some form of ant/load as any tx’d energy will be reflected by the open connection into the front end potentially frying it! If that happens depending on induced fault one possible symptom along with vastly deminished sensitivity on Rx or little/no Tx PWR is front end can end up in a partial latch up state pulling higher than expected supply current… leading perhaps to the problem you are seeing with excess PWR consumption. 
Additionally, how did you assemble the board?
I suspect good yields are possible with automated assembly, but it is extremely difficult to hand-place the CMWX1ZZABZ module and get full connectivity without getting a short, and unlike typical SMD IC packages they are very hard to rework without disassembling the internals. The recommended pads are wider than the spacing in between which leaves very little tolerance for having the wrong amount of solder paste - too little and no contact, too much and easy bridging. In working with a board using this as a minor component I ended up having to write a program to pulse all non-dedicated GPIOs in turn, watching with a scope I could then see which failed to toggle, or toggled twice at half amplitude because they were shorted to a neighbor. Ultimately as that project was a large expensive board of which this was only a small optional part, for the subsequent version the module ended up replaced by its constituent pieces - its unclear if the radio will even end up installed, but the MCU needed to work, which is something easily achieved with an STM32 QFP or QFN package. I might still use this in a smaller cheaper project that would be machine built from day one, but am tempted to pursue the more QFN-like ACSIP offering (if only availability were better).
@Jeff-UK I have not had an antenna connected yet, so there may be some merit in what you’re describing. I have not attempted anything beyond reflashing and testing AT/OK comms. VDD_TCXO has not been connected. I don’t know enough about the firmware to know if it would have been trying to TX or not. I have a couple of other boards unopened from the fabrication house, so I’m happy to compare the symptoms next week when my antennas & pigtails arrive.
@cslorabox The board(s) were professionally assembled. The Murata module is a small piece of the overall functionality, and not required for our initial use. I selected this module so that we can potentially play around with custom [multi-hop?] firmware in the future. I do need the module to go into a low power state though, hence my limited testing at this point.
Just a quick update on this - I got the antennas & pigtails so was able to attempt connecting.
I set the band, mode, keys, connected TCXO appropriately, and the module successfully performed an OTAA join.
Power consumption has now dropped by a couple of orders of magnitude. [Expected battery life has gone from days to years!] Thanks so much for your respective thoughts on this, very helpful.
–Nick
Might be helpful to those following the thread to say what the actual power consumption figure are …
I went from ~3.1mA (unconfigured, as detailed above) to ~0.032mA (configured, OTAA join ok). Note there are quite a number of other functional parts of my particular board that likely draw small amounts of current during shutdown, so this exact figure doesn’t likely relate to a murata module in isolation.
I have an MKRWAN 1310 here and with the follow sketch:
#include "ArduinoLowPower.h"
#include <LoRa.h>
#include <MKRWAN.h>
LoRaModem modem;
void setup() {
for (int i=0; i < 15; i++) {
pinMode(i, INPUT_PULLUP);
}
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN, HIGH);
delay(3000);
digitalWrite(LED_BUILTIN, LOW);
delay(500);
}
void loop() {
USBDevice.detach();
digitalWrite(LED_BUILTIN, HIGH);
delay(500);
digitalWrite(LED_BUILTIN, LOW);
delay(500);
LowPower.deepSleep(8000);
LoRa.begin(868E6);
LoRa.beginPacket();
LoRa.print("D:");
LoRa.endPacket();
LoRa.end();
digitalWrite(LORA_IRQ_DUMB, LOW);
digitalWrite(LORA_RESET, LOW);
digitalWrite(LORA_BOOT0, LOW);
}
The first time it hits the deep sleep it gives a current of 16uA, however subsequent times, i.e. after actually transmitting, the sleep current is 300uA.
I keep finding forum threads in various places that suggests its possible to get ~100uA (or lower) sleep current from the MKR 1310, but have not actually managed to find an example where someone transmits and then sleeps at <100uA.
Its frustrating because clearly the board is capable of such a low power, but something about the Murata module / firmware means its not shutting back down / going to sleep properly. This thread implies that the hardware issue with the module integration is fixed so it should just be a software change, but I can’t track it down…
1 Like
Hey there, did you manage to reduce the sleep current further?
If so, would you mind telling me how?
I ran your LED sketch and got the currents you said. I then moved my WAN1310 over to a caddy which had sensors connected to it (I2C, SPI etc) but I did not change the sketch, just kept the code the same, blinking the LED. But this time the sleep current went way up, to mA. I can only guess that this is because some of the sensors are drawing power somehow even though there is no code speaking to them, some pins must be on by default, I did try pulling pins up but no use, still mA sleep current.
Might possibly be helpful to tell the forum how many mA ?
Went from about 69uA to 3 mA
OK.
But the sketch posted by @amasidlover in Feb 2021, appears to be an Arduino device using point to point LoRa libraries.
There may well be solutions to the increase in sleep current for that particular library, but they would appear tobe of little relavence to the use of TTN libraries, which is the subject of this forum.
We are both using the WAN 1310, LoRa enabled Arduino.
Your first post refers to the LED / sleep test that uses the LoRa library so it’s not clear if you are using your MKRWAN 1310 as a LoRa point to point device as per the test code or as a LoRaWAN device.
If the former, as advised above, that would be off topic for this forum. If the latter, then you may want to look at the date of the post of the LoRa only test as not only is it off-topic albeit still of relevance, but it’s also rather stale.
You may also benefit from looking at the GitHub repro for the v1 code & how long the v2 code has been in “beta” and come to some conclusion about the product.
In the morning I’ll have a look at my notes from when I last used one of these wonder boards - two V8 turbocharged MCU’s strapped together - what could possibly go wrong?
Maybe so, but the library you appear to be using appears to be for point to point LoRa.
If so then any ‘solution’ for deep sleep may be of little relavence when a LoRaWAN library is in use, since the means or code of getting the combination of board and LoRa module into deep sleep would likely be different.
As a general comment, for a board sold specifically as a LoRaWAN board you might have expected the manufacturers (Arduino) to have produced a decent set of examples for sleep mode when used as a TTN\LoRaWAN board …
You might have more success asking for assistance in the Arduino forums, for instance a quick Google search found this;
1 Like