TOut - what that means?

[KD2PNR]

Thanks for the additional information. I have done some further investigations here, and so far I am seeing continuous problems with my connections to the FCS004 reflector rooms, and no problems with other connections, both C4FM and DMR. Because of that, I suspect there might be something going on with that reflector, and I see it on multiple rooms, and on all stations. That means that ALL entries except my own are marked TOut, leaving me missing the actual duration numbers.

I am wondering if a slight modification of the method to indicate an error might be possible? Rather than obliterate the sometimes useful duration data with TOut, could we just change the background color for that report, much like happens when the BER rate if out of line? By implementing it that way we keep the actual data, but still are getting an indication of an error, which I think was the original intent of the change. Another option might be to allow the user to somehow decide if they want the check done or not. I suspect that adding another parameter to the config data is a major issue, but maybe something simpler like testing for the presence of a file to disable it (/etc/no_timeout_checks is present) might also be an option. Because in my case (and others I have checked with as well) EVERY report is showing an error, and it is probably beyond my control to fix it, I find the loss of that data to be a minor problem, and would personally choose to not do that check.

[RC3C]

Hi guys

I just got info from MMDVM logs:

=== BG2EEN ===
M: 2020-10-22 01:29:27.360 0000: 04 00 5C 42 47 32 45 45 4E *..\BG2EEN*
M: 2020-10-22 01:29:28.096 DMR Talker Alias (Data Format 1, Received 13/14 char): 'BG2EEN ZhaoRu'
M: 2020-10-22 01:29:28.096 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-10-22 01:29:28.096 0000: 05 00 20 5A 68 61 6F 52 75 *.. ZhaoRu*
M: 2020-10-22 01:29:28.559 DMR Slot 2, received network end of voice transmission from BG2EEN to TG 46001, 1.9 seconds, 6% packet loss, BER: 0.0%
M: 2020-10-22 01:29:28.860 DMR Slot 2, received network voice header from BG2EEN to TG 46001
M: 2020-10-22 01:29:28.883 DMR Slot 2, received network end of voice transmission from BG2EEN to TG 46001, 0.4 seconds, 14% packet loss, BER: 0.0%
M: 2020-10-22 01:29:31.617 DMR Slot 2, received network voice header from BG2EEN to TG 46001
M: 2020-10-22 01:29:32.263 DMR Talker Alias (Data Format 0, Received 0/0 char): ''
M: 2020-10-22 01:29:32.264 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-10-22 01:29:32.264 0000: 05 00 20 5A 68 61 6F 52 75 *.. ZhaoRu*
M: 2020-10-22 01:29:32.979 DMR Talker Alias (Data Format 0, Received 0/0 char): ''
M: 2020-10-22 01:29:32.979 DMR Slot 2, Embedded Talker Alias Block 2
M: 2020-10-22 01:29:32.979 0000: 06 00 69 00 00 00 00 00 00 *..i......*
M: 2020-10-22 01:29:33.461 DMR Slot 2, received network end of voice transmission from BG2EEN to TG 46001, 2.6 seconds, 15% packet loss, BER: 9.4%
M: 2020-10-22 01:29:33.757 DMR Slot 2, received network voice header from BG2EEN to TG 46001
M: 2020-10-22 01:29:35.445 DMR Talker Alias (Data Format 1, Received 6/14 char): 'BG2EEN'
M: 2020-10-22 01:29:35.445 DMR Slot 2, Embedded Talker Alias Header
M: 2020-10-22 01:29:35.445 0000: 04 00 5C 42 47 32 45 45 4E *..\BG2EEN*
M: 2020-10-22 01:29:36.163 DMR Talker Alias (Data Format 1, Received 13/14 char): 'BG2EEN ZhaoRu'
M: 2020-10-22 01:29:36.163 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-10-22 01:29:36.163 0000: 05 00 20 5A 68 61 6F 52 75 *.. ZhaoRu*
M: 2020-10-22 01:29:36.896 DMR Talker Alias (Data Format 1, Received 14/14 char): 'BG2EEN ZhaoRui'
M: 2020-10-22 01:29:36.896 DMR Slot 2, Embedded Talker Alias Block 2
M: 2020-10-22 01:29:36.896 0000: 06 00 69 00 00 00 00 00 00 *..i......*
M: 2020-10-22 01:29:37.155 DMR Slot 2, received network end of voice transmission from BG2EEN to TG 46001, 4.4 seconds, 41% packet loss, BER: 9.7%
M: 2020-10-22 01:29:37.434 DMR Slot 2, received network voice header from BG2EEN to TG 46001
M: 2020-10-22 01:29:39.068 DMR Talker Alias (Data Format 1, Received 6/14 char): 'BG2EEN'
M: 2020-10-22 01:29:39.068 DMR Slot 2, Embedded Talker Alias Header
M: 2020-10-22 01:29:39.068 0000: 04 00 5C 42 47 32 45 45 4E *..\BG2EEN*
M: 2020-10-22 01:29:39.789 DMR Talker Alias (Data Format 1, Received 13/14 char): 'BG2EEN ZhaoRu'
M: 2020-10-22 01:29:39.789 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-10-22 01:29:39.789 0000: 05 00 20 5A 68 61 6F 52 75 *.. ZhaoRu*
M: 2020-10-22 01:29:40.508 DMR Talker Alias (Data Format 1, Received 14/14 char): 'BG2EEN ZhaoRui'
M: 2020-10-22 01:29:40.508 DMR Slot 2, Embedded Talker Alias Block 2
M: 2020-10-22 01:29:40.508 0000: 06 00 69 00 00 00 00 00 00 *..i......*
M: 2020-10-22 01:29:42.327 DMR Slot 2, network watchdog has expired, 5.8 seconds, 56% packet loss, BER: 10.3%
=== end ===

Today I got TOut after regular "shutdown -r" my hotspot



=== 27-10-2020 ==
I: 2020-10-27 08:59:30.752 D-Star RF Parameters
I: 2020-10-27 08:59:30.752 Module: B
I: 2020-10-27 08:59:30.752 Self Only: no
I: 2020-10-27 08:59:30.752 Ack Reply: yes
I: 2020-10-27 08:59:30.752 Ack message: BER
I: 2020-10-27 08:59:30.752 Ack Time: 750ms
I: 2020-10-27 08:59:30.752 Error Reply: yes
I: 2020-10-27 08:59:30.752 Remote Gateway: no
I: 2020-10-27 08:59:30.752 Mode Hang: 20s
M: 2020-10-27 08:59:30.888 D-Star link status set to "Linking to XRF250 C "
M: 2020-10-27 08:59:30.889 D-Star link status set to "Linked to XRF250 C "
M: 2020-10-27 08:59:31.019 D-Star, received network header from RC3C /INFO to CQCQCQ via XRF250 C
M: 2020-10-27 08:59:33.235 D-Star, network watchdog has expired, 5.1 seconds, 0% packet loss, BER: 0.0%
=== end ===

just now I got:


=== G0BVZ ===
M: 2020-10-27 09:35:51.764 DMR Slot 2, received network end of voice transmission from G0BVZ to TG 7000007, 2.6 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-27 09:36:14.400 DMR Slot 2, received network voice header from G0BVZ to TG 7000007
M: 2020-10-27 09:36:15.907 DMR Slot 2, network watchdog has expired, 0.1 seconds, 0% packet loss, BER: 0.0%
=== END ===

in DMR2YSF log file I have:

=== G0BVZ ===
M: 2020-10-27 09:35:49.162 Received YSF Header: Src: G0BVZ Dst: **********
M: 2020-10-27 09:35:49.162 DMR ID of G0BVZ: 2351469, DstID: TG 7
M: 2020-10-27 09:35:51.644 YSF received end of voice transmission, 2.5 seconds
M: 2020-10-27 09:36:14.153 Received YSF Header: Src: G0BVZ Dst: **********
M: 2020-10-27 09:36:14.153 DMR ID of G0BVZ: 2351469, DstID: TG 7
=== END ===

Hope it helps a bit.

[DG0OFZ]

Hi all,

many thanks, Anton! This confirms that my patch is working for D-STAR, DMR and YSF modes. I was only able to confirm this for YSF and DMR here.

As we can see, anytime when "TOut" is displayed, there is a reason for this: MMDVMHOST has logged these timeouts.

I've already tested another code to get back to displaying the time and add an "(TOut)" to it (hoping this is what KD2PNR likes to see). But I'm not sure to publish it, because there are no other complaints about it. I don't like to implement a patch for 2 or 3 users while the rest of the users are fine with it.

Maybe I will dicuss this with Andy. He should decide, whats in his software.

[RC3C]

Hi all,

many thanks, Anton! This confirms that my patch is working for D-STAR, DMR and YSF modes. I was only able to confirm this for YSF and DMR here.

As we can see, anytime when "TOut" is displayed, there is a reason for this: MMDVMHOST has logged these timeouts.

I've already tested another code to get back to displaying the time and add an "(TOut)" to it (hoping this is what KD2PNR likes to see). But I'm not sure to publish it, because there are no other complaints about it. I don't like to implement a patch for 2 or 3 users while the rest of the users are fine with it.

Maybe I will dicuss this with Andy. He should decide, whats in his software.

Hi Thomas. TNX 4 reply.

I am not complaining about the theme I raised. Just I'd like to ask to understand what happened wrong on my Pi-Star hotspot.
If it's OK as you told, so I am thinking we can close the topic.

[KD2PNR]

I have no issue with reporting errors, but when it happens on EVERY transmission, and I have no way that I know of to fix it, then I would prefer to have the durations not completely lost. I am only seeing this constantly when connected to a FCS004 based room, other sources will report problems occasionally, but not every time. Here is what I am seeing in my logs:

M: 2020-10-29 00:44:25.391 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:44:38.380 YSF, network watchdog has expired, 11.8 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:47:59.949 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:48:12.047 YSF, network watchdog has expired, 10.9 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:50:03.138 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:50:15.726 YSF, network watchdog has expired, 11.4 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:51:17.509 YSF, received network data from N4NT-ADAM to ALL at FCS004-54
M: 2020-10-29 00:51:26.311 YSF, network watchdog has expired, 7.4 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:51:45.356 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:51:58.444 YSF, network watchdog has expired, 11.8 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:52:12.685 YSF, received network data from KD9JSX to ALL at FCS004-54
M: 2020-10-29 00:52:26.564 YSF, network watchdog has expired, 12.6 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:52:31.787 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:52:47.486 YSF, network watchdog has expired, 14.5 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:55:04.014 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:55:16.900 YSF, network watchdog has expired, 11.5 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:57:18.414 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:57:30.604 YSF, network watchdog has expired, 11.0 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:57:32.781 YSF, received network data from K7HAM to ALL at FCS004-54
M: 2020-10-29 00:57:37.013 YSF, network watchdog has expired, 2.9 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:57:56.221 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:58:04.011 YSF, network watchdog has expired, 6.6 seconds, 0% packet loss, BER: 0.0%
M: 2020-10-29 00:58:49.131 YSF, received network data from WA4RX to ALL at FCS004-54
M: 2020-10-29 00:58:59.617 YSF, network watchdog has expired, 9.3 seconds, 0% packet loss, BER: 0.0%

As I said before, I get this on other spots and other rooms, as long as it is FCS004 provided. Because it is limited to just this reflector I think it likely they are doing (or not doing) something to cause this. If there is something I can do here to get more data I would be happy to do so. In any event, thanks for the consideration.

[G8SEZ]

Andy has committed a fix for this today, so your Pi-Stars should pick it up overnight or you can do an update manually.

https://github.com/AndyTaylorTweet/Pi-S ... e3bf534cb5

[KD2PNR]

Thanks so much for the update. I manually updated everything this morning, and indeed, the durations are back again.

Just one other comment - I checked my logs for messages when using the FCS reflector, and they still indicate constant network watchdog errors, however I only see the duration on the dashboard. I only question this as I looked at the new code Andy provided, and if I am reading it correctly it will simply place the duration in the proper place instead of TOut if the string contains the "seconds" string (i.e. data). This seems to me to be in conflict with the comment he provided indicating that perhaps I should be seeing something else (both perhaps) that will not only give me the actual duration, but also some form of error indicator. I am wondering if the intention was to append the duration time after the "TOut" text, rather than completely replace it?? In my case this would result in a very cluttered display for that column, but as a former programmer I can see the possible original intention.

I am happy with the way it is now, but just wanted to comment in case it is not the way Andy intended. Also I took a quick look at setting the background to red when an error is detected but php is new to me, so it is not obvious and I wanted to get this comment submitted.

Thanks again folks.

[G8SEZ]

I think the intention is that the dashboard shows the duration correctly but that any watchdog timer errors appear in the log. That means that debug information is there but you have to dig a little to get it.