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

      @thomand1000

      You can disable the WiFi (and Bluetooth since it's the same) radios by setting

      pycom.wifi_on_boot(False)

      This is stored internally and WiFI will not turn on again until you either initialise it manually or set pycom.wifi_on_boot(True)

      For LoRa/Sigfox this isn't an issue as the radio is only active if you enable it.

      The LTE modem should retain the last powered status for deepsleep cycles (using machine.deepsleep())

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