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.
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.
Would DSPBEW help with this? Anyone running an FR5000 want to comment on their configuration?
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.
Yes, BEW will help with. Limiting the RSSI reduction on voice peaks is exactly what it’s designed for.
Also:
Be sure you have discriminator audio feeding the RTCM.
Set the squelch pot 5 turns above threshold. Reading should be around 400 to 500.
···
On Fri, Jun 3, 2016 at 5:04 PM, Lee Woldanski ve7fet@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.
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.
Would DSPBEW help with this? Anyone running an FR5000 want to comment on their configuration?
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.
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.
Thanks Tim, will play with BEW and see what difference it makes. I’ve loaded BEW with Chuck Squelch on there now to give me the option of enabling BEW.
Definitely using discriminator audio from the receiver.
Squelch is cranked up about 7.5T above threshold, as it was opening too low for my liking at around 4-5T.
Squelch currently opens at around -119dBm as set, which puts me at:
Squelch Noise Gain Value: 16, Diode Cal. Value: 54, SQL pot 378
J1 is in to allow squelch to calibrate.
I’ll play with it some more and see how it behaves.
Yes, BEW will help with. Limiting the RSSI reduction on voice peaks is exactly what it’s designed for.
Also:
Be sure you have discriminator audio feeding the RTCM.
Set the squelch pot 5 turns above threshold. Reading should be around 400 to 500.
–
On Fri, Jun 3, 2016 at 5:04 PM, Lee Woldanski ve7fet@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.
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.
Would DSPBEW help with this? Anyone running an FR5000 want to comment on their configuration?
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.
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.
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@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.
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.
Would DSPBEW help with this? Anyone running an FR5000 want to comment on their configuration?
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.
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’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.
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@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.
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.
Would DSPBEW help with this? Anyone running an FR5000 want to comment on their configuration?
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.
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.
DET becomes EXDISC which becomes DISC at the accessory connector.
Detector audio from the IF IC looks like it gets buffered and filtered a bit before it hits the accessory connector. Hence, there may not be all the noise we want.
There also is circuitry in there to switch Wide/Narrow, which would be affected by channel programming.
I’m not going to bother to sweep it to see what the response is, as it is already installed at site.
I may swap back to stock squelch and enable BEW to see how that plays.
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.