Hello we have a couple Motorola repeaters we recently upgraded to asl 3 and seems sort of random but it stops transmitting during nets for about a minute. No time out notice or anything, but it's still receiving we can still hear them on the repeaters other than the one that is doing it, they both seem to be doing it. Thanks.
Make sure your transmitter is not over heating and that you have fans running on it.
Clay, I would advise you to first watch the repeater live and see if the ptt from asl is dropping.
But I kinda doubt that unless you have rf in the lines or near threshold values.
Motorola has a lot of protection circuits on TX that will either cause the tx to back down or off.
Perhaps I should specify that it is not a hardware problem both repeaters worked just fine running hamvoip. The only thing that was changed was the SD Cards running asl 3, and it only seemed to start doing it after the last update.
So, you are seeing the PTT line drop on the URI ?
Please capture some debug information as that seems unusual and unexpected:
-
Make sure that
debugappears in the line that startsconsole(ormessages.log) in the file/etc/asterisk/logger.conf. Restart Asterisk or do acore reloadif you need to edit it. -
From the Asterisk CLI enter
core set debug 4 app_rpt.so -
When the transmission drops out, node the debug events surrounding the dropout and post them here.
No ones been near the repeaters when they are doing it to look, both sites have limited access, and it doesn't always do it. I mean I could go sit at the one site, but I was hoping someone might have an idea why its doing it before i go to those extremes, and also the MTR2000 one of the ones that was doing it showed no errors in its internal logs.
I have set debug to 4 we will have to wait for it to happen.
You need to verify that the PTT line is dropping on the URI ?
Before I put time on it, I would like to know that it is from that point back to ASL.
There is a URI between them.
For all I know a transistor on the URI may be at fault or the actual voltage and you are not presenting anything that rules this kind of stuff out.
So, I'm not looking at software till we get past that.as it could be for nothing.
Intermittent does not sound like a software issue. But not saying it isn't.
Just not chasing my tail on a assumption.
So your saying that two working repeaters all of a sudden doing it, after they both have been upgraded to ASL3 is just a coincidence?
Whats this all about:
[2025-05-21 09:18:54.244] DEBUG[2774]: app_rpt/rpt_telemetry.c:1060 rpt_tele_thread: Requested channel DAHDI/pseudo-352598795
[2025-05-21 09:18:54.244] DEBUG[2774]: app_rpt/rpt_call.c:32 rpt_disable_cdr: No CDR present on DAHDI/pseudo-352598795
[2025-05-21 09:18:54.244] DEBUG[2774]: app_rpt/rpt_bridging.c:374 dahdi_conf_add: Channel DAHDI/pseudo-352598795 joining conference 1021
-- Hungup 'DAHDI/pseudo-352598795'
Debug logging is noisy and almost all of it will be expected/routine stuff. That's why we need to identify what gets logged right around the drop-out.
alright thanks I dont think either did it this morning.
MTR 3000 asterisk logs:
cut out around 1936
[2025-05-21 19:33:19.013] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870399&seqno=2331&nodes=T611419&apprptvers=3.4.5&apprptuptime=>
[2025-05-21 19:33:19.138] DEBUG[19053] app_rpt.c: Response: ok
[2025-05-21 19:33:25.893] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870405&seqno=2332&keyed=0&keytime=1515
[2025-05-21 19:33:26.016] DEBUG[19055] app_rpt.c: Response: ok
[2025-05-21 19:33:32.196] DEBUG[19057] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1730461198
[2025-05-21 19:33:32.196] DEBUG[19057] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-1730461198
[2025-05-21 19:33:32.196] DEBUG[19057] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-1730461198 joining conference 1021
[2025-05-21 19:33:52.853] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870432&seqno=2333&nodes=T611419&apprptvers=3.4.5&apprptuptime=>
[2025-05-21 19:33:52.976] DEBUG[19077] app_rpt.c: Response: ok
[2025-05-21 19:34:00.033] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870440&seqno=2334&keyed=0&keytime=1550
[2025-05-21 19:34:00.156] DEBUG[19079] app_rpt.c: Response: ok
[2025-05-21 19:34:26.913] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870466&seqno=2335&nodes=T611419&apprptvers=3.4.5&apprptuptime=>
[2025-05-21 19:34:27.037] DEBUG[19086] app_rpt.c: Response: ok
[2025-05-21 19:34:33.801] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870473&seqno=2336&keyed=0&keytime=1583
[2025-05-21 19:34:33.924] DEBUG[19090] app_rpt.c: Response: ok
[2025-05-21 19:35:00.530] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870500&seqno=2337&nodes=T611419&apprptvers=3.4.5&apprptuptime=>
[2025-05-21 19:35:00.654] DEBUG[19110] app_rpt.c: Response: ok
[2025-05-21 19:35:07.713] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870507&seqno=2338&keyed=0&keytime=1617
[2025-05-21 19:35:07.836] DEBUG[19112] app_rpt.c: Response: ok
[2025-05-21 19:35:34.706] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870534&seqno=2339&nodes=T611419&apprptvers=3.4.5&apprptuptime=>
[2025-05-21 19:35:34.829] DEBUG[19119] app_rpt.c: Response: ok
[2025-05-21 19:35:41.593] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870541&seqno=2340&keyed=0&keytime=1651
[2025-05-21 19:35:41.716] DEBUG[19121] app_rpt.c: Response: ok
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1964498358
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-1964498358
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-1964498358 joining conference 1021
[2025-05-21 19:36:06.655] DEBUG[19144] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-21128912
[2025-05-21 19:36:06.655] DEBUG[19144] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-21128912
[2025-05-21 19:36:06.655] DEBUG[19144] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-21128912 joining conference 1021
[2025-05-21 19:36:07.994] DEBUG[19145] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1241004314
[2025-05-21 19:36:07.994] DEBUG[19145] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-1241004314
[2025-05-21 19:36:07.994] DEBUG[19145] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-1241004314 joining conference 1021
[2025-05-21 19:36:08.264] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870568&seqno=2341&nodes=T611419&apprptvers=3.4.5&apprptuptime=>
[2025-05-21 19:36:08.387] DEBUG[19146] app_rpt.c: Response: ok
[2025-05-21 19:36:09.594] DEBUG[19148] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-839566493
[2025-05-21 19:36:09.594] DEBUG[19148] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-839566493
[2025-05-21 19:36:09.594] DEBUG[19148] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-839566493 joining conference 1021
[2025-05-21 19:36:12.214] DEBUG[19149] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-666453860
[2025-05-21 19:36:12.214] DEBUG[19149] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-666453860
[2025-05-21 19:36:12.214] DEBUG[19149] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-666453860 joining conference 1021
[2025-05-21 19:36:15.452] DEBUG[866] app_rpt.c: Making statpost to http://stats.allstarlink.org/uhandler?node=611410&time=1747870575&seqno=2342&keyed=0&keytime=1685What are you using for a wan IP network ? (provider)
The site this repeater is at is connected directly to the backbone of a fibre network with a copper connection directly to one of the isps switches, the other one is on cable internet with our own wifi link running on 5880 between the main hub site and the repeater site is like 20km away using mikrotik hardware, but we are having issues with its own audio coming in directly to that repeater not over the asl3 link, as with these two sites the asl node replaces the controller with a ARA FOB board, and once again i stress, all the same hardware, and connections worked just fine before we upgraded to asl3.
Don't really care how big it is, copper or fiber or rf, Sounds nice.
Is the WAN network CGNATed ?
Was hoping to get that info with 'who is the network provider?' and looking it up myself.
If you don't know or care to answer,
I will just leave it as 'I'm stumped without additional info'.
Just an update for anyone who may be following this. Upon discussion with some friends in IT they had experiences where cockpit seemed to have a memory leak, or some sort of resource run away in certain situations, causing undesired operation of other software on the machines, I had removed cockpit on both repeaters last week, and thus far the problem has not resurfaced. This could of course be coincidence so will continue to update you should some thing happen, or in a few weeks should it seem to have solved the problem.
73
The Cockpit leak is only if you leave a console window open for days.
I don't see which version of ASL3 your are running (looks like 3.4.5 based on the stat post). That may be helpful.
This "signature" is a typical telemetry CT or audio file being played into the repeater conference when RX drops:
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1964498358
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_call.c: No CDR present on DAHDI/pseudo-1964498358
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_bridging.c: Channel DAHDI/pseudo-1964498358 joining conference 1021
So just trimming out a bit of noise:
[2025-05-21 19:33:32.196] DEBUG[19057] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1730461198
[2025-05-21 19:36:01.775] DEBUG[19143] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1964498358
[2025-05-21 19:36:06.655] DEBUG[19144] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-21128912
[2025-05-21 19:36:07.994] DEBUG[19145] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-1241004314
[2025-05-21 19:36:09.594] DEBUG[19148] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-839566493
[2025-05-21 19:36:12.214] DEBUG[19149] app_rpt/rpt_telemetry.c: Requested channel DAHDI/pseudo-666453860
Are these short "Kurchunk" because local TX dropped?
It's VERY possible there is a race somewhere causing the TX output to turn off. I'm thinking once it's "off" the output may need to actually drop before it can "fix" itself.
It maybe worth creating an issue on github under app_rpt if it continues to occur - that way we can "remember" to hunt for it.
Also, recently we added the ability to capture the state without recording the files in the archive directory.
On the 3.5.0 release, setting archivedir to a valid path AND setting archiveaudio to false in rpt.conf will provide a log of events without recording - this would be helpful to determine if the software "thinks" it unkeyed.
Wouldn't you get the same info from
rpt show variables xxxxx
rpt show vars xxxxx for pre asl3
Or is the result taken from a different place in the code?
I wrote a script to show status based on it and has seemed to work fine for a long time.
If using the archive function is better, I will make some changes.