[asterisk-bugs] [Asterisk 0016017]: v23 caller id detection (UK) less than 100%

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Oct 6 16:50:40 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16017 
====================================================================== 
Reported By:                troublebot
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16017
Category:                   Channels/chan_dahdi
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.26.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-10-05 06:48 CDT
Last Modified:              2009-10-06 16:50 CDT
====================================================================== 
Summary:                    v23 caller id detection (UK) less than 100%
Description: 
Around 1 in 100 will fail with callerid.c: No start bit found in fsk data

After implementation of polarity detection in wcfxo.c I initially believed
there was an issue with my implementation or the hardware (X100P SE). I
setup enhanced logging and data capture and discovered that this was not
the case. There is a certain amount of noise present most of which could be
removed with a band pass filter, which I believe should help detection
rates. I do not believe the noise is inherent in the line, most of the
noise can be characterised as low frequency noise (mentioned in si3034 spec
as dc offset) and 4khz squeal. I have the raw data captured directly from
wcfxo if there is any interest in improving this. 
====================================================================== 

---------------------------------------------------------------------- 
 (0111938) davidw (reporter) - 2009-10-06 16:50
 https://issues.asterisk.org/view.php?id=16017#c111938 
---------------------------------------------------------------------- 
Although I'm not a DSP programmer, I think the basic problem is that
algorithms are being used that are designed to handle relatively long
telephony indication tones, but are being asked to handle tones that last
for less than 100 microseconds and consists of as little as 1.1 complete
cycles.

It is, in fact, fundamentally based on band pass filters, so ought to
reject signals at the extreme ends of the spectrum.  What I think the
algorithm is is to run IIR filters on the two nominal tone frequencies, and
of length 7, then run another filter on the difference (of the squares), to
try and average the result.  For tones that are not sub-multiples of 8kHz,
this probably works well, if you can average over many cycles, but I don't
see it working well for very short tones.

Again, I'm not an expert on DSP, and particularly not on FSK modems, but I
suspect, for this case, you have to take advantage of the continuous phase
nature of the modulation, if one wants high quality decoding. Also, there
doesn't seem to be any real advantage in using more than 1 signalling unit
of data in the filters, so I think that FIR filters would be as good.

I suspect it is the IIR filters that are having trouble with the start
bit, as they will have seen a long run of data in one signalling state
before the start bit.

Note this means I think the problem is in main/fskcmodem_*.c. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-06 16:50 davidw         Note Added: 0111938                          
======================================================================




More information about the asterisk-bugs mailing list