ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2 lights were off with a 3khz tone generated from a service monitor. I see oh between 6-8 DTMF's detected over the voter channel during use.. How do you fix that issue? Alan
This has nothing to do with the RTCM. The DTMF receiver is the same one that is used in all the other channel drivers for the other types of interfaces also. When the app_rpt stuff was first being developed (10+ years ago), the default parameters for the DTMF receiver seemed too "tight" for radio use. There were a number of combinations that were found of receivers and transmitting devices (HT's mobiles, etc) that did not seem to work reliably with the parameters the way they were, so we developed the "RADIO_RELAX" set of parameters, which are more "relaxed" then the normal ones. As time has gone on, there have been cases where using these "relaxed" parameters have seemed to do more harm then good. I dont know if your case is one of those. If you wish to try, I suggest re-compiling Asterisk with the RADIO_RELAX compile parameter turned off, and see if you like it that way better. I can guarantee you that you will have less "falsing" if you do that. What I can not guarantee is that you will get all the "real" digits decoded reliably (if you do that). Jim WB6NIL From: adamson_alan@hotmail.com To: app_rpt-users@ohnosec.org Date: Sun, 3 Jun 2012 15:26:06 -0400 Subject: [App_rpt-users] RTCM falsing DTMF RTCM falsing DTMF ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2 lights were off with a 3khz tone generated from a service monitor. I see oh between 6-8 DTMF's detected over the voter channel during use…. How do you fix that issue? Alan _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
I am one of those that found setting RADIO_RELAX off works much better. TT falsing has been reduced to near zero and decoding is still as fast as I can push the buttons. One thing I found was that I had to turn on the PL filter. Before I did that TT decoding was unbearably show with RADIO_RELAX off. -- Tim :wq On Jun 3, 2012, at 12:48 PM, Jim Duuuude wrote:
This has nothing to do with the RTCM. The DTMF receiver is the same one that is used in all the other channel drivers for the other types of interfaces also.
When the app_rpt stuff was first being developed (10+ years ago), the default parameters for the DTMF receiver seemed too "tight" for radio use. There were a number of combinations that were found of receivers and transmitting devices (HT's mobiles, etc) that did not seem to work reliably with the parameters the way they were, so we developed the "RADIO_RELAX" set of parameters, which are more "relaxed" then the normal ones.
As time has gone on, there have been cases where using these "relaxed" parameters have seemed to do more harm then good. I dont know if your case is one of those. If you wish to try, I suggest re-compiling Asterisk with the RADIO_RELAX compile parameter turned off, and see if you like it that way better. I can guarantee you that you will have less "falsing" if you do that. What I can not guarantee is that you will get all the "real" digits decoded reliably (if you do that).
Jim WB6NIL
From: adamson_alan@hotmail.com To: app_rpt-users@ohnosec.org Date: Sun, 3 Jun 2012 15:26:06 -0400 Subject: [App_rpt-users] RTCM falsing DTMF
ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2 lights were off with a 3khz tone generated from a service monitor. I see oh between 6-8 DTMF's detected over the voter channel during use…. How do you fix that issue? Alan
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
How we go about making this change? I have been having this issue at all my sites. On 6/3/2012 1:51 PM, Tim Sawyer wrote:
I am one of those that found setting RADIO_RELAX off works much better. TT falsing has been reduced to near zero and decoding is still as fast as I can push the buttons.
One thing I found was that I had to turn on the PL filter. Before I did that TT decoding was unbearably show with RADIO_RELAX off. -- Tim :wq
On Jun 3, 2012, at 12:48 PM, Jim Duuuude wrote:
This has nothing to do with the RTCM. The DTMF receiver is the same one that is used in all the other channel drivers for the other types of interfaces also.
When the app_rpt stuff was first being developed (10+ years ago), the default parameters for the DTMF receiver seemed too "tight" for radio use. There were a number of combinations that were found of receivers and transmitting devices (HT's mobiles, etc) that did not seem to work reliably with the parameters the way they were, so we developed the "RADIO_RELAX" set of parameters, which are more "relaxed" then the normal ones.
As time has gone on, there have been cases where using these "relaxed" parameters have seemed to do more harm then good. I dont know if your case is one of those. If you wish to try, I suggest re-compiling Asterisk with the RADIO_RELAX compile parameter turned off, and see if you like it that way better. I can guarantee you that you will have less "falsing" if you do that. What I can not guarantee is that you will get all the "real" digits decoded reliably (if you do that).
Jim WB6NIL
------------------------------------------------------------------------ From: adamson_alan@hotmail.com <mailto:adamson_alan@hotmail.com> To: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org> Date: Sun, 3 Jun 2012 15:26:06 -0400 Subject: [App_rpt-users] RTCM falsing DTMF
ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2lightswere off with a 3khz tone generated from a service monitor.
I see oh between 6-8 DTMF's detected over the voter channel during use.... How do you fix that issue? Alan
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
First I would update from svn, might as well as you have to recompile anyway. The instructions to update from svn are at https://allstarlink.org/support.html#astupgrade Before you do the make up grade edit /usr/src/astsrc/asterisk/menuselect.makeopts change the line that says MENUSELECT_CFLAGS=RADIO_RELAX LOADABLE_MODULES to MENUSELECT_CFLAGS=LOADABLE_MODULES then do make upgrade or make upgrade-acid as appropriate. -- Tim :wq On Jun 3, 2012, at 1:51 PM, Tim Sawyer wrote:
I am one of those that found setting RADIO_RELAX off works much better. TT falsing has been reduced to near zero and decoding is still as fast as I can push the buttons.
One thing I found was that I had to turn on the PL filter. Before I did that TT decoding was unbearably show with RADIO_RELAX off. -- Tim :wq
On Jun 3, 2012, at 12:48 PM, Jim Duuuude wrote:
This has nothing to do with the RTCM. The DTMF receiver is the same one that is used in all the other channel drivers for the other types of interfaces also.
When the app_rpt stuff was first being developed (10+ years ago), the default parameters for the DTMF receiver seemed too "tight" for radio use. There were a number of combinations that were found of receivers and transmitting devices (HT's mobiles, etc) that did not seem to work reliably with the parameters the way they were, so we developed the "RADIO_RELAX" set of parameters, which are more "relaxed" then the normal ones.
As time has gone on, there have been cases where using these "relaxed" parameters have seemed to do more harm then good. I dont know if your case is one of those. If you wish to try, I suggest re-compiling Asterisk with the RADIO_RELAX compile parameter turned off, and see if you like it that way better. I can guarantee you that you will have less "falsing" if you do that. What I can not guarantee is that you will get all the "real" digits decoded reliably (if you do that).
Jim WB6NIL
From: adamson_alan@hotmail.com To: app_rpt-users@ohnosec.org Date: Sun, 3 Jun 2012 15:26:06 -0400 Subject: [App_rpt-users] RTCM falsing DTMF
ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2 lights were off with a 3khz tone generated from a service monitor. I see oh between 6-8 DTMF's detected over the voter channel during use…. How do you fix that issue? Alan
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
// My fix for the DTMF falsing problem is to make one change to the file dsp.c // /usr/src/trunk/asterisk/main/dsp.c // Change this line in dsp.c (find the line by searching for 26.0) #define DTMF_TO_TOTAL_ENERGY ((digitmode & DSP_DIGITMODE_RELAXDTMF) ? 26.0 : 42.0) // To look like this line #define DTMF_TO_TOTAL_ENERGY ((digitmode & DSP_DIGITMODE_RELAXDTMF) ? 38.0 : 42.0) // The result for our 2 repeaters, // one on VHF using the USB fob, // and the other on UHF using multiple RTCM's, // is a reduction of DTMF falsing from hundreds per day to only 2 or 3 per day and // no problems decoding DTMF. // I do not turn off RADIO_RELAX because doing so caused problems with DTMF decode. // The only problem with my fix is that I have to re-edit dsp.c every time I update. // Remember to do the usual "makes" after editing this file. On Sun, Jun 3, 2012 at 4:01 PM, Tim Sawyer <tim.sawyer@me.com> wrote:
First I would update from svn, might as well as you have to recompile anyway. The instructions to update from svn are at https://allstarlink.org/support.html#astupgrade
Before you do the make up grade edit /usr/src/astsrc/asterisk/menuselect.makeopts change the line that says
MENUSELECT_CFLAGS=RADIO_RELAX LOADABLE_MODULES to MENUSELECT_CFLAGS=LOADABLE_MODULES
then do make upgrade or make upgrade-acid as appropriate. -- Tim :wq
On Jun 3, 2012, at 1:51 PM, Tim Sawyer wrote:
I am one of those that found setting RADIO_RELAX off works much better. TT falsing has been reduced to near zero and decoding is still as fast as I can push the buttons.
One thing I found was that I had to turn on the PL filter. Before I did that TT decoding was unbearably show with RADIO_RELAX off. -- Tim :wq
On Jun 3, 2012, at 12:48 PM, Jim Duuuude wrote:
This has nothing to do with the RTCM. The DTMF receiver is the same one that is used in all the other channel drivers for the other types of interfaces also.
When the app_rpt stuff was first being developed (10+ years ago), the default parameters for the DTMF receiver seemed too "tight" for radio use. There were a number of combinations that were found of receivers and transmitting devices (HT's mobiles, etc) that did not seem to work reliably with the parameters the way they were, so we developed the "RADIO_RELAX" set of parameters, which are more "relaxed" then the normal ones.
As time has gone on, there have been cases where using these "relaxed" parameters have seemed to do more harm then good. I dont know if your case is one of those. If you wish to try, I suggest re-compiling Asterisk with the RADIO_RELAX compile parameter turned off, and see if you like it that way better. I can guarantee you that you will have less "falsing" if you do that. What I can not guarantee is that you will get all the "real" digits decoded reliably (if you do that).
Jim WB6NIL
------------------------------ From: adamson_alan@hotmail.com To: app_rpt-users@ohnosec.org Date: Sun, 3 Jun 2012 15:26:06 -0400 Subject: [App_rpt-users] RTCM falsing DTMF
ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2 lights were off with a 3khz tone generated from a service monitor.
I see oh between 6-8 DTMF's detected over the voter channel during use…. How do you fix that issue? Alan
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
What one says on the internet never goes away. I posted that before I found that not filtering PL was causing a problem. That older post is still valid if RADIO_RELAX is too loose for your system. -- Tim :wq On Jun 3, 2012, at 10:00 PM, Chuck Henderson wrote:
// My fix for the DTMF falsing problem is to make one change to the file dsp.c // /usr/src/trunk/asterisk/main/dsp.c // Change this line in dsp.c (find the line by searching for 26.0) #define DTMF_TO_TOTAL_ENERGY ((digitmode & DSP_DIGITMODE_RELAXDTMF) ? 26.0 : 42.0) // To look like this line #define DTMF_TO_TOTAL_ENERGY ((digitmode & DSP_DIGITMODE_RELAXDTMF) ? 38.0 : 42.0) // The result for our 2 repeaters, // one on VHF using the USB fob, // and the other on UHF using multiple RTCM's, // is a reduction of DTMF falsing from hundreds per day to only 2 or 3 per day and // no problems decoding DTMF. // I do not turn off RADIO_RELAX because doing so caused problems with DTMF decode. // The only problem with my fix is that I have to re-edit dsp.c every time I update. // Remember to do the usual "makes" after editing this file.
On Sun, Jun 3, 2012 at 4:01 PM, Tim Sawyer <tim.sawyer@me.com> wrote: First I would update from svn, might as well as you have to recompile anyway. The instructions to update from svn are at https://allstarlink.org/support.html#astupgrade
Before you do the make up grade edit /usr/src/astsrc/asterisk/menuselect.makeopts change the line that says
MENUSELECT_CFLAGS=RADIO_RELAX LOADABLE_MODULES to MENUSELECT_CFLAGS=LOADABLE_MODULES
then do make upgrade or make upgrade-acid as appropriate. -- Tim :wq
On Jun 3, 2012, at 1:51 PM, Tim Sawyer wrote:
I am one of those that found setting RADIO_RELAX off works much better. TT falsing has been reduced to near zero and decoding is still as fast as I can push the buttons.
One thing I found was that I had to turn on the PL filter. Before I did that TT decoding was unbearably show with RADIO_RELAX off. -- Tim :wq
On Jun 3, 2012, at 12:48 PM, Jim Duuuude wrote:
This has nothing to do with the RTCM. The DTMF receiver is the same one that is used in all the other channel drivers for the other types of interfaces also.
When the app_rpt stuff was first being developed (10+ years ago), the default parameters for the DTMF receiver seemed too "tight" for radio use. There were a number of combinations that were found of receivers and transmitting devices (HT's mobiles, etc) that did not seem to work reliably with the parameters the way they were, so we developed the "RADIO_RELAX" set of parameters, which are more "relaxed" then the normal ones.
As time has gone on, there have been cases where using these "relaxed" parameters have seemed to do more harm then good. I dont know if your case is one of those. If you wish to try, I suggest re-compiling Asterisk with the RADIO_RELAX compile parameter turned off, and see if you like it that way better. I can guarantee you that you will have less "falsing" if you do that. What I can not guarantee is that you will get all the "real" digits decoded reliably (if you do that).
Jim WB6NIL
From: adamson_alan@hotmail.com To: app_rpt-users@ohnosec.org Date: Sun, 3 Jun 2012 15:26:06 -0400 Subject: [App_rpt-users] RTCM falsing DTMF
ok, so is it normal for the RTCM to get false DTMF when voice is doing over the link? I adjusted the RX audio so that the 2 lights were off with a 3khz tone generated from a service monitor. I see oh between 6-8 DTMF's detected over the voter channel during use…. How do you fix that issue? Alan
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
participants (5)
-
Alan Adamson -
Chuck Henderson -
Jim Duuuude -
Sione Ragle -
Tim Sawyer