Using DK-CH201 and the HelloChirp example, in app_config.h I:
(1) set CHIRP_SENSOR_FW_INIT_FUNC to ch201_gprmt_init
(2) enabled amplitude readout by uncommenting defines READ_AMPLITUDE_DATA and OUTPUT_AMPLITUDE_DATA
(3) Changed the value of CHIRP_SENSOR_MAX_RANGE_MM from 750 to 2500
(4)C hanged the MEASUREMENT_INTERVAL_MS from 100 to 1000
Rebuilt with no errors and reflashed the DK-CH201 OK.
Now I see that num_samples has (correctly) changed from '48' (when max range was 750mm) to '158' (when max range is 2500mm).
However, when I view the text output, I see that the amplitude data (correctly) shows the first 64 samples then simply repeats the first 64 values until it has read out the full 158 samples (see attached file).
Is there another parameter I need to adjust to get the longer range working correctly for amplitude data?
I am seeing this set of 158 amplitude samples, for example.
You can see the initial sequence 0 134 810 repeating several times.
Hello Chirp! - Chirp SonicLib Example Application
Compile time: Mar 9 2021 17:23:45
Version: 1.11.0 SonicLib version: 2.1.2
Initializing sensor(s)... starting group... OK
Sensor Type Freq RTC Cal Firmware
0 CH201 85544 Hz 2796@100ms gprmt_v7
Configuring sensor(s)...
Sensor 0: max_range=2502mm mode=TRIGGERED_TX_RX
Detection thresholds:
0 start: 0 level: 5000
1 start: 26 level: 2000
2 start: 39 level: 800
3 start: 56 level: 400
4 start: 79 level: 250
5 start: 89 level: 175
Initializing sample timer for 1000ms interval... OK
Starting measurements
Port 0: Range: 537.0 mm Amp: 1873
0
134
810
1757
1767
863
209
39
49
22
13
5
11
53
305
853
1452
1547
916
134
589
814
745
597
536
483
302
51
175
357
581
837
948
899
1392
2144
2283
1653
682
269
494
547
533
492
444
399
398
435
426
351
242
127
74
119
146
132
60
45
85
55
97
219
299
313
0
134
810
1757
1767
863
209
39
49
22
13
5
11
53
305
853
1452
1547
916
134
589
814
745
597
536
483
302
51
175
357
581
837
948
899
1392
2144
2283
1653
682
269
494
547
533
492
444
399
398
435
426
351
242
127
74
119
146
132
60
45
85
55
97
219
299
313
0
134
810
1757
1767
863
209
39
49
22
13
5
11
53
305
853
1452
1547
916
134
589
814
745
597
536
483
302
51
I came across this too and have solved it's caused by 1 issue and 2 possible solutions. The I2C register addresses are 8 bits (mem_read), but the driver references 16 bits, but the HAL 100% should be 8 bit (if you change it to 16, it won't work).
However in the driver it accesses the amplitude download register as 16 bits (preceded by 00, 01, 02 as the MSB), but that MSB gets dropped by the time it gets to the HAL (which expects 8 bits).
"64" is the IQ Data(4 Bytes) = 256 bytes in a burst read for the HAL.
I think whoever wrote it, was thinking 16 bit addressing in 256 byte chunks for the burst read i.e. 0x00XX 0x01XX 0x02XX etc.
I.E. It's telling the HAL, Get chunk 1 of 256 bytes, then get the next chunk of 256 etc. But it's 8 bit addressing, the next chunk is the same chunk.
3 ways to solve it:
1. Fix the HAL so that it uses 16 bits register addressing but only sends 8 bits over I2C, and uses the MSB on each call to determine which chunk it's reading and you'd need to continue the burst read for the 3 x 256 byte chunks. But the issue here is figuring out, when it's finished, and you'd have to update the driver to tell it. Seemed a pretty messy problem to me.
2. Or the way I solved it, change CH_IQ_SAMPLES_PER_READ from 64 to 150 (maximum number of samples on the CH101, change as appropriate if you have the CH201). What happens then is it doesn't chunk the burst read into 256 byte blocks, it does the full request all in one burst read (150 x 4(IQ size)) bytes.
3. In ch_common.c: get_sample data, after the USE_STD_I2C_FOR_IQ #endif, put use_prog_read=1 to force it to use the "Program" interface instead of the regular I2C address. This also works because it uses a different burst read mechanism (i.e. not the chbsp mem_read interface). However watch out if you have more than one sensor that the prog gpis is toggle correctly too and you're requesting from the correct sensor.
It would be nice if TDK could support their products. I see little response from TDK regarding this product to the many questions answered. It's been painful getting this working.