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
