Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    All radios on by default

    Scheduled Pinned Locked Moved FiPy
    fipyradioenergypower saving
    16 Posts 3 Posters 2.6k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • robert-hhR Offline
      robert-hh @thomand1000
      last edited by

      @thomand1000 Do you have an SD card plugged into the interface board? That adds another ~5 mA.

      T 1 Reply Last reply Reply Quote 0
      • T Offline
        thomand1000 @jmarcelino
        last edited by

        @jmarcelino Ah, thanks! I've never tried powering trough the Vin pin before, but I'll give it a try.

        1 Reply Last reply Reply Quote 0
        • T Offline
          thomand1000 @robert-hh
          last edited by

          @robert-hh No SD-card connected, but thanks for the tip!

          1 Reply Last reply Reply Quote 0
          • T Offline
            thomand1000 @jmarcelino
            last edited by

            @jmarcelino I now see a substantial drop in current after powering the device through the VIN. Thanks! Do you have any ideas as to what the peaks of about 200 mA could be btw? I still see them after powering through VIN. Strangly this doesn't happen the first time the device goes into deepsleep, but all consecutive runs. Before I go into deep sleep I store the lora state with lora.nvram_save(). Is this an expensive operation? I guess it's overwriting the state in ram, but this shouldn't take a couple of seconds of around 200 mA current drain? Any help is highly appreciated!

            J 1 Reply Last reply Reply Quote 0
            • J Offline
              jmarcelino @thomand1000
              last edited by jmarcelino

              Hi @thomand1000

              I believe those peaks are the FiPy actually preparing the LTE modem for deepsleep, but if so it definitely could adopt a smarter strategy to go about it.

              We'll investigate, thank you for your obvservations.

              T 1 Reply Last reply Reply Quote 0
              • T Offline
                thomand1000 @jmarcelino
                last edited by

                @jmarcelino Cool. My work on the FiPy is part of a master thesis where I'm doing test on energy consumption for different setups. I'm basically testing different algorithms or models that decide how often a device needs to send data to the server. A good model would send data less often than another less good model, because sending is more expensive. I'm doing tests where I accumulate power consumed by the device over a given time. For a good model, the result should be that it consumes less power and uses more time in deep sleep. However, with the potential bug with the 200 mA peaks, a good model that goes into deep sleep more times than a bad model would in the long run possibly consume more power. So my tests would be corrupted.

                I need to have a realistic expectation as to if my tests would be possible to perform before the deadline of my thesis. So, if you find the bug and a potential fix for it, how fast can a new firmware be deployed that fixes it?

                J 1 Reply Last reply Reply Quote 0
                • J Offline
                  jmarcelino @thomand1000
                  last edited by

                  Hi @thomand1000

                  Are you calling LTE.deinit() by any chance? Are you using LTE at all?

                  T 1 Reply Last reply Reply Quote 0
                  • T Offline
                    thomand1000 @jmarcelino
                    last edited by

                    @jmarcelino Yes. I'm deinit WLAN, Server, Bluetooth and LTE. I'm also doing pycom.wifi_on_boot(False). It seems to work since the consumption drops a lot. And everything seems fine until I'm going into deep sleep the second time. I'm never doing any of these deinit() calls again. Should I?

                    J 1 Reply Last reply Reply Quote 0
                    • J Offline
                      jmarcelino @thomand1000
                      last edited by

                      @thomand1000
                      If you don't actively use the LTE it's actually better not to deinit() it, don't call LTE module even. The modem should automatically go into deepsleep mode.

                      T 1 Reply Last reply Reply Quote 0
                      • T Offline
                        thomand1000 @jmarcelino
                        last edited by

                        @jmarcelino I've tested this now (removed lte = LTE() and lte.deinit() ) and the peak is still there. The device goes into deep sleep, but like before the current rises quickly to about 200 mA for a couple of seconds before it goes into deep sleep. I also find it strange that it doesn't happen the first time the device goes into deep sleep, but all consecutive runs. The first time now, since I don't deinit() LTE the current is at about 200 mA and drops down to deep sleep. Then when waking up it is around 60-70 mA when measuring and then peaks to 200 right before deep sleep.

                        1 Reply Last reply Reply Quote 0

                        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                        With your input, this post could be even better 💗

                        Register Login
                        • 1 / 1
                        • First post
                          Last post

                        Pycom on Twitter

                        Pycom