Hi, We are a water utility company in Australia playing around with CH-101 sensor. We were able to connect and use the Soniclink GUI application to get the waveform and run the Hello chirp program to get the values out using the dev kit. But our engineer needs the commands for communicating via I2C with the sensor using our equipment to operate different modes and get the distance values corresponding to each pings(all values corresponding to A-scan waveforms for each samples). We are unable to find any documentation with regards to this.
It would be much appreciated if you can provide us with this information and all the documents corresponding to the Sensor till date under this question.
We have referred to the document attached below. On page 11, explains interfacing but does not provide details corresponding to it and this is the area where we nee more details.
DS-000331-CH-101-Datasheet-v1.0.pdf was the document I tried to attach but failed due to exceeded size
It seems this forum isn't been moderated, or did you find any answers anywhere?
I'm also trying to reverse engineer the code for the CH-101 module.
There are several aspects about this sensor.
First of all, the sensor has a SoC (System on a Chip), that would need to be programmed at least once after powerup (not sure if it gets stored or not, since it is stored on a RAM memory which usually is volatile and it is erased after a power reset).
This can be found in ch101_gpr_xxxx_fw.c files. It's a hex code generated by them
//File generated from v39_open-v2.hex at 2019-10-03 11:48:39.357000 by klong
A file that we can't have access to or to its source code.
And I assume you would either communicate with that firmware or that firmware sets the inner workings of the chip, but the registers remain the same.
Again, the chip runs on black magic or on some quantum interdimensional foam. Cthulhu knows how.
The firmware update is also explained by the usage of the PROG pin. And that pin is used each time, in the initialization sequence.
The constant I2C addresses and registers are explained by the fact that you can ping the chip without having any code on it.
I'm planning to publish a code on git (once I have it running). At the moment I'm using STM dev boards and Mbed for the firmware.
The example code they provide is pretty obfuscated and seems to be written by interns. It has a lot of functions and modes that are only implemented, but not well documented. Also the soniclib adds another extra layer on top of the chirp library that makes it hard to reverse engineer it. And it has a ton of functionalities that are not relevant for a test. I'd like to have one sensor, initialize it, send a command, receive a pack of data and repeat. That's all. Not fancy non-blocking readings with queues and groups of sensors that have a billion structures to them. If the user needs that, he can implement it by itself.
Maybe TDK sees this post and updates the example codes or gives a more detailed datasheet of this product.
It's a nice device with potential, but the lack of tech support will knock it down.
I tested the hardware with ultrasonic measurement equipment. The sending signal is very poor, I assume it's the 1.8Volt, they spend for moving the membrane. Also there is no usable tof (time-of-flight) measurement. The transducer can detect movements of the targeting object, but after stopping the movement the output signal vanishes. There I think it's calculated into nirwana. I assume the signal is inside a big noise spectrum and they have an algo to get it out from this.
With the asic between, it's not possible to see the real signal, so I'm interested in disabling the algo. And I don't have to detect objects 2 meters away: small distances = small transducers and vv.
Is there any chance that we can have a call (skype, whatsapp, messenger)? I'd like to discuss a couple aspects with you.
We can discuss here in the forum.
My company does not reverse engineering, no time for that. If Invensense does not want to provide a datasheet or reliable software libraries, then this product
is just a gimmick. Or they only support customers who will buy millions of millions. But I don't see the market for this quantity.
I understand. Well, that might be actually the case. Since the sensor chip is not available for sale. You can't buy only one chip anywhere. You can only buy either the module or the dev kit.
I want to ask you about some specs. Does it perform well? Since this is only a hobby project, I don't want to spend almost 200$ just to test a chip that is either not well supported (apparently it's not) aaand maybe the specs are not suitable for my needs.
The end application for this would be to read the position of an object that will be within 2-40cm from sensor, with an acceptable error under 1mm. If everything goes well, I'll end up adding a couple of them in parallel.
I'd like to know the max sampling frequency you have achieved (actual I2C readings on the host, not internal samplings), noise range for this given distance (maybe using the short range firmware) and if you have noticed any major flaws with it.
I just have these 33 samples from the default firmware.
The zero signal line is always pumping (rise and fall), this is an indication for heavy signal processing. 1mm accuracy is wishfulness.
Buy a 400kHz industrial sensor then you have half the wavelength under perfect conditions.
Not sure if you wanted to upload some image or something when you referred to "these 33 samples"
Could you tell me the noise range?
upper: 33 samples of sin/cosine
lower: amplitude and range of a Al Target 30mm width.
Hm, more than <Browse...>, set path and picture < 512kB does not come into my mind...