Deepsleep on the pysense is a complete disaster
-
Deepsleep on the pysense is a complete disaster:
- Writing to files before going to sleep does not work as expected. Sometimes it does, sometimes it does not, more not.
- RTC is reset to 0 when waking up, who made that stupid decision?
- Based on the number of questions on the forum it is completley unclear how to minimise power consumption and to which extend.
(see elsewhere in my forum posts for some details.
-
See my other post: https://forum.pycom.io/topic/4571/writing-to-text-file-to-log-debug-prints
In short:
"... py.go_to_sleep() does not close the 'operating system' running on the main processor in a decent way before cutting its power. That is really really bad! ..."causing garbage in files wriiten before using py.go_to_sleep()
When using machine.deepsleep() that issue is not there, as it clearly puts the system to sleep correctly. Except then for the pysense is not put to sleep. And I need to put that to sleep as well, but how ... (in a decent way please)?
-
@crumble I think you have summed up the Pycom situation pretty well with "Using the pycom devices for private solutions can be fun. But using them to sell hardware? No thats not fun at all (at this moment)". From my experience the pycom products have great potential but the hardware and firmware for them to run reliably for many hours/days/weeks/months are still works in progress with 'fixes' causing further unrelated issues and development is driven by the user base. I like the pycom concepts but for production work I have had no choice to use other, mature, products.
Looking through posts on this forum indicates there are many issues being encountered, over many products and that is not helped by gaps in the documentation and lack of updates to match hardware/firmware revisions and some device information being kept secret. It is a cumulative effect of lots of little issues, of firmware updates causing some changes or failures to other parts of the same code. There are a large number of workarounds in evidence (and I have had to find some for myself while I work with GPY/FiPy devices), I don't want to discourage Pycom, rather the opposite - improve the products in all aspects and they will be serious devices.
I continue to look in here to assess how the development is progressing, but at this stage it still looks like unfinished works by the comments being posted. :-(
-
@PeterB said in Deepsleep on the pysense is a complete disaster:
It can not even write to files reliable when using sleep.
I think it is vice versa. You have to use sleep, because the flush=True does not work in this python implementation.
I can understand your frustration. Using the pycom devices for private solutions can be fun. But using them to sell hardware? No thats not fun at all (at this moment). Running them with low amount of issues needs a lot of sleep statements. You have to realize theat you need them and you have to find the length by try and error by using really long tests. Switching to a newer version to get rid of some errors means that you have to do the whole timing stuff again, because they are related to a certain version. So you cannot calculate the cost of product and - at this state - cannot release a product with the feeling you stuff works.
For private use I can simply wait until the issues are solved. I think most of my problems will be fixed. I noticed soem trouble when pycom increased the performance by using the second core. So they run into all the trouble with memory and synchronize problems with the Espressive IDF. I guess 6-12 months and most of the troubles are fixed. But customers don't like to wait. They want that you fix the problems ASAP.
I like to see better documentation, examples which work out of the box and hardware which can be programmed out of the box. I expected not that I got only some pre soldered hardware. I expected a working lib.
They need more honest customer communication. I think they do a good job on the hard- and software according to their limited resources. A goodbye bessage for instance. Pycom had good staff for the forum, but they are gone overnight. No message that we have to keep calm, 'cause the senior developers will have a look every now and then a brief look on our problems. For the small user base we have good forum with friendly and helpful regulars. Sometimes I think I am back in the good old Atari/Commodre times. Not because I had to solder again. Its more like "Does the management know which product they sell and what their customers need?"
-
@jcaron said in Deepsleep on the pysense is a complete disaster:
@PeterB said in Deepsleep on the pysense is a complete disaster:
@jcaron said in Deepsleep on the pysense is a complete disaster:
@PeterB Pysense-controlled deep sleep completely cuts the power to the whole *Py module.
Not fully as e.g. the accelerometer can be working wihich is needed in my case
I’m talking about the *Py module (WiPy, LoPy, FiPy...). That module is completely powered down during Pysense-controlled deep sleep. Sensors on the Pysense are indeed a different matter.
It is quite normal that the RTC is reset, as it's no longer powered during deep sleep.
Ruunng on battery the ESP32 is still powered during sleep and according its documentation the RTC can continue to function. It is only hard rest to 0 by some firmware ...
That is the whole ID about a RTC, that it continues to work at sleep.I believe you missed the point: the ESP32 is no longer powered during Pysense-controlled Deep Sleep. As in completely switched off. Not connected to any power source. Taking the *Py module out of its socket would give the same result. So nothing on the ESP32 runs, nothing at all, including the RTC.
What you are referring to is ESP32 Deep Sleep, which is what you would get using
machine.deepsleep
, but that’s very different from Pysense-controlled Deep Sleep.Oh, ok.
Nothing documented, useless.I am done with the Pycom for any application which needs to go to sleep.
It can not even write to files reliable when using sleep.
We solved the RTC issue with an external RTC. We got it more enough working for our application, including writing files. Not to the extend really required, but for now good enough. It took us ages to get it at that level. It works but we have no idea why. In a better structured version, made to be able to improve the functionality, it does not work. We seem to have been just lucky we got it working is some form. But improving and extending its functionality is impossible.Pycom a nice concept but does not live up to its promises.
-
@PeterB said in Deepsleep on the pysense is a complete disaster:
@jcaron said in Deepsleep on the pysense is a complete disaster:
@PeterB Pysense-controlled deep sleep completely cuts the power to the whole *Py module.
Not fully as e.g. the accelerometer can be working wihich is needed in my case
I’m talking about the *Py module (WiPy, LoPy, FiPy...). That module is completely powered down during Pysense-controlled deep sleep. Sensors on the Pysense are indeed a different matter.
It is quite normal that the RTC is reset, as it's no longer powered during deep sleep.
Ruunng on battery the ESP32 is still powered during sleep and according its documentation the RTC can continue to function. It is only hard rest to 0 by some firmware ...
That is the whole ID about a RTC, that it continues to work at sleep.I believe you missed the point: the ESP32 is no longer powered during Pysense-controlled Deep Sleep. As in completely switched off. Not connected to any power source. Taking the *Py module out of its socket would give the same result. So nothing on the ESP32 runs, nothing at all, including the RTC.
What you are referring to is ESP32 Deep Sleep, which is what you would get using
machine.deepsleep
, but that’s very different from Pysense-controlled Deep Sleep.
-
@crumble said in Deepsleep on the pysense is a complete disaster:
@PeterB said in Deepsleep on the pysense is a complete disaster:
You are using a lot of with statements. So you do not have controll when a file closed. Better you use the explicit way to close them. Additionally you save some heap.
If you are running you logger in a different thread, you need locks to synchronize it.
Even if I add file.flush() and file.close() explicitely it does not work.
-
@PeterB said in Deepsleep on the pysense is a complete disaster:
You are using a lot of with statements. So you do not have controll when a file closed. Better you use the explicit way to close them. Additionally you save some heap.
If you are running you logger in a different thread, you need locks to synchronize it.
-
@jcaron said in Deepsleep on the pysense is a complete disaster:
It may be a good idea to add a short
sleep
before it if there is anything that could still be pending when you go to sleep.Yeah, but there is a big difference in the way people think. If pycom offers a high level language, I expect to use high level methods when using only theire hardware. It is not easy to find all the small waits. My code is full of sleep statements because of the broken ESP32/IDF.
If they do not have the manpower for it, they shall write it into teh documentation where we have to be careful. Its getting better with newer IDF versions, but I miss clear information in the documentation. Especially when most of the problems can be blamed on the ESP. Even a "will not be fixed" can be helpful. So we know that waiting will not help and we have to develop workarounds. INTEL and MS still exists even if they have a lot of the "won't be fixed" issues
-
@jcaron said in Deepsleep on the pysense is a complete disaster:
@PeterB Pysense-controlled deep sleep completely cuts the power to the whole *Py module.
Not fully as e.g. the accelerometer can be working wihich is needed in my case
It may be a good idea to add a short
sleep
before it if there is anything that could still be pending when you go to sleep.Done it, even 5 seconds does not help. Expicitely closed files, flushed them. NOTHING helps.
It is quite normal that the RTC is reset, as it's no longer powered during deep sleep.
Ruunng on battery the ESP32 is still powered during sleep and according its documentation the RTC can continue to function. It is only hard rest to 0 by some firmware ...
That is the whole ID about a RTC, that it continues to work at sleep.If you want to maintain the RTC active you'll have to use the module's native deep sleep (
machine.deepsleep
) instead. But you would probably have to do more stuff to minimise the Pysense's current draw during sleep in that case.But reading the forum and some initial tries machine.deepsleep has a lot of other issues.
-
@PeterB said in Deepsleep on the pysense is a complete disaster:
Deepsleep on the pysense is a complete disaster:
- Writing to files before going to sleep does not work as expected. Sometimes it does, sometimes it does not, more not.
Deepsleep cuts the power to the ESP. So you have to ensure the files are closed before you sent the device to deepsleep.
As wel you have to use the latest IDF 'cause the ESP32 has too much problems, which are fixed by the underlying OS and Frameworks.
- RTC is reset to 0 when waking up, who made that stupid decision?
Espressif who build the SoC. If you need the RTC, add an external or use the normal sleep mode.
- Based on the number of questions on the forum it is completley unclear how to minimise power consumption and to which extend.
Yes, documentation needs links to the hardware. And better out of the box libs. But they have the same problem as we. The ESP32.
I would like to see them more focused on the existing hardware than developing new one. They are too small to dance on that many parties. I hope that they slow down when this router stuff is on the market.
-
@PeterB Pysense-controlled deep sleep completely cuts the power to the whole *Py module.
It may be a good idea to add a short
sleep
before it if there is anything that could still be pending when you go to sleep.It is quite normal that the RTC is reset, as it's no longer powered during deep sleep.
If you want to maintain the RTC active you'll have to use the module's native deep sleep (
machine.deepsleep
) instead. But you would probably have to do more stuff to minimise the Pysense's current draw during sleep in that case.Using Pysense-controlled deep sleep it is definitely possible to achieve a current draw in the 10-20 µA range. Things may be quite different if you keep any of the sensors running though.
But I do agree that the whole thing lacks clear documentation.