Hello Patrick,
?5) USB Audio Class Digital alsa audio output interface
`hw:3,0'
?- device name?????? =
CODEC????????????????????????????????????????????????????? ?
?- interface name??? = USB
Audio????????????????????????????????????????????????? ?
?- usb audio class?? =
(n/a)????????????????????????????????????????????????????? ?
?- character device? =
/dev/snd/pcmC3D0p????????????????????????????????????????? ?
?- samplerates (Hz)? =
S8:32000,44100,48000?????????????????????????????????????? ?
?????????????????????? S16_LE:32000,44100,48000
Very interesting this device has native 32000 support.? I don't
think I've seen that before.
?6) USB Audio Class Digital alsa audio output interface
`hw:4,0'
?- device name?????? =
CODEC_1??????????????????????????????????????????????????? ?
?- interface name??? = USB
Audio????????????????????????????????????????????????? ?
?- usb audio class?? =
(n/a)????????????????????????????????????????????????????? ?
?- character device? =
/dev/snd/pcmC4D0p????????????????????????????????????????? ?
?- samplerates (Hz)? =
S8:32000,44100,48000?????????????????????????????????????? ?
??????????????????????
S16_LE:32000,44100,48000?????????????????????????????????? ?
?- monitor file????? =
/proc/asound/card4/pcm0p/sub0/hw_params??????????????????? ?
?- stream file?????? = /proc/asound/card4/stream0
I'm not sure why you're seeing TWO of these though.? That's unusual
if not wrong unless you have two of these unit connected
--
What makes you think that 38000 is better than say 48000 or
44100?
--
Oh! Believe me I don't! LOL It's what I found that worked. I
guess if other stations can decode it then it's better than the
alternative if you get my drift! LOL
But now with that first command I see that 32000, 44100 and
48000 are native but my other stations can't decode the
transmitted signal at those rates for some reason.
I could try using plughw:
Your previous email said you were using "ADEVICE
plughw:CARD=CODEC,DEV=0" aka.. you ARE using the "plughw" aspect of
the ALSA sound system.? Anyway.. can provide some sound captures of
direwolf running your SCU-17 at say 44100 and 48000 which DON'T
decode on your other station?? This shouldn't be happening.?
Btw.. what is your other station using for a soundcard, TNC, etc?
--
I think your observation here needs some more troubleshooting in
the Direwolf code.? The way I interpret "-DTR" is that DTR
should *never* be asserted on that serial port.? Curious, if you
shutdown Direwolf and any other programs that might use the
SCU-17.. now UNPLUG it's USB cable, wait 5 seconds, plug it's
USB cable back in, and then run the "dmesg" command in a
terminal window, what do the last 10 lines or so show about the
USB device being detected by the kernel?
--
I agree, -DTR shouldn't assert anything on DTR but it does by my
observation. It inverts the commands when not signaled and
asserts them when signaled.
Here are those dmesg lines...
I'll have to look to see what might be going on here on v1.7 and
v1.6.??
Btw.. for your compiler errors on v1.7, this is an issue with gpsd
and it's ever changing libraries.? If you can DISABLE the support
for gpsd at compile time just for this test, I think that will get
you going.
152012.974697] usb 3-2.2.1: new high-speed USB device number 16
using xhci_hcd
[152013.075624] usb 3-2.2.1: New USB device found,
idVendor=0424, idProduct=2512, bcdDevice= b.b3
[152013.075633] usb 3-2.2.1: New USB device strings: Mfr=0,
Product=0, SerialNumber=0
[152013.133731] hub 3-2.2.1:1.0: USB hub found
[152013.133996] hub 3-2.2.1:1.0: 2 ports detected
[152013.490715] usb 3-2.2.1.1: new full-speed USB device number
17 using xhci_hcd
[152013.621512] usb 3-2.2.1.1: New USB device found,
idVendor=10c4, idProduct=ea70, bcdDevice= 1.00
[152013.621522] usb 3-2.2.1.1: New USB device strings: Mfr=1,
Product=2, SerialNumber=5
[152013.621527] usb 3-2.2.1.1: Product: CP2105 Dual USB to UART
Bridge Controller
[152013.621531] usb 3-2.2.1.1: Manufacturer: Silicon Labs
[152013.621534] usb 3-2.2.1.1: SerialNumber: 00F8CEC3
[152013.626585] cp210x 3-2.2.1.1:1.0: cp210x converter detected
[152013.635739] usb 3-2.2.1.1: cp210x converter now attached to
ttyUSB0
[152013.638582] cp210x 3-2.2.1.1:1.1: cp210x converter detected
[152013.647739] usb 3-2.2.1.1: cp210x converter now attached to
ttyUSB1
[152013.726708] usb 3-2.2.1.2: new full-speed USB device number
18 using xhci_hcd
[152013.852525] usb 3-2.2.1.2: New USB device found,
idVendor=08bb, idProduct=29b3, bcdDevice= 1.00
[152013.852536] usb 3-2.2.1.2: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
[152013.852542] usb 3-2.2.1.2: Product: USB Audio CODEC
[152013.852546] usb 3-2.2.1.2: Manufacturer: Burr-Brown from
TI???????????? ?
[152015.359738] input: Burr-Brown from TI?????????????? USB
Audio CODEC? as
/devices/pci0000:00/0000:00:08.1/0000:05:00.4/usb3/3-2/3-2.2/3-2.2.1/3-2.2.1.2/3-2.2.1.2:1.3/0003:08BB:29B3.0008/input/input20
[152015.418918] hid-generic 0003:08BB:29B3.0008: input,hidraw5:
USB HID v1.00 Device [Burr-Brown from TI?????????????? USB Audio
CODEC ] on usb-0000:05:00.4-2.2.1.2/input3
Ok.. that looks all reasonable.
--
#ADEVICE plughw:CARD=CODEC,DEV=0 hw:CARD=CODEC,DEV=0?
<--------------- not correct: this line is specifying the
same device TWICE
--
My understanding was the first was for input the other for
output. Some other applications like JS8Call and WSJTX don't
like pointing to the exact some device at times, but it worked.
You're correct.. I forgot about that syntax.
--
TXDELAY 50? <------------ Thast delay value is probably way
too high for an FTM300.? I would expect this value to be between
120 and 200
--
I tried 200 and WOW that was a long TX delay so I turned it
down. 50 was nice and short.
Ugh.. sorry.. I was forgetting that the unit here is 10s of
milliseconds.?? What you should shoot for here is say 120 to 200ms.?
In Direwolf syntax, that should be a "12" to a "20".?? Start at "20"
and see if everything works in communicating to remote packet
stations (not just home packet stations).? Then slowly work your way
down in say 25ms increments.? Since the FTM300 is a digital radio, I
would think it can support faster than average key up times of about
150ms but you'll just have to experiment here.
The machine is a quad core with hyper threading, well hyper
transport for AMD with a boost up to 3.2Ghz. It's not the
fastest machine out there but it's by far faster than any Pi
could ever think of being
I'd rather ensure a good decode then try to save a little bit on
the CPU but if I can get great decode and performance I'm all
ears.
I'm not sure what you mean by append a "/3
See the Direwolf User Guide in the "MODEM" section.
If you have any suggestions on changing my config I'll give it
a go and test, I'm all ears and very happy to make improvements
and proper adjustments.
I won't be able to do any testing until this evening.
I have it all written down:?
??
--David
KI6ZHD
