TMF8801

Sensors Distance
1

Hi

Regarding use of TMF8801.

I am aiming for making a distance measurement between approximately 25 mm to 175 mm (changing distance). I have two question/problem.

  1. What is the max. ODR?

Ive seen it listed as 30 Hz / 33 ms. But isn’t that just the nomimel as described in DS p.16. Ranging Time Default Settings, nom. 33 ms. (default p.18).

One can set the CMD_DATA2 = repetition_period in mSec, and it seems to be able to go lower, is there a problem in doing so?

I have tried changing from library setting 100 ms to 25 ms, it seems to be working.

  1. Why does the measurement make a jump at 99 mm?

Tried with/without calibration. Calibration is done as in the library ex. 4. And (nearly) following the guidelines from DS, “calibration test shall be done in a housing with minimal ambient light and no target within 40 cm in field of view of the TMF8801”.

Without calibration, readings vary from being approximately 30-75 % to big (getting less and less to big, the more the distance), and it makes this jump at around an actual distance of 75 mm, TMF is reading from 99 and then jumps to ~131 mm, see image 1.

With calibration, readings are almost OK, and it jumps at around distance 99 mm, TMF is reading from 99 and then jumps to ~105 mm, see image 2.

With calibration, and CMD_DATA6 = 0x03 (default sparkfun 0x23) meaning “Bit 5= 1 When 1 combine the capture of the short and long distance histogram for maximum speed” NOW set to NOT combine, readings are still almost OK , readings now make a big jump again TMF reading from 99 and jump to ~131 mm, see image 3.

Ive noticed that the TMF8701, is an almost identically chip, with the possibility of shifting between two modes, Proximity and distance mode. Which maybe would make somehow sense explaining this. But this should not be the case with the TMF8801. (cant check for correct chip, since the IDs are the same, REGISTER_ID = CHIP_ID_NUMBER= 0x07).

This code I added in ex. 1 og 4 from the library/github, to change ODR.

delay(500); // OBS must be 500 (50 didnt work (after calibrate) else just stops)
  // OBS this must be after calibrating, because setCalibration makes a resetDevice
  tmf8801.setRegisterValue(REGISTER_CMD_DATA2, 0x21); // 0x28= 40 ms, 0x21= 33 ms, 0x19= 25 ms
  tmf8801.setRegisterValue(REGISTER_CMD_DATA6, 0x03); // sparkfun default, 0x23= 0b 0010 0011
  // Bit 5= 1 When 1 combine the capture of the short and long distance histogram for maximum speed (0x03) ikke combine
  // Bit 7= 0 When 1 do not go to standby between measurements (faster measurement times but higher (0xA3) ikke standby
  tmf8801.setRegisterValue(REGISTER_COMMAND, COMMAND_STOP); //
  delay(500);
  tmf8801.setRegisterValue(REGISTER_COMMAND, COMMAND_MEASURE);
  delay(500);

Udklip3.PNG

Udklip2.PNG

Udklip1.PNG

2

OK, so out of curiosity I found and tried another TMF8801 lib from DFRobot. Using this library the readings of the distance does NOT jump at 99. I would still prefer using Sparkfuns lib, now that I found out how to change some of the CMD registers to set the ODR to a wanted value. But its quiet difficult to understand what is going on/what the difference is?

Does anyone have more knowledge/understandings of this?

Thanks

3

When asking for app revision, I am getting different answers when running Sparkfun and DFRobot lib. It is still a puzzle to me why this is the case. Maybe this has something to do with DFRobot uploading some other SW patch, which I can see DFrobot has in the github, sparkfun doesn’t seem to have this.

This is what I found:

Application major revision. Minor rev. Application patch number. Chip revision ID

APPREV_MAJOR Register (Address 0x01), sparkfun= 2, DFRobot= 3

APPREV_MINOR Register (Address 0x12), sparkfun= 0, DFRobot= 0

APPREV_PATCH Register (Address 0x13), sparkfun= 15, DFRobot= 12

REVID Register (Address 0xE4), sparkfun= 3, DFRobot= 3

Complete Sparkfun 2.0.15.3

Complete DFRobot 3.0.12.3

Code DFRobot for showing this:

Serial.print("Software Version: ");
  Serial.println(tof.getSoftwareVersion());

Code Sparkfun for showing this:

Serial.print("APPID Register (Address 0x00) 0xC0 app0 ell 0x80 boot");
    Serial.println(tmf8801.getRegisterValue(0x00));
    Serial.print("APPREV_MAJOR Register (Address 0x01) ");
    Serial.println(tmf8801.getRegisterValue(0x01));
    Serial.print("APPREV_MINOR Register (Address 0x12) ");
    Serial.println(tmf8801.getRegisterValue(0x12));
    Serial.print("APPREV_PATCH Register (Address 0x13) ");
    Serial.println(tmf8801.getRegisterValue(0x13));
    Serial.print("REVID Register (Address 0xE4) ");
    Serial.println(tmf8801.getRegisterValue(0xE4));

https://github.com/sparkfun/SparkFun_TM … no_Library

https://github.com/DFRobot/DFRobot_TMF8x01

4

I do think it is necessary to have a RAM patch download function. It says in AN000597 that App0 Application (I²C Register 0 has the value 0xC0), outdated, so do not use without patching. And the libraries from DFRobot and 107-systems have this functionality.

This might help eliminating the strange behavior (the jumping, which isn’t there when I tried using DFRobot lib).

Another thing is the dataAvailable function, isn’t it missing something. As described AN000597 p.23. First read and check that register 0x1E is 0x55, then read and make use of either TID Register (Address 0x1F) Unique transaction ID, or RESULT_NUMBER Register (Address 0x20) Result number, incremented every time there is a unique answer. The function is only reading the 0x55?

Maybe some nicer way to change repetition_period in mSec/ODR, as described.

And if possible running more TMFs at the same bus. If it was possible to change the address. COMMAND Register (Address 0x10) command 0x49 DS p.31. I dont know though if it is that simple.