Does deepsleep work at all

[jmarcelino]

@Camot said in Does deepsleep work at all:

If I put 5v to the 5v pin, the Lopy does nothing. If I put in 3.3v at the same 5v pin, it is starting. And yes, I am using the 5v pin ....first pin right to the heartbeat.

Can you explain it a bit better please? Where are you supplying 5V from? Is this with the LoPy inserted into the Deep Sleep shield?

[Camot]

This post is deleted!

[daniel]

@Camot the deepsleep shield has a battery protection mechanism (LiPo batteries get damaged if you discharge them completely), therefore when the input voltage falls close to 3.3V, the deepsleep shield will disconnect power to protect the battery. This threshold voltage can be increased with the set_min_voltage_limit() and enable_auto_poweroff() methods from the deepsleep library. In any case trying to power it with a voltage that is too low won't damage anything.

What do you mean with so many hardware bugs? Besides the deepsleep problem that we already acknowledged, and we did our best to compensate with the deepsleep shield, what other hardware issues have you found?

Cheers,
Daniel

[Thosch42]

Hi all!
I recognized a similar behaviour with my Lopy. The DS-shields arrived yesterdayand I start to work with them. My hardware setup is pretty simple: Expansionboard V2.1A, DS shield V1.0, LoPy, 2000mAh LiPo, attached to the Expansionboard and powered by USB.
I start with upgrading a OTAA LoRaWAN node. It work for a while, then it stopped working with:
Joined yet!!!
Traceback (most recent call last):
File "main.py", line 75, in <module>
File "deepsleep.py", line 156, in go_to_sleep
File "deepsleep.py", line 105, in calibrate
IndexError: list index out of range
MicroPython v1.8.6-724-g2b9ed601 on 2017-07-28; LoPy with ESP32

Cheers,
Thomas

[chumelnicu]

Lopy + DeepSleep Shield after 10-12 cicles of 10 minites deepsleep stop working to0

I use deepsleep.py library

I really think is one bug with deepsleep function

[bucknall]

Hi @Thosch42,

Could you please share which version on the deepsleep.py library you are using? I think myou might be on an older version of the library.

You can find the latest version, here - https://github.com/pycom/pycom-libraries/tree/master/deepsleep

Let me know if this helps,

Thanks!

[Thosch42]

@bucknall It's Version 1.0.0

[Thosch42]

@bucknall My last pull was yesterday, at app. 9.00 MEST, right after I held my Air Mail Bag from Pycom in my hand ;-)

[chumelnicu]

@bucknall that from your link library i use too.

The question is ..Why deepsleep is working 10-12 cycles ..and after that lopy program is stop.
I use Lopy+deepsleep sheeld, powered from USB

[this.wiederkehr]

The relevant lines are:

    pulses = pycom.pulses_get(COMM_PIN, 50000)
    self.uart = UART(1, baudrate=10000, pins=(COMM_PIN, ))
    self.clk_cal_factor = (pulses[3][1] - pulses[1][1]) / EXP_RTC_PERIOD

obviously pycom.pulses_get returned a list not compatible with the indexes in pulses[3][1] - pulses[1][1]

[bucknall]

@chumelnicu Ok thanks for letting me know, I'll investigate this!

[chumelnicu]

@bucknall Thank you !

[chumelnicu]

@this.wiederkehr And ? Solutions is .. ? :)

[livius]

@this.wiederkehr said in Does deepsleep work at all:

returned a list not compatible with the indexes

What do you mean in "not compatible"?

[this.wiederkehr]

I can only guess from the source as there is no documentation for pycom.pulses_get:

pulses[3][1] - pulses[1][1] should get the time difference from the second to the fourth pulse. If e.g. there is no fourth pulse there will be no list entry for pulses[3] which will result in the error 'IndexError: list index out of range'.

The hacky solution would be to wrap this in a try-except block and retry if there is the IndexError ...

[chumelnicu]

@this.wiederkehr Ok .. now speak for human beings now please :)

I dont know how to do that. Can you tell me the code line who is supose to fix that ?

Than you ! :)

[chumelnicu]

This post is deleted!

[this.wiederkehr]

@chumelnicu said in Does deepsleep work at all:

dont know how to do that. Can you tell me the code line who is supouse to fix that ?
Than you ! :)

Exchange the calibration function in deep_sleep.py with the following one, take care on the indentation (sorry I dont have a board at my hand to test right now, so use at your own risk :-)
That is not a fix, that is a hack to catch an error (which should not be there in the first place) and retry the calibration procedure ...

def calibrate(self):
    """ The microcontroller will send the value of CTRL_0 after setting the bit
        and then will send the following pattern through the data line:
           val | 1 | 0 | 1*| 0 | 1*| 0 | 1
           ms  | 1 | 1 | 1 | 1 | 8 | 1 | -
        The idea is to measure the real life duration of periods marked with *
        and substract them. That will remove any errors common to both measurements
        The result is 7 ms as generated by the PIC LF clock.
        It can be used to scale any future sleep value."""


    while True:
        try:
            # setbits, but limit the number of received bytes to avoid confusion with pattern
            self._magic(CTRL_0_ADDR, 0xFF, 1 << 2, 0, 7)
            self.uart.deinit()
            Pin(COMM_PIN, mode=Pin.IN)
            pulses = pycom.pulses_get(COMM_PIN, 50000)
            self.uart = UART(1, baudrate=10000, pins=(COMM_PIN,))
            self.clk_cal_factor = (pulses[3][1] - pulses[1][1]) / EXP_RTC_PERIOD
            break
        except IndexError:
            print('calibration failed')
    if self.clk_cal_factor > 1.25 or self.clk_cal_factor < 0.75:
        self.clk_cal_factor = 1

[chumelnicu]

@this.wiederkehr Ok .. maybe you right but this is beyond me , I think is beter to wait for @daniel and @bucknall opinion or fix solution.

Thank you very much @this-wiederkehr

[daniel]

Hello,

While we find out why sometimes less calibration pulses are received, please use the new library that has a try-except block around the calibration:

https://github.com/pycom/pycom-libraries/commit/074bc7ee0181451720bbeb30d627debafc617ad8