5 years, 10 months ago.

mDot in sleep STOP mode

Dear Sirs,

I have asked a question in the "mDot_LoRa_Sleep_Example", and here is the link:

https://developer.mbed.org/questions/68441/Current-consumption-in-sleep-STOP-mode/?c=21938

I am obtaining 150uA current consumption in STOP mode with the mDot, but I expect about 50uA.

I know that libmdot doesn't support STOP mode yet.

But, could you guide me on how to set the microcontroller and pin configurations to have less current consumption in this mode?

Thank you and regards,

Gilen

Question relating to:

Library for LoRa communication using MultiTech MDOT. Lora, mdot, multitech

Hi again,

I have noticed that the last version of libmdot (1.0.7) has the feature of a new Sleep mode.

I suppose that the Sleep modes implemented in libmdot are the corresponding STM32F4 low power modes: SLEEP mode (with peripherals active, about 500uA current consumption) and STANDBY mode (without SRAM preserve, about 35uA current consumtion).

What about the STOP mode? Will this mode be implemented in next versions of libmdot? I think this will be the most useful mode for a large part of LoRa applications.

Thank you and regards,

Gilen

posted by Gilen Tell 31 Mar 2016

This problem was resolved in libmDot-mbed5. I got sleep (really stop) current down to about 50uA after setting GPIO as per the utility to analog input, with data retention

posted by Daniel Lavin 22 Mar 2017

2 Answers

5 years, 10 months ago.

Gilen,

Not quite. Version 1.0.7 of the mDot library does not support STM32F4 SLEEP mode. It does support STM32F4 STANDBY mode (which we call deepsleep) and STM32F4 STOP mode (which we call sleep).

Cheers,

Mike

Accepted Answer

Hi Mike,

But I have accomplished currents in STOP mode of 40 uA. And I am meassuring 500 uA with this libmdot version. The datasheet of STM32F411RE specifies currents between 10 and 113uA. Whats the matter?

posted by Gilen Tell 01 Apr 2016

It is important to remember that the 411 processor is not the only thing consuming power on the mDot. That being said, I am certain that STOP mode current consumption can be cut down below 500uA. There are steps that can be taken to reduce power consumption in STOP mode that the library currently isn't taking: set GPIO pins to analog input, switch to the internal oscillator, etc. This kind of optimization might be in the roadmap for the library, but it currently isn't implemented.

-Mike

posted by Mike Fiore 01 Apr 2016

Ok Mike, I understand.

I have another question about this new version refered to transmission power. With the previous version with the same configuration of transmission power of 14dBm, the current meassured in TX was 110mA. But with this new version the current meassured is about 55uA.

Is there any changelog or any correction of bug about this issue in the new version? Should I configure the transmission power in any other mode? I am doing it with function "setTxPower(14)".

Cheers,

Gilen

posted by Gilen Tell 01 Apr 2016

That looks way too low. Are you sure the mDot was actually transmitting when you got the 2nd reading?

posted by Mike Fiore 01 Apr 2016

Yes, of course, the packets are arriving to the Conduit gateway, and forwarded to the LoRaWAN server in the cloud. I could measure with an spectrum analyzer the power transmited to verify that 14dBm are coming out from antenna connector, but this will be next week. Can you confirm that the PA_BOOST is configured correctly in the new version of libmdot? And validate that power trasmitted is the configured one? Thank you, Gilen

posted by Gilen Tell 01 Apr 2016

Hi Mike,

I have done current mesurements again and now last version and previous version are consuming the same current in TX: 56mA. Now I'm doubting if the previous measures I make any mistake. Could you confirm me which is the current that I can expect with 14dBm, please?

Thank you and regards,

Gilen

posted by Gilen Tell 04 Apr 2016

Hi again,

Finally I have detected the cause of those current consumption deviations. When the mDot does not have antenna connected the current in TX is 110mA. When the antenna is connected the current is 55mA. Until now I had never seen such behavior in a RF system. So any measurement must be done with RPSMA antenna.

This should have an explanation, but it is the task of mDot designers or Semtech SX1272 tranceiver manufacturer to explain it.

Cheers,

Gilen

posted by Gilen Tell 04 Apr 2016

Actually this makes sense for the SX1272. The PA has a typical draw of 125 mA at +20 dBm with a well matched antenna (VSWR < 3:1). The PA is not a typical PA design, but a switched design so higher current draw for a poorly matched RF path is not unexpected.

posted by Timothy Barr 08 Apr 2016
5 years, 9 months ago.

I had some trouble following this - I went over it again and I see what I think was a typo a few days ago by Gilen: "new version the current meassured is about 55uA." I think "55mA" was meant.

Also, regarding the 2X current draw with NO antenna: it might be that the RF amplifier circuit does not like an open circuit and draws more current in that case.

Sorry this appears where it does - it refers to posts BELOW it. This forum does not operate as expected.

Hi Mike,

Yes, this was a mistake in units.

Now, the current deviation is explained. This troubleshooting gave me headaches, and by chance I found the solution.

Thank you for your support,

Gilen

posted by Gilen Tell 11 Apr 2016