Deep Sleep Mode and MDot LORA configuration.

[Ajay K]

I am initializing the LORA settings when the mdot is powered on.

1) I begin by resetting the configuration and this happens only the first time mdot powers on and not on future power-recycles.
2) I set mode=AUTO_OTA, Enable Acks, Set network name,passphrase, sub-band, TX power, # of join attempts and I currently use ADR.
3) Finally save the configuration by calling the mdot saveConfig method.

When I enter deep sleep mode and when the mdot wakes up, I am assuming since I am in AUTO_OTA mode and since I saved the configuration, I don’t have to set any of the settings again correct or even if the mdot is power cycled, it should read from the saved configuration file?

Unless I need to explicitly change the network name/pass phrase or the sub-band.

Is my assumption correct?

Thanks,
Ajay.

[Mike Fiore]

Ajay,

That’s correct. Your session should also be saved so that you don’t need to rejoin the network after waking up.

Cheers,

Mike

[Andrew Lindsay]

If you’re using deep sleep on the mDot then be warned that Multitech have removed this feature from the mDots and was only discovered during debugging to identify why it wasn’t working as expected anymore.

[WARNING] This mDot hardware version does not support deep sleep… using sleep.

Therefore a lot of your code may no longer work as expected. They claim that it is because some customers found it wasn’t as low power consumption as they expected. I’d like to have been the judge of that and decide if I want to use this feature in my designs.

The workaround is to not update the libmDot library and stick with the revision 15:b50f92f which does include the functioning deep sleep mode.

Andrew

[Ajay K]

Thanks Mike and Andrew for your inputs. so based on Andrews comments the latest libmdot removes the deep sleep feature, while the version I am on currently supports it. Although we wanted to originally use the non deep sleep mode because of the RAM being intact, but we chose the deep sleep mode because of the lower current consumption.

So Mike are there tests from the Multitech side confirming that the current consumption in the non deep sleep mode is in the ~50UA range? Is there any links on the site that you can point me to wrt to the new current consumption under non-deep sleep mode, before we switch over? Although its a technical decision, once the mdots are in the field the firmware updates would be harder to implement.

Thanks,
Ajay

[Mike Fiore]

Ajay,

If you want to investigate our new libraries that support mbed 5, you should take a look at our Dot-Examples program which contains a number of example applications for the mDot and xDot.

https://developer.mbed.org/teams/MultiTech/code/Dot-Examples/

If you want to try out the latest libmDot in mbed 2 instead, you can use the mDot_LoRa_Sleep_Example.

https://developer.mbed.org/teams/MultiTech/code/mDot_LoRa_Sleep_Example/.

In both cases, sleep mode on the mDot should get current consumption into the ~50uA range.

Cheers,

Mike

[Andrew Lindsay]

I decided to do some tests on this comparing deep sleep libmDot to the sleep only crippled libmDot. There seem to be some interesting results.

libmDot 15:b50f92f when using deep sleep – 75-90uA.
libmDot 17:0da384b+ When using sleep – 130uA.
libmDot 17:0da384b+ When using deep sleep and get warning – 42uA

If selecting deep sleep is producing the warning saying it is using sleep instead of deep sleep, then why does it show a much lower power consumption that when sleep is selected?

The 42uA was not consistent as sometimes when it entered sleep mode via the deep sleep warning it failed to reduce the power consumption at all and stayed above the normal 6mA or more.

I’m going to repeat the tests again in the morning and try a number of mDots to see if this is the same on them all.

Thanks

Andrew

[Mike Fiore]

Andrew,

We’re working on updating documentation that explains the differences you’re observing. The short version is this:

libmDot 17:0da384b sleep mode sets most internal IO pins to analog input with no pull resistors to achieve the lowest possible consumption. A few must be set low or high instead of left floating. External IO pins are the responsibility of the user for the following reason: we don’t know what is happening on those pins. Your application may need to keep a pin high, low, etc while the device is asleep. We have code in the Dot-Examples program that demonstrates how the user application can put whichever of these pins they wish into the analog input no pull state for lowest consumption. If you add this code to your test for sleep mode, you’d see current consumption similar to deepsleep.

libmDot 17:0da384b deepsleep mode handles the internal IO pins similarly to sleep mode but also handles the external IO pins, emulating what would happen in ST standby mode. Nearly all of the external IO pins are set to analog input no pull except for the few we discovered that are causing the extra current consumption in some situations. The processor goes into stop mode just, RAM is retained, and the application resumes after waking up just like sleep mode. The only difference is what happens to the external IO pins.

We will be updating the warning box on the mDot platform page in the LoRa Stack section to better explain this difference.

Hope this helps.

Cheers,

Mike

[Andrew Lindsay]

OK, thanks Mike for this. Documentation is key.

I’ve tested some new code using the Dot examples sleep and I/O configuration, I’m now seeing less than 50uA so an improvement.

Regards

Andrew

[Mike Fiore]

Andrew,

Glad to hear it! We greatly appreciate your feedback and your activity on the developer forum and mbed!

Cheers,

Mike

[Andrew Lindsay]

It can be frustrating at times….When I get a spare day I may even tackle mbed-os5!!!

Thanks for your continued support Mike and the guys.

Andrew

[Ajay K]

Thanks a lot Andrew for running those tests. We are going to begin those test shortly as well on libmdot 17 revision. By the Dot examples you meant using libmdot-mbedos5 or the latest libmdot revision 17 on the older mbed os?

Thanks,
Ajay.

[Author]

Posts