Distance Sensing with the OPT3101

Hi - I’ve also had problems with reading correct distances. I’ve ported the code to C, running on an NXP ARM microprocessor, and was getting bad values. Then, as a shot in the dark, applied the fix listed in the original topic- reg A0 = 0x2198 and now am getting values that make sense.

Is the eprom data specific for each board, or generic for the design? Can you send me a copy please so I can check the other values? Not sure if I can read the data directly from the eprom, but can compare with registers once the eprom load has completed.

I posted this in the original topic, but that says that it is closed, so reposting here.

Thanks, Andy H

Hi, Andy.

The EEPROM data contains both calibration values specific to your board and other data that is the same across all boards. If the same correction to register 0xA0 that fixed the other user’s board also worked for you, it’s possible yours was corrupted in the same way. However, so that we can make sure, could you also post the output of the ReadEEPROM example from the library with your board?

Kevin

Ok - will try that tomorrow.

Regards, Andrew Hartnett

Here’s the eprom data Kevin - I think it’s correct! It’s a little complicated as my I2C routines are completely different from the Arduino ones, so translating is complex. Haven’t got the serial number code working yet - let me know if you really need that.
Regards. Andy

\xa0\x00\xb2\xf1\xb4\x2f\x9d\x72\xb4\x7f\x00\x00\x0b\x09\x00\x10\x0c\x00\x00\xbf\x29\xe4\x93\x2f\x2a\x20\x49\x7c\x2b\x78\x69\x00\x2c\xa7\x0b\x00\x2d\xbb\xe4\x5e\x2e\xa0\x01\x84\x2f\x2a\xfa\x4c\x30\x15\x0a\x20\x31\x21\x15\x5f\x32\xfd\x4a\xb0\x33\xca\xf0\x4b\x34\x57\xfc\x60\x35\x14\xca\x00\x36\x37\xd9\x00\x37\x10\xe6\x00\x38\xa1\xfa\x29\x39\xd6\x9b\xf1\x3a\xc3\xc0\x4d\x3f\xc8\x08\x00\x41\x10\x80\x8c\x42\x03\x3d\x00\x43\x83\x00\x00\x45\xdd\x85\x8c\x47\xc8\x08\x80\x48\xc8\x08\x00\x49\xc8\x08\x00\x51\xc9\x33\x00\x52\x5f\x3c\x00\x53\x11\x34\x00\x54\xbc\x3c\x00\x55\x58\x34\x00\x5e\x00\x63\x13\x5f\xf8\x16\xbb\x60\x1d\xea\xd8\x61\xdf\x88\x00\x72\x50\x00\x00\x85\x7a\x26\x00\x86\x82\x26\x00\xb4\xd3\xe4\xe8\xb5\x01\x00\x00\xb8\x1a\x6c\x01\xb9\xa6\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff

It looks like the first two bytes of the EEPROM got corrupted, just like what happened to the first user in the other thread, so you should be able to fix it permanently it by running the same program I posted there. (If you have an Arduino available, it might be easiest to use that so you can run the program directly, but it should also be possible to translate it to a different platform if you are careful.)

Afterwards, if you can confirm that the first 2 bytes changed to \xb4 \xf0, that should indicate the fix worked. Please let me know if you run into any issues.

Kevin

OK thanks - looks pretty straightforward – I’ll try it in the morning. Don’t have an Arduino, but this looks easy enough.

Regards, Andrew Hartnett

parkescape@cox.net

OK - bytes 0 and 1 of the eprom reset succesfully, and sensor now works without having to write the value to register 0xA0.

Why does that work though? How did the temporary write to 0xA0 correct the invalid value in 0xB4 lower byte?

Thanks for the help.

Andy H

I’m glad the fix worked for you. It seems like the first few bytes of the EEPROM got corrupted to write an incorrect value to register 0xA0 (without affecting the final value of register 0xB4). The temporary fix restores what’s supposed to be in 0xA0, and the permanent fix restores the EEPROM so it does not overwrite 0xA0 incorrectly.

Kevin