BGS2-E produces sporadic loud noise after accepting incoming voice call | Telit Cinterion IoT Developer Community
April 5, 2017 - 4:26pm, 5543 views
We use BGS2-E with Revision 02.000 for our mobile gateway with tip/ring interface.
At the interface there is a small PABX connected. But we may also cause this problem with simple resistor.
The selected audio hardware therefore is set to AT^SNFS=6.
Microphone path parameters are set to AT^SNFI=0, 32767, which gives "normally" a good audio result.
But now we get more and more reports about sporadic loud noise after the gateway accepts an incoming voice call. The loudness changes and sometimes there is absolutely no noise (with same hardware). To be sure we checked the MIC input but this is not the cause.
Nevertheless we can mute this noise with AT+CMUT. After unmute the noise is still active.
The only way we have found to stop the noise is either to send a tone with AT^SNFG=1000,1000,100 or another loud tone or voice passes the audio path.
Any idea what we can do against this noise? Has is something to do with the internal noise reduction or echo cancellation algorithm?
Thanks in advance!
Hello,
Is the noise heard by the other party or on the BGS2-E module's side?
Are you using the analog audio or digital? Are you using headset, handset, etc. Can you check the other audio settings? Maybe your connected device provides some settings.
If this disappears after muting the microphone it could be a kind of feedback. Maybe correction of the side tone parameter could change something. Please see the audio programming model in the at commands specification.
Please check the detailed firmware version with ati1.
Regards,
Bartłomiej
Hallo,
the noise is heard by the other party only (which originates the call).
On the BGS2-E module side there is nothing .. silence ..
We use analog audio interface with discrete implementation of 2/4 wire interface. But as mentioned before we checked this first and there is no noise at the MICN/MICP input.
The ati1 response is:
Cinterion
BGS2-E
REVISION 02.000
A-REVISION 01.000.17
If we reduce inBbcGain or inCalibrate then noise doesn't occur as much as before and noise loudness is reduced as well of course.
Maybe we can prevent the module from produce this noise that way or there is a hidden command to "reset" the audio interface?
Your advice would be very welcome.
Dziękuję
Lothar
Hello,
The interesting thing is that generating a local tone with AT^SNFG can cause this noise to disappear. Could you paste all other audio settings? Is there any handsfree system used or maybe handset - does it have any influence?
I can't see this firmware version in public official releases.
I don't know any special command to reset the interface besides SNFD which resets all the parameters to default values which won't be helpful here.
Maybe changing the audio **** to dedicated to the kind of microphone and speaker used would help.
Is it easy to reproduce this? How frequently does it happen?
What audio codec setting is used (AT^SCFG="Call/SpeechVersion1")?
Regards,
Bartłomiej
Hallo,
we don't use any handset or handsfree system. We connect a pabx to the gsm-gateway's
2/4-wire interface. The incoming call is answered by the pabx with a special tone which
causes the BGS2-E to produce noise.
The audio settings for our hardware is:
AT^SNFI: 0, 32767
AT^SNFO: 0, 0, 8192, 16384, 24576, 32767, 2, 0
AT^SAIC: 2, 1
AT^SNFS: 6
AT^SCFG: "Call/SpeechVersion1", "2"
I have just tried it and it happens at 4 of 10 calls.
I may send you email with the mobile phone number if you wanna listen to.
Regards,
Lothar
Hallo,
i did some more evaluation tests.
When i change codec to half rate (HR) there is no noise problem.
But we need full rate (FR) codec and as i have checked with AT^MONI we actually use S_EFR (enhanced full rate) for voice call.
Because of that i had a look at ETSI EN 300 728 document:
Comfort noise aspects for Enhanced Full Rate (EFR) speed traffic channels (GSM 06.62)
I found:
"The comfort noise parameters are estimated on the TX side and transmitted to the RX side before the radio transmission is switched off ... this allows the comfort noise to adapt to the changes of the noise on the TX side"
I wonder if this could be the cause for my problem?
That would explain why i can stop this noise when other tones passes the codec. When background acoustic noise evaluation corrects the noise parameters and SID frame is transmitted to the RX side noise level becomes normal.
Would that be a possible explanation?
But that will be hard to fix. We have no influence about what sounds are transmitted by devices, connected to our device.
Regards,
Lothar
Hello,
That's even more interesting that with half rate there is no noise.
You may also check and test the AMR setting (AT^SCFG="Audio/AMR").
The theory is interesting.
The noise is heard when the call is established and also when this special tone is being generated and can only be stopped when some other tones passes the codec.
I was previously thinking also about the settings of the other mobile and codecs used and the frequency of the tone if it is not exceeding the frequencies that can be transmitted via the codec.
The module is a part of a gateway which is connected to PABX. Is the gateway manufactured by your company? Have you been taking into account the Audio Interface Design document while designing the gateway?
I have sent you an email - please send the number in a reply (and maybe timeslot when you don't change anything) - I'll try to hear that also.
Regards,
Bartłomiej
Hello,
I have heard the noise - it could sound as an amplified background noise.
I have also looked int this document - as I understand this it's about the background acoustic noise, which is transmitted together with the speech and in order it would not disappear when the radio transmission is cut (which according to the document can be very annoying for the listener) it is generated on the receiver side when nobody is talking on the other side.
So I'm not sure if this is a main problem here because if we have a machine that answers the call and generates sounds there should be probably no microphone connected which can catch the background noise.
Regards,
Bartłomiej
Hallo,
the audio interface is designed according to "Audio Interface Design for GSM Applications".
We also did a PCB review by Gemalto Munich before hardware release.
AMR setting (AT^SCFG="Audio/AMR") is disabled.
I think that comfort noise doesn't care about the audio hardware which cause trouble in this special case.
If i could switch off the noise generation that would probably the best. Or switch off the Voice Activity Detector (VAD). Humans need that noise for their comfort but machines doesn't ;-)
I have forwarded this thread to our module distributor to request further support.
You mentioned that the firmware is not visible in public offical releases. Maybe there is
a better firmware which fixed this thing.
Regards and wesołych świąt,
Lothar
Hello,
Maybe it would be worth trying to enable AMR.
My point was just that this noise should rather not be generated by the machine.
Nevertheless maybe it's a good moment to engage the distributor because our theoretical discussion didn't point us to any solution so far. We have 3 pieces of hardware: the module built in the gateway and the PABX - some tests with this hardware will be probably needed. If the distributor will also state that the module is guilty here they will be able to send this to the Gemalto support for further analysis.
However I'd encourage you to experiment with different SNFS settings also as there are different echo cancellation, noise reduction settings etc.
It seems that there are no newer firmware for revision 2. But there are revisions 3 and 4.
Frohe Ostern,
Bartłomiej
Hallo Lothar,
very likely your echo canceller is not good enough within the first seconds of call. After call establishment or after changing audio **** by AT^SNFS the echo canceller ***** some 100 mseconds to adapt to the acoustic environment. If this does not sucseed within the first mseconds, you get this feedback noise. Your sending tone work around (AT^SNFG) just helped the echo canceller over the first few mseconds.
Two things you can check:
1. possibly your HW produces too much clipping noise (harmonics), then the echo canceller has difficulties to adapt. You can hear this clipping noise with your ear. If you hear any clipping at all, it is already too much for your echo canceller. Then you should improve the audio path of your HW until there is no noise and clipping which could disturb the echo canceller. Your echo canceller will thank you by adapting faster and working much more smoothly.
2. This is more a work around than a fix. You could start each call with lower AT^SNFO values (e.g. 10dB lower) and then during the call you increase the volume by e.g. 10 x 1dB per 100msec.
Best regards Marten