# ASL3 Warning From chan\_usrp.c **URL:** \ **Category:** AllStarLink\ **Created:** [December 16, 2024, 7:16pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493 "2024-12-16T19:16:59Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![jamesev01](https://community.allstarlink.org/user_avatar/community.allstarlink.org/jamesev01/32/3649_2.png) [@jamesev01](https://community.allstarlink.org/u/jamesev01)\ **Post date:** [December 16, 2024, 7:16pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/1 "2024-12-16T19:16:59Z")
Using a RPi5 I installed DVSwitch on the same instance as ASL3 and linked it to ASL3 using chan\_usrp. The following message is repeated for each transmission received from DVSwitch in the asterisk log: WARNING[265959] chan\_usrp.c: Channel usrp/127.0.0.1:34001:32001: Receive queue exceeds the threshold of 320 I tried to determine the origin of this message in the source code but have been unsuccessful. I also notice that received audio from DVSwitch is mangled at the very beginning of a received transmission but soon becomes normal. Possibly a result of the same issue. Is there a known resolution to this issue? Can it be resolved in configuration, or a change to the source code? ---
**Author:** ![KC2NJV](https://community.allstarlink.org/user_avatar/community.allstarlink.org/kc2njv/32/3634_2.png) [@KC2NJV](https://community.allstarlink.org/u/KC2NJV)\ **Post date:** [December 21, 2024, 3:04am UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/2 "2024-12-21T03:04:27Z")
I have this on one of my nodes as well… ---
**Author:** ![WA3WCO](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wa3wco/32/3123_2.png) [@WA3WCO](https://community.allstarlink.org/u/WA3WCO)\ **Post date:** [December 21, 2024, 3:54am UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/3 "2024-12-21T03:54:27Z")
> [@jamesev01](#): > > I tried to determine the origin of this message in the source code but have been unsuccessful. Line 598 of […/app\_rpt/channels/chan\_usrp.c](https://github.com/AllStarLink/app_rpt/blob/master/channels/chan_usrp.c) logs this message. > [@jamesev01](#): > > Is there a known resolution to this issue? Can it be resolved in configuration, or a change to the source code? I don’t see any open [GitHub / app\_rpt](https://github.com/AllStarLink/app_rpt/issues) reported issues. Can you create a new issue? 🙂 ---
**Author:** ![KC2NJV](https://community.allstarlink.org/user_avatar/community.allstarlink.org/kc2njv/32/3634_2.png) [@KC2NJV](https://community.allstarlink.org/u/KC2NJV)\ **Post date:** [December 21, 2024, 11:37am UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/4 "2024-12-21T11:37:34Z")
Issue recorded on Git… ---
**Author:** ![Mike](https://community.allstarlink.org/user_avatar/community.allstarlink.org/mike/32/1569_2.png) [@Mike](https://community.allstarlink.org/u/Mike)\ **Post date:** [December 21, 2024, 12:09pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/5 "2024-12-21T12:09:08Z")
> [@jamesev01](#): > > I tried to determine the origin of this message in the source code but have been unsuccessful. > > I also notice that received audio from DVSwitch is mangled at the very beginning of a received transmission but soon becomes normal. Possibly a result of the same issue. Have you looked at your dvswitch logs for answers ? On the surface, it does not look like a asl3 or usrp error but the input stream in error. USRP is not satisfied with it. Hence the message spew from the channel driver. ---
**Author:** ![KC2NJV](https://community.allstarlink.org/user_avatar/community.allstarlink.org/kc2njv/32/3634_2.png) [@KC2NJV](https://community.allstarlink.org/u/KC2NJV)\ **Post date:** [December 21, 2024, 2:28pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/6 "2024-12-21T14:28:49Z")
This is a representative sample of MMDVM log ```auto M: 2024-12-21 13:59:47.928 YSF, GPS Position from K0EHT-RON on radio=0x34 is lat=39.208000 long=-94.679665 M: 2024-12-21 14:00:11.734 YSF, received network end of transmission, 24.7 seconds, 0% packet loss, BER: 0.0% M: 2024-12-21 14:00:17.009 YSF, received network data from KE8EFQ to ALL at KU0S/GW I: 2024-12-21 14:00:17.009 YSF, Lookup call KE8EFQ returned id 0 -> 1234567 M: 2024-12-21 14:00:18.499 YSF, GPS Position from KE8EFQ on radio=FTM-100D is lat=41.188000 long=-81.976997 M: 2024-12-21 14:00:25.305 YSF, received network end of transmission, 8.4 seconds, 0% packet loss, BER: 0.0% M: 2024-12-21 14:00:31.876 YSF, received network data from K0EHT-RON to ALL at KU0S/GW I: 2024-12-21 14:00:31.876 YSF, Lookup call K0EHT returned id 3129461 -> 3129461 M: 2024-12-21 14:00:32.665 YSF, GPS Position from K0EHT-RON on radio=0x34 is lat=39.208000 long=-94.679665 M: 2024-12-21 14:00:36.566 YSF, received network end of transmission, 4.8 seconds, 0% packet loss, BER: 0.0% M: 2024-12-21 14:03:14.379 YSF, received network data from W1KN to ALL at BM3104 I: 2024-12-21 14:03:14.379 YSF, Lookup call W1KN returned id 3154382 -> 3154382 M: 2024-12-21 14:03:14.849 YSF, received network end of transmission, 0.9 seconds, 0% packet loss, BER: 0.0% M: 2024-12-21 14:03:21.339 YSF, received network data from W1KN to ALL at BM3104 I: 2024-12-21 14:03:21.340 YSF, Lookup call W1KN returned id 3154382 -> 3154382 M: 2024-12-21 14:03:24.460 YSF, received network end of transmission, 3.7 seconds, 0% packet loss, BER: 0.0% ``` This is a representative sample of Analog log: ```auto I: 2024-12-21 14:18:27.121 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ I: 2024-12-21 14:19:01.064 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX I: 2024-12-21 14:19:47.769 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ I: 2024-12-21 14:20:16.067 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX I: 2024-12-21 14:21:01.926 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ I: 2024-12-21 14:21:49.294 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX I: 2024-12-21 14:22:01.050 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ I: 2024-12-21 14:22:27.360 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX ``` No errors “E:” in those files or YSFGateway (where the switch is tuned). ---
**Author:** ![Mike](https://community.allstarlink.org/user_avatar/community.allstarlink.org/mike/32/1569_2.png) [@Mike](https://community.allstarlink.org/u/Mike)\ **Post date:** [December 21, 2024, 2:49pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/7 "2024-12-21T14:49:12Z")
> [@KC2NJV](#): > > representative sample This is somewhat meaningless. A sample when the USRP error is given might mean something. Analog bridge is the last to handle the stream before sent to USRP. You really should be presenting this to those at dvswitch for help. It does not appear to be a asl issue. ---
**Author:** ![KC2NJV](https://community.allstarlink.org/user_avatar/community.allstarlink.org/kc2njv/32/3634_2.png) [@KC2NJV](https://community.allstarlink.org/u/KC2NJV)\ **Post date:** [December 21, 2024, 2:56pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/8 "2024-12-21T14:56:02Z")
If all the logs repeat the same types of data, then one is not going to identify an error. There are no errors in the DVSwitch log files. ---
**Author:** ![Mike](https://community.allstarlink.org/user_avatar/community.allstarlink.org/mike/32/1569_2.png) [@Mike](https://community.allstarlink.org/u/Mike)\ **Post date:** [December 21, 2024, 3:31pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/9 "2024-12-21T15:31:07Z")
Assuming the usrp channel driver is working correctly, It is not getting data correctly and is the one telling you that fact. The error. It gets it’s data from analog\_bridge. By structure, That is all I can say about it. You will need to ask > **[main groups.io Group](https://dvswitch.groups.io/g/main)** > > The \*official\* place to go for discussion/support for DVSwitch, DVSwitch Mobile, Quantar Bridge, DMRlink and HBlink Download the DVSwitch Raspberry Pi server image DVSwitch Server RPi image ( http://dvswitch.org/DVSwitch-Server-RPi.zip ) Download the... ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [January 2, 2025, 7:46pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/10 "2025-01-02T19:46:20Z")
We are seeing the same warning as well. `[2024-12-23 09:05:50.336] WARNING[1142] chan_usrp.c: Channel usrp/127.0.0.1:34001:32001: Receive queue exceeds the threshold of 320` In our case, it appears on inbound DMR voice calls longer than a few seconds, but does not appear to cause any issues with audio on the analog output side of things. It really sounds like the analog driver is not keeping up with the stream (queue is being over run by the Analog\_Bridge), but it must be “really close” to 320, otherwise I would think we would notice audio problems… ---
**Author:** ![Mike](https://community.allstarlink.org/user_avatar/community.allstarlink.org/mike/32/1569_2.png) [@Mike](https://community.allstarlink.org/u/Mike)\ **Post date:** [January 2, 2025, 8:37pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/11 "2025-01-02T20:37:47Z")
> [@N8RAW](#): > > We are seeing the same warning as well. > **[main groups.io Group](https://dvswitch.groups.io/g/main)** > > The \*official\* place to go for discussion/support for DVSwitch, DVSwitch Mobile, Quantar Bridge, DMRlink and HBlink Download the DVSwitch Raspberry Pi server image DVSwitch Server RPi image ( http://dvswitch.org/DVSwitch-Server-RPi.zip ) Download the... ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [January 2, 2025, 9:54pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/12 "2025-01-02T21:54:45Z")
I guess I stated it “wrong” - USRP is the software not keeping up with the stream… Nothing has changed with DVSwitch or the Analog\_Bridge, but ASL has. Why would we suspect it is a problem with Analog\_Bridge? I suppose at this point it’s more of a log filler than a problem. ---
**Author:** ![N2DYI](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n2dyi/32/1712_2.png) [@N2DYI](https://community.allstarlink.org/u/N2DYI)\ **Post date:** [January 3, 2025, 1:52am UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/13 "2025-01-03T01:52:05Z")
I’m curious about something. In your DVSwitch setup, are you using Analog\_Reflector between Analog\_Bridge and ASL? If not, have you tried disabling metadata export from Analog\_Bridge to see if anything changes? in /opt/Analog\_Bridge/Analog\_Bridge.ini, find the line; `exportMetadata = true ; Export metadata to USRP partner (transcode setups require this)` Change true to false, then systemctl restart analog\_bridge If you are sending directly from Analog\_Bridge to ASL, you don’t need this. However, if you are sending to Analog\_Reflector, then sending Analog\_Reflector to ASL, you should leave it enabled to maintain metadata. This metadata sends a chunk at the start of a transmission, which comes out as a sort of popping sound if it isn’t intercepted by Analog\_Reflector, or disabled entirely. I wonder if this changes the behavior of ASL’s USRP driver when fed by DVSwitch Server or not. ---
**Author:** ![jamesev01](https://community.allstarlink.org/user_avatar/community.allstarlink.org/jamesev01/32/3649_2.png) [@jamesev01](https://community.allstarlink.org/u/jamesev01)\ **Post date:** [January 3, 2025, 10:51am UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/14 "2025-01-03T10:51:37Z")
Thanks for pointing out exportMetadata. As OP in this thread, I mentioned there was a glitch heard at the start of received transmissions. With exportMetadata=false, the glitch is gone, but the asterisk log warning messages remain. ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [January 3, 2025, 2:41pm UTC](https://community.allstarlink.org/t/asl3-warning-from-chan-usrp-c/22493/15 "2025-01-03T14:41:05Z")
So channel driver is generating the error here: > The warning is NEW to the driver code as of October 26, 2024: > > > \* chan\_usrp: Add TX/RX debug messages > > This updates chan\_usrp to have debug m…essage for TX and RX on and off. The messages closely match those in chan\_simpleusb and chan\_usbradio. This indication is needed to help users troubleshoot problems when using this driver. > > I also added a queue overflow warning message should the internal queue overflow. This should never happen, but if it does, it needs to be reported. > > \* chan\_usrp: Add TX/RX debug messages > > Changed the queue overflow to show the actual threshold. I’d say the warning is misleading for sure → It says it has exceed the threshold then give us the `USRP_VOICE_FRAME_SIZE` instead of `QUEUE_OVERLOAD_THRESHOLD` Since this is a “new” error, it may have been occurring forever as well, we just didn’t know it.