You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am giong to assume that the answer is "no" but here it goes.
On my MLX90640 I have mode set to MLX90640_CHESS, resolution set to MLX90640_ADC_18BIT, and refresh rate set to MLX90640_16_HZ. (Tried at 32 and 64, but there was just too much noise) The code I am calling is as follows:
Later I have dump this: gfx.prinf("Grab: %d, Calc: %d", grab_end_time - grab_start_time, calculate_start_time - calculate_end_time); to the LCD.
I consistently see the "Grab" clock in at 40-50ms, and the "Calc" as 8ms. I had assumed it was the "CalculateTo" that was the times sink, but after profiling I found it was the grab. Since 16hz would be closer to 60 I chalk that up to the inaccuracy of mills() on the ESP32 though. If I check the delta between calling the call to getFrame and drawing to the FB I get ~80-85ms 🤣. Anyway the data sheet seems to imply that it continuously read pages until will set the ready status every time a page is complete and ready to read. Does that mean the "first" frame will always be some random delay from 0-60ms depending on where the underlying ram is being populated? If this is the case what would happen if you read one page, then wander off do something else and then read the second page? I assume it will refresh the page in 60ms so you really don't want to miss that second page. Is this understanding correct? The reason I ask is that I am using this along with an ESPcam. Alone it can display at a good 10-12FPS on the LCD, but add in 60ms * 2 and its not pretty.
The text was updated successfully, but these errors were encountered:
I am giong to assume that the answer is "no" but here it goes.
On my MLX90640 I have mode set to
MLX90640_CHESS
, resolution set toMLX90640_ADC_18BIT
, and refresh rate set toMLX90640_16_HZ
. (Tried at 32 and 64, but there was just too much noise) The code I am calling is as follows:Later I have dump this:
gfx.prinf("Grab: %d, Calc: %d", grab_end_time - grab_start_time, calculate_start_time - calculate_end_time);
to the LCD.I consistently see the "Grab" clock in at 40-50ms, and the "Calc" as 8ms. I had assumed it was the "CalculateTo" that was the times sink, but after profiling I found it was the grab. Since 16hz would be closer to 60 I chalk that up to the inaccuracy of
mills()
on the ESP32 though. If I check the delta between calling the call togetFrame
and drawing to the FB I get ~80-85ms 🤣. Anyway the data sheet seems to imply that it continuously read pages until will set the ready status every time a page is complete and ready to read. Does that mean the "first" frame will always be some random delay from 0-60ms depending on where the underlying ram is being populated? If this is the case what would happen if you read one page, then wander off do something else and then read the second page? I assume it will refresh the page in 60ms so you really don't want to miss that second page. Is this understanding correct? The reason I ask is that I am using this along with an ESPcam. Alone it can display at a good 10-12FPS on the LCD, but add in 60ms * 2 and its not pretty.The text was updated successfully, but these errors were encountered: