Hello.
I have many problems with the Call Progress Tone (CPT) detector in the Volib's TDU.
I encountered the same issue with the TDU test case than with my program, so it can easily be reproduced.
I use the following setup: VoLIB C64x+ 2.0.0.3, OMAP-L138, in little endian ELF.
I'm trying to detect a 300Hz cadenced dial tone, which follows the repeated pattern: 200ms ON, 200ms OFF, 600ms ON, 1000ms OFF.
The samples are attached here (file 300Hz_cadenced_dialtone.dat), which are 8 bits u-law, at 8kHz. The tone sequence is played 3 times, with a silence of 500ms at the beginning. The power is around -20 dBm.
In file tdusim.c, in function main(), I simply add the following line at 1845, and comment out all the other tests.
sftBasicDetectionFILE(tduInst, tdu_CTL_CPT_ON, "300Hz_cadenced_dialtone.dat");
The CPT does not perform very well. The tone duration is very variable and inaccurate (sometimes as low as 50ms duration for the 200ms tone). Sometimes, it just doesn't see the tone. Each time I run the test case, it seems to report identical results, which are shown here (note I added time computation at the end).
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 138 (At: 630 ms, Delta: 630 ms)
Tone: CPT : Event: OFF, Time: 0 ms, Power: -55 dBm0, Frame: 146 (At: 730 ms, Delta: 100 ms)
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 217 (At: 1025 ms, Delta: 295 ms)
Tone: CPT : Event: OFF, Time: 0 ms, Power: -80 dBm0, Frame: 307 (At: 1535 ms, Delta: 510 ms)
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 542 (At: 2650 ms, Delta: 1115 ms)
Tone: CPT : Event: OFF, Time: 0 ms, Power: -55 dBm0, Frame: 546 (At: 2730 ms, Delta: 80 ms)
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 627 (At: 3075 ms, Delta: 345 ms)
Tone: CPT : Event: OFF, Time: 0 ms, Power: -55 dBm0, Frame: 705 (At: 3525 ms, Delta: 450 ms)
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 994 (At: 4910 ms, Delta: 1385 ms)-> missed 1
Tone: CPT : Event: OFF, Time: 0 ms, Power: -80 dBm0, Frame: 1106 (At: 5530 ms, Delta: 620 ms)
However, if I set the parameter "tduSim.options.overwrite_scr" to TRUE, the results are worse... and still inaccurate.
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 194, (At: 910 ms, Delta: 910 ms)-> missed 1
Tone: CPT : Event: OFF, Time: 0 ms, Power: -80 dBm0, Frame: 306, (At: 1530 ms, Delta: 620 ms)
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 514, (At: 2510 ms, Delta: 980 ms)
Tone: CPT : Event: OFF, Time: 0 ms, Power: -80 dBm0, Frame: 546, (At: 2730 ms, Delta: 220 ms)
Tone: CPT : Event: ON, Time: 60 ms, Power: -18 dBm0, Frame: 619, (At: 3035 ms, Delta: 305 ms)
Tone: CPT : Event: OFF, Time: 0 ms, Power: -55 dBm0, Frame: 705, (At: 3525 ms, Delta: 490 ms)-> missed all the rest
Clearing the scratch buffer seems to affect the CPT detector. Another problem I observed, but I couldn't reproduce in the test case, is that for multiple instances of TDU, the CPT detector reports the same event in many instances altough only one "hears" the tone cadence.
This problem does not occur in the DTMF detector (I tested only this one). The time stamps are precise, and multiple instances are not affected.
If anyone could help, I would really appreciate. It's been a long time (almost a year) since I had to work around problems with the CPT, but the timestamp problem can't be.
Regards,
Jean-Denis Boyer
