I2C communication between ch101 sensor and arduino

Hello.

I want to use chirp's ch101(ultrasonic sensor; you can see what the product is in Qwiic Chirp 101 Ultrasonic Rangefinder - SPX-17046 - SparkFun Electronics) with arduino not chirp's ch101 development kit.

I think that I can use I2C communication between ch101 and arduino.
I checked the slave addresses using 'i2c scanner' (Arduino Playground - I2cScanner)
There were two addresses. One was 0x29(application address), and the other was 0x45(programming address)

But I could not get any data from those addresses. How can I get distance data with this product? please help me.


Here is my code

#include <Wire.h>

#define Chirp_ADDR 0x29 // or I used 0x45
//there was not any mention of register address in chirp's data sheet. so I just used 0
#define Chirp_REG_TMEP 0
#define ANSWERSIZE 2 // I used 2 byte arbitrarily

int rstPin = 13;
int progPin = 12;
int intPin = 11;

void setup() {
Wire.begin();
Serial.begin(921600);
}

void loop()
{

digitalWrite(rstPin, HIGH);
digitalWrite(progPin, LOW);

float distance = GetDistance();
Serial.print("distance : ");
Serial.println(distance);
Serial.print("\n");
delay(1000);
}

float GetDistance() {
Wire.beginTransmission(Chirp_ADDR);
Wire.write(Chirp_REG_TMEP);
Wire.endTransmission();

Wire.requestFrom(Chirp_ADDR, ANSWERSIZE);
Serial.println("Receive data");

if(Wire.available()){
Serial.println("Yes data");
}
else {
Serial.println("No data");
}

byte firstByte = Wire.read();
byte secondByte = Wire.read();
int sumByte = ((int)firstByte << 4)|(secondByte>>4);
float distanceValue = sumByte;

return distanceValue;
}


Result

  1. when I used 0x45, the result was...
    Receive data
    Yes data
    distance : 10.00 (Only the value of 10.00 is output regardless of the distance)

  2. when I used 0x29, the result was...
    Receive data
    Yes data
    distance : 0.00

So how is it wired up?

That is a complex chip and I doubt that your code is sufficient to drive it. If it was then an Arduino library would be simple enough to make but the product page says it has not been produced.

Invensense/TDK CH101: https://invensense.tdk.com/products/ch101/

Sparkfun module: https://www.sparkfun.com/products/17046 and Github repository: https://github.com/sparkfunX/Qwiic_Chirp_101_Ultrasonic_Rangefinder
It is experimental and for developers. There is no library for it yet.

The only Arduino related code that I can find is this: https://forum.arduino.cc/t/tdk-ch101-integration-with-esp32/687805, but that does not even seem close to a solution.

The data sheet says

The CH101 contains two separate I2C interfaces, running on two separate slave addresses. The first is for loading firmware into the on-chip program memory, and the second is for in-application communication with the CH101. The 7-bit programming address is 0x45, and the 7-bit application address default is 0x29. The application address can be reprogrammed to any valid 7-bit I2C address.

I see no evidence of you loading any file into the device at 0x45 or any other address.
That is the only use of that address.

Looks like you made quite a few assumptions. I'm not surprised they turn out not to work.

Did you actually read the programmer's guide on the Sparkfun website you linked to?

Hmm... It's true that I actually don't know much about this sensor. (I am not a programmer😥)

I used 'Hello Chirp' Example in programmer's guide with development kit.
I am not sure how to approach to use this sensor with arduino.

What should I change in the hello chirp example?

The connection is like this.

[Ch101 ---- Arduino]
SCL ---- A5
SDA ---- A4
3v3 ---- 3.3V
GND ---- GND

RST_N ---- 13
PROG ---- 12
INIT ---- 11

The data sheets (Fig-1) says that maximum AVDD/VDD supply is 2.2V with a typycal value of 1.8V. So, this device is not compatiable with Arduino UNO.


ch101-2
Figure-1:

But the SparkFun product information page says

Our Qwiic breakout provides voltage regulation and level shifting for the MOD-CH101 Evaluation Module.

That is correct; where, SparkFun's Customized Module is compatible with corresponding Arduino having built-in 1.8V/3.3V or 1.8V/5V level sifters. I was talking about the bare chip itself which is 1.8V device.

Is the SparkFun product equipped with 1.8V/5V level sifter to be compatiable with UNO? If Yes, then why is @sujin9 connecting 3.3V supply to the Module? I searched the net, but could find circuit diagram for the SparkFun's CH101 Module.

As SparkFun is saying about "voltag regulator", then most probably their module contains 1.8V/3.3V level sifter; as a result, it could be operated with 3.3V Arduino DUE.

It's on the sparkfun website linked to in the first post. https://cdn.sparkfun.com/assets/4/9/1/9/3/Qwiic_Chirp_101.pdf
The module will interface with any device that runs on 2.5V ~ 6V.

The Module could be operated with a Vin/Vcc voltage from 2.5V to 6V (Fig-1) which is the input specification for the Vin/1.8V voltage regulator. So. to operate it with UNO, the Vin/Vcc pin should be connected with 5V and not with 3.3V.
AP2127k
Figure-1:

That's correct. However, it's highly likely that the device would also work when connected to 3V3 as that level is very likely to be correctly detected as a logic high by the Atmega328P.

Based on the information given at the right-top of Fig-1, 3.3V will be detcetd as Logic HIGH; but, VIH is given as 3.0 minimum. So, when we have the facility to use 5V, why should we go for 3.3V or 3.0V? In addition, we need to consider "noise margin". therefore, it is highly recommended to use upper side possible (5V).

pb0Output
Figure-1:

Well, obviously. The point is, and that's what you appear to be missing, is that the suboptimal 3.3V connection doesn't explain the problem of OP. I agree that it's better to connect this module to 5V, but doing so is not going to magically solve the original problem.

So that shows the data transfer is working, at least in the case of situation 1. While a reading of zero could represent a none functioning device, a reading of 10, shows that some data is being transferred.

The problem is, as I stated before, that

The CH101 contains two separate I2C interfaces, running on two separate slave addresses. The first is for loading firmware into the on-chip program memory, and the second is for in-application communication with the CH101

This needs to be done first, I suspect that it has not been done. Looking at the data sheet there is also a "program" input to the chip and I am assuming that this has to be pulled in the right direction when loading the firmware.

I suspect factory firmware is present on the device alright. The TDK programmer's guide doesn't state it explicitly, so it's a gamble.
In any case, like I said before, it really helps to read the programmer's guide for the device. It clearly indicates, for instance, that the I2C register definitions are firmware -dependent, so whatever registers you try to read/write need to be correct for the firmware that's present on the device. Again, the Sparkfun website links to the programmer's guide: https://cdn.sparkfun.com/assets/8/f/3/f/4/AN-000175-SonicLib-Programmers-Guide-v1.0.pdf

This is not just any old I2C device with a straightforward interface. It's more flexible, but as a consequence it's also a little less forgiving of the "nah, I'll forego the reading and just wing it" approach.

Before interpreting a data, it must be technically good; lkewise, the hardware setup of a programmable device must be upto the specification before we write software for it.

When the UNO is a 5V device and the SparkFun Module has the option for 5V supply, then it is best to connect the Module with 5V.

Look, we don't disagree on this. The thing is, getting this thing to run on 5V is a matter of replugging literally one cable. Getting the thing to talk to a microcontroller over I2C is actually going to take a little study on behalf of the OP. That's where the real challenge is. Forgive me for saying so, but the talk of 3.3V vs. 5V only distracts from the root of the problem.

If @sujin9 is operating the Senosr Moudule with UNO, he must connect the Vcc-pin of the Module with 5V and only then various software codes could be tried to make it work.