|
I'm one of these people--I'm sure you know at least ten--who don't like squelch crashes and who think reverse-burst on CTCSS or DCS is the way to eliminate them. Therefore, imagine my surprise when, even though both my VHF and UHF Shari's are set to produce one, none of my radios act like there is one. I've been told by many people that it's my radios' fault, that they just don't process reverse burst properly. This is demonstrably not correct. I can use one radio to talk to the other, and when I un-key, the receiving radio snaps off immediately totally without a tail. I listen to folk walking around with radios in my apartment building, and when they un-key, same thing--the audio just goes away without a hint of a squelch tail. So then, what is happening on the Shari transmision that causes every one of my radios--two Tytera 380' (one MD, one UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng 888's--to ignore the reverse-burst and give me a loud obnoxious crash when my Shari's un-key, yet they all behave correctly when talking to each other?
|
I have the reverse burst turned on and I use a MD-380, a Baoefeng UV-5B and a Baoefeng BF-F8+.? I don’t get a squelch tail on any of them.? You might to run the shari-pixx-prog again and make sure the reverse burst was actually turned on.? Also might want to check that the receive ctscss was programmed into your radios as well. If they’re carrier squelched that can cause a squelch crash too.? ? --- Sent From Mail For Windows 10 On My HP Envy x360 Ultrabook. ?
toggle quoted message
Show quoted text
From: Steve MatzuraSent: Friday, June 12, 2020 1:23 PM To: [email protected]Subject: [SHARI] Reverse Burst CTCSS/DCS ? I'm one of these people--I'm sure you know at least ten--who don't like squelch crashes and who think reverse-burst on CTCSS or DCS is the way to eliminate them. Therefore, imagine my surprise when, even though both my VHF and UHF Shari's are set to produce one, none of my radios act like there is one. I've been told by many people that it's my radios' fault, that they just don't process reverse burst properly. This is demonstrably not correct. I can use one radio to talk to the other, and when I un-key, the receiving radio snaps off immediately totally without a tail. I listen to folk walking around with radios in my apartment building, and when they un-key, same thing--the audio just goes away without a hint of a squelch tail. So then, what is happening on the Shari transmision that causes every one of my radios--two Tytera 380' (one MD, one UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng 888's--to ignore the reverse-burst and give me a loud obnoxious crash when my Shari's un-key, yet they all behave correctly when talking to each other? ? ? ? ? ?
|
I'm going to state the obvious, and it may sound snarky, but it's
not meant to be. If the Shari is set to send a DCS tone and the
radios respond, then I turn the Shari DCS off and the radios don't
break squelch, then I obviously have the radios programmed
correctly. Both my radios are set to DCS value 411 (411N on the
Shari). When my node is off the air, I can use one radio to talk
to the other, and it's totally tailless. I can never remember
whether the value for reverse-burst ON is 0 or 1, but I *can* tell
you that either setting produces the same result--a loud crashy
tail. Also, I think I can reasonably assume that the setting for
reverse burst on the Shari is enabled when the time the carrier
stays on after the courtesy tone is longer. Sure wish I could
figure this out, because I *know* it's supposed to work correctly.
On 6/12/2020 2:32 PM, David H. via
groups.io wrote:
toggle quoted message
Show quoted text
I have the reverse burst turned on and I
use a MD-380, a Baoefeng UV-5B and a Baoefeng BF-F8+.? I don’t
get a squelch tail on any of them.? You might to run the
shari-pixx-prog again and make sure the reverse burst was
actually turned on.? Also might want to check that the receive
ctscss was programmed into your radios as well. If they’re
carrier squelched that can cause a squelch crash too.?
?
---
Sent From Mail For Windows 10 On My HP Envy
x360 Ultrabook.
?
?
I'm one of these people--I'm sure you know
at least ten--who don't like
squelch crashes and who think reverse-burst
on CTCSS or DCS is the way
to eliminate them. Therefore, imagine my
surprise when, even though both
my VHF and UHF Shari's are set to produce
one, none of my radios act
like there is one. I've been told by many
people that it's my radios'
fault, that they just don't process reverse
burst properly. This is
demonstrably not correct. I can use one
radio to talk to the other, and
when I un-key, the receiving radio snaps
off immediately totally without
a tail. I listen to folk walking around
with radios in my apartment
building, and when they un-key, same
thing--the audio just goes away
without a hint of a squelch tail. So then,
what is happening on the
Shari transmision that causes every one of
my radios--two Tytera 380'
(one MD, one UV-MD), a scanner, a Kenwood
TM-D700, and a pair of Bao
Feng 888's--to ignore the reverse-burst and
give me a loud obnoxious
crash when my Shari's un-key, yet they all
behave correctly when talking
to each other?
?
?
?
?
?
|
In the programming world 1 is on and 0 is off.?
Hope this helps.?
-Brad
On Fri, Jun 12, 2020 at 2:49 PM Steve Matzura < number6@...> wrote:
I'm going to state the obvious, and it may sound snarky, but it's
not meant to be. If the Shari is set to send a DCS tone and the
radios respond, then I turn the Shari DCS off and the radios don't
break squelch, then I obviously have the radios programmed
correctly. Both my radios are set to DCS value 411 (411N on the
Shari). When my node is off the air, I can use one radio to talk
to the other, and it's totally tailless. I can never remember
whether the value for reverse-burst ON is 0 or 1, but I *can* tell
you that either setting produces the same result--a loud crashy
tail. Also, I think I can reasonably assume that the setting for
reverse burst on the Shari is enabled when the time the carrier
stays on after the courtesy tone is longer. Sure wish I could
figure this out, because I *know* it's supposed to work correctly.
On 6/12/2020 2:32 PM, David H. via
wrote:
I have the reverse burst turned on and I
use a MD-380, a Baoefeng UV-5B and a Baoefeng BF-F8+.? I don’t
get a squelch tail on any of them.? You might to run the
shari-pixx-prog again and make sure the reverse burst was
actually turned on.? Also might want to check that the receive
ctscss was programmed into your radios as well. If they’re
carrier squelched that can cause a squelch crash too.?
?
---
Sent From Mail For Windows 10 On My HP Envy
x360 Ultrabook.
?
?
I'm one of these people--I'm sure you know
at least ten--who don't like
squelch crashes and who think reverse-burst
on CTCSS or DCS is the way
to eliminate them. Therefore, imagine my
surprise when, even though both
my VHF and UHF Shari's are set to produce
one, none of my radios act
like there is one. I've been told by many
people that it's my radios'
fault, that they just don't process reverse
burst properly. This is
demonstrably not correct. I can use one
radio to talk to the other, and
when I un-key, the receiving radio snaps
off immediately totally without
a tail. I listen to folk walking around
with radios in my apartment
building, and when they un-key, same
thing--the audio just goes away
without a hint of a squelch tail. So then,
what is happening on the
Shari transmision that causes every one of
my radios--two Tytera 380'
(one MD, one UV-MD), a scanner, a Kenwood
TM-D700, and a pair of Bao
Feng 888's--to ignore the reverse-burst and
give me a loud obnoxious
crash when my Shari's un-key, yet they all
behave correctly when talking
to each other?
?
?
?
?
?
|
True enough,and so it is.
I found something in the MD-380 CPS that might have been the
culprit--the "Admit criteria" was set to "Always," so I changed it
to "Correct CTCSS/DCS" but it made no difference.
I take it "QT reverse" should be 180? I assume that's degrees, as
in 180° out of phase?
I can't think of anything else to change, except maybe quelch
from normal to tight.
On 6/12/2020 2:51 PM, Brad Trogdon
wrote:
toggle quoted message
Show quoted text
In the programming world 1 is on and 0 is off.?
Hope this helps.?
-Brad
On Fri, Jun 12, 2020 at 2:49
PM Steve Matzura < number6@...>
wrote:
I'm going to state the obvious, and it may sound
snarky, but it's not meant to be. If the Shari is set to
send a DCS tone and the radios respond, then I turn the
Shari DCS off and the radios don't break squelch, then I
obviously have the radios programmed correctly. Both my
radios are set to DCS value 411 (411N on the Shari).
When my node is off the air, I can use one radio to talk
to the other, and it's totally tailless. I can never
remember whether the value for reverse-burst ON is 0 or
1, but I *can* tell you that either setting produces the
same result--a loud crashy tail. Also, I think I can
reasonably assume that the setting for reverse burst on
the Shari is enabled when the time the carrier stays on
after the courtesy tone is longer. Sure wish I could
figure this out, because I *know* it's supposed to work
correctly.
On 6/12/2020 2:32 PM, David H. via wrote:
I have the reverse burst turned
on and I use a MD-380, a Baoefeng UV-5B and a
Baoefeng BF-F8+.? I don’t get a squelch tail on any
of them.? You might to run the shari-pixx-prog again
and make sure the reverse burst was actually turned
on.? Also might want to check that the receive
ctscss was programmed into your radios as well. If
they’re carrier squelched that can cause a squelch
crash too.?
?
---
Sent From Mail For Windows 10 On
My HP Envy x360 Ultrabook.
?
?
I'm one of these people--I'm sure
you know at least ten--who don't like
squelch crashes and who think
reverse-burst on CTCSS or DCS is the way
to eliminate them. Therefore,
imagine my surprise when, even though both
my VHF and UHF Shari's are set to
produce one, none of my radios act
like there is one. I've been told
by many people that it's my radios'
fault, that they just don't
process reverse burst properly. This is
demonstrably not correct. I can
use one radio to talk to the other, and
when I un-key, the receiving
radio snaps off immediately totally without
a tail. I listen to folk walking
around with radios in my apartment
building, and when they un-key,
same thing--the audio just goes away
without a hint of a squelch tail.
So then, what is happening on the
Shari transmision that causes
every one of my radios--two Tytera 380'
(one MD, one UV-MD), a scanner, a
Kenwood TM-D700, and a pair of Bao
Feng 888's--to ignore the
reverse-burst and give me a loud obnoxious
crash when my Shari's un-key, yet
they all behave correctly when talking
to each other?
?
?
?
?
?
|
In Hamvoip SimpleUSB, what's TXAudioDelay set to?
Or, are you talking about something else?
My Kenwood doesn't go chk at the end of transmissions when I have CTCSS on both transmit and receive.
toggle quoted message
Show quoted text
On 6/12/2020 2:22 PM, Steve Matzura wrote: I'm one of these people--I'm sure you know at least ten--who don't like squelch crashes and who think reverse-burst on CTCSS or DCS is the way to eliminate them. Therefore, imagine my surprise when, even though both my VHF and UHF Shari's are set to produce one, none of my radios act like there is one. I've been told by many people that it's my radios' fault, that they just don't process reverse burst properly. This is demonstrably not correct. I can use one radio to talk to the other, and when I un-key, the receiving radio snaps off immediately totally without a tail. I listen to folk walking around with radios in my apartment building, and when they un-key, same thing--the audio just goes away without a hint of a squelch tail. So then, what is happening on the Shari transmision that causes every one of my radios--two Tytera 380' (one MD, one UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng 888's--to ignore the reverse-burst and give me a loud obnoxious crash when my Shari's un-key, yet they all behave correctly when talking to each other?
|
I have no such parameter. However, I do have these:
L) Change CTCSSFROM Mode (currently "no")
M) Change RXONDELAY value (currently "0")
N) Change RXAUDIODELAY value (currently "5")
toggle quoted message
Show quoted text
On 6/12/2020 5:23 PM, Chris Smart wrote: In Hamvoip SimpleUSB, what's TXAudioDelay set to?
Or, are you talking about something else?
My Kenwood doesn't go chk at the end of transmissions when I have CTCSS on both transmit and receive.
On 6/12/2020 2:22 PM, Steve Matzura wrote:
I'm one of these people--I'm sure you know at least ten--who don't like squelch crashes and who think reverse-burst on CTCSS or DCS is the way to eliminate them. Therefore, imagine my surprise when, even though both my VHF and UHF Shari's are set to produce one, none of my radios act like there is one. I've been told by many people that it's my radios' fault, that they just don't process reverse burst properly. This is demonstrably not correct. I can use one radio to talk to the other, and when I un-key, the receiving radio snaps off immediately totally without a tail. I listen to folk walking around with radios in my apartment building, and when they un-key, same thing--the audio just goes away without a hint of a squelch tail. So then, what is happening on the Shari transmision that causes every one of my radios--two Tytera 380' (one MD, one UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng 888's--to ignore the reverse-burst and give me a loud obnoxious crash when my Shari's un-key, yet they all behave correctly when talking to each other?
|
FWIW: I set my SHARI up just with CTCSS. I haven't tried DCS. No crashing with my MD380. All I changed from a default new channel was frequency, power, CTCSS encode/decode frequency, and squelch to tight. I'll try DCS later to see what happens. The SHARI has tone burst tone on.
toggle quoted message
Show quoted text
On 6/13/2020 10:26 AM, Steve Matzura wrote: I have no such parameter. However, I do have these:
L) Change CTCSSFROM Mode (currently "no")
M) Change RXONDELAY value (currently "0")
N) Change RXAUDIODELAY value (currently "5")
On 6/12/2020 5:23 PM, Chris Smart wrote:
In Hamvoip SimpleUSB, what's TXAudioDelay set to?
Or, are you talking about something else?
My Kenwood doesn't go chk at the end of transmissions when I have CTCSS on both transmit and receive.
On 6/12/2020 2:22 PM, Steve Matzura wrote:
I'm one of these people--I'm sure you know at least ten--who don't like squelch crashes and who think reverse-burst on CTCSS or DCS is the way to eliminate them. Therefore, imagine my surprise when, even though both my VHF and UHF Shari's are set to produce one, none of my radios act like there is one. I've been told by many people that it's my radios' fault, that they just don't process reverse burst properly. This is demonstrably not correct. I can use one radio to talk to the other, and when I un-key, the receiving radio snaps off immediately totally without a tail. I listen to folk walking around with radios in my apartment building, and when they un-key, same thing--the audio just goes away without a hint of a squelch tail. So then, what is happening on the Shari transmision that causes every one of my radios--two Tytera 380' (one MD, one UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng 888's--to ignore the reverse-burst and give me a loud obnoxious crash when my Shari's un-key, yet they all behave correctly when talking to each other?
|
No matter what I change, reverse burst does *NOT* close the squelch and I get a crash. My UV-MD380 behaves the same way. However, they talk to each other and back and forth to Bao Feng and Kenwood radios just fine. The Shari nodes work great on the BF's and Kenwood radios, too. There's something fundamentally wrong about how I've set up the MD and UV-MD radios. Squelch tight or normal, CTCSS or DCS, even if I change the degree value for the reverse burst from 180 to 120 (or whatever the alternate value is), still no change. I fully understand that this is all so trivial and probably pedantic, too, but if some can get it to work, that means there's something I'm not understanding, and that's what I want to correct--my understanding of how this all works, which I thought I had down.
toggle quoted message
Show quoted text
On 6/16/2020 4:32 PM, Patrick Perdue wrote: FWIW: I set my SHARI up just with CTCSS. I haven't tried DCS. No crashing with my MD380. All I changed from a default new channel was frequency, power, CTCSS encode/decode frequency, and squelch to tight. I'll try DCS later to see what happens. The SHARI has tone burst tone on.
On 6/13/2020 10:26 AM, Steve Matzura wrote:
I have no such parameter. However, I do have these:
L) Change CTCSSFROM Mode (currently "no")
M) Change RXONDELAY value (currently "0")
N) Change RXAUDIODELAY value (currently "5")
On 6/12/2020 5:23 PM, Chris Smart wrote:
In Hamvoip SimpleUSB, what's TXAudioDelay set to?
Or, are you talking about something else?
My Kenwood doesn't go chk at the end of transmissions when I have CTCSS on both transmit and receive.
On 6/12/2020 2:22 PM, Steve Matzura wrote:
I'm one of these people--I'm sure you know at least ten--who don't like squelch crashes and who think reverse-burst on CTCSS or DCS is the way to eliminate them. Therefore, imagine my surprise when, even though both my VHF and UHF Shari's are set to produce one, none of my radios act like there is one. I've been told by many people that it's my radios' fault, that they just don't process reverse burst properly. This is demonstrably not correct. I can use one radio to talk to the other, and when I un-key, the receiving radio snaps off immediately totally without a tail. I listen to folk walking around with radios in my apartment building, and when they un-key, same thing--the audio just goes away without a hint of a squelch tail. So then, what is happening on the Shari transmision that causes every one of my radios--two Tytera 380' (one MD, one UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng 888's--to ignore the reverse-burst and give me a loud obnoxious crash when my Shari's un-key, yet they all behave correctly when talking to each other?
|
The cause is the Decoders in these radios don't respond well to Reverse Burst as they do not sense the phase reversal as written in the standard.
Some ham rigs suck at it too.
Chicken Tail, the method of turning the tone off for about 500ms works on MOST radios.
Sent from my mobile device. Please forgive my brevity.
toggle quoted message
Show quoted text
No matter what I change, reverse burst does *NOT* close the squelch and
I get a crash. My UV-MD380 behaves the same way. However, they talk to
each other and back and forth to Bao Feng and Kenwood radios just fine.
The Shari nodes work great on the BF's and Kenwood radios, too. There's
something fundamentally wrong about how I've set up the MD and UV-MD
radios. Squelch tight or normal, CTCSS or DCS, even if I change the
degree value for the reverse burst from 180 to 120 (or whatever the
alternate value is), still no change. I fully understand that this is
all so trivial and probably pedantic, too, but if some can get it to
work, that means there's something I'm not understanding, and that's
what I want to correct--my understanding of how this all works, which I
thought I had down.
On 6/16/2020 4:32 PM, Patrick Perdue wrote:
> FWIW: I set my SHARI up just with CTCSS. I haven't tried DCS. No
> crashing with my MD380. All I changed from a default new channel was
> frequency, power, CTCSS encode/decode frequency, and squelch to tight.
> I'll try DCS later to see what happens. The SHARI has tone burst tone on.
>
>
> On 6/13/2020 10:26 AM, Steve Matzura wrote:
>> I have no such parameter. However, I do have these:
>>
>>
>> L) Change CTCSSFROM Mode (currently "no")
>> M) Change RXONDELAY value (currently "0")
>> N) Change RXAUDIODELAY value (currently "5")
>>
>> On 6/12/2020 5:23 PM, Chris Smart wrote:
>>> In Hamvoip SimpleUSB, what's TXAudioDelay set to?
>>>
>>> Or, are you talking about something else?
>>>
>>>
>>> My Kenwood doesn't go chk at the end of transmissions when I have
>>> CTCSS on both transmit and receive.
>>>
>>>
>>>
>>> On 6/12/2020 2:22 PM, Steve Matzura wrote:
>>>> I'm one of these people--I'm sure you know at least ten--who don't
>>>> like squelch crashes and who think reverse-burst on CTCSS or DCS is
>>>> the way to eliminate them. Therefore, imagine my surprise when,
>>>> even though both my VHF and UHF Shari's are set to produce one,
>>>> none of my radios act like there is one. I've been told by many
>>>> people that it's my radios' fault, that they just don't process
>>>> reverse burst properly. This is demonstrably not correct. I can use
>>>> one radio to talk to the other, and when I un-key, the receiving
>>>> radio snaps off immediately totally without a tail. I listen to
>>>> folk walking around with radios in my apartment building, and when
>>>> they un-key, same thing--the audio just goes away without a hint of
>>>> a squelch tail. So then, what is happening on the Shari transmision
>>>> that causes every one of my radios--two Tytera 380' (one MD, one
>>>> UV-MD), a scanner, a Kenwood TM-D700, and a pair of Bao Feng
>>>> 888's--to ignore the reverse-burst and give me a loud obnoxious
>>>> crash when my Shari's un-key, yet they all behave correctly when
>>>> talking to each other?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
|
No worries, brevity is good. Does the Shari support that turn-off
instead of reverse burst method? I also thought I found something
like that in the MD380 codeplug.
On 6/17/2020 8:06 AM, Sam Nabkey wrote:
toggle quoted message
Show quoted text
The cause is the Decoders in these radios don't respond well to
Reverse Burst as they do not sense the phase reversal as written
in the standard.
Some ham rigs suck at it too.
Chicken Tail, the method of turning the tone off for about 500ms
works on MOST radios.
Sent from my mobile device. Please forgive my brevity.
No matter what I change, reverse burst
does *NOT* close the squelch and
I get a crash. My UV-MD380 behaves the same way. However,
they talk to
each other and back and forth to Bao Feng and Kenwood radios
just fine.
The Shari nodes work great on the BF's and Kenwood radios,
too. There's
something fundamentally wrong about how I've set up the MD
and UV-MD
radios. Squelch tight or normal, CTCSS or DCS, even if I
change the
degree value for the reverse burst from 180 to 120 (or
whatever the
alternate value is), still no change. I fully understand
that this is
all so trivial and probably pedantic, too, but if some can
get it to
work, that means there's something I'm not understanding,
and that's
what I want to correct--my understanding of how this all
works, which I
thought I had down.
On 6/16/2020 4:32 PM, Patrick Perdue wrote:
> FWIW: I set my SHARI up just with CTCSS. I haven't
tried DCS. No
> crashing with my MD380. All I changed from a default
new channel was
> frequency, power, CTCSS encode/decode frequency, and
squelch to tight.
> I'll try DCS later to see what happens. The SHARI has
tone burst tone on.
>
>
> On 6/13/2020 10:26 AM, Steve Matzura wrote:
>> I have no such parameter. However, I do have these:
>>
>>
>> L) Change CTCSSFROM Mode (currently "no")
>> M) Change RXONDELAY value (currently "0")
>> N) Change RXAUDIODELAY value (currently "5")
>>
>> On 6/12/2020 5:23 PM, Chris Smart wrote:
>>> In Hamvoip SimpleUSB, what's TXAudioDelay set
to?
>>>
>>> Or, are you talking about something else?
>>>
>>>
>>> My Kenwood doesn't go chk at the end of
transmissions when I have
>>> CTCSS on both transmit and receive.
>>>
>>>
>>>
>>> On 6/12/2020 2:22 PM, Steve Matzura wrote:
>>>> I'm one of these people--I'm sure you know
at least ten--who don't
>>>> like squelch crashes and who think
reverse-burst on CTCSS or DCS is
>>>> the way to eliminate them. Therefore,
imagine my surprise when,
>>>> even though both my VHF and UHF Shari's are
set to produce one,
>>>> none of my radios act like there is one.
I've been told by many
>>>> people that it's my radios' fault, that
they just don't process
>>>> reverse burst properly. This is
demonstrably not correct. I can use
>>>> one radio to talk to the other, and when I
un-key, the receiving
>>>> radio snaps off immediately totally without
a tail. I listen to
>>>> folk walking around with radios in my
apartment building, and when
>>>> they un-key, same thing--the audio just
goes away without a hint of
>>>> a squelch tail. So then, what is happening
on the Shari transmision
>>>> that causes every one of my radios--two
Tytera 380' (one MD, one
>>>> UV-MD), a scanner, a Kenwood TM-D700, and a
pair of Bao Feng
>>>> 888's--to ignore the reverse-burst and give
me a loud obnoxious
>>>> crash when my Shari's un-key, yet they all
behave correctly when
>>>> talking to each other?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
|
