nlsa
commented
5 years ago OK, I figured it out. [Background: I am porting the C++ MLX90640-library to C# on a Netduino]. It turns out that the Netduino.Foundation's I2CBus.WriteRead() has some sort of limited internal capacity. Even though it was doing the repeated Start condition, the returned byte array for the whole sub-page was 2/3 packed with invalid data. The rest was 0xFF. The sub-page data had values in every cell, not just odd or even, which led to my question above. The solution was to read in smaller chunks as nseidle has described in the Arduino port at https://github.com/sparkfun/SparkFun_MLX90640_Arduino_Example. Now each sub-page is returned in chess pattern as expected and the MLX90640 works like a champ.
I apologize for being thick, but could someone please tell me whether the following is correct? I think that a frame is the entire 32*24 field of pixels, and a sub-page (in Chess mode) is the "even" or "odd" pixels within the frame. The "even" or "odd" sub-pages are updated in RAM alternately. If I use MLX90640_GetFrameData() to read RAM, I get the whole frame (both sub-pages at once), correct? I understand that the pixels in the two sub-pages are calibrated separately and their pixel temperatures are calculated separately, too. BUT... The MLX90640 32x24 IR array Datasheet, Figure 7 "Recommended measurement flow" shows each each sub-page (sub-frame?) being read separately. Why would you do this if MLX90640_GetFrameData() returns the whole frame in one operation? Also, the example data spreadsheet includes two frames with 832 values in each. Are these supposed to be sub-pages or just two full example frames? Am I misunderstanding the nature of frames and sub-pages?