Best posts made by basgoossen

Yes, it worked ;-). I locked myself up in the office for the last 48 hours. And rewrote AsyncWebserver but using Ethernet.h instead of LWiP. All features of AsyncWebserver are available, the only thing you need to take care of is the periodic upkeep (a single line of code in the main loop).
I also added an updater for the internal ESP clock (separate) to update over NTP via Ethernet.h.

All in all it took the most out of the past 48 hours but for me it was very worthwhile. Consumed progmem is less than half of what is was (total program went down from 1.1MB to 604kB). Static ram usage went down from (critical 90%) to a comfortable 35%. Dynamic Ram usage decreased by a 40%. All of this is probably mostly due to the fact that we can rely on the W5500's internal IP stack instead of LWiP.

Another gain for me is that the periodic upkeep is very predictible, making my main control loop (which also runs RS485) more stable and very predictible. Loop time is now (very) stable at under a ms. Wheres with LWiP it would vary a lot under network load. As an embedded system engineer (by background) this is one of the things that pleases me the most. I can serve a 60MB file or even upload a large file (limited only by storage) to the system without noticable impact on the main process.

Performance wise it seems to be a tad slower for now than LWiP over WiFi with AsyncWebserver. Serving the webui of around 3MB takes about a second longer at roughly 4 seconds to fully load. But there is plenty room for optimization as i now only use a single socket buffer of 2048kB in the w5500 at a time. So there is about 8 times as much performance available.

I'll most likely make a Github page for this if there is any interest from the community. For now i'm going to have a good sleep 😉👍

PPG is pretty finicky and the signal more often than not requires cleanup by software algorithms. Double readings are not uncommon and appear even in medical grade sensors. Most sensors used nowadays have multiple emittors or a single emittor with multiple sensors. The "evaluation sensor" with one led and one sensor used for this device will indeed require very precise and stable placement. Even so i'd recommend trying to get the raw signal out of the sensor if possible at 24-40hz (24 and 40hz are commonly used for PPG processing algorithms and usually a good place to start from). working with and visualising the raw signals will give you a much better insight of what you're measuring.

Current supplyed by the Core2 is not gona be a limiting factor in this. Noise of the voltage convertor could cause issues, but this can only be checked if the raw signal is analysed. Often sensors make use of motion sensors to discard readings during detected motion.

I also had some issues with the M5Stack basic and SD cards. I was unable to read 9 out of 10 cards. In the end i ended up slowing down the SD card clock from 40Mhz to 10Mhz, this solved all the read issues for me. You can achieve this by editing the M5Stack.cpp file, in the function M5Stack begin SD is enabled using the following function:

// TF Card
if (SDEnable == true) {
    SD.begin(TFCARD_CS_PIN, SPI, 40000000);
}

I changed this to:

// TF Card
if (SDEnable == true) {
    SD.begin(TFCARD_CS_PIN, SPI, 10000000);
}

Since than i have had no more troubles reading from and writing to the SD card.