getting desperate: pysense does not start, while with another program it works



  • I have an very simple boot.py:

    import network
    import pycom
    
    from machine import Pin
    from pysense import Pysense
    from LIS2HH12copy import LIS2HH12  # acc readings at 800Hz and full scale 2G
    from rtc_ext_DS3231 import rtc_ext_DS3231
    
    LONGSLEEP = 60
    
    # turn off PySense LED
    pycom.heartbeat(False)
    print("starting1")
    
    # for getting out of sleep when INT_PIN is pulled up
    INT_PIN = Pin("P9", Pin.IN, Pin.PULL_DOWN)
    print("starting2")
    py = Pysense()
    print("starting3")
    py.setup_sleep(LONGSLEEP)
    acc = LIS2HH12()
    print("starting4")
    rtc_ext = rtc_ext_DS3231()
    print("starting5")
    

    But the "starting3" never occors while "starting2" does.
    Any ideas?



  • @jcaron said in getting desperate: pysense does not start, while with another program it works:

    @PeterB I already raised the issue here: https://forum.pycom.io/topic/4105/py-setup_sleep-time/4

    As is quite usual around here, the person in charge of documentation updates seems to have fallen into a black hole somewhere.

    NB: count yourself lucky, this is actually something you can infer from the source code. I've had to disassemble the Pysense PIC firmware to achieve my goals at some point. Even had to write the disassembler myself...

    Thank you very much. This solves possibly other unexplained problems we have seen as well. Will use the setup_sleep() now only just in front of the go_to_sleep().

    I had a qucick look in to the library, Except for setting some time values, which I do not think causes the issue it calls calibrate_rtc() which in it turns calls:

            self._write(bytes([CMD_CALIBRATE]), wait=False)
            self.i2c.deinit()
            Pin('P21', mode=Pin.IN)
            pulses = pycom.pulses_get('P21', 100)
            self.i2c.init(mode=I2C.MASTER, pins=(self.sda, self.scl))
    

    Perhaps the issue in one of those statements.



  • @PeterB I already raised the issue here: https://forum.pycom.io/topic/4105/py-setup_sleep-time/4

    As is quite usual around here, the person in charge of documentation updates seems to have fallen into a black hole somewhere.

    NB: count yourself lucky, this is actually something you can infer from the source code. I've had to disassemble the Pysense PIC firmware to achieve my goals at some point. Even had to write the disassembler myself...



  • @jcaron said in getting desperate: pysense does not start, while with another program it works:

    @PeterB setup_sleepalready starts changing some of the settings of the PIC on the Pysense, and that probably includes disabling (directly or indirectly) USB. You should only call it just before go_to_sleep, with nothing between the two.

    Really, it does not make much sense that the two are separate calls, but that's how it is at the moment.

    Setting up is normally done at the beginning of a program. If a function is called setup_sleep I expect that it just prepares for it, not to actually do something which breaks some other functionality upfront which should only be done when the actual go to sleep is executed.

    See here one other point of fustration with PyCom modules. This kind of weird behaviour, breaking seperation of concerns principles, is even not dcumented, it is just there.

    But now I know it should go together with the go to sleep, I will just use it there.



  • @crumble said in getting desperate: pysense does not start, while with another program it works:

    Using deepsleep does not work like you expect.

    The pysense will cut the power to your *Py. Wakeup will reboot the *Py. So the code behind your deepsleep call (when added py.go_to_sleep(boool) ) will never be called.

    Use normal sleep at this point or build some kind of boot where you store the loop counter in nvram.

    Yes that I knew and expected for the actual go_to_sleep, not for setting it up I would say!
    As you see in my post the program continued to work after the py.setup_sleep().



  • Using deepsleep does not work like you expect.

    The pysense will cut the power to your *Py. Wakeup will reboot the *Py. So the code behind your deepsleep call (when added py.go_to_sleep(boool) ) will never be called.

    Use normal sleep at this point or build some kind of boot where you store the loop counter in nvram.



  • @PeterB setup_sleepalready starts changing some of the settings of the PIC on the Pysense, and that probably includes disabling (directly or indirectly) USB. You should only call it just before go_to_sleep, with nothing between the two.

    Really, it does not make much sense that the two are separate calls, but that's how it is at the moment.



  • Found the culprit:

    py.setup_sleep(LONGSLEEP)

    stops all printing and connection on USB
    but the program continues after it, as can be seen by the blinking LEDs

    Why?



  • I am a small step further:

    The next program:

    print("starting main.py", flush=True)
    blink("red", 1)
    
    # for getting out of sleep when INT_PIN is pulled up
    INT_PIN = Pin("P9", Pin.IN, Pin.PULL_DOWN)
    print("starting pysense", flush=True)
    blink("red", 1)
    py = Pysense()
    print("pysense started", flush=True)
    blink("red", 1)
    py.setup_sleep(LONGSLEEP)
    acc = LIS2HH12()
    print("acc started", flush=True)
    blink("red", 1)
    #rtc_ext = rtc_ext_DS3231()
    rtc_ext = None
    print("RTC started", flush=True)
    blink("green", 1)
    
    

    Shows the 4 blinking red LEDs and the green blinking LED but does not do all the printing:

    starting main.py
    starting pysense
    pysense started
    Connection error: Error: timeout
    

    It still prints one after py = Pysense(), but no further printing, any ideay why? Why the connection time error?



  • @Martinnn Well, our next order for pre-production testing will be 300 GPys with PyScans, which should last us till July. Then we will start dealing in larger quantities - but I take your point.

    While Pycom has the edge now, it's certain that others will develop similar hardware products in the near future. The thing that will keep customers loyal is if we get support from Pycom that cannot be bettered. Right now that is not happening. I'd rather not have to redesign a wheel for our car, but when the wheel manufacturer won't tell you the sizes, mounting hole locations or the pressures, you don't really have a lot of choice. It's a shame as the platform has real potential.



  • @John-Baird The hardware documentation certainly is extremely poor (up to a point where one could consider it unusable), which would be less severe if they would publish the source (schematics etc). At least they have a position open for some documentation guy.
    I am just wondering how all this works out commercially. If you have to pay like ten employees every month, this certainly won't come from selling a handful of boards to the few regulars of this forum. Future will tell.



  • @PeterB I hear you Peter, I hear you. We have now decided to develop our own board rather than continue to base our designs on Pycom for those reasons, and a few more.

    <rant>
    The documentation on the PyScan board, which we want to use, is quite poor. For example

    • The link to the documentation (https://docs.pycom.io/.gitbook/assets/pyscan-specsheet.pdf) contains a picture of the PySense board and the combined details of the PySense and PyTrack boards. It's basically completely wrong.
    • Nowhere does it mention the IO expander, nor is there a library for it. You have to get the chip datasheet and figure it out. You have to experiment with how it responds to deepsleep. It could have been very useful for us.
    • The pinout diagram shows the pinout of the 10 pin expansion port as having two straight 3v3 out pins. The PySense board labels one as board power and one as sensor power, implying they can be switched independently. Haven't figured that out yet, but we need very low power, so it had the potential of also being really useful.
    • The PIC controller used for deepsleep has no documentation and you have to figure it out for yourself. Some of it just can't be guessed at.
    • The pinout diagrams of the processor modules and the boards use totally different systems. It took me a week to diagnose a hardware error because "Tx/Rx" meant different things on different diagrams.

    These may seem like small things, but we shouldn't have to "guess" at how it works.

    My big fear is that with these bits that are not documented Pycom is free to change how they function when they please. I saw a post today about someone with a LoPy that started rebooting every 11 minutes. Turns out Pycom decided to initialise an 11-minute watchdog on the PyBytes version of the code. I get why they would want that, and I make heavy use of the WDT myself, but users should not be left guessing why their code crashes.

    It is disappointing to have put months of effort into understanding the platform and all it has to offer, only to have the quality of the documentation prove to be a stumbling block. (If anyone from Pycom ever reads this - please get a couple of good technical writers and treat documentation as seriously as code. Better yet, reach out to your current users and figure out what they want, then give it to them)
    </rant>



  • Thank you very much for the suggestions. The program presented is the only one running yet, so it is not yet put to sleep. But anyhow will test it with:

    • Blinking LEDs
    • Flush in print statements
    • A delay before the py = Pysense()

    I am getting more and more frustrated to use Pycom in a professional environment, although the concept is great:

    • The RTC of the ESP32 (which according ESp32 documentation continous to function in sleep mode) is used by the OS in such a way that it does not maintain its time when in sleep (also not documented), meaning an external RTC is required to keep time.
    • The SD card does not always work when getting out of sleep (also not/badly documented). It differs from device to device. So unreliable.
    • Atom is regularly not able to upload the firmare as the safe boot fails and then Atom loses also the connection and everything has to be restarted and restarted. This means major time is wasted while debugging.
    • It is not documented what the difference between boot.py and main.py is. It is also not clear whether objects created in boot.py are guaranteed to be available in main.py. It is also not clear whether utilising e.g. pysense in both boot.py and main.py is allowed or not.

    Although the forum is a great help!
    But a forum is not a replacement for good documentation and a reliable functioning product.



  • @crumble Another easy thing to check is to put a time.sleep() after the print, but before the shutdown. Allows the underlying OS time to timeout and flush the data, but forcing a flush at the right time is the better way of doing it if you are trying to maximise battery life.

    I've used this on everything from 1.18.xx through to the latest development version.



  • @John-Baird

    if the connection is not cut, the print shall show up completly.
    Which firmware version do you use? flush never worked for me in the past.



  • @PeterB Try changing print("starting3") to print("starting3", flush=True) and see what happens. I've had similar issues before where Python hands the data to be printed to the underlying OS, but then shutsdown the system before it gets sent to stdout. The flush forces the OS to write it immediately.



  • @PeterB

    depending on firmware versions you may run into i2c errors.
    Add some sleep time before the pysense call.



  • @jcaron said in getting desperate: pysense does not start, while with another program it works:

    @PeterB Can you confirm what version of the Pysense module you are using (and if by any changes you made any changes in it)?

    Have you tried commenting the other imports to see if that changes anything?

    Do you have anything else connected to the Pysense?

    It is not really different from the other program it works on.
    Could it be a problem with Atom not showing all the print statements?

    I will use blinking LED instead to check



  • @PeterB Can you confirm what version of the Pysense module you are using (and if by any changes you made any changes in it)?

    Have you tried commenting the other imports to see if that changes anything?

    Do you have anything else connected to the Pysense?



  • Hi @PeterB
    I moved your post to the correct section.


Log in to reply
 

Pycom on Twitter