Lopy Current Profile
-
Hi,
Here is the current draw profile I get from a Lopy4 connected to a 4V regulated lab supply with no expansion or interface boards attached. I do deinit Bletooth and WLAN at the very top of my code and the code also includes wifi on boot set to false.
The pperating current draw of the device is around 36 mA to 38 mA which matches the datasheet and there is a jump during the time I expect Lora transmission at around 5000mS mark.
I'm unable to explain the following:
1: The 150mA to 180mA current draw which drops at 2000mS mark. The device is initialized before the massive spike.
2: I send the device into deep sleep right after transmission. Why does it stay awake for an additional 3000 mili seconds?
-
@jcaron Thanks again for your help. Just uploading the profile of the test unit waking up, disabling the radios and going to sleep right away with a total of 15 lines of code for the record and future reference. Looks like the effect of program size is not much as you suggested.
-
@kavehoo Yes. When you go to deep sleep, nearly everything on the module is switched off, including the CPUs and their memory, so all state is lost, and you start from scratch.
That's a good reason for trimming down any code you load to the minimum. Alternatives could include frozen bytecode which may help a bit.
-
@kavehoo Wake-up from deep-sleep is a cold start.
-
@jcaron I just ran more tests and observed the exact same profile not only on cold starts, but whenever the device wakes up from deep sleep. Does this mean "the loading/parsing/compiling of the micropython code or something like that" that you mentioned earlier repeats even on wake-ups the same way it happens on cold starts?
-
@jcaron I understand. Thanks for the help. Really appreciate it.
-
@kavehoo Even if your application does not need it, it is required for LoRaWAN compliance: the network may send MAC commands in downlinks to change settings such as available channels, data rate to use (for ADR), RX settings, and more...
If the device doesn’t listen for those, it is not compliant, and in the worst case it can cause communication issues.
-
@jcaron Thanks heaps for this. Makes sense. I'll try to have a look at an I/O pin to make sure when the device starts up.
Is there any way to make the device not to listen for messages from the network after it transmits as this is not required in my application or there is no way around it?
-
@kavehoo In a class A LoRaWAN device, whenever you send, the device has to listen for a downlink from the network during two windows, RX1 and RX2 (with different channels / data rate settings).
RX1 and RX2 are always one second apart. The delay between TX and RX1 is configurable by the network. The default value is 1 second.
This would explain the two slight increases at 6 and 7 seconds (RX1 and RX2 respectively).
Not quite sure why it takes that long after the end of RX2 to go to deep sleep, though.
Are you sure the device is fully initialised and has started executing before the spike? I would expect that to be the loading/parsing/compiling of the micropython code or something like that.
If you can monitor another signal in parallel with current, you way want to toggle pins at different places in your code to check what is executing when.
