chan_simpleusb, chan_usbradio: Use tune sections from main config file.

[InterLinked1]

Instead of having separate tune files for each node, look for a section for the node in the main config file.

Closes #276

[KB4MDD]

The static void tune_write(struct chan_simpleusb_pvt *o) routine, in both drivers, will need to be updated to save the tune settings. It is still writing the settings to the old config file.

[InterLinked1]

tune_write

Good catch! I missed those since they were not using the CONFIG_TUNE macro like the other ones. I'll update that and repush.

I'm also going to change from rewriting the entire file to using the ast_config APIs.

[tsawyer]

Getting error on asterisk start:

ERROR[4118856]: chan_simpleusb.c:891 hidthread: Channel 25334: Device string 1-1.3:1 was not found.

./asl-find-sound

1-1.3:1.0   --> 0d8c:0013 C-Media Electronics Inc.

Add this to simpleusb.conf under[25334]

devicenum=1
devstr=1-1.3:1.0
rxmixerset=750
txmixaset=450
txmixbset=0

*CLI> susb show settings

Active radio interface is [25334]
Device String is 1-1.3
Card is -1
Rx Level currently set to 750
Tx A Level currently set to 450
Tx B Level currently set to 0

[InterLinked1]

Getting error on asterisk start:

ERROR[4118856]: chan_simpleusb.c:891 hidthread: Channel 25334: Device string 1-1.3:1 was not found. ./asl-find-sound

1-1.3:1.0 --> 0d8c:0013 C-Media Electronics Inc. Add this to simpleusb.conf under[25334]

devicenum=1 devstr=1-1.3:1.0 rxmixerset=750 txmixaset=450 txmixbset=0 *CLI> susb show settings

Active radio interface is [25334] Device String is 1-1.3 Card is -1 Rx Level currently set to 750 Tx A Level currently set to 450 Tx B Level currently set to 0

Not sure how to interpret this... I remember Danny saying that warning was showing up before, so is all good or not?

[tsawyer]

It's not good, nor is the -1 from susb show settings. Another problem is the URI green LED is not blinking.

Bottom line is the URI is not recognized by app_rpt.

[tsawyer]

@InterLinked1 Maybe this will help.

The string comparison in simpleusb.c line 882 is not matching.

The actual device string is 1-1.3:1.0 as determined by Jason's asl-find-sound bash script.

That string has been entered into simpleusb.conf. But chan_simpleusb seems to be dropping the .0 as the error reads as follows:

ERROR[5895]: chan_simpleusb.c:891 hidthread: Channel 25334: Device string 1-1.3:1 was not found.

[InterLinked1]

@InterLinked1 Maybe this will help.

The string comparison in simpleusb.c line 882 is not matching.

The actual device string is 1-1.3:1.0 as determined by Jason's asl-find-sound bash script.

That string has been entered into simpleusb.conf. But chan_simpleusb seems to be dropping the .0 as the error reads as follows:

ERROR[5895]: chan_simpleusb.c:891 hidthread: Channel 25334: Device string 1-1.3:1 was not found.

Was this working before and is not working now (a regression) or was it not working before and still not working now?

I pushed a slight change; could you do core set debug 10 chan_simpleusb and reload?

[tsawyer]

Was this working before and is not working now (a regression) or was it not working before and still not working now?

Simpleusb used to load fine. It has not worked since the tune settings have moved.

Debug and reload: Device string is still Device String is 1-1.3:1

[InterLinked1]

Was this working before and is not working now (a regression) or was it not working before and still not working now?

Simpleusb used to load fine. It has not worked since the tune settings have moved.

Thanks, that helps!

Debug and reload: Device string is still Device String is 1-1.3:1

But are there any debug messages output, or none?

I can't look at this right now but I can log into your box to debug more. Is this 2509, or Murdoch?

[tsawyer]

I can log into your box to debug more.

Yes, 2509.

I guess you didn't compile it...

chan_simpleusb.c: In function ‘load_tune_config’:
chan_simpleusb.c:797:1: error: version control conflict marker in file
  797 | <<<<<<< HEAD
      | ^~~~~~~
chan_simpleusb.c:800:1: error: version control conflict marker in file
  800 | >>>>>>> bb24ae8b5b892a4984f370a109bdd321a8d4eb80
      | ^~~~~~~
chan_simpleusb.c:766:6: warning: variable ‘configured’ set but not used [-Wunused-but-set-variable]
  766 |  int configured = 0;
      |      ^~~~~~~~~~
chan_simpleusb.c:765:6: warning: variable ‘opened’ set but not used [-Wunused-but-set-variable]
  765 |  int opened = 0;
      |      ^~~~~~
chan_simpleusb.c:809:1: warning: control reaches end of non-void function [-Wreturn-type]
  809 | }
      | ^
make[1]: *** [/usr/src/asterisk-20.5.2/Makefile.rules:150: chan_simpleusb.o] Error 1
make: *** [Makefile:396: channels] Error 2

[InterLinked1]

I can log into your box to debug more.

Yes, 2509.

I guess you didn't compile it...

chan_simpleusb.c: In function ‘load_tune_config’: chan_simpleusb.c:797:1: error: version control conflict marker in file 797 | <<<<<<< HEAD | ^~~ chan_simpleusb.c:800:1: error: version control conflict marker in file 800 | >>>>>>> bb24ae8b5b892a4984f370a109bdd321a8d4eb80 | ^~~ chan_simpleusb.c:766:6: warning: variable ‘configured’ set but not used [-Wunused-but-set-variable] 766 | int configured = 0; | ^~~~~~ chan_simpleusb.c:765:6: warning: variable ‘opened’ set but not used [-Wunused-but-set-variable] 765 | int opened = 0; | ^~ chan_simpleusb.c:809:1: warning: control reaches end of non-void function [-Wreturn-type] 809 | } | ^ make[1]: [/usr/src/asterisk-20.5.2/Makefile.rules:150: chan_simpleusb.o] Error 1 make: [Makefile:396: channels] Error 2

Looks like those creeped in due to some Git weirdness.

Config issues have been resolved and changes repushed. Comments welcome.

[tsawyer]

The device string is correct now thanks to @InterLinked1. I did some basic testing including susb commands and connected a URI to a repeater. All seems well. Over to you @KB4MDD for further testing.

[tsawyer]

The repeater used for testing USB was found stuck in transmit. The node (2509 and 25334) was configured with chan_voter and chan_simpleusb. The voter node (2509) was not keyed. The USB node did not have a URI attached so unknown how repeater was keyed. Will monitor.