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.
    • T Offline
      thomand1000 @jmarcelino
      last edited by

      @jmarcelino Ok. The following is what I'm getting in current consumption. Deep sleep is around 15 mA (after I found the info that the RTS and CTS pins should be taken off. This info should also be under deepsleep docs). 15 mA is still a bit high right?

      In the image you can see that the device wakes from deep sleep, sends a packet over LoRa, checks if there is anything incoming from the server and then goes into deep sleep again. I have checked my code and put in pycom.rgbled and timers before the machine.deepsleep(20000) I have in my code and the over 200 mA peak in the picture happens every time for about 2 seconds before the device goes into deepsleep.

      Any ideas to what it might be? I use nvs_set and nvs_get to store some variables during deepsleep, but I'm pretty sure that this isn't an I/O operation causing this. This happens at a different time in my code anyway, so I don't think that is the cause. I removed the nvs_get/nvs_set and the peak is still there...

      0_1525118174124_Skjermbilde 2018-04-30 kl. 21.51.18.png

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

        @thomand1000
        How are you powering the FiPy and measuring the current?

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

          @jmarcelino through USB. It’s connected to a PyMakr dev board

          J robert-hhR 2 Replies Last reply Reply Quote 0
          • J Offline
            jmarcelino @thomand1000
            last edited by jmarcelino

            @thomand1000
            Connecting over USB you'll see an added, constant, power consumption from the USB-Serial chip (Expansion 2) or PIC micro (Expansion 3) as well as the USB LED.

            T 2 Replies Last reply Reply Quote 0
            • 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