开云体育

Hello Larry,

I thought that udp:7355 would do for the receiver and that null would be assumed for the transmitter. This is only for listening right now. I'll use ADEVICE instead. This is on a Debian Bookworm laptop, not a pi. The audio is coming in on UDP from SDR++. The version: Dire Wolf DEVELOPMENT version 1.8 D (Jul 27 2024). The current receiver is a SDRplay RSPDX.

So, like this?

net105.conf:

ACHANNELS 1

CHANNEL 0

ADEVICE udp:7355 null

MODEM 300 1600:1800 7@30 /4 D

direwolf -c ./net105.conf -t 0 -n 1 -b 16 -r 48000

That all looks reasonable. The tuning of the SDR software is beyond the scope of Direwolf but pay attention to it's setup in terms of gain, LNA, AGC, needless over sampling rates, noise blankers, etc. I'm sure there are some SDR guides out there on the Internet focused on optimal software tuning and don't forget, not all SDRs are equal and you do get what you pay for when trying to really dig out the weak signals if you have a good antenna.

--David
KI6ZHD

On Monday, September 2nd, 2024 at 1:31 PM, David Ranch via groups.io <direwolf-groupsio@...> wrote:

Hello Larry,

I'm running direwolf this way on Debian:

On what computer and radio hardware? What are your goals here? Just 300bps HF receive ONLY? Also, what version of Direwolf are you running? I would recommend to compile up the newest 1.8 "dev" branch as it has the best code available and is quite stable.

net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D

A few things:

- you don't show your ADEVICE line

- Since you're using "/4", I assume you're using a SBC like a Raspberry Pi, etc?

- which "modem" to pick is a bit all over the place right now. The older details in the User Guide documentation on page 67 of the UserGuide ( file:///home/dranch/Downloads/User-Guide-7.pdf ) and section 9.2.4 says to use modem "B" and not "D" though in the new 1.8 DEV code they are actually the SAME setting now ( line 734). I hope in the future that the newer User Guide cleans out all the old/redundant/deprecated demodulator lines.

command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355

- I don't think the "-B 300:1600:1800" is a legal command line string

- Is this a receive only setup or a receive/transmit setup?

Are these options optimal for HF 300 baud?

Yes... and I also see you have enabled FX.25 support which I would recommend as it can make a big difference for remote stations that support it. If the remote station doesn't support it, they will ignore that data and still continue to function. See for more details.

I prefer to use command line options as much as possible instead of .conf file settings. I'd also like to get rid of any redundancies or default items in the .conf file.

I can appreciate that point of view and for basic needs, that's possible but if you have advanced needs, you WILL need to use direwolf.conf.

I am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.

Few things I can think of:

- What program are you using with Direwolf? Specifically if you plan on making HF packet BBS connections, you might consider using a AGWPE-based program that can support the new AX.25 v2.2 support in Direwolf. There are optimizations in this newer protocol which should help situations around re-transmissions, etc. compared to the v2.1 spec. I've found that most stations that support FX.25 will also support AX.25 v2.2. Btw.. if you DO enable this feature and try to initiate a connection to a remote station that does NOT support v2.2, there will be substantial delays until a connection is made as the remote station will ignore the v2.2 connection attempts. To disable this v2.2 support for known remote callsigns, use the " V20 <callsignA-1> <callsignB-2> etc" in the Direwolf conf file. See PDF page 141 of the User Guide for more details.

- If you are going to be transmitting, consider lowering your AX.25 MTU and/or MaxFrame (aka "window size"). Finding the right balance here depends on the error rate to the remote station depending on HF propagation. An MTU of 128 is about as high as you will want to go and some people tune it down to 64 for very bad propagation that requires lots of re-tries. Same thing for Window size. I would recommend to start with a window of 1 but if the path is very good, you might be able to get up to 4 (or maybe even better).


- There are other options mentioned in the User Guide section 10.3 that you might consider though unless you know what you're doing, leave the defaults alone. If you have QSOs with people on Net105, you might ask them what they recommend here in different times of the year (changes in propagation, etc), etc.

--David
KI6ZHD