Closed nburnett closed 6 years ago
slavysis
commented
6 years ago Result -4 is a warning that there are more than 4 outlier pixels. This most likely indicates that the EEPROM dump is not correct. Did you verify the I2C communication?
Can you share some logs of the EEPROM data and the frame data?
Best regards
nburnett
commented
6 years ago Thanks for the prompt response!
So as for verifying I2C communication, I've verified I can use an i2c scanning sketch and can see a device at 0x33. Is there a specific way you'd like me to verify communication? I don't have much in the way hardware diagnostic tools.
For EEPROM Logs do you just need the values inside of eeMLX90640[832] after running:
static uint16_t eeMLX90640[832]; int status; status = MLX90640_DumpEE (0x33, eeMLX90640);
And for the frame data do you need the values inside of mlx90640Frame after running:
static uint16_t mlx90640Frame[834]; int status; status = MLX90640_GetFrameData (0x33, mlx90640Frame);
Is the output from a Serial.println of all those values enough or does it need to be in a specific format?
I see the excel sheet to compare the values but got confused after reading the comments in the first sheet about using the values on the sheet as an input. Is there another step where I have to set data on the sensor before using?
Again sorry for any super basic questions.
slavysis
commented
6 years ago Well, it would be nice to compare the data you read with some oscilloscope traces. If you do not have one, I think the dumped data might still be helpful. Indeed I need the data after _MLX90640DumpEE and the data after _MLX90640GetFrameData Please put some delimiter in-between the values (comma, space, whatever...). The excel sheet with the reference values was designed in order to verify that the driver is properly compiled. So in order to have the same parameters values, one should first load the input values from the sheet - instead of calling _MLX90640DumpEE (0x33, eeMLX90640) or changing the dump EEPROM subroutine so that it does not read the EEPROM, but loads the values from the xls file.
Best regards
Best regards
nburnett
commented
6 years ago While I was in the process of getting together the EEPROM / Frame data I noticed that the return value of MLX90640_I2CRead was indicating that there was "no ack read". When it checks :
if (Wire.endTransmission(false) != 0)
Wire.endTransmission equals 7, so it returns 0.
So I'm assuming I have some sort of wiring issue, as for the EEPROM data / Frame data it doesn't look like it's actually getting filled in because of the MLX90640_I2CRead never actually getting to read anything.
slavysis
commented
6 years ago If there is no ack from the device, the dump EERPOM function should return -1. Please check the signals with an oscilloscope or logical analyzer. It is possible that the problem is not in the wiring but the i2c implementation.
nburnett
commented
6 years ago Ok, I will look into that and see if I can acquire some diagnostic hardware and get back to you. Thank you very much for your time and pointing me in the right direction.
nseidle
commented
6 years ago You should checkout @PeterAJansen notes on getting the SparkFun sketches to work on an ESP32. You're probably having I2C communication issues related to the ESP32.
nburnett
commented
6 years ago Thanks for the additional information! I gave it a try but unfortunately it didn't resolve my issue. But based on the idea that the esp32 and or arduino-esp32 toolchain was the issue. I swapped the esp32 for an esp8266 and assigned the the gpios in the wire.begin() call and was able to get both examples working.
I was occasionally getting some random garbage in serial output but if it started working and I didn't move the setup it all kept working. So I'm assuming I just have some wiring issues that are causing the occasional data loss and checkered output.
It definitely could be that I have something incorrect in my esp32 toolchain, and maybe why the steps mentioned above didn't work. However if I can just switch chips and keep going I'm going to do that. Any microcontroller suggestions for this specific sensor?
nseidle
commented
6 years ago Teensy. Namely, I've been using the 3.5. We've had issues with other platforms (Due has I2C weirdness, ESP is bit banging I2C) whereas the Teensy libraries are solid. Some folks may have luck with the RasPi but I haven't played with it together with the MLX90640 yet.
nburnett
commented
6 years ago Thanks for the info @nseidle, I ordered a teensy 3.5 so I can have some known working hardware to create my prototype on.
I've also asked PeterAJansen in his notes ticket you linked above if he could provide the version of the esp32 toolkit and what method he used to install. Just in case I was installing an incorrect version.
Also, @slavysis thanks for your help, and your quick response time as well!
I'm currently having issues trying to get the basic example from the SparkFun MLX90640 Arduino examples available on GitHub which is based on the mlx90640-library with an esp32. I'm having an issue with getting meaningful sensor readings and I'm wondering if it's because of the MLX90640_ExtractParameters is returning and error code of -4.
I traced where the -4 error code came from and it was in the ExtractDeviatingPixels function which has the following check and sets warn = -4:
else if (outlierPixCnt > 4) { warn = -4; }I'm assuming this has to successfully complete for accurate results?After this, the code continues to run MLX90640_GetFrameData which then is returned a status of -8 which I've read the driver.pdf document where it says that "the most probable reason is that the I2C frequency is too low" but altering the i2c frequency doesn't seem to have any effect.
Here is an example of the output that I'm getting:
I'm sure I'm doing something wrong but I'm stuck and am not sure where to go from here. I've verified that an i2c scanning sketch can find the device at 0x33 and I've verified that the input voltage seems to be a steady 3.3v.
Any help would be greatly appreciated, and please forgive me for any silly questions, I'm quite new to the hardware side of things!