Configuring 300baud with multiple decoders defaults to wrong demodulator

[dranch]

Using the configuration:

MODEM 300 1900:2100 7@30 /4 D

results in the following error:

Channel 0: Demodulator + option can't be combined with multiple frequencies.

It seems this warning is coming with the use of "7@30" but from what I can tell, when specifying the "300" modem, it's NOT selecting the "D" modulator for 300BAUD AFSK but instead, it's seemingly defaulting to the "E+" demodulator that's used for 1200bps AFSK. If you look at the bottom of the table in Section 9.2.2, it says:

"Note: The @ and + options are mutually exclusive. Both can?t be used at the same time on the same channel"

I'm not sure why these are mutually exclusive but if you FORCE the specific 300bps demodulator, the error goes away:

MODEM 300 1900:2100 7@30 /4 D

--
Dire Wolf DEVELOPMENT version 1.7 D (Feb 22 2022)
Includes optional support for: gpsd hamlib cm108-ptt

Reading config file /etc/ax25/direwolf-ft950.conf
Audio device for both receive and transmit: plughw:1,0 (channel 0)
Channel 0: 300 baud, AFSK 1900 & 2100 Hz, D, 44100 sample rate / 4.
0.0: D 1810 & 2010
0.1: D 1840 & 2040
0.2: D 1870 & 2070
0.3: D 1900 & 2100
0.4: D 1930 & 2130
0.5: D 1960 & 2160
0.6: D 1990 & 2190
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...

[bjpetit]

One additional note on this. I'm running direwolf on HF and have updated my modem config to explicitly set the demodulator as noted above. I found that when I specified the D modulator with my 300 BPS config the printed audio level was always 0.
Original config...
MODEM 300 1600:1800 7@30 D /1

Log output...

Apr 24 16:47:17 modempi direwolf[20738]: RK3KPK-8 audio level = 0(-99/-99)   [NONE]   ___||__
Apr 24 16:47:17 modempi direwolf[20738]: Audio input level is too low.  Increase so most stations are around 50.
Apr 24 16:47:17 modempi direwolf[20738]: [0.3] RK3KPK-8>N4WI-1:(I cmd, n(s)=0, n(r)=1, p=1, pid=0xf0)s n4wi<0x0d>

However, if i replaced demodulator D with demodulator E, I would receive real audio levels.
Updated config...
MODEM 300 1600:1800 7@30 E /1
Log output...

Apr 24 16:54:16 modempi direwolf[20890]: NS2B audio level = 81(13/15)   [NONE]   __|||__
Apr 24 16:54:16 modempi direwolf[20890]: [0.3] NS2B>ID:NS2B Penfield NY -0/KBD -1/BBS -7/NODE -11/PACNET<0x0d>

I'm keeping an eye on my HF performance with modulator E, but so far things look good. At any rate, it appears that there is an issue with measuring (or printing) the audio level with modulator D and the 300 baud configuration.

[guitarpicva]

@bjpetit Have you found that demodulator E is best in your testing? We are looking at direwolf as a special use "modem" and for exclusively HF. I would love to hear your conclusions on the different demodulators.

[bjpetit]

@guitarpicva I have found that in my experiments the E demodulator decoded slightly more packets on HF.
A couple notes on my setup. I'm running an. FT-991A into a RasPi 4 via the rig's soundcard. I have the rig's AGC turned off and the IF filter set to 3k.
I set up my Pi to run two separate instances of direwolf listening to the same sound device. One running demodulator D and the other E. The modem config was the same as the lines I posted in the prior post, except that I used the /2 on both the reduce the sample frequency, just to keep some CPU headroom.
The radio was tuned in to common packet frequencies on 20m during the day and 40m at night. Im also running FX.25 on both instances.

• The E demodulator uses about 50% more CPU than D on my set up
• In raw counts the E demodulator caught a few more frames
  • Over a 12hr sample the E demodulator saw 1106 frames vs 1102 frames for the D demodulator
  • There were some instances where the D demodulator caught a frame and the E didn't, but more instances where E caught a frame D missed.

[guitarpicva]

@bjpetit Excellent information Brent. Appreciate the details. Our use case is an IC-F8101 with internal sound card (likely the same chipset as yours). I am not sure the CPU usage is worth the small increase in frames decoded, particularly on a constrained SOC board.