Last Rx Pkt System time: , diff: 417650208 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0
in rtcm status has ?
I have little knowledge in the whole Allstar system.
We operate a repeater with a transmitter at the main site and 3 satellite receivers connected to the main site via a 3 GHz link.
In the voting system, one of the receivers always disappears once and loses the connection to the host (“host connection lost”).
What does last Rx PKT mean ?
Thank you for the development of the Allstar system
I guessing here: the 1st diff is how long ago the last packet was received. The 2nd diff is a comparison of the packet to GPS time. The index looks like it might be a count.
The lost host connection is likely due to a poor IP network. Run voter ping name # a few times to test the network.
voter ping santiago-uhf 10
PING (Santiago-UHF) Response: seqno: 1 diff: 8 ms
PING (Santiago-UHF) Response: seqno: 2 diff: 8 ms
PING (Santiago-UHF) Response: seqno: 3 diff: 9 ms
PING (Santiago-UHF) Response: seqno: 4 diff: 8 ms
PING (Santiago-UHF) Response: seqno: 5 diff: 11 ms
PING (Santiago-UHF) Response: seqno: 6 diff: 20 ms
PING (Santiago-UHF) Response: seqno: 7 diff: 27 ms
PING (Santiago-UHF) Response: seqno: 8 diff: 31 ms
PING (Santiago-UHF) Response: seqno: 9 diff: 21 ms
PING (Santiago-UHF) Response: seqno: 10 diff: 8 ms
PING (Santiago-UHF): Packets tx: 10, rx: 10, oos: 0, Avg.: 15.100 ms
PING (Santiago-UHF): Worst: 31 ms, Best: 8 ms, 100.0% Packets successfully received (0.0% loss)
Thanks Tim for the quick reply and for the explanations.
There was a small error in my post. I had copied the 3 lines in the RTCM Status Menu with copy and paste and something was lost:
Current Time: Thu Apr 29, 2021 19:11:38.320
Last Rx Pkt System time: (System Time Not Set), diff: 520827728 msec
Last Rx Pkt Timestamp time: (System Time Not Set), diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0
That means: (System Time Not Set). Which time is meant, because the times are all given.
About the network problem: I thought about that too.
But I also thought that a lost network connection, when it returns, will cause the recipient to reappear in the voter list.
However, it seems that he remains permanently disappeared. But you have to reckon with an interrupted network connection, even if it occurs rarely, e.g. once a day ?
Yes, the RTCM should return to the voter list. My RTCM drop on occasion but will return right away once the outage is corrected. BTW, the RTCM sends keep alive packets. If chan_voter missed 5 in row the RTCM is considered off line.
Sounds like that one RTCM is not logging in properly. Double check the passwords. Also make sure the password is the first parameter after the equal sign on the siteName = password, transmit... string in voter.conf Remember the password has to be unique. Are the GPS and Login LEDs performing as expected on that one RTCM?
Unless you configured that RTCM in the voter.conf file to be a transmitter, it will never receive a pack from the network to be recorded in this “Rx Pkt”.
But assuming that you have not wired up a transmitter connection at this RTCM because it is connected as a receiver only, you could configure it in voter.conf as a transmitter. Then this information would be more meaningful, and you could also connect up a monitor speaker with a small audio amplifier at this RTCM to listen to the repeater transmit audio at the remote receive site, and get accurate time status in these lines.
First I would like to thank Chuck for the explanation “Rx Pkt”.
Together with the explanation of Tim I now understood it.
Probably I noticed the menu item in the status menu only now, because I have not seen it in the firmware before.
I have s also immediately tested in my configuration and see now at the RTCM at the transmitter site is also beautiful the values correctly displayed. At the RTCM which are only at receiver sites, I just see the entry as described above.
I need to describe my configuration a little more. Due to my bad English I put the question a little bit wrong.
Configuration DB0YY Repeater:
We have 4 sites. At the central location in the middle of our town is the transmitter of the repeater and the allstar server. At 3 remote sites are each a receiver, a RTCM and a 3 GHz ubiquity link to the central site.
What happens:
Sometimes the audio from one of the receivers is not received at the central server. However, the logical connection to the RTCM exists as Tim described. It is not always the same site at which the audio transmission is interrupted.
We see it in the wonderful Allmon tool from Tim. We then fix the problem by logging in the receiver RTCM of the faulty connection. There all values of the configuration are displayed correctly. There we call the diagnostic mode and leave it again. This causes the RTCM to reconnect to the host and then audio is transmitted again.
I can’t understand what happens when the audio transmission is interrupted. The faulty connection is displayed in Allmon, but without audio (RSSI).
By the way. I really need to go back to the server location sometime. At the moment this is unfortunately not possible due to the pandemic. I wos not there for more then 1 year. So it will take some time until I can test on site and then I would also bring the server software up to date.
Has your system worked in the past and it’s just recently started acting up?
If the network is not dropping out as indicated by ping and/or telnet but you are loosing audio you are looking at a possible GPS timing issue. The timing has to be perfect or audio won’t pass. Make sure all 4 (3 remotes and master) all agree on the time of day. I’ve seen the time slip by one second.
As all three of the remotes drop out (individually at different times) I’d be thinking the problem is at the master site. Are you getting any messages on the Asterisk console of interest? Have you restarted the server or Asterisk since this started happening?
It’s interesting that you basically disable the remote RTCM to get it to come back on line. I’ve seen that behavior with some ISPs not liking port 667. They disable the port until the traffic stops. That seems unlikely in your case as (I assume) you are on a private 3Ghz network. I had to move my system to another port (I used an IRLP port) to overcome the problem.
There are posts here on Community and the WiKi about updating the RTCM firmware. You might try that when you have physical access to the sites.
Assuming that your 3Ghz links are 100% solid, a likely problem is that the various RTCM’s have times that are off by 1 second. This is a common problem. The best way to resolve this is to telnet into each and every RTCM and use the menu choice to reboot the RTCM without interrupting the power. When they come up this way they are much more likely to each have exactly the same time.