¿ªÔÆÌåÓý

Re: Other Stations don't decode


 

¿ªÔÆÌåÓý


Hello Patrick,

OK, I think I've got it figured out. This has been my obsession for a bit to long now and I'm glad to have it figured out.

Good to hear.


The SCU-17 can not and does not handle a 44100 sampling rate nor a 48000 sampling rate.? The sampling rates I have found that works are between 22,000 (might be lower) and 38,000 Hz at most. I tried 40,000, 44,100, 48,000 and they didn't work.

That doesn't sound right at all.? Try this command to display what sampling rates this SCU-17 device offers:

?? bash <(wget -q -O - ) -l usb -s


You will want to use the NATIVE sampling rate offered by the card because if you don't and you use the "plughw" prefix in your direwolf.conf's "ADEVICE" line, this will make ALSA take the native sampling rate from the hardware and then interpolate it into the rate you specify.? That's MORE work for the computer to do and will yield poorer audio.


I have my sample rate set as follows....
ARATE 38000

What makes you think that 38000 is better than say 48000 or 44100?




The SCU-17 with Direwolf will trigger FSK and PTT at the same time depending on how you have it set.
The default setting for the SCU are...
DTR - FSK
RTS - PTT
To get the SCU to trigger PTT without FSK on you have to set PTT to -DTR RTS. This will turn FSK on when receiving but off when transmitting. This appears to not affect receiving in any way that I've noticed.
Example:.....
PTT /dev/ttyUSB1 -DTR RTS
FSK and PTT on during transmit....
PTT /dev/ttyUSB1 DTR RTS

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??


Hopefully someone else using a SCU-17 finds this thread useful.

Here is my config file for reference and for software TNC use only
ACHANNELS 1
ARATE 38000
#ARATE 44100
#ADEVICE plughw:CARD=CODEC,DEV=0 hw:CARD=CODEC,DEV=0? <--------------- not correct: this line is specifying the same device TWICE
ADEVICE plughw:CARD=CODEC,DEV=0
DWAIT 0???? <------------ This is the default but also shouldn't be needed in almost any sitation; TXDELAY ultimate can mask any use of this variable
#SLOTTIME 10
PERSIST 63
TXDELAY 50? <------------ Thast delay value is probably way too high for an FTM300.? I would expect this value to be between 120 and 200
#TXTAIL 10
FULLDUP OFF

CHANNEL 0

MYCALL replace-me-with-your-call

MODEM 1200? <---------- Depending on your computer's higher performance hardware, you can append a "/3" to do sub-sampling and lower the CPU load
#MODEM 2400
#MODEM 4800
#MODEM 9600


# PTT Notes for the SCU-17
# DTR Triggers FSK, RTS Triggers PTT, -DTR will leave FSK on until TX is triggered

#PTT COM1 RTS
#PTT COM1 RTS -DTR
#PTT /dev/ttyUSB1 RTS
PTT /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00F8CEC3-if01-port0 DTR RTS

AGWPORT 8000
KISSPORT 8001

FIX_BITS 1? <-----------? Do note that FIXBITS is probably OK for connected packet but might create unacceptably weird decodes for APRS.? If you are going to use this for connected mode packet, you actually will want to use the line "FIX_BITS 1 AX25" where the "AX25" tells Direwolf to disable the APRS-specific heuristics.? Packets will decode a little better and Direwolf will complain less about the packets not conforming to APRS specific formatting.

--David
KI6ZHD

Join [email protected] to automatically receive all group messages.