I have a design using the CH101 and I never seem to see the INT pin being pulsed either when the mode is free running or pitch/catch.
When it's free running I have the INT pin connected to an I/O expander device (yes it's 1.8V) and the pins are configured as inputs.
If it's configured for pitch/catch the I/O expander pin is set to be output and input as needed. I see my pulse being generated on the INT pin shortly before the pin is configured as an input, but never see the INT pin pulse. The pulse is rather longer than normal (compared to say the dev board) at around 100uS.
The device appears to be configured properly and it does the RTC cal procedure at the beginning and I see the 100ms pulse on the INT pin ok. I can read back the mode, operating frequency etc, so the I2C communications is ok.
Is there some way I can find out why the sensor isn't happy? Maybe there is some configuration setting I am not doing. I am using the ch_config_t struct to configure most of the settings such as the mode, max range etc. Here's a snippet of reading back the config values:
Mod2: fitted, trigger mode: Free running, I2C address: 01, FW version: gpr_sr_narrow_gpr-101_v43a, Frequency: 172 KHz.
Mod2: target int mode: disabled, max range: 201 mm, static range: 21 mm, scale factor 12473.
After configuring the sensor I call:
ch_set_rx_pretrigger(pGroup, 0);
Presumably this should be mostly it for free-running mode? I do configure the port as an input after the above call but still no INT pulse. The pin on my side is definitely an input.
As I say, I don't have any better luck in pitch/catch mode when I generate a pulse on the INT pin either. I've tried just reading sample data to see if the sensor is actually doing anything but it always returns NO_TARGET.
I've tried different firmware versions and changing max range etc. I'm wondering what the minimum configuration settings are you can give it to get it work, even if it isn't optimised nicely for what you want it to do. I'm desperate at this stage just to see the INT pin pulse, even if the range data doesn't make sense.
Gary.
I think I know why I wasn't seeing any INT signals.
The SonicLib library performs an initialisation procedure in the chdrv_group_start() function where all the PROG pins in a group are asserted whilst holding the nRESET pin low on all devices. My design had assumed only one PROG pin would be asserted at a time so I guess the sensors were not being set correctly into IDLE mode.
They appear to be in IDLE mode after a power up anyway so I've just temporarily commented out the lines in chdrv_group_start() that assert the PROG pins on all sensors within a group.
Hello @garymetallervlcouk did you solve the problem? I'm facing the same issue. Regards.
If you can share your hardware connection schematics for INT part, that will be helpful. Chx01's INT is not pushpull I/O, specially when the level shifter is used in the integration, should be careful.
Hi, what do you mean by" Chx01’s INT is not pushpull I/O"?
In the datasheet, it shows that the INT pin don't need external pull/push resistors.
You can treat the Chx01's INT pin as the open drain and bidirectional I/O, not a push-pull I/O. So when you are using a level shifter, it need support the bidirection and enough driving capability. I attach the 1st gen DK board schematics for your reference.