ASL3 Warning From chan_usrp.c

App_rpt-users
1

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?

2

I have this on one of my nodes as well…

3

Line 598 of …/app_rpt/channels/chan_usrp.c logs this message.

I don’t see any open GitHub / app_rpt reported issues. Can you create a new issue? :slight_smile:

4

Issue recorded on Git…

5

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.

6

This is a representative sample of MMDVM log

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:

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).

7

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.

8

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.

9

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

1 Like