Generate pwm signals

[Toff]

Hi,

Anyone knows how to generate 12 to 16 pwm signals with the same base frequency around 100kHz (PMIC), but with different duty cycles and phase shifts?

If you're interersted in why I think I need it, just ask. I started writing, but it became a bit long and maybe it will get you bored, so I'm starting with this short version first. 

Thanks,
Toff

[pigrew]

I'm always curious about what other's projects are, so do explain.

I've been trying to do very high-resolution PWM with the STM32F334 micro, and it hasn't worked out that well for me (due to somewhat high jitter), but my guess is that your application doesn't need ultra-low jitter. This micro's HRPWM1 has 10 outputs, which I believe can be set to trigger at arbitrary points in the 16-bit clock, so you can get your phase shift and duty cycle.

As for the other timers, you'd have to use the other PWM resources on the chip, and start the various timers synchronously. You should be able to get up to your count of 12. If some signals are inverses of eachother, or you are using centered PWM, then you have a bit more freedom in choice of micro.

In my project, I'm ending up using an FPGA which could support a few dozen outputs, but is much more difficult to implement.

A perhaps better (but more expensive) option would be the TI C2000 micros. If you look at TI's list of Piccolo MCUs, there are many shown as having >12 channels of PWM. The TMS320F28069M is one example, but I expect there would be a much better choiceof Piccolo.

EDIT: There is a Stack  Overflow article with many other suggestions.

EDIT2: The TMS32F280049 launchpad probably can do everything you need, and since it's a dev board, you could try it out with minimal investment of hardware development time.

-Nathan

[PCB.Wiz]

Anyone knows how to generate 12 to 16 pwm signals with the same base frequency around 100kHz (PMIC), but with different duty cycles and phase shifts?

Can you explain phase shifts ?? That's not usually a feature in PWMs, at least not fully variable phase.

You also need to include the expected resolution.
eg the simplest PWMs are counter+compare, and a (say) 32MHz clock gives 320 steps at 100kHz.
To get more resolution, some MCUs bump that MHz and/or use delay lines, and some dither a LSB, so they can average.

There are standard LED peripherals that include many channels of PWM (but I think not user-defined phase shift) 
- eg PCA9635  specs a 25MHz Clk, and 97kHz 256 step PWM - but no phase.

Addit: I find a  PCA9685, which has ON and OFF times control so claims any phase (not clear how that locks during live changes ?), and can have 25MHz int or 50Mhz ext clock.
So you could get to 500 steps of any-phase pwm at 100kHz with a 50MHz clock  (or 9 bits and 51.2MHz)
The ISL97671A also mentions phase, but that may be one register for equal-steps-skews ?


If you really need phase, you might need to use a small FPGA like Lattice iCE40

[NorthGuy]

The most straightforward is to use MCU with several PWM outputs. For example, PIC16F1779 has 8 PWM modules. If you take two MCUs and clock them externally from a common source, they're easy to synchronize and get 16 PWM signals. If you need complimentary PWM, there are MCUs which can generate complementary PWM signals, thus you'll need less PWM modules.

Another option is to use CPLD or FPGA which can give you lots of PWM outputs. They're very easy to synchronize and program with great precision, but they're more expensive.

[Sal Ammoniac]

Can you explain phase shifts ?? That's not usually a feature in PWMs, at least not fully variable phase.

Phase shifts, in the context of PWM, usually refers to what's known as asymmetric PWM.

Consider PWM implemented as center-aligned using a counter that counts up and counts down, with a compare register that turns the output port on and off when the counter matches the compare register both when counting up and when counting down. That's the normal case--consider that to be a phase shift of zero. Now if the PWM circuit supports two separate compare registers, one for when the counter is counting up and another for when it's counting down, generating phase shifts is as simple as setting the two compare registers to different values. If you want to shift the phase so the PWM HIGH output occurs earlier (with respect to the zero phase timing, and without changing the duty cycle), subtract an offset from the "counting up" and add it to the "counting down" compare registers. To shift the phase to a later time offset, add the offset to the counting up compare register and subtract it from the counting down compare register.

[Toff]

While trying to post I got the error that 'the message body was left empty'. Seems like it is too long indeed... I'll try splitting it up then.

Already thanks for the great replies! Its was my first post, didn't know what to expect, long time follower though. The replies already contain a lot of interesting info which I gladly digest. And apparently the long version is welcome, so hold on and read on if you like.

But first, with phase shifted pwm I try to specify different pwm signals with the same base frequency that have, beside different duty cycles, also different timings on when the rising edge occurs wrt each other signal. For my application it would be needed to adjust the duty cycles as well as the phase shifts. What I certainly want to try is the following analogy: its like opening a door and allowing flow, then switching doors to continue the flow from another reservoir while riding on inductance. Jitter I assume is not that important as mentioned by Nathan, think normal requirements are ok here. Hope that's more clear.

Here it goes:

For an IOT project I'm looking at solar energy capture and ultracap storage. With the solar I hope to be able to set it once and enjoy the data coming in, and also making something self sustainable feels good. 🙂 Already running a solar powered DS18B20 on ESP8266 with FOTA, connected to a RPi with Node-Red, Influx db and Grafana. Thanks to the great work of other people. If the node is placed near the window, it easily survives a cloudy day with just the solar cell directly connected to the ultracap. However, the temperature is sometimes quite a bit off from central in the room and fluctuates quite a lot with me opening and closing the curtains... Not ideal... Putting the sensor further back in the room significantly reduces the captured energy, surviving just a couple of sunny days, not recharging enough to keep on going. Hence a more effective / efficient way is needed or just bigger solar cells of coarse... but, although minimal, I like some aesthetics. And I suspect that there is quite some loss due to not working near the MPPT point. The working point might have been ok near the window with lots of light, or just enough light by itself. The conditions 1 meter further back in the room are apparently already that different.

To go further and improve the power supply part, I've looked for energy harvesting ic's and found some interesting things like ADP5091 but those do not fulfill my requirements. I'd like it to be able to do cold startup, MPPT, providing the captured power first to the attached microcontroller instead of having to wait for a charged ultracap up to Vccmin. And also use the energy stored in the ultracap below Vccmin of the micro to get through the night. This is important as ultracaps with a voltage higher than 3V become expensive and  scarce, according to my searches at least. So low voltage storage in the range of 2.3-2.7V seems the way to go and hence a lot or all of the stored energy is in the part below Vccmin of the ESP8266. Up to now I didn't find a solution that ticks those boxes. Anyone knows such a solution?

...

[Toff]

...

Based on what I learned in searching for the right parts and putting things together, I started playing around with mosfets, inductors and capacitors themselves to conceptually build something. I thought of many setups like solar - boost - ultracap - boost - µc setup with a bypass over the ultracap etc etc. After some shetching and reoganizing, something came up that might do the trick. I choose to minimize the amount of bulky components like inductors (using just one) and use mosfets instead to route the energy flows around, so there are a couple of those in use as HSPDS (high side power distribution switches).

Being curious if it could work, the search shifted to find a way to drive the mosfets. The thing is that there are quite some, minimum 10, preferable 12, 16 would give some breathing space for expansion would that be needed. Almost all of them must be able to do PWM, however not all at the same time. I think 3, maybe 4 would be enough. And between the active PWM signals, different duty cycle and phase shifting is needed.

As I know a thing or 2 about AVR microcontrollers, I started looking at GPIO PWM expanders like the interesting PCA9685. Its output frequency is limited to 1526Kz, making it useless for this application. Inline edit: PCB.Wiz mentions higher output freq, so I will definitely have another look there. As already partly replied, other expanders (mostly LED drivers) seem to only have open drain outputs, which probably would require an additional mosfet driver to be able to switch fast enough while keeping quiescent current low, and don't have to phase shift the PWM signals eather.

Don't know much about FPGA's, but I think I might have to look there to have the needed flexibility. Before jet another deep dive in searching, I thought it might be a good thing just asking. If FPGA's are a good choise, which I don't know at the moment, maybe some advise on where to start with them?

Ah, btw also wanting some ADC's of coarse, think 8 will be ok I hope. That's unfortunately no feature creep... just me being a bit (too?) focused on the driving part... Its for measuring the internal voltages and some currents. Guessing 10bit should be ok. Sure there will be some additional requirements, but don't know those at the moment.

As already mentioned, thanks for the replies, need to have a siesta and digest the info. 

[PCB.Wiz]

I started looking at GPIO PWM expanders like the interesting PCA9685. Its output frequency is limited to 1526Kz, making it useless for this application. Inline edit: PCB.Wiz mentions higher output freq, so I will definitely have another look there. As already partly replied, other expanders (mostly LED drivers) seem to only have open drain outputs, which probably would require an additional mosfet driver to be able to switch fast enough while keeping quiescent current low, and don't have to phase shift the PWM signals eather.

Yes, reading that data further, where they say ON and OFF times, have separate registers, they actually mean way-points, not duration.
The PWM rate is fixed at /4096, and cannot be modified, to highest is 50M/4096.
 

Being curious if it could work, the search shifted to find a way to drive the mosfets. The thing is that there are quite some, minimum 10, preferable 12, 16 would give some breathing space for expansion would that be needed. Almost all of them must be able to do PWM, however not all at the same time. I think 3, maybe 4 would be enough. And between the active PWM signals, different duty cycle and phase shifting is needed.

I do not see a compelling need here for completely random phase, if your problem here is solar energy conversion, you might prefer to find SMPS switching modules/ICs that are very efficient, and then controlling those with a MCU with ADC/DAC's. Such an approach is more scalable too.

What powers do you target ? - I think not much, from energy harvesting comments ?

If you are working at many-amps, then it can help to have phases aligned to (appx) match the voltage division. eg a 50% nom operating point, has 2 x 180' PWMs, and a 33% nominal operating point, might have 3 PWMs at 120' each. This mostly lowers the RMS ripple current rating of the power supply caps, FETS do not care so much about phase.

 

[Toff]

I started looking at GPIO PWM expanders like the interesting PCA9685. Its output frequency is limited to 1526Kz, making it useless for this application. Inline edit: PCB.Wiz mentions higher output freq, so I will definitely have another look there. As already partly replied, other expanders (mostly LED drivers) seem to only have open drain outputs, which probably would require an additional mosfet driver to be able to switch fast enough while keeping quiescent current low, and don't have to phase shift the PWM signals eather.

Yes, reading that data further, where they say ON and OFF times, have separate registers, they actually mean way-points, not duration.
The PWM rate is fixed at /4096, and cannot be modified, to highest is 50M/4096.

The ON/OFF toggle times of the PCA9685 seem exactly what I need! I'll stitch it together in sw. Unfortunately I stopped looking at it while seeing the 1526Hz limit. Thanks for pointing that out!

The frequency is the issue then. However, I can already start, its just bigger filter components for now then. Probably also works better with my 200Mhz scope...

Being curious if it could work, the search shifted to find a way to drive the mosfets. The thing is that there are quite some, minimum 10, preferable 12, 16 would give some breathing space for expansion would that be needed. Almost all of them must be able to do PWM, however not all at the same time. I think 3, maybe 4 would be enough. And between the active PWM signals, different duty cycle and phase shifting is needed.

I do not see a compelling need here for completely random phase, if your problem here is solar energy conversion, you might prefer to find SMPS switching modules/ICs that are very efficient, and then controlling those with a MCU with ADC/DAC's. Such an approach is more scalable too.

What powers do you target ? - I think not much, from energy harvesting comments ?

If you are working at many-amps, then it can help to have phases aligned to (appx) match the voltage division. eg a 50% nom operating point, has 2 x 180' PWMs, and a 33% nominal operating point, might have 3 PWMs at 120' each. This mostly lowers the RMS ripple current rating of the power supply caps, FETS do not care so much about phase.

Completely random phase probably it is not. However I can't say at the moment what exactly makes it work nicely instead. Need to test that and hence want to be able to have some flexibility. I could simulate so some cases to know a bit more. But its quite a bit of work.

About the efficiency of existing solutions of you're definitely right, and I have been thinking a lot of that too, I must have no hopes in matching that any time soon, interesting stuff that is being used. Knowing that, I actually often tried to go back to standard solutions. But I keep bumping into the problem that I can't do everything I want, sometimes it is close though. Issue for me is the routing of the energy to the places I want and hence significantly improving uptime.

Then its a tradeoff between an ineffective but efficient combination of existing solutions, not doing completely what I want or being overly complex versus trying to build something effective, less efficient myself.

At the moment using an ESP8266 and some sensors, the power requirements are low (average in the orde of 1mA, max 300mA) and scalable by adjusting the deepsleep time, depending on the available power, its not that strict. Although, as mentioned, some regular harvesting is welcome.

[NorthGuy]

What are the characteristics of your solar panel (open circuit voltage and short circuit current, both measured in full light)? Do you only need power for MCU/Sensors?

Note: I assume your panel is very small. If not, do not measure short circuit current until you read and understand how to do this without hurting yourself.

[tautech]

This project sourcing energy from a PV and charging a cap does not need to be hard or complex as it can be done with 4000 series IC's and some careful component selection to get the most efficient operation.

I looked at this for a PV powered project a few years back using a 150mm² 6V 100mA PV to charge a 2200uF 200V cap to 150V which when optimized it could do in just a few seconds in full sunlight.
We used the lowest leakage cap we could find and it could hold 100+V overnight.

The charge pump was optimized for a specific switching ON time and the frequency of which was varied to use all power available.
A 4047 provided the constant width pulses and the VCO in a 4046 controlled the frequency of such.

4 active blocks was the whole circuit, VCO,  Monostable, Mosfet driver and Charge pump.
With only 100mA from the PV available we wasted excess energy through 2 HV zeners and including them the circuit was only 16 parts, the 200V cap being the largest by far.

[Sal Ammoniac]

Don't know much about FPGA's, but I think I might have to look there to have the needed flexibility. Before jet another deep dive in searching, I thought it might be a good thing just asking. If FPGA's are a good choise, which I don't know at the moment, maybe some advise on where to start with them?

FPGAs generally have lots of I/O, so generating 12-16 PWMs (or even 100) would be a relatively trivial task for an FPGA.

FPGAs, if you've never used them, can have a steep learning curve, especially if you're a software guy (software guys typically have difficulty getting their heads around the idea that everything happens at once in an FPGA--there's no "processor" sequentially executing instructions one after another). PWM generation is very simple to do in an FPGA--just a little more difficult than blinking an LED-- and once you create a PWM module in Verilog or VHDL, you can instantiate as many copies as you need for your application.

[PCB.Wiz]

...
At the moment using an ESP8266 and some sensors, the power requirements are low (average in the orde of 1mA, max 300mA) and scalable by adjusting the deepsleep time, depending on the available power, its not that strict. Although, as mentioned, some regular harvesting is welcome.

1mA is probably viable with charge pumps, 300mA less so.
Inductors have the advantage of higher efficiency, and wider operating ranges, and a smaller BOM.

So you need to nail down exactly what solar cell(s) you will use, and then push up the deep sleep time and lower the on time as much as possible.
If you use ESP8266, then maybe another micro-power MCU can manage deep sleep and collect some data, prior to sending.

RF MCUs advance all the time, so you should also look at the leading edge.
There are more wireless MCUs coming out, and some are targeting solar-energy levels.
Here is an example,
https://iot.eetimes.com/battery-less-iot-could-soon-be-a-reality-with-bluetooth-multi-sensor-platform/

[CM800]

An FPGA or CPLD is a great option. I feel people over exaggerate their difficulty.

You could go with one of the low cost lattice units. IMHO it's a good direction to go in, and won't let you down.

[Toff]

What are the characteristics of your solar panel (open circuit voltage and short circuit current, both measured in full light)? Do you only need power for MCU/Sensors?

Note: I assume your panel is very small. If not, do not measure short circuit current until you read and understand how to do this without hurting yourself.

Just to be able to charge the ultracap directly, I'm now using an SCC3733 cell, spec sheet:
https://cdn.solarbotics.com/products/datasheets/scc3733.pdf
Voc = 6.7V, Isc = 20mA
Choose this to have a bit of charging during overcast conditions.

For the setup I have in mind, the working point is not critical, maybe except for the startup oscillator.

Power is for MCU, sensors and mostly communication. Establishing the connection is the big consumer, see attachment. It lists the total wake time of the ESP when communicating. Its already much improved by only communicating when there is something useful to report and by storing the Wifi channel, ssid, ip, gateway and subnet on the ESP8266 itself (thanks to www.bakke.online) if a working connection was established (difference between 'New conn' and 'Mem conn' in figure). Checking for firmware updates also takes a bit of time as it at this moment still often fails to get the version from the server 'FW ver fail', but is only done when there is enough charge.

[Toff]

FPGAs generally have lots of I/O, so generating 12-16 PWMs (or even 100) would be a relatively trivial task for an FPGA.

FPGAs, if you've never used them, can have a steep learning curve, especially if you're a software guy (software guys typically have difficulty getting their heads around the idea that everything happens at once in an FPGA--there's no "processor" sequentially executing instructions one after another). PWM generation is very simple to do in an FPGA--just a little more difficult than blinking an LED-- and once you create a PWM module in Verilog or VHDL, you can instantiate as many copies as you need for your application.

Thanks for the info!
Is there an Arduino equivalent in the FPGA world to get started?

Love your comment about the sw guys, counting me as one of them. Also like hw btw. Thats what I love about embedded, its a whole package to work on.

[Sal Ammoniac]

Is there an Arduino equivalent in the FPGA world to get started?

Probably the closest thing to an Arduino equivalent in the FPGA world is the Digilent boards (Xilinx) or Terasic boards (Altera/Intel). Boards from these two companies are widely used in university courses on FPGAs.  I've never used Lattice or Microsemi, so have no experience with their FPGAs.

https://store.digilentinc.com/fpga-development-boards-kits-from-digilent/
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=163

[Toff]

...
At the moment using an ESP8266 and some sensors, the power requirements are low (average in the orde of 1mA, max 300mA) and scalable by adjusting the deepsleep time, depending on the available power, its not that strict. Although, as mentioned, some regular harvesting is welcome.

1mA is probably viable with charge pumps, 300mA less so.
Inductors have the advantage of higher efficiency, and wider operating ranges, and a smaller BOM.

So you need to nail down exactly what solar cell(s) you will use, and then push up the deep sleep time and lower the on time as much as possible.
If you use ESP8266, then maybe another micro-power MCU can manage deep sleep and collect some data, prior to sending.

RF MCUs advance all the time, so you should also look at the leading edge.
There are more wireless MCUs coming out, and some are targeting solar-energy levels.
Here is an example,
https://iot.eetimes.com/battery-less-iot-could-soon-be-a-reality-with-bluetooth-multi-sensor-platform/

Again, thanks for the info!

Currently the ESP8266 is waking up periodically. Based on the measured Vcc voltage = ultracap voltage, the deep sleep period is adjusted to cope with low power conditions and also to 'dissipate' power is the 3V ultracap is nearly full.

Already done some reduction of wake times by storing the OneWire sensor adress in RAM of the ESP. This clearly speeds up things (difference between searchOW & measOW in attached figure). Then the ESP goes back to sleep for 1s to allow the DS18B20 to do its work. After waking the temperature is read in and compared to the previously send temperature. If there is a significant differenct, now at 0.25°C, a now value is communicated to the server (see other figure for communication times), else there is nothing to report, ntr in the figure.

[NorthGuy]

I think it's much simpler.

To get the most energy, you must keep the panel voltage at MPPT, which is about 5.2 V. Your MCU/Supercap is below this. S, you need a buck converter.

Input capacitor. FET. Comparator driving FET.

Panel voltage gets too high -> FET turns on and puts a load on the panel -> input cap dischardges -> voltage drops.

Panel voltage gets too low -> FET turns off and removes load -> panel charges input cap -> voltage increases.

After the FET - inductor, diode and your supercap as an output cap (google buck converter for the schematics). Safety switch to prevent overvoltage on the supercap.

That's all you need to harvest the most energy.

Use low power/low voltage MCU which can stand a range of voltages below supercap max voltage (say 1.8 to 3.3V). Feed it from supercap without regulator. Make sure it has BOR protection. Let it collect data while powered.

As supercap voltage gets close to max voltage - power up your WiFi module and transmit. As supercap discharges, stop the transmission and let it charge back.

[PCB.Wiz]

Is there an Arduino equivalent in the FPGA world to get started?

This is a good example, of the lower pin count, lower power FPGAs
http://www.latticesemi.com/Products/DevelopmentBoardsAndKits/iCE40UltraPlusBreakoutBoard
Note these still do not compete with the lowest power MCUs so you have to have a problem that needs a FPGA.
Your current problem does not, but you could experiment using a FPGA, in a highly flexible manner.

[Toff]

I think it's much simpler.

To get the most energy, you must keep the panel voltage at MPPT, which is about 5.2 V. Your MCU/Supercap is below this. S, you need a buck converter.

Input capacitor. FET. Comparator driving FET.

Panel voltage gets too high -> FET turns on and puts a load on the panel -> input cap dischardges -> voltage drops.

Panel voltage gets too low -> FET turns off and removes load -> panel charges input cap -> voltage increases.

After the FET - inductor, diode and your supercap as an output cap (google buck converter for the schematics). Safety switch to prevent overvoltage on the supercap.

That's all you need to harvest the most energy.

Use low power/low voltage MCU which can stand a range of voltages below supercap max voltage (say 1.8 to 3.3V). Feed it from supercap without regulator. Make sure it has BOR protection. Let it collect data while powered.

As supercap voltage gets close to max voltage - power up your WiFi module and transmit. As supercap discharges, stop the transmission and let it charge back.

Thanks for the ideas. A MCU with good voltage range is indeed useful. Now working with the ESP8266 (Vccmin 2.5V, can go to 2.3V, but I suspect Wifi gets difficult then) and 3V ultracap, so it has 0.5V to play with. Hence there is quite some energy left in the unused 2.5V. A boost converter could use most of this. Then its already buck and boost configuration.

Also the MPPT of 5.2V shifts with lighting conditions. So the buck from the solar cell is preferably adjustable to survive typical Belgian cloudy days. Maybe even boost is needed, I'll check the Voc with low light conditions. Its all possible of coarse, but exactly that leads to my starting point of not being one solution / becoming bulky. Creating somethings that works is simple. Creating something that keeps working in difficult conditions is a challenge. 

[PCB.Wiz]

Also the MPPT of 5.2V shifts with lighting conditions. So the buck from the solar cell is preferably adjustable to survive typical Belgian cloudy days. Maybe even boost is needed, I'll check the Voc with low light conditions. Its all possible of coarse, but exactly that leads to my starting point of not being one solution / becoming bulky.

Parts like LTC3129 include MPPC, and target Solar cell operation, with single digit uA operating currents.
There are sub-uA SMPS parts, but they are rarer at 6.7V tolerant VIN.
Some designs use a nano-power Linear regulator, and a small (sub 1uA) wakeup MCU like EFM8SB1, that then enables the bigger processor, and its SMPS.

[NorthGuy]

Also the MPPT of 5.2V shifts with lighting conditions. So the buck from the solar cell is preferably adjustable to survive typical Belgian cloudy days. Maybe even boost is needed, I'll check the Voc with low light conditions. Its all possible of coarse, but exactly that leads to my starting point of not being one solution / becoming bulky. Creating somethings that works is simple. Creating something that keeps working in difficult conditions is a challenge. 

MPPT voltage changes very little with lighting conditions, at least in the range where you can produce something. It does change with temperature.

Day-to-day variations are huge. Say, my house panels could produce 35kWh in a sunny spring day, perhaps even more. But in a snowy winter day it may be as low as 300Wh. It's over 100 times difference. I have a weather station (built with two 2V AGM batteries, which IMHO better serves the purpose compared to supercaps). Everything is sized for the worst conditions, so in a good sunny day it only uses 0.5% of the energy that could have been produced. Thus, there was no point mingling with MPPT at all. Instead, I have built purely analog temperature adjusted (batteries need higher voltage when it's cold) charger - practically a single FET driven by a comparator. When it's cold in winter, the charging voltage goes over 5V putting it very close to MPPT. Other times, there are oceans of unused energy anyway. It worked quote well, about 7 years now, with temperatures from -47 to +39 C.

[Toff]

Also the MPPT of 5.2V shifts with lighting conditions. So the buck from the solar cell is preferably adjustable to survive typical Belgian cloudy days. Maybe even boost is needed, I'll check the Voc with low light conditions. Its all possible of coarse, but exactly that leads to my starting point of not being one solution / becoming bulky.

Parts like LTC3129 include MPPC, and target Solar cell operation, with single digit uA operating currents.
There are sub-uA SMPS parts, but they are rarer at 6.7V tolerant VIN.
Some designs use a nano-power Linear regulator, and a small (sub 1uA) wakeup MCU like EFM8SB1, that then enables the bigger processor, and its SMPS.

Thanks, the LTC3129 seems a good candidate to extract the energy from the solar cell. I also already found the LTC3105, BQ25505, BQ25570 and the ADP509x.

Thing is the ultracaps. Since their low capacity compared to batteries its useful/needed to extract most energy out of them without having to go too bulky. Indeed easier to switch to batteries. Might have to do that. Although, with moderate light conditions (near the window) things now already are working great without any SMPS and no maintenance what so ever seems needed. So I am curious if it can work 1m back in the room (as mentioned in the big description above) with a bit more clever harvesting than it has now. Think I downgrade my requirements for now and already start on the harvesting SMPS. Hope to report back on that soon.

[Toff]

MPPT voltage changes very little with lighting conditions, at least in the range where you can produce something. It does change with temperature.

Yep, my bad, you're right.
http://solarpowerplanetearth.com/solarpanels.html
http://solarbotics.net/starting/200202_solar_cells/200202_solar_cell_use.html

Did some measurements on the solar cell with low light conditions in which it needs to capture something it it wants to say alive. Getting following values of Voc & Isc, also estimated Pmppt = 70%*Voc*Isc, seems about right based on the links above.
3.8V - 132µA - 352µW
4V - 172µA - 483µW
4.2V - 217µA - 640µW
still a bit off from the mppt voltage, but maybe pushing the low light conditions further back in the room a bit too much then?! Although, the deepsleep power consumption of the ESP8266 is 20µA, a bit for the sensors, which would end up somewhere around 100µW. Should be enough too keep on going and sit out the bad times I hope.

Day-to-day variations are huge.

Thanks for sharing your experience. I also notice the huge variation in my home solar installation. EDIT: If interested I can share a nice graph of that. Hence, the code allows for quite a range of downscaling the current consumption with variable deepsleep time and disabling non urgent tasks etc, but sometimes something has to come in. If its pushing the limits too much I definitely learned a lot and I'll switch to batteries.