[App_rpt-users] RTCM/VOTER Squelch/Firmware Question

[Lee Woldanski]

HI Chuck,

Yes, set the define in harfwareprofile.h.

I'll go dig out the schematic for this repeater a double check what is in
the path for the discriminator.

I believe the change to the alternate squelch/RSSI has virtually eliminated
the squelch tail, but the jury is still out until I listen some more to
actual traffic.


Lee

On Sun, Jun 5, 2016 at 9:35 AM, Chuck Henderson <
rpt2 at chuck.midlandsnetworking.com> wrote:

> If anyone if off frequency a little bit that will make the voice talk off
> worse.  Double check that the repeater and the users are all on frequency.
> Don't use narrow bandwidth on the repeater receiver.  Make sure that the
> discriminator audio is not rolled off even a little bit at the high end.
> There should not be resistors in series or capacitors to ground between the
> discriminator chip output pin and the voter board input, for best results.
> I tried DSPBEW a couple of times but don't use it on any of my repeaters.
> Did you uncomment line 64 in HardwareProfile.h to get both of my changes?
> One change is to the squelch action and the other is to how RSSI is
> calculated.
> Also, I comment out
> ;thresholds =
> and set
> linger = 0
> in /etc/asterisk/voter.conf
> Chuck, WB9UUS
>
>
>
>
>
> On Fri, Jun 3, 2016 at 7:04 PM, Lee Woldanski <ve7fet at tparc.org> wrote:
>
>> I am in the process of deploying my first of a few VOTER (through hole)
>> boards in the conversion of one of my local repeater to add voting.
>>
>> My master receiver with transmit is running on an ICOM FR5000, using
>> discriminator out, carrier squelch (no PL), with a VOTER (of course).
>>
>> I've got a couple questions that hopefully someone can answer for me.
>>
>>
>> 1) I've noticed with the default (v1.50) firmware running, I am getting
>> nasty squelch crashes when a user un-keys.
>>
>> Watching it in Allmon2, there looks like there is a LOT of flutter on the
>> signals, going from near 255 all the way down to the hundreds. The flutter
>> seems to be co-incident with voice peaks. Looking in the source code, this
>> appears it should have been fixed... yet I still see the artifacts?
>>
>> The squelch crash seems to be co-incident with the RSSI dropping near 0
>> when the user un-keys. Which would be fine for the 2-level squelch action,
>> if it were true... but the users seem to have a strong signal otherwise.
>>
>> 2) Would DSPBEW help with this? Anyone running an FR5000 want to comment
>> on their configuration?
>>
>> 3) I've compiled and loaded "Chuck Squelch" on it, and it is definitely
>> an improvement. We'll see if I like the change.
>>
>> Related to that, do I need to do the diode/squelch calibration routines
>> every time I re-flash the firmware, or will those settings be retained in
>> EEPROM (and would they be the same between the different firmware)?
>>
>>
>> So far I am liking the opportunities this change from a hardware
>> controller is enabling. A BIG thanks to everyone who has put their time and
>> effort in developing the hardware and software to get to where it is today.
>>
>>
>> Cheers!
>>
>> --
>> Lee Woldanski, AScT
>> VE7FET
>>
>> _______________________________________________
>> App_rpt-users mailing list
>> App_rpt-users at 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.
>>
>
>


-- 
Lee Woldanski, AScT
VE7FET
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20160605/32458435/attachment.html>