Doug, First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with. I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better. Thanks! -Mike On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote:

------------------------------ From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line. On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote:

------------------------------ From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

OK, so I did some more testing. I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high. Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops. Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone.. Are there any settings that control this? The LED on the radio (and hence my COR input) is controlled by noise squelch opening. On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 10:18:19 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line.

On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote:

------------------------------ From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

Doug, this behavior happens even if I manually toggle the COR independent of the radio and audio so unless I'm not understanding, I can't see this being the radio. I tried changing unkeywait to 1000 but made no difference other than extending the time the PTT is active for the courtesy tone, and thus extending the window in which the COR line going high will be ignored. Seems that anything that extends the time that the PTT is active for the courtesy tone also extends the time that the COR is ignored. Just to make sure I'm not doing anything stupid or have an unconventional setuo,. my test setup is: HT -> DMK URI -> BBB (node 1998) -> ethernet -> Allstar on a VM (node 1620) -> IAX -> Zioper soft phone on laptop HT has audio in/out connected to the URI. PTT from the URI is not connected to the HT while testing. Signal from receive LED on the HT goes to COR URI input. I have the HT tuned to the weather frequency and I'm making/breaking the antenna connection to simulate picket fencing and I'm monitoring the audio received by the URI/BBB on the softphone. Bottom line is if the COR line drops, the courtesy pause and tone is instantly triggered, triggering the URI PTT. This works. But, if while the PTT is active, the COR line goes high again, the audio through the URI is not routed through until the COR line goes low* and high again after the PTT/courtesy tone is done transmitting. * when going low after getting ignored going high, no courtesy tone is triggered. Would it be useful/appropriate change carrierfrom to "no" and instead set ctcssfrom = usb and switch the radio output to the ctcss input on the URI and see if the problem still exists? Thanks for all the help! -Mike On Fri, Sep 26, 2014 at 8:37 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

You can try the changing the courtesy time wait then set back to duplex=1

The wait-times section This section allows the wait times for voice responses and other audio telemetry events to be adjusted. All wait times are in milliseconds.

*telemwait* sets the time before sending the general audio telemetry responses used in the application which are not specifically defined below *idwait* sets the time to wait before sending ID audio telemetry *unkeywait* sets the amount of time to wait before sending the courtesy tone. This can be used to ensure breaking stations can get their turn *calltermwait* sets the amount of time between an autopatch disconnect and the audio telemetry message indicating the call has been terminated

The unkeywait is the one to mess with. It is 400ms on the BBB by default. Make it longer like 1000 so it spans the dropout period you are seeing. Experiment with times.

If that doesn't work I really think you should try a different radio. My thoughts are that it is some kind of recovery issue with TX.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 18:59:26 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

OK, so I did some more testing.

I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high.

Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops.

Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone..

Are there any settings that control this?

The LED on the radio (and hence my COR input) is controlled by noise squelch opening.

On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 10:18:19 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line.

On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote:

------------------------------ From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

I'm starting to think its the URI. First, I got rid of all the components (transistor and RC) because they made little difference and don't want the added complexity. I went back to usbinvert. I brought the radio and URI to the 1620 node on the VM (basically a stock install of ACID) and connected Zoiper directly to the node. This left the BBB and its configuration completely out of the loop and I still got the same behavior. Next I reconnected the URI and radio to the BBB and connected directly to it via Zioper (I didn't do this before because I was having trouble connecting Zoiper to the BBB, but I got that figured out) and it's still the same behavior. And just to eliminate the radio, I disconnected it completely, connected the COR input to a pullup, and grounded it by hand. When I ground the COR line (usbinvert), I can hear slight background noise through Zoiper and when I unground it, the courtesy tone is triggered (URI PTT active as well) and then the background noise goes away when the CT is done. But if I ground the COR line while the courtesy tone is playing, it ignores the COR and does not pass audio to zioper until I cycle the COR line again. And finally I tried using the CTCSS input, same exact behavior. I know there is a URI test program from DMK, but I didn't really see a way to simply read out the status of the inputs, just automated tests requiring a loopback. -Mike On Fri, Sep 26, 2014 at 9:47 PM, Doug Crompton <doug@crompton.com> wrote:

The ctcss and carrier from are just bits so technically you could use either one and it would work the same. You do need to set the one you are not using to none. We always use carrierfrom even though it is ctcss that is driving it.

I tried what you are doing here. I listened to myself iaxrpt from a distant node. Then I key the local PTT on my handheld into my local node. I immediately unkey and then keyed again before I heard the courtesy tone and it worked fine. Tried it several times.

Why don't you eliminate the 1620 node in the test and iaxrpt directly to 1998 to see what happens there.

This is acting like what you would see with an rxdelay setting but it should be 0 by default unless you somehow got that into your config. Specifically say rxdelay=0 in the 1998 rpt.conf context to be sure.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 21:15:03 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug, this behavior happens even if I manually toggle the COR independent of the radio and audio so unless I'm not understanding, I can't see this being the radio.

I tried changing unkeywait to 1000 but made no difference other than extending the time the PTT is active for the courtesy tone, and thus extending the window in which the COR line going high will be ignored. Seems that anything that extends the time that the PTT is active for the courtesy tone also extends the time that the COR is ignored.

Just to make sure I'm not doing anything stupid or have an unconventional setuo,. my test setup is:

HT -> DMK URI -> BBB (node 1998) -> ethernet -> Allstar on a VM (node 1620) -> IAX -> Zioper soft phone on laptop

HT has audio in/out connected to the URI. PTT from the URI is not connected to the HT while testing. Signal from receive LED on the HT goes to COR URI input.

I have the HT tuned to the weather frequency and I'm making/breaking the antenna connection to simulate picket fencing and I'm monitoring the audio received by the URI/BBB on the softphone.

Bottom line is if the COR line drops, the courtesy pause and tone is instantly triggered, triggering the URI PTT. This works. But, if while the PTT is active, the COR line goes high again, the audio through the URI is not routed through until the COR line goes low* and high again after the PTT/courtesy tone is done transmitting.

* when going low after getting ignored going high, no courtesy tone is triggered.

Would it be useful/appropriate change carrierfrom to "no" and instead set ctcssfrom = usb and switch the radio output to the ctcss input on the URI and see if the problem still exists?

Thanks for all the help! -Mike

On Fri, Sep 26, 2014 at 8:37 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

You can try the changing the courtesy time wait then set back to duplex=1

The wait-times section This section allows the wait times for voice responses and other audio telemetry events to be adjusted. All wait times are in milliseconds.

*telemwait* sets the time before sending the general audio telemetry responses used in the application which are not specifically defined below *idwait* sets the time to wait before sending ID audio telemetry *unkeywait* sets the amount of time to wait before sending the courtesy tone. This can be used to ensure breaking stations can get their turn *calltermwait* sets the amount of time between an autopatch disconnect and the audio telemetry message indicating the call has been terminated

The unkeywait is the one to mess with. It is 400ms on the BBB by default. Make it longer like 1000 so it spans the dropout period you are seeing. Experiment with times.

If that doesn't work I really think you should try a different radio. My thoughts are that it is some kind of recovery issue with TX.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 18:59:26 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

OK, so I did some more testing.

I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high.

Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops.

Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone..

Are there any settings that control this?

The LED on the radio (and hence my COR input) is controlled by noise squelch opening.

On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 10:18:19 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line.

On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote:

------------------------------ From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 DougWA3DSPhttp://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

I should further clarify the "duplex=1 mode" settings. This is the mode when in rpt.conf has duplex set to 1 and usbradio has duplex=0. This config is a half duplex mode but gives a courtesy beep and tail after RX activity. The duplex=1 mode in rpt.conf tells the node it is in half duplex mode but sends a courtesy beep and a tail after it receives a signal from the node receiver. The duplex=0 in usbradio tells the URI hardware that your radio is only half duplex and cannot transmit while receiving. The setup for half duplex nodes is kinda nice as it tells the user that they are making the sinplex node. A setting of duplex =0 in rpt conf and duplex =0 in usbradio is the same as above with no courtesy tone and no tail. It works just as well as above but there is no local feedback to let you know if you are hitting the simplex node or not. Jon VA3RQ On 9/27/2014 12:11 PM, REDBUTTON_CTRL wrote:

Ok In a bid to understand what it is you think is wrong let me clarify from what you are saying below. Your node is set up for duplex=1 (half duplex with courtesy beep and tail) right? And the problem you are seeing is the node will not receive a signal when it is transmitting the courtesy beep or tail - right?

If the above is correct, then this configuration cannot receive a signal while it is transmitting. This is normal for this configuration. If your radio is portable or mobile radio, then your radio can only receive or transmit but not both simultaneously. So in duplex =1 mode the URI assumes your receiver is active if the node isnt transmitting. So the node ignores all receiver activity while its transmitting. Once the tail is gone then it will listen to thereceiver cor line.

For some reason from you explanation below you are expecting the node to receive in full duplex. Unless the radio you have connected is capable of full duplex, this wont work. If the radio connected to the URI is a pair of radios or a duplexed base station and if you set the duplex setting to duplex=2 in rpt conf and duplex =1 in usbradio then it will receive while its transmitting.

Hope I understand this right and this helps.

Jon VA3RQ

On 9/27/2014 11:47 AM, Mike M wrote:

...

I'm starting to think its the URI.

First, I got rid of all the components (transistor and RC) because they made little difference and don't want the added complexity. I went back to usbinvert. I brought the radio and URI to the 1620 node on the VM (basically a stock install of ACID) and connected Zoiper directly to the node. This left the BBB and its configuration completely out of the loop and I still got the same behavior.

Next I reconnected the URI and radio to the BBB and connected directly to it via Zioper (I didn't do this before because I was having trouble connecting Zoiper to the BBB, but I got that figured out) and it's still the same behavior.

And just to eliminate the radio, I disconnected it completely, connected the COR input to a pullup, and grounded it by hand. When I ground the COR line (usbinvert), I can hear slight background noise through Zoiper and when I unground it, the courtesy tone is triggered (URI PTT active as well) and then the background noise goes away when the CT is done. But if I ground the COR line while the courtesy tone is playing, it ignores the COR and does not pass audio to zioper until I cycle the COR line again.

And finally I tried using the CTCSS input, same exact behavior.

I know there is a URI test program from DMK, but I didn't really see a way to simply read out the status of the inputs, just automated tests requiring a loopback.

-Mike

sage to the list detailing the problem.

---

App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

Oh, hmm, I think I see what you are saying. I knew it was going to be something stupid. The problem here isn't the URI, software, or the radio. It's that I disconnected PTT to the radio for testing. I failed to realize, which you just pointed out, that if the PTT is asserted, and actually connected to the radio, the radio's COR line will drop and will not return until the PTT is released. Basically all this time I've been testing a scenario that will never happen (COR asserted from radio while PTT is asserted from URI). Man I feel dumb. Very sorry for taking up peoples time and the list bandwidth and a very big thank you to all that helped. -Mike On Sun, Sep 28, 2014 at 9:52 AM, Mike M <kf7mbk@w7ara.net> wrote:

...

Your node is set up for duplex=1 (half duplex with courtesy beep and tail) right?

Correct, in both conf files.

...

And the problem you are seeing is the node will not receive a signal when it is transmitting the courtesy beep or tail - right?

While true, this isn't the actual problem.

I drew a diagram which will hopefully be worth 1000 words. https://lh3.googleusercontent.com/-q3CmjOEBsMA/VCg72OZCNbI/AAAAAAAAPSc/wCZoJ...

Though I just realized, I may have the order of the silence and the tone backwards. Regardless, it is not the important issue.

-Mike

From: REDBUTTON_CTRL <jrorke@cogeco.ca> To: app_rpt-users@ohnosec.org Cc: Date: Sat, 27 Sep 2014 12:11:19 -0400 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused Ok In a bid to understand what it is you think is wrong let me clarify from what you are saying below. Your node is set up for duplex=1 (half duplex with courtesy beep and tail) right? And the problem you are seeing is the node will not receive a signal when it is transmitting the courtesy beep or tail - right?

If the above is correct, then this configuration cannot receive a signal while it is transmitting. This is normal for this configuration. If your radio is portable or mobile radio, then your radio can only receive or transmit but not both simultaneously. So in duplex =1 mode the URI assumes your receiver is active if the node isnt transmitting. So the node ignores all receiver activity while its transmitting. Once the tail is gone then it will listen to thereceiver cor line.

For some reason from you explanation below you are expecting the node to receive in full duplex. Unless the radio you have connected is capable of full duplex, this wont work. If the radio connected to the URI is a pair of radios or a duplexed base station and if you set the duplex setting to duplex=2 in rpt conf and duplex =1 in usbradio then it will receive while its transmitting.

Hope I understand this right and this helps.

Jon VA3RQ

On Sat, Sep 27, 2014 at 8:47 AM, Mike M <kf7mbk@w7ara.net> wrote:

...

I'm starting to think its the URI.

First, I got rid of all the components (transistor and RC) because they made little difference and don't want the added complexity. I went back to usbinvert. I brought the radio and URI to the 1620 node on the VM (basically a stock install of ACID) and connected Zoiper directly to the node. This left the BBB and its configuration completely out of the loop and I still got the same behavior.

Next I reconnected the URI and radio to the BBB and connected directly to it via Zioper (I didn't do this before because I was having trouble connecting Zoiper to the BBB, but I got that figured out) and it's still the same behavior.

And just to eliminate the radio, I disconnected it completely, connected the COR input to a pullup, and grounded it by hand. When I ground the COR line (usbinvert), I can hear slight background noise through Zoiper and when I unground it, the courtesy tone is triggered (URI PTT active as well) and then the background noise goes away when the CT is done. But if I ground the COR line while the courtesy tone is playing, it ignores the COR and does not pass audio to zioper until I cycle the COR line again.

And finally I tried using the CTCSS input, same exact behavior.

I know there is a URI test program from DMK, but I didn't really see a way to simply read out the status of the inputs, just automated tests requiring a loopback.

-Mike

On Fri, Sep 26, 2014 at 9:47 PM, Doug Crompton <doug@crompton.com> wrote:

...

The ctcss and carrier from are just bits so technically you could use either one and it would work the same. You do need to set the one you are not using to none. We always use carrierfrom even though it is ctcss that is driving it.

I tried what you are doing here. I listened to myself iaxrpt from a distant node. Then I key the local PTT on my handheld into my local node. I immediately unkey and then keyed again before I heard the courtesy tone and it worked fine. Tried it several times.

Why don't you eliminate the 1620 node in the test and iaxrpt directly to 1998 to see what happens there.

This is acting like what you would see with an rxdelay setting but it should be 0 by default unless you somehow got that into your config. Specifically say rxdelay=0 in the 1998 rpt.conf context to be sure.

73 Doug WA3DSP http://www.crompton.com/hamradio

________________________________ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 21:15:03 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug, this behavior happens even if I manually toggle the COR independent of the radio and audio so unless I'm not understanding, I can't see this being the radio.

I tried changing unkeywait to 1000 but made no difference other than extending the time the PTT is active for the courtesy tone, and thus extending the window in which the COR line going high will be ignored. Seems that anything that extends the time that the PTT is active for the courtesy tone also extends the time that the COR is ignored.

Just to make sure I'm not doing anything stupid or have an unconventional setuo,. my test setup is:

HT -> DMK URI -> BBB (node 1998) -> ethernet -> Allstar on a VM (node 1620) -> IAX -> Zioper soft phone on laptop

HT has audio in/out connected to the URI. PTT from the URI is not connected to the HT while testing. Signal from receive LED on the HT goes to COR URI input.

I have the HT tuned to the weather frequency and I'm making/breaking the antenna connection to simulate picket fencing and I'm monitoring the audio received by the URI/BBB on the softphone.

Bottom line is if the COR line drops, the courtesy pause and tone is instantly triggered, triggering the URI PTT. This works. But, if while the PTT is active, the COR line goes high again, the audio through the URI is not routed through until the COR line goes low* and high again after the PTT/courtesy tone is done transmitting.

* when going low after getting ignored going high, no courtesy tone is triggered.

Would it be useful/appropriate change carrierfrom to "no" and instead set ctcssfrom = usb and switch the radio output to the ctcss input on the URI and see if the problem still exists?

Thanks for all the help! -Mike

On Fri, Sep 26, 2014 at 8:37 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

You can try the changing the courtesy time wait then set back to duplex=1

The wait-times section This section allows the wait times for voice responses and other audio telemetry events to be adjusted. All wait times are in milliseconds.

telemwait sets the time before sending the general audio telemetry responses used in the application which are not specifically defined below idwait sets the time to wait before sending ID audio telemetry unkeywait sets the amount of time to wait before sending the courtesy tone. This can be used to ensure breaking stations can get their turn calltermwait sets the amount of time between an autopatch disconnect and the audio telemetry message indicating the call has been terminated

The unkeywait is the one to mess with. It is 400ms on the BBB by default. Make it longer like 1000 so it spans the dropout period you are seeing. Experiment with times.

If that doesn't work I really think you should try a different radio. My thoughts are that it is some kind of recovery issue with TX.

73 Doug WA3DSP http://www.crompton.com/hamradio

________________________________ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 18:59:26 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

OK, so I did some more testing.

I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high.

Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops.

Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone..

Are there any settings that control this?

The LED on the radio (and hence my COR input) is controlled by noise squelch opening.

On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try?

73 Doug WA3DSP http://www.crompton.com/hamradio

________________________________ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 10:18:19 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line.

On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

73 Doug WA3DSP http://www.crompton.com/hamradio

________________________________ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote:

________________________________ From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

73 Doug WA3DSP http://www.crompton.com/hamradio

________________________________ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

What HT brand/model are you using, just out of curiosity? On 9/26/2014 11:37 PM, Doug Crompton wrote:

Mike,

You can try the changing the courtesy time wait then set back to duplex=1

The wait-times section This section allows the wait times for voice responses and other audio telemetry events to be adjusted. All wait times are in milliseconds.

*/telemwait/* sets the time before sending the general audio telemetry responses used in the application which are not specifically defined below */idwait/* sets the time to wait before sending ID audio telemetry */unkeywait/* sets the amount of time to wait before sending the courtesy tone. This can be used to ensure breaking stations can get their turn */calltermwait/* sets the amount of time between an autopatch disconnect and the audio telemetry message indicating the call has been terminated

The unkeywait is the one to mess with. It is 400ms on the BBB by default. Make it longer like 1000 so it spans the dropout period you are seeing. Experiment with times.

If that doesn't work I really think you should try a different radio. My thoughts are that it is some kind of recovery issue with TX.

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 18:59:26 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

OK, so I did some more testing.

I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high.

Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops.

Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone..

Are there any settings that control this?

The LED on the radio (and hence my COR input) is controlled by noise squelch opening.

On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> wrote:

Mike,

Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try?

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Date: Fri, 26 Sep 2014 10:18:19 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com <mailto:doug@crompton.com> CC: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line.

On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com <mailto:doug@crompton.com> CC: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> wrote:

------------------------------------------------------------------------ From: doug@crompton.com <mailto:doug@crompton.com> To: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org> Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ 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 To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

Try this in usbradio.conf (this is not recognized in simpleusb): rxondelay=25 ; This will instruct the usbradio driver to ignore the COR line ; for a specified number of 20mSec intervals following the release of PTT. On 9/26/2014 11:37 PM, Doug Crompton wrote:

Mike,

You can try the changing the courtesy time wait then set back to duplex=1

The wait-times section This section allows the wait times for voice responses and other audio telemetry events to be adjusted. All wait times are in milliseconds.

*/telemwait/* sets the time before sending the general audio telemetry responses used in the application which are not specifically defined below */idwait/* sets the time to wait before sending ID audio telemetry */unkeywait/* sets the amount of time to wait before sending the courtesy tone. This can be used to ensure breaking stations can get their turn */calltermwait/* sets the amount of time between an autopatch disconnect and the audio telemetry message indicating the call has been terminated

The unkeywait is the one to mess with. It is 400ms on the BBB by default. Make it longer like 1000 so it spans the dropout period you are seeing. Experiment with times.

If that doesn't work I really think you should try a different radio. My thoughts are that it is some kind of recovery issue with TX.

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 18:59:26 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org

OK, so I did some more testing.

I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high.

Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops.

Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone..

Are there any settings that control this?

The LED on the radio (and hence my COR input) is controlled by noise squelch opening.

On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> wrote:

Mike,

Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try?

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Date: Fri, 26 Sep 2014 10:18:19 -0700

Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com <mailto:doug@crompton.com> CC: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>

The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line.

On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> wrote:

Mike,

Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail.

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com <mailto:doug@crompton.com> CC: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>

Doug,

First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with.

I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better.

Thanks! -Mike

On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> wrote:

------------------------------------------------------------------------ From: doug@crompton.com <mailto:doug@crompton.com> To: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400

That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that.

I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out.

Also I assume you are not using any rxdelay?

*73 Doug WA3DSP http://www.crompton.com/hamradio*

------------------------------------------------------------------------ From: kf7mbk@w7ara.net <mailto:kf7mbk@w7ara.net> Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org> Subject: [App_rpt-users] Fwd: COR signal getting confused

Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email.

I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it.

I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.)

Linked is a scope image.

https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb...

Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low.

Anyone ever experience this and/or have ideas on how to fix it?

Thanks.

Mike KF7MBK

_______________________________________________ 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 To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.

rxdelay delays qualifying the COS signal until the number of milliseconds after PTT release. This would be true for the courtesy tone also because any TX could cause a false COS trigger if you had that problem. Maybe you just need to disable the courtesy tone. 73 Doug WA3DSP http://www.crompton.com/hamradio From: doug@crompton.com To: app_rpt-users@ohnosec.org Date: Sat, 27 Sep 2014 00:49:15 -0400 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused That command does work in simpleusb also but I think it is the opposite that is the problem. It is not responding. Worth a try I suppose. 73 Doug WA3DSP http://www.crompton.com/hamradio Date: Sat, 27 Sep 2014 00:32:19 -0400 From: kp4tr.ramon@gmail.com To: doug@crompton.com; kf7mbk@w7ara.net CC: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Fwd: COR signal getting confused Try this in usbradio.conf (this is not recognized in simpleusb): rxondelay=25 ; This will instruct the usbradio driver to ignore the COR line ; for a specified number of 20mSec intervals following the release of PTT. On 9/26/2014 11:37 PM, Doug Crompton wrote: Mike, You can try the changing the courtesy time wait then set back to duplex=1 The wait-times section This section allows the wait times for voice responses and other audio telemetry events to be adjusted. All wait times are in milliseconds. telemwait sets the time before sending the general audio telemetry responses used in the application which are not specifically defined below idwait sets the time to wait before sending ID audio telemetry unkeywait sets the amount of time to wait before sending the courtesy tone. This can be used to ensure breaking stations can get their turn calltermwait sets the amount of time between an autopatch disconnect and the audio telemetry message indicating the call has been terminated The unkeywait is the one to mess with. It is 400ms on the BBB by default. Make it longer like 1000 so it spans the dropout period you are seeing. Experiment with times. If that doesn't work I really think you should try a different radio. My thoughts are that it is some kind of recovery issue with TX. 73 Doug WA3DSP http://www.crompton.com/hamradio From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 18:59:26 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org OK, so I did some more testing. I have routed the signal out of the radio to an NPN and switched from usbinvert to usb as suggested. This made little difference, but in this configuration I could make the RC work a little better bridging the dropouts. But still would end up not detecting carrier after a quick dropout even though the COR signal into the dongle was high. Duplex = 0 seems to eliminate the problem. Is there a setting to tell it how long to wait after COR dropped to start transmitting the courtesy tone? (though I suppose that would defeat the purpose of the duplex=1 setting) Note that I have the PTT disconnected for testing, so all I see is the red LED come on as soon as the COR out of the radio drops. Actually as I'm typing this and playing with it, I just noticed it appears if the COR is restored ANY time the PTT is active for the courtesy tone, it will ignore the COR line until it's dropped and brought back up AFTER the PTT is done. This behavior seems VERY repeatable, even with a cleanly restored COR signal, So it may have nothing to do with quick dropouts and everything to do with the courtesy tone.. Are there any settings that control this? The LED on the radio (and hence my COR input) is controlled by noise squelch opening. On Fri, Sep 26, 2014 at 3:05 PM, Doug Crompton <doug@crompton.com> wrote: Mike, Are you using PL or noise squelch or both? Like I said I have not seen this problem and I am using basically stock timing. Every time the PL or squelch goes untrue for a certain (short) duration you should hear a courtesy tone. Perhpas you should try duplex=0 just to see if there is an issue with TX recovery. Do you have another radio you can try? 73 Doug WA3DSP http://www.crompton.com/hamradio From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 10:18:19 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org The scope image in the OP shows there doesn't appear to be a problem with pulling hi or low, The transitions (without the RC) are very clean and go all the way to ground.. It seems like the URI is doing edge detection instead of level detection, and it's just missing fast edges. Wasn't sure if this was something that could be tweaked in software or if I'll have to put some external debounce logic on the line. On Fri, Sep 26, 2014 at 10:07 AM, Doug Crompton <doug@crompton.com> wrote: Mike, Before you change any timing make sure as Jon pointed out that your COS signal is going hard high and low on signal and non-signal. You might need a pullup. The URI is kind of weak in that regard. It should be TTL levels <.5 volt low and >2.5 volt high and preferably rail to rail. 73 Doug WA3DSP http://www.crompton.com/hamradio From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 09:56:21 -0700 Subject: Re: [App_rpt-users] Fwd: COR signal getting confused To: doug@crompton.com CC: app_rpt-users@ohnosec.org Doug, First: thanks for the excellent writeup on getting allstar running on the BBB. I used it to get up and running very quickly and is the setup I am having this issue with. I am running duplex =1 as well. I have not changed any timing values, (I'm essentially running the as-installed setup from the install image on your site) but I will take a look at them and see if I can make some changes for the better. Thanks! -Mike On Fri, Sep 26, 2014 at 9:49 AM, Doug Crompton <doug@crompton.com> wrote: From: doug@crompton.com To: kf7mbk@w7ara.net Subject: RE: [App_rpt-users] Fwd: COR signal getting confused Date: Fri, 26 Sep 2014 12:46:14 -0400 That is very strange. Have you changed any of the default timing values? Are you using simplex/duplex? Courtesy tone? Timing values could effect that. I use simplex with courtesy tone (duplex=1 in rpt.conf) on several nodes and I have never seen that problem. I have one user who has a signal like you describe. He walks in a park with a handheld and he is often in and out. Also I assume you are not using any rxdelay? 73 Doug WA3DSP http://www.crompton.com/hamradio From: kf7mbk@w7ara.net Date: Fri, 26 Sep 2014 08:50:51 -0700 To: app_rpt-users@ohnosec.org Subject: [App_rpt-users] Fwd: COR signal getting confused Resending since my initial post has been pending moderation for 2 days now and got no reply from the list owner email. I have modified an HT to bring out the receive LED signal and use it as the COR input to a DMK URI. It is a digital signal as viewed on a scope (i.e. very short slope in the transitions) This seems like it would work well and it does on strong signals. But on marginal signals where the LED may blink on and off quickly (like during picket fencing), it seems to confuse the URI (or the software) were it will start off good, but then a quick dropout of the COR signal will cause the software to no longer detect carrier, even though the signal on the COR input has been restored. Even if the input is solid high (or low in my case, I'm using usbinvert) it will not detect a carrier until there is another dropout of adequate time to "reset" it. I've tried putting a simple RC on the input but it didn't really help much. Seems the URI (or software) needs a significant minimum time between transitions to properly detect them, long enough that it would delay the carrier detection too much without a circuit more complex than an RC (i.e. something that would allow instant keyup, but delay the key down.) Linked is a scope image. https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvb... Carrier was detected until this signal dropout event. Ch A is my RC filtered signal sent to the URI, Ch B is the signal out of the radio. Carrier was not detected after the 5th dropout even though the signal remained low. Anyone ever experience this and/or have ideas on how to fix it? Thanks. Mike KF7MBK _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. < /div

_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.