Ok, that's the other issue: You would first create (and thereby start) the task to handle that websocket transfer. Then, when the request handler 'fires', you need to do two things: 1. get the file descriptor from the request and store it 'somewhere', and 2. tell the task that it can now fetch that ...

Another rabbit hole ? Nah, almost there ;-) Check the example . You can either use httpd_ws_send_frame() from inside the request-handling function, or, also inside the request handler, extract a file descriptor from the request which you can then store and use with httpd_ws_send_frame_async() later...

Yeah, my thought was that a lower max speed setting might potentially maintain the number of possible increments across the smaller speed range, resulting in smaller absolute increments of the actual speed. But maybe it just caps the speed at the lower value and does nothing else...

Who knew a clock could use an RTC, huh! :lol: ;-) Maybe @Espressif could consider providing a Vbat pin with automatic switch-over for retention power of RTC RAM and timer on future chips... (Potentially also enable the ULP to run uninterrupted via that supply, or even the option to wake-up the ULP ...

Maybe also an option:
"The DS1307 serial real-time clock (RTC) is a low- power, full binary-coded decimal (BCD) clock/calendar plus 56 bytes of NV SRAM."

Waking up the ULP by LP IO What exactly is that LP IO, isn't the interrupt already one of them? Yeah, GPIO, LP IO... ;-) I just meant ULP_LP_CORE_WAKEUP_SOURCE_LP_IO . How I understand it is the signal on the pin is one half of waking-up process, the other half is ULP listening for that trigger so ...

Given that the servo is a) a digital one and b) as a servo, made for position control rather than speed control, it may well be that you're out of luck trying to precisely manage the speed.

Have you tried programming the servo for a lower speed setting?

hours count (uint64)

Probably a waste of storage space as vacuum tubes and their enclosing universes tend to break down a lot earlier than 2^64 hours after first deployment

I don't now anything about the CNC controllers you use, but from what you say I'd guess: Old setup: x/y: 320 steps/mm * 1.8°/step = 576°/mm, i.e. 360°/576° = 0.625 mm/revolution (= 5/8 mm/rev) z: 400 steps/mm * 1.8°/step = 720°/mm, i.e. 360°/720° = 0.5 mm/revolution (=4/8 mm/rev) Now we need to know...

In my uri handler I am saving the request pointer (httpd_req_t*) to a global variable of the same type (httpd_req_t). Don't do that. The request data pointed to is only valid until the request handler returns. Check httpd_req_async_handler_begin() . The uri handler calls a task via xTaskNotifygive(...