Short version of long story.

I'm building a dual band APRS mobile setup, 2m and 30m.

The "main" software is YAAC on Lubuntu.

On 2m, I'm using a venerable Kenwood TH-D7e, on HF, Direwolf feeding an
Icom 706mk2g.

When it works, it works very well indeed. But, oh those sound card settings!

Yes, under Alsa things are somewhat convoluted, but I've an idea or two for the
wish list if I may.

1:
Could we have as a setup diagnostic, a simple ASCII text graphic indicating the
incoming sound level from the radio, vs what Direwolf "expects" as an ideal
level. An animated version of Alsamixer's level settings in essance. It doesn't
need to decode at the same time, but it would help enormously to confirm that
it's been configured to use the correct sound in device, and that the level was
somewhere near what it expects.

At present, in the presence of heavy QRM on an otherwise quiet channel, it's
nigh on impossible to get it set right.


Coupled with the above, perhaps a simple way (in the .conf file?) to send some
configuration settings to the Alsa sound system, so that it always starts up with
Direwolf in the "right way" (TX and RX levels) once you've found the true magic
settings.

At present, it seems that the input level at least, is entirely random. The
output level has jumped on me a couple of times too.

Maybe I'm missing something (other than grey cell's these days) but other
similar soundcard based DSP tools, have some way of their own to even crudly
manipulate the sound system for their needs, and indicate that they are at least
"hearing" something.


2:
Could the program NOT seize the com port RTS/DTR lines and set them +ve by
default? When you specify a serial port to use for PTT control. It sets both
lines high when the program first starts, so with a dumb PTT circuit, the rig's
gone into transmit while the software is trying to receive.


I have a PTT interface for the 706 that uses both DTR and RTS in oposition.
ONLY RTS+ and DTR- will key the radio, none of the other three combinations
(or floating lines) will key it. No more spurious TX events as computers boot,
or re-enumerate things when other gadgets are added/removed!

PTT /dev/ttyUSB102 -DTR I eventually found works for me as things are now.
(I have a udev rule pointing "ttyUSB102" at whatever ttyUSBx the unique
interface is working as, I got fed up of chasing it arround each time the PC was
booted..)


Related to the above, I feel it would be very good for all, if it were possible to
specify the state of the two lines (RTS/DTR) for not only PTT Active, but also for
PTT Idle.

I.e. Split the assignment of the port to use, with how it's used.

PTTport /dev/ttyUSBn # only to specify what port to use

PTTactive RTS -DTR # what to do, to key the radio
PTTidle -RTS DTR # what to do, to unkey the radio.


Plus for the future, how about the ability to throw a serial string at the radio,
for PTT on/off. CAT command style etc. But for that you need to specify
bitrate, parrity, stopbits etc etc...

PTTmsgsettings '4800,n,8,1,RTS,DTR' # specify everything needed!
PTTtxsmsg 'message to send for transmit'
PTTrxsmsg 'message to send for receive'

(Just examples for ideas. The message formatting should allow plain ascii, and
hex bytes, 0x13, 0x10 etc to cater for just about everything.)


Comments, good and bad welcome.

I know, it's open source, but I'm not a 'C' programmer of any repute. In any
case, though I might be able to eventually muddle through and figure out the
PTT issues, I havent a clue about how you handle soundcards and streaming
data etc. I'll leave that side for those that do.

Cheers All.

Dave G0WBX-9 (earlier today.)

Using all of the COM port selections possible with DireWolf, all I've ever been able to get is a "stuck in transmit" condition.

The program will be unusable for me until this problem is sorted out.

I think this list will start seeing more activity when this is addressed too. Apparently I'm not the only one who has been forced to give up on using DireWolf with the COM port assignment as it is.

73 DE Charles, N5PVL

开云体育

Hello Dave,

Could we have as a setup diagnostic, a simple ASCII text graphic indicating the
incoming sound level from the radio, vs what Direwolf "expects" as an ideal
level

This already exists. In the output of direwolf if you log it shows things like:


Digipeater WIDE1 audio level = 66 [NONE]
[0] N5ZEF-9>S7RSSQ,N6ACK-11,WIDE1*,WIDE2-1:`2YZm-"u\`"4!}_"<0x0d>
, Yaesu FTM-350, In Service
N 37 23.3100, W 122 01.6200, 13 MPH, course 306, alt 33 ft
[0L] KI6ZHD-7>APUDR1,WIDE2-1:=3720.62N/12160.00Wx/A=000077Using dantracker v0.02.0429 (), gps sats 3

WR6ABD audio level = 54 [NONE]
[0] WR6ABD>APN382:;146.64-LP*111111z3706.10N/12150.50WrT162 R35m NetTu2000 LPRC.net LPrieta<0x0d>
Object, "146.64-LP", Repeater, Kantronics KPC-3 rom versions
N 37 06.1000, W 121 50.5000
T162 R35m NetTu2000 LPRC.net LPrieta

KI6SEJ-10 audio level = 36 [NONE]
[0] KI6SEJ-10>SW2YYQ,WIDE1-1,WIDE2-2:`1P7l <0x1c>j/]"
MIC-E, JEEP, Kenwood TM-D710, En Route
N 37 29.9100, W 121 52.2700, 0 MPH, alt 2684 ft

Digipeater WR6ABD audio level = 55 [NONE]
[0] KI6SEJ-10>SW2YYQ,WR6ABD*,WIDE2-2:`1P7l <0x1c>j/]"
MIC-E, JEEP, Kenwood TM-D710, En Route
N 37 29.9100, W 121 52.2700, 0 MPH, alt 2684 ft

Digipeater WIDE1 audio level = 68 [NONE]
[0] K6GSJ-1>SWRSRT,N6ACK-11,WIDE1*,WIDE2-1:`2(/m W>/"6:}MT-RTG
, Off Dutymal car (side view)
N 37 23.2400, W 122 12.1900, 12 MPH, course 59, alt 712 ft
MT-RTG



Notice the first lines of each block... it shows the levels of 66, 54, 36, 55, 68. The ideal setting is to have most stations heard around a level of ** 50 **

. An animated version of Alsamixer's level settings in essance. It doesn't
need to decode at the same time, but it would help enormously to confirm that
it's been configured to use the correct sound in device, and that the level was
somewhere near what it expects.

Not sure what you mean here if you're already using the ncurses based alsamixer

At present, in the presence of heavy QRM on an otherwise quiet channel, it's
nigh on impossible to get it set right.

Yes... I too have asked for a debugging mode to give an idea if the direwolf process is hearing anything or not (open squelch).

Coupled with the above, perhaps a simple way (in the .conf file?) to send some
configuration settings to the Alsa sound system, so that it always starts up with
Direwolf in the "right way" (TX and RX levels) once you've found the true magic
settings.

Check out "alsactl store" and "alsactl restore". Put that in your startup script and you'll be golden

At present, it seems that the input level at least, is entirely random. The
output level has jumped on me a couple of times too.

That shouldn't happen with using the alsactl command

2:
Could the program NOT seize the com port RTS/DTR lines and set them +ve by
default? When you specify a serial port to use for PTT control. It sets both
lines high when the program first starts, so with a dumb PTT circuit, the rig's
gone into transmit while the software is trying to receive.

This would be best answered by John but I do know sometimes, initializing the serial ports can be difficult.

I have a PTT interface for the 706 that uses both DTR and RTS in oposition.
ONLY RTS+ and DTR- will key the radio, none of the other three combinations
(or floating lines) will key it. No more spurious TX events as computers boot,
or re-enumerate things when other gadgets are added/removed!

That's a nice setup and I'm looking for something similar to this for the Rpi. One GPIO line would be an "enable/disable" line (hold HIGH to enable) and the other GPIO line for actual PTT. This is really needed when the RPI is off or rebooting and with a dumb PTT circuit, it's keying the radio!

PTT /dev/ttyUSB102 -DTR I eventually found works for me as things are now.
(I have a udev rule pointing "ttyUSB102" at whatever ttyUSBx the unique
interface is working as, I got fed up of chasing it arround each time the PC was
booted..)

Yes.. but as you've found, the udevrules are the way to go.

Plus for the future, how about the ability to throw a serial string at the radio,
for PTT on/off. CAT command style etc. But for that you need to specify
bitrate, parrity, stopbits etc etc...

HAMlib is the solution here but currently not supported.


--David
KI6ZHD

Dave,
I'm using Direwolf as a Rx-only Igate on 30m on an Odroid3, but there are also instructions for the
RPi. As my setup is Rx-only, I haven't transmitted using it but I will relate some of my experiences.
1. If you watch the screen output (when it is started in a terminal), audio levels will be displayed
when it receives packets. Adjust the level with alsamixer.
Once you are happy with the settings, from a terminal type "sudo alsactl store". This will save the
settings and restore them on boot.
2. There is options for using GPIO pins on the RPi as PTT but this maybe not what you are after.
Another option is to run multiple instances of direwolf at the same time. I have to do this to take
advantage of the quad core architecture of the Odroid.
Two instances mean two different config files, so you get to choose different settings for each. I
had to do some alsa magic to get the different instances to share the same audio card and it this is
an option, I'll happily share specific instructions.
On the subject of logging and viewing the terminal output, the new "logging" feature introduced in
V1.1 only saves received stations. I like to save the terminal output to watch for errors, so this
is what I do.
Firstly, you need to install the "moreutils" package (sudo apt-get install moreutils).
Then you start direwolf (daemonized) as follows:

./direwolf -t 0 -c direwolfa.conf 2>&1 | ts '[%Y-%m-%d %H:%M:%S]' >> <path_to_logfile_and_name> &

Where:
- t 0 Removes the colors from the terminal output. This doesn't work properly in Linux
- c direwolfa.conf The config file to read. I have three called a, b and c
- 2>&1 Redirects error to stdout (normally the screen however keep reading :-) )
- | ts '[%Y-%m-%d %H:%M:%S]' This is the timestamp function installed when 'moreutils' was installed
and will prepend a line with a timestamp
- >> <path_to_file> This redirects the line with timestamp to the logfile named here.
- & The trailing & starts direwolf in the background

I have three different config files that are started via a script, creating three different
instances of direwolf that allows me to cover 100Hz either side of the 30m freq :-)

Ian
VK1IAN

One other thing, PTT via cat command is not supported on the 706MkIIG

Ian

Hi All. (Charles, David and Ian)

Thanks for the replies, all very useful.


Charles:
Re the stuck PTT, yes, that is what I found too. As soon as the program grabs
the port, both DTR and RTS are set high, irrespective of what you expect, or
have specified in the .conf file.

The circuit for my little interface is at:-

if anyone is interested. An 11k pdf.

In that case, all I had to do, was leeve RTS stuck High, and tell Direwolf to use
the DTR line, but activate it by sending it -ve.

PTT /dev/ttyUSBx -DTR That worked for me just fine with that interface,
configured so RTS goes to PTTkey, and DTR goes to PTTblock.

Hope something helps you with your PTT mayhem.


David:
Yes, I'm aware of the audio level indicatior, but that ONLY shows, when it's
successfully received and decoded a packet. Along with the most excelent little
tuning indicator! Problem is, here in the UK at home, there is a very high noise
level, so decodes are rare, but the overall peak/average "Level" would be about
the same. (I've 'scoped the audio from the radio, the AGC in fast mode does a
good job.)

So it would be very usefull, if a live level indicator could be provided by DW even
with no decoding, so that the radio's line out level, and PC's soundcard settings
could be setup very much easier, and a lot quicker than waiting (sometimes for
10's of minutes) for something to be successfully decoded so you can try and
guess what to do with the level settings.

Thanks for the recommendation re the "alsactl store" and "alsactl restore" idea.
I'll look into that, also invoking DW from a script. Doing all that from a script
does seem to be a good idea. I just need to learn the correct way. (I'm still a
Linux novice when it comes to many things others take for granted!)

The PTT control I can work arround for now, but it obviously needs sorting as
others seem to have found issues with it also. (Stuck in TX etc.) I must admit,
I've not tried it via a "Real Hardware" serial port, only over USB<>RS232 things
(both FTDI and Prolific.)

It is sometimes the default behaviour of the drivers, if a port is "opened" by an
app, DTR and RTS are asserted by default. But, the controling application can
easily override that behaviour, if so desired. I've done it myself in a "past life"
with other software I was supporting, on another OS, plus other Linux ham apps
(Fldigi, Flrig etc) do the correct thing.

(The same PC also has those installed, and they work realy well with the exact
same hardware etc. As does also, QSSTV!)

Not sure of Hamlib. I've messed with that in the past, but I found it very hit n
miss. Again, when it works, it works very well. (I have used Grig in the past
too.) But if there is something bad about the configuration, it's a nightmare to
untangle. It's also another layer of complexity that is not good for ones sanity
when portable/mobile! ;-)


Ian:
Same comments re the level settings. DW only provides an indication of the
input level once it's successfully received and decoded something. I (and others
I think) feel that something "live" is needed in real time, to set the levels before
leaving it alone to decode stuff.

OK on your particular use of Direwolf. Nice...
I have a working setup on a Pi that I plan to leave monitoring 30m while I'm
away, as a RX only gate to the IS. I had it running well a few weeks back, but
found I had to moderatly overclock the Pi (900MHz) and drop the sample rate to
11k, to get acceptable performance, but it was working very well, 5 decoders at
40Hz spacing. The Pi was running at about 60% usage. (Raspian with HW
floating point.) The RX was/will be a KX3.

With one of the cheap stick on heatsinks, the Pi's CPU temp is back down to less
than it was at 700MHz with no h'sink. I left it running for a few days, no
problems (then...)

Yes I know the IC-706 rigs don't support CAT command for PTT, but other radios
do, though some have other issues if you go that route...

Also, yes, udev rules are magic, once you've figured things out.

Yes too, the default text/background colours on a LCD screen are terrible. I too
use -t 0 to turn the colour off, then I can read it!


Thanks again everyone. Now to go find and read about those Alsa settings
tools. And general shell scripting too I suspect.

Still a lot to learn, and time ticks on. Two weekends to go, then it all gets used
in anger! And I realy would like to have everything at least startup in the
"right" way, especially the audio level as seen by DW from the Radio.


73.

Dave G0WBX. (Lunchtime over, back to t'mill.)

Hi All.

I have at least now nailed down the wandering transmit audio level issue, using
alsactl to restore settings in a simple script, before launching Direwolf.

Sorry, I don't have access to that computer, else I'd show the script I use. But
in essance its only two (active) lines.

Thanks for the tip.

Dave G0WBX.

开云体育

Hello Dave,

Yes, I'm aware of the audio level indicatior, but that ONLY shows, when it's
successfully received and decoded a packet. Along with the most excelent little
tuning indicator! Problem is, here in the UK at home, there is a very high noise
level, so decodes are rare, but the overall peak/average "Level" would be about
the same. (I've 'scoped the audio from the radio, the AGC in fast mode does a
good job.)

Ok, I understand your ask and I've asked for something similar in the past just to confirm that there is good audio routing through the sound system to Direwolf. So far, I haven't seen any feature to support this. With that said, I doubt showing the background noise will be all that helpful as a receiver that's saturated will do non-linear things. Anyway, I would recommend to email John, WB2OSZ directly with your feature request and see what he thinks.

Thanks for the recommendation re the "alsactl store" and "alsactl restore" idea.
I'll look into that, also invoking DW from a script. Doing all that from a script
does seem to be a good idea. I just need to learn the correct way. (I'm still a
Linux novice when it comes to many things others take for granted!)

If you're interested, I can send you some different examples of how I start up packet on my systems. One example is pretty minimal & strait forward for a Raspberry Pi. My other example is a very large startup script to support packet, HF, etc with very heavy tuning (found here: )

The PTT control I can work arround for now, but it obviously needs sorting as
others seem to have found issues with it also. (Stuck in TX etc.) I must admit,
I've not tried it via a "Real Hardware" serial port, only over USB<>RS232 things
(both FTDI and Prolific.)

USB PTT is a real... and it's now the norm.. NOT ISA/PCI/PCIe based serial ports! The Rpi and other little Linux machines are a little different as we now have GPIO pins to do stuff like this which is, in theory, more strait forward.

It is sometimes the default behaviour of the drivers, if a port is "opened" by an
app, DTR and RTS are asserted by default. But, the controling application can
easily override that behaviour, if so desired. I've done it myself in a "past life"
with other software I was supporting, on another OS, plus other Linux ham apps
(Fldigi, Flrig etc) do the correct thing.

Yes, but that still creates TX "glitches". I'm still thinking that the best approach is TWO lines. One line going high is the ENABLE line. Only when the ENABLE line goes high AND the PTT line goes high, then PTT will assert.

Not sure of Hamlib. I've messed with that in the past, but I found it very hit n
miss. Again, when it works, it works very well. (I have used Grig in the past
too.) But if there is something bad about the configuration, it's a nightmare to
untangle. It's also another layer of complexity that is not good for ones sanity
when portable/mobile! ;-)

Hamlib sure has a bad reputation but I've never had any real issues with it. I personally prefer to always use a hardware PTT line. Less latency, less complication.

I have a working setup on a Pi that I plan to leave monitoring 30m while I'm
away, as a RX only gate to the IS. I had it running well a few weeks back, but
found I had to moderatly overclock the Pi (900MHz) and drop the sample rate to
11k, to get acceptable performance, but it was working very well, 5 decoders at
40Hz spacing. The Pi was running at about 60% usage. (Raspian with HW
floating point.) The RX was/will be a KX3.

What would happen when running at 700Mhz? Were you seeing low sample rates from Direwolf's periodic STDOUT logging?

Still a lot to learn, and time ticks on. Two weekends to go, then it all gets used
in anger! And I realy would like to have everything at least startup in the
"right" way, especially the audio level as seen by DW from the Radio.

What is in two weeks?

--David