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
|
V1.8 (dev) - Packets being digipeated to NCHANNEL
I am trying to get IS-traffic to be sent via a networked-kiss interface.
?
packets retrieved from IS being digipeated to the network-kiss interface (in my case channel 6) produce the following output:
[ig>tx] OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
[6.is] X>X:}OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
?
expected behaviour:
[ig>tx] OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
[6.is] OE6PLD-2>APDW18:}OE6MMF-1>APLG01,TCPIP*,qAC,T2CSNGRAD:=4711.45NL01545.85E&LoRa iGATE
?
can anybody confirm this behaviour or has NCHANNEL running correctly?
?
regadrs
peter, OE6PLD
?
?
|
I'm running direwolf this way on Debian:
net105.conf:
==============
ACHANNELS 1
CHANNEL 0
MODEM 300 1600:1800 7@30 /4 D
command line:
==============
direwolf -c ./net105.conf -t 0 -n 1 -b 16 -B 300:1600:1800 -r 48000 -X /4 udp:7355
Are these options optimal for HF 300 baud? 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 am decoding a lot of packets on 14.105 MHz LSB but want to make sure the options are optimized.
?
thanks,
Larry
?
?
|
Re: Good volume level to start with?
Thomas: The 5W limit is per my club's president who's also the main repeater person, and is because we already have two 2m repeaters and two 70cm repeaters at the site plus another club's 2m repeater is nearby. We've already had interference issues happening and I think he wants to avoid that again after adding the digipeater. I'll tell him what you said though, and see what he says.
?
David: I suppose I could get a Yaesu FT-2980R. Digirig also makes a cable that will work on it. (I like their cables as they're well-made, shielded and already have ferrites, vs. some sort of homebrew cable solution.) A commercial radio like a Motorola would need the homebrew cable provided a Moto data connector could even be found in the Philippines. We do have connections in the US and Canada who may be able to help though. I mean, on the one hand I highly doubt that the APRS traffic levels would ever put a strain on the FT-60, but on the other hand there's what Thomas said about the hidden node problem.
?
It's all food for thought. Thank you both for the information. 73.
|
Re: Good volume level to start with?
Hello DW7GDL,
I have a digipeater and igate at home, using a Retevis RT-95
(same radio as the Anytone AT-778UV) with its mic jack and
external speaker jack connected to a Digirig Mobile which is
connected to a Raspberry Pi 3B+ running Direwolf 1.7. I want to
set up a, widerange digipeater-only at my club's repeater site
only this time using a Yaesu FT-60R HT with its speaker mic jack
connected to the Digirig. 5 watts would be all that's needed as
that's all that the repeaters transmit at.
In addition to Thomas's points, you should be aware that running a
high level APRS digi with an HT might be bad news depending on the
traffic levels.? HT's aren't designed for heavy amounts of TX cycles
and your radio might overheat or fail per-maturely.? You also seem
like you want to decode weak APRS signals and while a Yaesu FT60 is
a quality HT, it's receiver is probably not as good as many common
amateur radio mobile radios.? If you can swing it, I think you'll be
better served on all fronts with using a mobile radio.? Could be a
good opportunity to get a used ex-commercial radio for this fixed
function role.
--David
KI6ZHD
|
Re: Good volume level to start with?
Hi,
It is good that you realize that the audio volume settings (especially the transmit audio volume) are important for successful packet operation.
However you are mistaken when you assume that strong or weak FM signals change the receive audio volume, they don't. The audio volume changes the FM deviation (amount of change in frequence compared to the unmodulated carrier frequency) which
is fully independent of the strength of the RF signal. That is the good news.
Also good is that both hardware TNCs and software.TNCs like Direwolf are generally pretty good in dealing with a wide range of receive audio volumes. Just monitoring the Direwolf console for the incoming audio levels is generally sufficient
to tell whether or not an adjustment is warranted.
The transmit audio volume is much more important and you really do want to make an effort to get that close to optimal. If you don't have access to test equipment follow the rule of very slowly increasing transmit audio level to the point where
the volume no longer increases (at a receive radio) and then reduce it again by a small amount. An audio decibel app on your phone can help with that task.
You are mentioning radio transmit power as well. For packet communication you often need more transmit power than a comparable voice radio station because you want avoid the hidden-node problem (which requires that everybody can hear your transmissions).
73,
Thomas
KK6FPP
|
Good volume level to start with?
I have a digipeater and igate at home, using a Retevis RT-95 (same radio as the Anytone AT-778UV) with its mic jack and external speaker jack connected to a Digirig Mobile which is connected to a Raspberry Pi 3B+ running Direwolf 1.7. I want to set up a, widerange digipeater-only at my club's repeater site only this time using a Yaesu FT-60R HT with its speaker mic jack connected to the Digirig. 5 watts would be all that's needed as that's all that the repeaters transmit at.
?
There are extremely few APRS users here, just one or two (we're trying to get more people interested) so I currently have no way to tell what the "average" level is. Since receive is via the speaker jacks on both radios, what's a good initial volume setting to use to be able to receive weaker signals without causing clipping or distortion later if we get more APRS users?
|
Re: heard position appears changed by object position
Hmm, already running 1.7 release on my tx-igate.
|
Re: heard position appears changed by object position
A 1.7 development version is in use.? I'll test on 1.7 Release to see if there's any change.
|
Re: heard position appears changed by object position
The location of objects created by a station is presumably erroneously used to update the location in the heard table for the station, as seen when using the debug option -d m
This causes an incorrect distance calculation when determing whether packets received from the server for the station should be sent to RF.
?
Heard table entry preceding a packet for an object being heard:
VK2RBE-1 ? ?4 ? 0 ? 0 ? ? 0:02 ? ? - ? ?-35.05 ?147.56 ?0
?
then a packet for one of the objects is heard:
VK2RBE-1 audio level = 56(10/11) ? ?||||_____
[0.1 15:00:35] VK2RBE-1>APDW17,RFONLY:;438.025 ?*111111z3507.95S/14722.33ErT091 -500 Wagga linked rptr
mheard_save_rf: VK2RBE-1 0 - update time, was 0 hops 180 seconds ago.
callsign ?cnt chan hops ? ?RF ? ? ?IS ? ?lat ? ? long ?msp
VK2RBE-1 ? ?5 ? 0 ? 0 ? ? 0:00 ? ? - ? ?-35.13 ?147.37 ?0
?
Graeme VK2HFG
|
Hello Cassie,
Alright everyone. The initial setup is done I think. Both rig
setups are able to receive packets off 144.39 and are able to do
a transmit test with -x a.
?
Hooray!
Awesome.? Good work.
?
Now that both rigs are set up, I want to test transmission of
packets to eachother- basically I want to send a packet with rig
a, and have direwolf on rig b receive it. I saw in your set up
guide that you recommended the following beacon:
PBEACON delay=00:15 every=1 SYMBOL=/- lat=37^20.00N lon=121^00.00W power=4 height=20 gain=6 comment="was KI6ZHD Change me, CA" via=WIDE1-1
My plan is to add this to the config file for rig a (with an
obvious change in my location and call sign) and then I expect
rig a would be able to receive it? Would that be the best way to
go about doing this?
Sure.. that will work though I would now recommend you learn a bit
about how APRS works, how the different "WIDE" constructs work
(WIDE1-1, vs WIDE2-1), etc. as they are important.? Beyond that,
DIrewolf is really intended to be an APRS "server" but not really a
client.? When I say "client", I mean say show a map with all the
learned stations and their locations, send messages, interact with
services like APRS/email gateways, APRS/Winlink gateways, etc.?
There are several APRS clients out there that are multi-platform and
they don't have to run on the same machine as Direwolf.? I have a
short list of some of the possibilities here:
??
Beyond using AX.25 packet radio with APRS, there are also classic
AX.25 packet terminal clients too:
??
--David
KI6ZHD
|
Alright everyone. The initial setup is done I think. Both rig setups are able to receive packets off 144.39 and are able to do a transmit test with -x a.
?
Hooray!
Huge thank you for the support from David and Bob and everyone else who helped out and sent me messages. I honestly would have probably lost my mind if I had been doing this all solo.
Now the next question, which I wonder if I should start a new topic for? If so, let me know:
?
Now that both rigs are set up, I want to test transmission of packets to eachother- basically I want to send a packet with rig a, and have direwolf on rig b receive it. I saw in your set up guide that you recommended the following beacon:
PBEACON delay=00:15 every=1 SYMBOL=/- lat=37^20.00N lon=121^00.00W power=4 height=20 gain=6 comment="was KI6ZHD Change me, CA" via=WIDE1-1
My plan is to add this to the config file for rig a (with an obvious change in my location and call sign) and then I expect rig a would be able to receive it? Would that be the best way to go about doing this?
?
Again, you all are the best.
I hope you all have a great day!
Cassie
?
?
|
Hi Cass
You will strike different opinions on what sound system to use,
basic ALSA, pulseaudio and pipewire seem to be the main
contenders. If the PC's are dedicated to just running direwolf or
rather you will never ever want to concurrently access the audio
hardware from multiple applications, then ALSA will probably be
the best choice. If you wish to test it without removing
pulseaudio permanently then do the following;
add the audio group to the user that runs direwolf, log out/in
pulseaudio --kill
Re-enable the ADEVICE line and start direwolf
Use alsamixer to set input and output volumes. The default (from
memory) is to retain those settings from the last reboot.
When you next reboot or log out/in. pulseaudio will of course
start again. Given you aren't likely to need audio for anything
else for a while, leaving the audio group as is, is probably safe.
I remember that for some distros removing pulseaudio also removes
the basic ALSA stuff (leaving no sound support), so maybe look for
a removal method that applies to yours. There may be a dpkg
reconfigure option to check, oh and worth making sure the system
is patched to latest as well.
pavucontrol wont show the direwolf application until it actually
starts, but the initial opening order is not important. Only
rigctld before direwolf is.
You will always get the VOX/PTT warning from the sub RX channel.
It can be ignored.
Bob
On 28/8/24 23:34, cdres wrote:
toggle quoted message
Show quoted text
David-
?
I can honestly say I have no idea where the binary came from.
But, I agree that I should be able to recompile it which I will
start doing this week. I have a feeling a lot of things will be
working smoother once I get that fixed.
Bob-
?
You were totally right. Running
ps ax| grep pulse
showed a pulseaudio process... so I uncommented the ADEVICE,
saved, reopened the rigctld, then opened pavucontrol and then
direwolf. Not sure if that's the recommended order but it seemed
to work, at least it got rid of that error:
?
I'm hoping the rest of the issues are fixed once I recompile
direwolf.
?
Jay-
?
Thank you for your encouragement. This is not what I expected
to be doing this year, but I am excited to be working on the
project. I have a feeling I will be back on here pretty
regularly with updates and/or new issues that I find. haha.
?
I'll work on direwolf and report back.
?
-Cass
_._,_._,_
|
David-
?
I can honestly say I have no idea where the binary came from. But, I agree that I should be able to recompile it which I will start doing this week. I have a feeling a lot of things will be working smoother once I get that fixed.
Bob-
?
You were totally right. Running
ps ax| grep pulse
showed a pulseaudio process... so I uncommented the ADEVICE, saved, reopened the rigctld, then opened pavucontrol and then direwolf. Not sure if that's the recommended order but it seemed to work, at least it got rid of that error:
?
I'm hoping the rest of the issues are fixed once I recompile direwolf.
?
Jay-
?
Thank you for your encouragement. This is not what I expected to be doing this year, but I am excited to be working on the project. I have a feeling I will be back on here pretty regularly with updates and/or new issues that I find. haha.
?
I'll work on direwolf and report back.
?
-Cass
|
I haven't chipped in as I don't have anything to contribute, having only used Direwolf along with a Digirig Mobile sound card to make a run-of-the-mill APRS digipeater and igate, but I before this thread has run its course (which it sounds like it will do soon, after you download the Digirig tarball and build it with support for hamlib enabled: I can at least help with that if needed) I just wanted to say how fascinating it's been, seeing a STEM student creating a ground control station for a cubesat (Cass, you should name the bird Major Tom, heeheehee.) This has been the most interesting topic in any of the groups.io support forums I subscribe to and I wish you success.
?
Cheers and 73, DV7GDL
|
Excellent Cassie!
Might be good to check that your distro isn't running pulseaudio.
The "could not open plughw" kind of screams that. Try
ps ax| grep pulse
And if it comes back with the any pulseaudio process the initial
direwolf workaround is to comment out the ADEVICE line and use
pavucontrol (PulseAudio Volume Control) to set the right port and
volumes. Eventually you may want to configure the PC sound system
as something else though.
I second David's comments re building direwolf from source. In
fact hamlib has also had a raft of fixes so a source build of that
might be good too
Cheers Bob
On 27/8/24 09:39, cdres wrote:
toggle quoted message
Show quoted text
The partial reset worked! I can't even begin to express how
awesome it is to see something other than an error come out of
this thing.
?
Now onto the next event of direwolf.
?
So, In trying to keep up with the recommendations that have
trickled in below, here is where I am at in the config file:
?
ADEVICE plughw:2,0
ACHANNELS 2
CHANNEL 0
MYCALL ()
MODEM 1200
PTT RIG 2 localhost:4532
ACHANNEL 2
CHANNEL 1
MYCALL ()
MODEM 1200
AGWPORT 0
KISSPORT 0
IGTXLIMIT 6 10
TXDELAY 20
TXTAIL 10
?
So I ran:
?
rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -c 0x7c?
?
and then opened a new terminal, ran:
?
direwolf
?
and got this sadness:
?
?
But, I feel the progress!
-Cass
?
?
|
Hello Cres,
The partial reset worked! I can't even begin to express how
awesome it is to see something other than an error come out of
this thing.
Great to hear you're making progress!
?
and got this sadness:
?
?
The error is just like it reads.. your version of Direwolf wasn't
build with hamlib support.? Where did you get this binary???
Recompiling isn't too hard and it's covered in the Direwolf User
Guide (as well as my doc too).? On the upside, Direwolf 1.8A is
already old so once you re-compile using the DEV branch (not the
master branch), you'll be also getting a bunch of Direwolf bug fixes
and improvements too!
--David
KI6ZHD
|
The partial reset worked! I can't even begin to express how awesome it is to see something other than an error come out of this thing.
?
Now onto the next event of direwolf.
?
So, In trying to keep up with the recommendations that have trickled in below, here is where I am at in the config file:
?
ADEVICE plughw:2,0
ACHANNELS 2
CHANNEL 0
MYCALL ()
MODEM 1200
PTT RIG 2 localhost:4532
ACHANNEL 2
CHANNEL 1
MYCALL ()
MODEM 1200
AGWPORT 0
KISSPORT 0
IGTXLIMIT 6 10
TXDELAY 20
TXTAIL 10
?
So I ran:
?
rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -c 0x7c?
?
and then opened a new terminal, ran:
?
direwolf
?
and got this sadness:
?
?
But, I feel the progress!
-Cass
?
?
|
I should ask, does dmesg display the USB ports and Burr Brown
sound card when the rig is hot plugged? if so that kind of (now)
suggests there is a rig setting awry. It might also be worth
confirming the rig firmware is up to date. (ie download from Icom,
but I think needs Windows to load it.)
If you don't have the manual re a rig reset get back to me.
Bob
On 27/8/24 08:18, cdres wrote:
toggle quoted message
Show quoted text
Hello again,
?
So following:
?
"rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -c 0x7c
in one shell window, and
rigctl -m 2"
?
and then trying a f command, yields the same sad
communication timed out message.
I first tried the above commands with sudo, which yielded
the same results as non sudo.
?
Then I tried the:
"rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -t 4534 -c
0x7c
rigctl -m 2 -r localhost:4534"
?
which also had the same results
?
I then did the:
?
"sudo netstat -tulpn | grep 4532"
and
"sudo netstat -n |grep 4532"
both of the above commands I did in a separate window while
the rigctld and rigctl were still running- but then I also
redid them after shutting all of the windows down with ctrl C
and then opening a fresh terminal.
?
both commands didn't seem to do anything- they executed
with no error, but no output. they just went to a new line for
a new prompt.
?
" ps -axww | grep USB and ?ps -axww | grep serial"
both showed no processes, other than the grep search
itself.
?
I did do a wiggle test on the cable that we have, and
didn't notice anything weird, but we have a million of these
cables in the lab so I switched it out for a different one
with no difference in dmesg or in the rig command response.
?
So. I think I'm at the point where I need to do a rig
reset, we don't have anything saved on there that can't be
plugged back in. I am making a list before I reset it though
to make sure I get all of the settings on there that I need to
in order to run rigctld as well as direwolf...
?
What I have is:
FM/D
55. off
56. 50%
59. USB
60. 19200
61. 7ch
62. off
63. --/GPS
64. --/GPS
?
I am really starting to understand why the previous coms
team thought the rigblaster was a magic wand. I am happy that
you all are here though, I feel like doing this the right way
will limit our headaches in the future.
?
-Cass
?
|
Sorry, I did also check
rigctl -l | grep 9100
and it is still the 3068
?
-Cass
|
JayMot DW7GDL