Call sign keeps repeating
Call sign keeps repeating
I have had the problem of hearing other hams and my call sign being repeated over and over with no way to stop it unless I shut everything down for an indeterminate amount of time. This happened twice tonight once with an over seas station then with mine. I am using a MMDVM hat on a rpi 3b. All updates are current to the best of my knowledge. Version 1.4.17 firmware. Any comments would be appreciated.
Re: Call sign keeps repeating
If this listing corresponds to the timeframe for your experience, then you were stuck in a "overflow in the DMR RF queue" problem:
What causes this, how it starts, when it starts, how it stops, why does it stop by itself, why does it come and go - these are all questions that don't seem to have an answer so far. The biggest problem is that it is unpredictable and irreproducible, making it difficult to find common denominators or factors relating to the error. That, and if it continues for too long in any given situation, your logs fill up and can jam the entire system - rare, but can happen.
Be that as it may, recycling the MMDVMHOST service seems to help:
or you can simply reboot, as you did. Neither is guaranteed to fix (work around) the problem, so as a last resort, one just has to wait it out. The problem does go away eventually for any given day.
Out of curiosity - searching for common factors here - were you running straight DMR or where you coming through a gateway? Where you using a local repeater or where you connected to inet directly?
Code: Select all
M: 2022-11-01 03:58:35 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:38 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:42 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:45 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:49 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:52 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:56 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:58:59 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:03 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:06 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:13 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:17 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:20 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:24 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:27 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:31 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:34 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:38 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:41 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:45 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:48 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:52 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:55 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 03:59:59 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:02 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:06 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:09 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:41 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:44 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:48 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:51 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:55 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:00:58 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:01:02 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:01:05 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:01:09 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:01:12 TS2, KI5VHC TG 31656, 3.7 seconds, 0% packet loss, BER: 0.0%
M: 2022-11-01 04:01:15 TS2, KI5VHC TG 31656, 3.1 seconds, 35% packet loss, BER: 0.0%What causes this, how it starts, when it starts, how it stops, why does it stop by itself, why does it come and go - these are all questions that don't seem to have an answer so far. The biggest problem is that it is unpredictable and irreproducible, making it difficult to find common denominators or factors relating to the error. That, and if it continues for too long in any given situation, your logs fill up and can jam the entire system - rare, but can happen.
Be that as it may, recycling the MMDVMHOST service seems to help:
Code: Select all
sudo systemctl restart mmdvmhost.serviceOut of curiosity - searching for common factors here - were you running straight DMR or where you coming through a gateway? Where you using a local repeater or where you connected to inet directly?
Re: Call sign keeps repeating
Yes the times listed are in the time frame I experienced the problem. I am not using DMR though, and I am using a MMDVM hat on my raspberry pi 3b in the ysf mode in the Americas link room. I am on my WIFI wireless not wired. I have tried to use the ysf2dmr before but never could get it to connect. Maybe because I don't have a DMR radio and was using my Yaesu FT-70D. Still learning about the system. Thanks for the answer.
Re: Call sign keeps repeating
Thanks for your feedback!
Your setup fits with what I'm suspecting here: some kind of systemic intermodal/interoperability issue. It does not involve anything within Pi-Star per se or with the hardware (Pi's or Hat's); firmware or inet speed/connectivity issues, choice of time slots, time of day, duplex/simplex - all unlikely sources as well.
From what I can tell, it appears to involve certain talk groups that are linked across modes: either some info isn't being passed through completely or there's a loop of some sort occurring along the path, or the timing is off somewhere in the chain - can't determine from here. Obviously, some components in this system aren't playing nicely with each other.
We need more eyeballs on this, more data, more examples, other thoughts on causes and possible fixes.
Your setup fits with what I'm suspecting here: some kind of systemic intermodal/interoperability issue. It does not involve anything within Pi-Star per se or with the hardware (Pi's or Hat's); firmware or inet speed/connectivity issues, choice of time slots, time of day, duplex/simplex - all unlikely sources as well.
From what I can tell, it appears to involve certain talk groups that are linked across modes: either some info isn't being passed through completely or there's a loop of some sort occurring along the path, or the timing is off somewhere in the chain - can't determine from here. Obviously, some components in this system aren't playing nicely with each other.
We need more eyeballs on this, more data, more examples, other thoughts on causes and possible fixes.
Re: Call sign keeps repeating
Not relevant to your actual problem but...
The purpose of ysf2dmr mode is specifically meant for for using a YSF radio to cross over to DMR on the net side. You WILL likely need a DMR ID # (I don't know what YSF uses to identify users, but it may not pass for DMR). I'm only configured for D-STAR and DMR, and use separate radios for those (the AMBE CODEC for D-STAR is not compatible with DMR/YSF/etc., requiring a $$$ chip to decode one and encode to the other).
--
AF6VN
Dennis L Bieber