Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a "valid way" to speed up MLX90640_GetFrameData #115

Open
geiseri opened this issue Mar 8, 2024 · 0 comments
Open

Is there a "valid way" to speed up MLX90640_GetFrameData #115

geiseri opened this issue Mar 8, 2024 · 0 comments

Comments

@geiseri
Copy link

geiseri commented Mar 8, 2024

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:

int getFrame(float *framebuf)
  float emissivity = 0.95;
  uint16_t mlx90640Frame[834];
  int status;
  for (uint8_t page = 0; page < 2; page++) {
     grab_start_time = millis();
     status = MLX90640_GetFrameData(0, mlx90640Frame);
     grab_end_time = millis();

     if (status < 0) {
       return status;
     }

     float tr = MLX90640_GetTa(mlx90640Frame, &_params) - 8;
     calculate_start_time = millis();
     MLX90640_CalculateTo(mlx90640Frame, &_params, emissivity, tr, framebuf);
     calculate_end_time = millis();
  }
  return 0;

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant