I implemented the pause/resume feature on a different branch (and only for the esp32) and did test it with the esp32 mainline. Worked well in my short test. You'd have to test it for yourself with the lobo fork and in full use: https://github.com/kevinkk525/micropyth ... use_resume

It also deactivates the wifi completely to save the max amount of power.

I was able test the pause/resume enhancement today on my custom Lobo fork. It works really well - I ran a 3 hour test and every MQTT publish @2min interval was received by the broker.

Results - current measurements

WiFi continuously on: current fluctuates between 65mA RMS and 120mA RMS (mostly in the 65mA to 70mA range)
Oscilloscope measurements show regular current spikes to 600mA peak (no scope images to show - forum has reached quota of attachments)

WiFi paused: current is stable at 47mA RMS.

Clearly, this is a big improvement - using this new feature should allow the battery life to be extended by a minimum of 25%.

Definitely. I reviewed his work extensively. His I2S implementation was definitely more ambitious than mine. I only implemented master I2S, no slave. I tried to pattern the I2S uPy API arguments and methods using the I2S API that he defined (with the hope that we can find a common I2S abstraction between the PyBoard(s) and ESP32).

I was able test the pause/resume enhancement today on my custom Lobo fork. It works really well - I ran a 3 hour test and every MQTT publish @2min interval was received by the broker.

Results - current measurements

WiFi continuously on: current fluctuates between 65mA RMS and 120mA RMS (mostly in the 65mA to 70mA range)
Oscilloscope measurements show regular current spikes to 600mA peak (no scope images to show - forum has reached quota of attachments)

WiFi paused: current is stable at 47mA RMS.

Clearly, this is a big improvement - using this new feature should allow the battery life to be extended by a minimum of 25%.

A huge thanks for developing this capability!

I'm glad to hear that! Those numbers look interesting.

@pythoncoder Is that a feature you'd consider adding to the mqtt_as library as well as micropython_iot? It's certainly a feature that has to be used carefully as the publish coro would "block" the calling coro until the wifi is resumed and if that calling coro publishes in separate tasks the uasyncio loop could overflow.
This would certainly prove useful to many battery powered applications.

I have pushed an update to asynchronous MQTT which works on ESP8266, ESP32 and Pyboard D.

My first port of call on power reduction is to use the Pyboard D with my low power version of uasyncio. This should retain resilience. Power consumption figures will depend on the performance of the WiFi chip but, based on measurements with Pyboard 1.x and comments from Damien about Pyboard D performance, I'm hoping for figures in single digits of mA.

Definitely. I reviewed his work extensively. His I2S implementation was definitely more ambitious than mine. I only implemented master I2S, no slave. I tried to pattern the I2S uPy API arguments and methods using the I2S API that he defined (with the hope that we can find a common I2S abstraction between the PyBoard(s) and ESP32).

Hello Mike!
I'm very excited to see that you are picking this up. I regretted not being able to see this through to where it could become part of the main branch. But in order for my approach to work it would have required scheduling capabilities that just weren't available at the time, and once I lost the momentum I haven't managed to pick it back up again.
I would be happy to discuss more about my approach and the challenges; feel free to send a PM if you are interested.

You might also be interested in an I2S audio daughterboard that I developed for the pyboard; I used it for a lot of my development and also sent out some samples to some of the more active MicroPython developers at the time. (@pythoncoder was one of the lucky recipients.) I need to dig into a couple boxes; if I can find one to spare I would be happy to send it to you if you would find it helpful.

I have gotten that impression, though I have not had a chance to dig in to see how it works and how I might be able to use it.

At this point, the biggest hurdle for me to revive my project is to figure out how to incorporate my 3.5-year-old work into the current code base so that I can start hacking on it again. I suspect that it won't be a simple rebase at this point

A better starting point might be to examine the API that Mike worked out for the ESP32. So far I've only had a quick look; it does look familiar though. He is using the machine module instead of pyb, which is probably the better way forward.

At that point, I could look at pulling in the underlying I2S engine. The important part that really didn't work before was that the file I/O to the SD card was happening in the ISR because I had no way to schedule that as a background task so I could exit the ISR. My understanding is that should be easier to do now.

@Mike Teachman - if you are going to jump on this, I would be happy to piggyback on your efforts and contribute as I can. I would much rather help to advance your project than have you hold back just because I happen to be interested again

To that end, I did find the box with my remaining I2S daughterboards; two were marked as having some problem or another, possibly repairable, at least three are likely functional, and 5 bare boards waiting to be assembled. (I could always make more or have someone else make them if there is sufficient interest.)

Followup on my last message - Mike, I see that you are going to be receiving a Pyboard D; at best you would need some kind of adapter to use my I2S daughterboard. Otherwise I can't say anything regarding compatibility, but it won't be plug-and-play like with the original pyboard.

Have the ISR call micropython.schedule() to run the I/O in normal context.

Use uasyncio.

Use threading.

I have written a tutorial on uasynciowhich may be found in this repo which you might find useful. I'm happy to offer any help I can. At the time I thought the problems you were getting were with C DMA programming and concluded it was too deep for me

If the audio I/O can be persuaded to use the stream protocol with an ioctl function the above repo has a fork of uasyncio which is capable of running stream I/O at a higher priority than other tasks.