AndyTaylorTweet / Pi-Star_DV_Dash

Pi-Star DV Dashboard (Based on works by Hans-J. Barthen (DL5DI) and Kim Huebel (DG9VH)).
http://www.pistar.uk/downloads/
111 stars 120 forks source link

TX Duration continues to increment even though DMR TX has stopped. #117

Open g0hww opened 4 years ago

g0hww commented 4 years ago

I have noticed that the Dashboard for the GB7YJ DMR repeater (I am only a user, not the repeater keeper) sometimes shows an incrementing TX Duration even though that specific transmission has stopped. The repeaters Dashboard identifies its versions as: Pi-Star:3.4.17 / Dashboard: 20200813

More often than not, this occurs when my MD-390 transmits an SMS message containing GPS data from an area with marginal repeater coverage, so in that case the repeater is receiving the transmission over RF. The TX counter continues to increment even after I have turned my radio off.

Under such circumstances, I have stopped the incrementing TX counter by making another transmission, at which point the Dashboard appears to be completely normal.

I have also seen this occur in relation to TG traffic arriving at the repeater over the Net, but this has been rarer in my experience.

I will attempt to grab screenshots of this behaviour at the next opportunity.

I have seen another quirk which may or may not be related. This other quirk seems to show a row of activity which clearly pertains to DMR voice traffic with a TG destination, that appears on an adjacent row to another row showing an SMS transmission. This 2nd quirk populates the last 3 columns of the DMR voice activity with the "SMS" string, such that 2 adjacent rows show "SMS" in the last three columns. If it becomes clear that this is an entirely unrelated problem, I will raise a different a different issue.

AndyTaylorTweet commented 4 years ago

The dashboard only knows what is in the logs, the log will be missing the EoT marker (end of transmission), so the counter will keep counting, it should time-out.

g0hww commented 4 years ago

Perhaps, specifically in the case of SMS transmissions, the timeout could be shorter, as the maximum transmit duration of SMS messages should presumably be well bounded.

Do you think the other quirk that I reported should be raised as a separate issue?

AndyTaylorTweet commented 4 years ago

For the second quirk - I could do with a screen grab and ideally the last 10-20 lines of the MMDVMHost log file too. I could just remove the timer for SMS - that seems the most obvious way to deal with those.

g0hww commented 4 years ago

I could just remove the timer for SMS - that seems the most obvious way to deal with those.

Yes, that sounds ideal.

For the other quirk, I shall try and get a screenshot, but it does seem to be a rare occurrence. It might not be easy to get log extracts as I am not the repeater keeper, but when I can identify an occurrence, I can ask the keeper to provide a log extract covering that time period.

thovoigt commented 4 years ago

We just discussed this problem in the German Brandmeister user group via Telegram: In some cases this behaviour is seen, when the transmitting station ist timing out. So there is no line with "received network end of voice transmission from ..." in the log. Instead of this we found a line like

M: 2020-09-25 17:00:33.659 DMR Slot 2, network watchdog has expired

I replaced line #513 in /var/www/dashboard/mmdvmhost/functions.php

if (strpos($logLine,"RF user has timed out")) {

with this code to solve it:

if (strpos($logLine,"RF user has timed out") || strpos($logLine,"watchdog has expired")) {

So my dashboard is now showing "TOut" instead of infinite counting the seconds.

73s de Thomas, DG0OFZ