Hi all,
I recently had a VOTER board not TX or RX anymore. I logged in with telnet and could see that it was connected successfully to the host, no errors, and PTT=1 when it was supposed to be transmitting.
However looking at the LED, both TX or RX LEDs don’t work and the board doesn’t receive or transmit accordingly.
Has anyone come across this problem? My next step is a complete recalibration and reset back to defaults.
In voting applications the GPS time has to be correct. Is this a voting system?
Are there any errors/messages on the Asterisk console or logs?
Restart asterisk if you haven’t already.
Hi Tim,
Yes voting and simulcast.
No errors in the Asterisk console, I’ll go through the logs later. The GPS time was correct.
Restarted Asterisk and all the voters, still nothing.
On another note,
I’ve had problems in the past with ethernet out of bounds and (sometimes) GPS time errors. Is it recommended to have a dedicated VOTER board for just timing on the main site? Currently my VOTER board there also simulcasts and votes/does timing.
I’ve set all the boards to 10M Half duplex too.
Mine has done this and I had to power cycle it. Reboot didn’t work.
I did a power cycle on site, didn’t come back up. I pulled all the gear out and it’s back at home now awaiting looking at. It might require a full system re-calibration.
There needs to be a GPS clocked RTCM near (on the same ethernet segment) as the node computer. That same RTCM can also be physically connected to a radio.
BTW, RTCM and VOTER boards are different units. The RTCM is a surface mounted component package in a metal cast available from micro-node.com and others. The VOTER board is a through hole (discrete component) type board only. They are not many around and they are no longer available.
Which do you have?
Hi Tim,
I’ve had my VOTER’s for a number of years now, in fact I’ve emailed you on a few occasions about them, so thanks for your help.
Yes I have a GPS clocked VOTER board at my main site with the node PC. The VOTER in this case is connected to a radio. I had heard that it works better if you have a dedicated VOTER board just for timing not connected to a radio, you may be able to confirm.
I have the VOTER, not RTCM running the 2021 Chuck squelch to fix the GPS issue
Never heard of that one.
I don’t think there is a problem supporting both a radio and the computer with one unit.
Bit of an update on this, if anyone else has any ideas, or suggestions?
I recently made some changes to our AllstarLink system, upgraded to the latest version of HamVOIP and upgraded to the v3.0 firmware.
I also moved my master timing source to another location.
Most of the problems have now disappeared - except for one…
We have a three site system.
Site 1 is the “master” where it’s got a RX only voter board and the Pi 4 running HamVOIP.
Site 2 has a TX/RX and is connected using the same ISP (who route internally, not out via the internet) as the master site.
Site 3 has a TX/RX and is connected to a different ISP.
Site 3 will work perfectly fine for maybe a week, and then it will stop transmitting or receiving. Still shows connected in Allmon and telnetting in says it’s still connected. Whenever there is TX or RX activity, it shows the GPS out of bounds error with a minus number, something I’ve seen before.
To fix, all I need to do is reboot the voter board and it’s good for maybe another week. As there is no ability to schedule a reboot on the voter boards, I have to rely on someone telling me when the repeater isn’t transmitting from that site anymore.
I haven’t tried scheduling just the Pi to reboot maybe daily in the middle of the night to see if that fixes it?
The latency from site 3 is sub <30ms, but I think there may be some shaping or jitter which probably causes the problem - I’m just surprised it never resolves itself as it’s good for a long period of time before needing rebooting.
What are your buffers set to? I find 1200 on the RTCM and 250 on voter.conf works well in most circumstances.
If rebooting fixes the problem for weeks then sure, reboot the node periodically.
I heard of this once, RTCM Network Issue but I don’t think that’s the problem you are having.
Also are you using the terms “voter board” and RTCM interchangeably or do you have a mixture?
Hi Tim,
I’m using a buflen of 250 and in the VOTER 1500.
I’ve experimented with lower values and as others have documented, it becomes flakey with the other sites having issues.
Next time it fails, I will reboot the node instead of the board and see what happens - as you say if it fixes it, I’ll just schedule reboots… it will mess up some of the monitoring stats I guess.
I’m using only homemade VOTER boards in this environment. I could possibly swap out Site 3 that has the problems with an RTCM (or another board that I have built).
I checked that link - yeah that’s not really what I’m seeing. There aren’t disconnects, in fact the board says it’s still connected. It’s just whenever it receives a signal or goes to TX, the GPS out of bounds error pops up.
Port on the switch it’s connected to is set to 10M full duplex - Mikrotik RB2011
We’ve seen many issues with GPS units. Might try another GPS. I kind of gave up on voting because of those issues.
No worries.
I use the BG7TBL GPS units on all three sites. Perhaps I should swap out the unit at the problematic site to see if it fixes it.
Otherwise the QRP Labs QLG2 is a good alternative (especially if you are just voting and don’t need the 10 MHz for simulcast). You just need to disable the Galileo, GLONASS and Beidou GPS data so the VOTER/RTCM can recognize it and use a TTL to serial converter for the VOTER.
Here is the VOTER board under the fault condition. Been working fine for over a week, this morning it stopped transmitting/receiving and showing the out of bounds error. I restarted Asterisk only, which made no difference. I didn’t do a full reboot of the Pi.
Had to restart the VOTER board for it to work.
