DSPRelated.com
Forums

question about callerid detection

Started by Li Hao July 19, 2003
Hi, all:

I am working on a callerid detection algorithm issue. This algorithm has
been working well with AMD79Q021 QSLAC chip. But since we switched to
Slilicon Lab si050 DAA chip, the callerid algorithm failed miserably.

The algorithm runs on C5409. It basically does FSK demodulation by doing a
delayed sample multiplication following by a Low Pass filter. LPF'ed output
are used to decide 0 or 1.

From what I can debugg to see, it looks like the signal after the LFP never
really converges. In other words, it never consistantly gives a binary 1 in
4 to 7 samples. Does anyone have any idea what could be the problem? Or
anyone can suggest how to approach this problem.

Thanks.



Sorry, I sent 2 same questions twice. It took 2 days for them to show up, so
I thought it got lost somewhere.

Anyway, I have actually found the problem was due to a DC offset introduced
in the output signal in the new chip. The mu-law encoded samples are ranging
from around 60 to 255. So looks like I need a high pass filter to filter out
the component. Does anyone know whether I have to apply this filter to the
mu-law samples or won't until the samples converted into linear format?

Thanks for any comment.

-----Original Message-----
From: Li Hao [mailto:]
Sent: Saturday, July 19, 2003 12:33 PM
To: '
Subject: [c54x] question about callerid detection Hi, all:

I am working on a callerid detection algorithm issue. This algorithm has
been working well with AMD79Q021 QSLAC chip. But since we switched to
Slilicon Lab si050 DAA chip, the callerid algorithm failed miserably.

The algorithm runs on C5409. It basically does FSK demodulation by doing a
delayed sample multiplication following by a Low Pass filter. LPF'ed output
are used to decide 0 or 1.

From what I can debugg to see, it looks like the signal after the LFP never
really converges. In other words, it never consistantly gives a binary 1 in
4 to 7 samples. Does anyone have any idea what could be the problem? Or
anyone can suggest how to approach this problem.

Thanks. _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join: Send an email to

To Post: Send an email to

To Leave: Send an email to

Archives: http://www.yahoogroups.com/group/c54x

Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/



Li Hao-

> Sorry, I sent 2 same questions twice. It took 2 days for them to show up,
> so
> I thought it got lost somewhere.
>
> Anyway, I have actually found the problem was due to a DC offset
> introduced
> in the output signal in the new chip. The mu-law encoded samples are
> ranging
> from around 60 to 255. So looks like I need a high pass filter to filter
> out
> the component. Does anyone know whether I have to apply this filter to the
> mu-law samples or won't until the samples converted into linear format?

What is the normal u-Law sample range on the old chip? If ranging between
0 and 255, then you have to fix the source of the problem, instead of
trying to cover with a filter band-aid.

Jeff Brower
system engineer
Signalogic > -----Original Message-----
> From: Li Hao [mailto:]
> Sent: Saturday, July 19, 2003 12:33 PM
> To: '
> Subject: [c54x] question about callerid detection > Hi, all:
>
> I am working on a callerid detection algorithm issue. This algorithm has
> been working well with AMD79Q021 QSLAC chip. But since we switched to
> Slilicon Lab si050 DAA chip, the callerid algorithm failed miserably.
>
> The algorithm runs on C5409. It basically does FSK demodulation by doing a
> delayed sample multiplication following by a Low Pass filter. LPF'ed
> output
> are used to decide 0 or 1.
>
> From what I can debugg to see, it looks like the signal after the LFP
> never
> really converges. In other words, it never consistantly gives a binary 1
> in
> 4 to 7 samples. Does anyone have any idea what could be the problem? Or
> anyone can suggest how to approach this problem.
>
> Thanks.



Jeff,

Thanks for reply. The samples from old chip was 0 to 255. Some A/D chips
introduce DC offset in the analog signal before digitizing them. There is
nothing really we can do. It is a Silicon Lab DAA chip. So we have to do the
filter "band-aid" if we want to use the chip.

Do you or anyone have any recommandation on the filter design?
Thanks.

-----Original Message-----
From: Jeff Brower [mailto:]
Sent: Monday, July 21, 2003 11:19 AM
To: Li Hao
Cc:
Subject: RE: [c54x] question about callerid detection Li Hao-

> Sorry, I sent 2 same questions twice. It took 2 days for them to show up,
> so
> I thought it got lost somewhere.
>
> Anyway, I have actually found the problem was due to a DC offset
> introduced
> in the output signal in the new chip. The mu-law encoded samples are
> ranging
> from around 60 to 255. So looks like I need a high pass filter to filter
> out
> the component. Does anyone know whether I have to apply this filter to the
> mu-law samples or won't until the samples converted into linear format?

What is the normal u-Law sample range on the old chip? If ranging between
0 and 255, then you have to fix the source of the problem, instead of
trying to cover with a filter band-aid.

Jeff Brower
system engineer
Signalogic > -----Original Message-----
> From: Li Hao [mailto:]
> Sent: Saturday, July 19, 2003 12:33 PM
> To: '
> Subject: [c54x] question about callerid detection > Hi, all:
>
> I am working on a callerid detection algorithm issue. This algorithm has
> been working well with AMD79Q021 QSLAC chip. But since we switched to
> Slilicon Lab si050 DAA chip, the callerid algorithm failed miserably.
>
> The algorithm runs on C5409. It basically does FSK demodulation by doing a
> delayed sample multiplication following by a Low Pass filter. LPF'ed
> output
> are used to decide 0 or 1.
>
> From what I can debugg to see, it looks like the signal after the LFP
> never
> really converges. In other words, it never consistantly gives a binary 1
> in
> 4 to 7 samples. Does anyone have any idea what could be the problem? Or
> anyone can suggest how to approach this problem.
>
> Thanks.

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join: Send an email to

To Post: Send an email to

To Leave: Send an email to

Archives: http://www.yahoogroups.com/group/c54x

Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/



Li Hao-

> Thanks for reply. The samples from old chip was 0 to 255. Some A/D chips
> introduce DC offset in the analog signal before digitizing them.

But they should not; normally the offset comes from a different source.
My guess is that the Silicon Labs device has a different full-scale range
or a different referernce voltage than your previous AMD/Siemens device --
you said you changed the chip, but not the surrounding analog I/O
circuitry, right?

Try adjusting the offset to the DAA chip input. Maybe replace an R or a
couple of Rs with trimpots so you can see the effect easily on a scope.

Li, if you don't fix the offset, than the CallerID is just the beginning
of your problems. Other things won't work either, because the data is not
right.

Jeff Brower
system engineer
Signalogic

> There is
> nothing really we can do. It is a Silicon Lab DAA chip. So we have to do
> the
> filter "band-aid" if we want to use the chip.
>
> Do you or anyone have any recommandation on the filter design?
> Thanks.
>
> -----Original Message-----
> From: Jeff Brower [mailto:]
> Sent: Monday, July 21, 2003 11:19 AM
> To: Li Hao
> Cc:
> Subject: RE: [c54x] question about callerid detection > Li Hao-
>
>> Sorry, I sent 2 same questions twice. It took 2 days for them to show
>> up,
>> so
>> I thought it got lost somewhere.
>>
>> Anyway, I have actually found the problem was due to a DC offset
>> introduced
>> in the output signal in the new chip. The mu-law encoded samples are
>> ranging
>> from around 60 to 255. So looks like I need a high pass filter to filter
>> out
>> the component. Does anyone know whether I have to apply this filter to
>> the
>> mu-law samples or won't until the samples converted into linear format?
>
> What is the normal u-Law sample range on the old chip? If ranging between
> 0 and 255, then you have to fix the source of the problem, instead of
> trying to cover with a filter band-aid.
>
> Jeff Brower
> system engineer
> Signalogic >> -----Original Message-----
>> From: Li Hao [mailto:]
>> Sent: Saturday, July 19, 2003 12:33 PM
>> To: '
>> Subject: [c54x] question about callerid detection
>>
>>
>> Hi, all:
>>
>> I am working on a callerid detection algorithm issue. This algorithm has
>> been working well with AMD79Q021 QSLAC chip. But since we switched to
>> Slilicon Lab si050 DAA chip, the callerid algorithm failed miserably.
>>
>> The algorithm runs on C5409. It basically does FSK demodulation by doing
>> a
>> delayed sample multiplication following by a Low Pass filter. LPF'ed
>> output
>> are used to decide 0 or 1.
>>
>> From what I can debugg to see, it looks like the signal after the LFP
>> never
>> really converges. In other words, it never consistantly gives a binary 1
>> in
>> 4 to 7 samples. Does anyone have any idea what could be the problem? Or
>> anyone can suggest how to approach this problem.
>>
>> Thanks.