Firstly, thanks for putting this project together! I really appreciate having a working reference for the MI0802/ESP32-S3 combo, since its such a new product, so few examples out there.
I got the firmware building and streaming successfully on ESP-IDF v5.2.3 (board variant: Meridian ESP32S3 Mini / Octal PSRAM), but I'm seeing a persistent vertical column banding artifact in the thermal image that I haven't been able to resolve. Wondering if this is something you've seen or have advice on?
Here's what it looks like:
Fixed vertical stripes across the image, several columns wide, at irregular intervals
Confirmed not scene-dependent --> covering the lens completely with a uniform-temperature object didn't change the pattern at all
The stripe position/shape changes between power cycles, but stays consistent within a single boot session
The absolute temperature range reported also shifts noticeably between boots (e.g., 75–79°C vs. 43–48°C for the same room/objects, and is way hotter regardless than the actual room temp)
What I've ruled out:
Not the DMA descriptor type mismatch I noticed in Drv_SPI_DMA_Transmit/Drv_SPI_DMA_PrepDesc (lldesc_t vs. the IDF 5.2.x dma_descriptor_t have different bit-field layouts for eof/owner). That function turns out to be unused; the actual capture path uses Drv_SPI_Transmit() (direct-mode SPI, no DMA descriptors).
Lowering the SPI clock from 14MHz to 5MHz in Drv_SPI_SENXOR_Init doesn't help. It actually hangs SenXorLib's init entirely (watchdog resets in Initialize_Filter/register writes), so the library seems to have hardcoded timing assumptions tied to clock speed.
Adding a pull-down on the DATA_AV interrupt pin (Drv_Gpio_Init_DATA_IRQ) didn't fix it and introduced an unrelated stack overflow crash.
What looks like a promising but unconfirmed lead:
SenXorLib.h exposes FrameBuf_struct.StartOfFrame and extern uint32_t CapFirstByte, which look like they could be frame-alignment/validity signals, but I haven't confirmed whether Data_AV_FIFO_Int_Handler or anything else in the app layer actually checks them before treating a frame as valid.
Did you run into anything like this when you originally got your unit working? Any pointers on frame sync, calibration data application, or SenXorLib quirks would be a huge help. Happy to share full logs/photos if useful!
Firstly, thanks for putting this project together! I really appreciate having a working reference for the MI0802/ESP32-S3 combo, since its such a new product, so few examples out there.
I got the firmware building and streaming successfully on ESP-IDF v5.2.3 (board variant: Meridian ESP32S3 Mini / Octal PSRAM), but I'm seeing a persistent vertical column banding artifact in the thermal image that I haven't been able to resolve. Wondering if this is something you've seen or have advice on?
Here's what it looks like:
Fixed vertical stripes across the image, several columns wide, at irregular intervals
Confirmed not scene-dependent --> covering the lens completely with a uniform-temperature object didn't change the pattern at all
The stripe position/shape changes between power cycles, but stays consistent within a single boot session
The absolute temperature range reported also shifts noticeably between boots (e.g., 75–79°C vs. 43–48°C for the same room/objects, and is way hotter regardless than the actual room temp)
What I've ruled out:
Not the DMA descriptor type mismatch I noticed in Drv_SPI_DMA_Transmit/Drv_SPI_DMA_PrepDesc (lldesc_t vs. the IDF 5.2.x dma_descriptor_t have different bit-field layouts for eof/owner). That function turns out to be unused; the actual capture path uses Drv_SPI_Transmit() (direct-mode SPI, no DMA descriptors).
Lowering the SPI clock from 14MHz to 5MHz in Drv_SPI_SENXOR_Init doesn't help. It actually hangs SenXorLib's init entirely (watchdog resets in Initialize_Filter/register writes), so the library seems to have hardcoded timing assumptions tied to clock speed.
Adding a pull-down on the DATA_AV interrupt pin (Drv_Gpio_Init_DATA_IRQ) didn't fix it and introduced an unrelated stack overflow crash.
What looks like a promising but unconfirmed lead:
SenXorLib.h exposes FrameBuf_struct.StartOfFrame and extern uint32_t CapFirstByte, which look like they could be frame-alignment/validity signals, but I haven't confirmed whether Data_AV_FIFO_Int_Handler or anything else in the app layer actually checks them before treating a frame as valid.
Did you run into anything like this when you originally got your unit working? Any pointers on frame sync, calibration data application, or SenXorLib quirks would be a huge help. Happy to share full logs/photos if useful!