Re: Non symmetrical transmit-receive modes and speeds
Hey Bill,
I don't know how useful this would be for most users but I
would recommend to create a Github "issue" on Direwolf's Git repo to
track this request.
--David
KI6ZHD
toggle quoted message
Show quoted text
Wild idea this morning when mentioning to a friend that the IC7100
will receive 9600 with the internal modem but cannot transmit (darn
transformers?) at 9600.
Maybe it doesn't have to run 9600 on both up and download. Perhaps it
could receive at 9600, like from a tcp file server, and send the ACK's
back at whatever speed worked - maybe 2400 or 3500.
If we have flexibility to configure the soundmodem separately for
transmit and receive channels - it opens up options to tune systems to
get the best available speed.
I haven't fired up/compiled DW for a few months so I don't have an up
to date running instance to check. Maybe this is already there. If
not, maybe it'll be a low hanging tweak.
Onward!
73
Bill, W7NWP
|
DINAH () is a USB sound interface that works with Dire Wolf and the 857D.? A 6 pin miniDIN m/m cable is included with the kit.
|
Non symmetrical transmit-receive modes and speeds
Wild idea this morning when mentioning to a friend that the IC7100
will receive 9600 with the internal modem but cannot transmit (darn
transformers?) at 9600.
Maybe it doesn't have to run 9600 on both up and download. Perhaps it
could receive at 9600, like from a tcp file server, and send the ACK's
back at whatever speed worked - maybe 2400 or 3500.
If we have flexibility to configure the soundmodem separately for
transmit and receive channels - it opens up options to tune systems to
get the best available speed.
I haven't fired up/compiled DW for a few months so I don't have an up
to date running instance to check. Maybe this is already there. If
not, maybe it'll be a low hanging tweak.
Onward!
73
Bill, W7NWP
|
Re: 2400 vers A or B?-Update
Let me add the computers were both OLD XP Acer netbooks.
I think 1.6Ghz and 2Gigs of RAM. CPU was running at
25-30% just with modems. SM took more(due to waterfall I guess?)
Trip - KT4WO
|
Re: 2400 vers A or B?-Update
The interface is:
So no--No xformers. I just bought and built these interfaces and so far
seem to work well. In the past I have ALWAYS built my own- Going back
to 1999 on PSK and MFSK. But for 28 bucks thought I would try them.
UZ7HO has 3 "Direwolf modes"? DW 2400 A and B --also DW4800.
A and B both worked DW to SM, just the DW4800 fell over.
Tnx for "MODEM 3500" info but, although I love/use DW, many of the
other users like SM so I need to stay compatible with them.?
When/If I set up a link to a 2nd node or if I can get users to
"feel the need for speed"? at that point I will tap the discriminator.
Lets see--Did I miss anything you ask?
"specific about the cabling" --- Nope, just strait from interface to MIC/Speaker ports.
"Fldigi ODFM" --YES! I saw that other day, I am building as I type!? BUT due
to the RSID every TX it would seem to have slow turn-around?? maybe??
Trip - KT4WO
|
Ok, thank you David that logic clicked into place. I've been assuming the CAT port on the 857D was capable of sound as well control. On the upside, I have a cheap CM108(?) from Amazon that I'll try right now.
73,
KJ7PLR, Dan
|
Hello KJ7PLR,
I'm relatively new to direwolf, learning the ropes. So
much possibility and an amazing piece of software.?
RaspberyPi4 Type 1 USB <-> Yaesu 857D CAT mini din, using an
RTSystems USB-62C cable.
The RTS cable doesn't do sound.
I have this configuration working properly using flrig
at 4800 baud. Image attached. PTT works.
No image attached but I would expect PTT would work but that's it.
arecord -l shows no capture devices.?
aplay -l shows only the bcm2835 as card0
Correct.? You need a sound device to use.? Refer to the Direwolf
UserGuide doc but it's recommended to use a Syba USB sound device
which costs $9.?
My question is: how should direwolf/raspian be
configured to utilize the FTDI cable for everything including PTT,
as flrig ?does? I'm close. but missing something obvious.
You could use a GPIO pin off the Raspberry Pi with a simple
transistor circuit for PTT and use that cable elsewhere.? Now, if
you would like to do full rig control on your FT857 with this cable,
you can do so.? You could continue to use Flrig for rig control or
since Direwolf is a command like tool, you could use the command
line centric Hamlib program like rigctl to do basic rig control.? Up
to you.
--David
KI6ZHD
|
Re: 2400 vers A or B?-Update
Hello Trip,
Radios:? Kenwood?? TM-281 and TK-762(VHF)
Audio In and Out: MIC and Speaker connects.
TK-762 on dummy load.
TM-281 on vert. antenna 50ft away.
What sound devices did you use?? Anything specific about the cabling
between the sound device and the radio?? Any Isolation transformers
in there?? Those are VERY bad for higher bandwidth modes
In short, 2400b (DW Vers A and B) works well. This is
between DW to DW,
SM to DW and SM to SM.
The ONLY 2400b that didn't work was SM 2400 AFSK.
Just for the archives, which modem one in UZ7HO Soundmodem worked
with which Direwolf 2400 modem?
3600b --? No luck at all.
Hmmm.. I think I might have mislead you.? It's 3599 and BELOW that
should work with the mic/speaker connections.? 3600 and higher use
the 4800 modem which is already specified as needing the
discriminator aka 9600bps pin connection.? Try the setting:
? MODEM 3500
As I understand it, you should be able to specify this as lower
rates going all the way back down to 2400.? Doing it another way,
maybe consider working your way UP.? Please note that these
non-standard speeds would ONLY work Direwolf to Direwolf.
4800b -- No luck here also.
As documented, this shouldn't WORK as this modem needs the wider
bandwidth.
After finding that 2400b worked it was disappointing
that 3600b and 4800b did not.
Bummer!!
Good opportunity to hack your radios and get to those discriminator
connections:
?? search for say: "kenwood TK-762 modification for discriminator
input"
??
?? Kenwood TK-762: ?
?? Kenwood TM-281A:
??
??
Btw.. for higher speeds, there is also a new Fldigi ODFM set of
modes being developed:
??
--David
KI6ZHD
|
Good Morning.
I'm relatively new to direwolf, learning the ropes. So much possibility and an amazing piece of software.?
RaspberyPi4 Type 1 USB <-> Yaesu 857D CAT mini din, using an RTSystems USB-62C cable.
I have this configuration working properly using flrig at 4800 baud. Image attached. PTT works.?
arecord -l shows no capture devices.?
aplay -l shows only the bcm2835 as card0
When I run direwolf,?
My question is: how should direwolf/raspian be configured to utilize the FTDI cable for everything including PTT, as flrig ?does? I'm close. but missing something obvious.?
Thank you all,
KJ7PLR. AZ USA
|
Re: 2400 vers A or B?-Update
RE: Testing Direwolf(DW) and UZ7HO Soundmodem(SM) at
1200/2400/3600/4800b with common MIC feed radios.
Radios:? Kenwood?? TM-281 and TK-762(VHF)
Audio In and Out: MIC and Speaker connects.
TK-762 on dummy load.
TM-281 on vert. antenna 50ft away.
In short, 2400b (DW Vers A and B) works well. This is between DW to DW,
SM to DW and SM to SM.
The ONLY 2400b that didn't work was SM 2400 AFSK.
3600b --? No luck at all.
4800b -- No luck here also.
It seems that most any off the shelf VHF rig should
handle 2400b.
After finding that 2400b worked it was disappointing that 3600b and 4800b did not.
Bummer!!
YMMV
Trip - KT4WO
|
Re: How to block specific call?
I try contacting people when I can as well with maybe 50% luck.
?
Here is a filter I use at a specific site where I only want to digipeat if the position is within 16 km of the point, or it is Messages, Status or Telemetry, BUT nothing allowed from callsign1-1 or callsign2*
?
FILTER 0 0 (r/37.51/-121.59/16 | t/mst ) &? ( ! b/callsign1-1/callsign2* )
? [ the parenthesis might be off in this example, so user beware ]
?
You might want a filter range of 200km or more.? This keeps non-locked GPS from digipeating.
Ideally more should be allowed to digipeat, but this will show additional options.
?
Arnold, KQ6DI
On 03/08/2021 1:00 PM Patrick Connor via groups.io <n3tsz@...> wrote:
?
?
Or, you could use ! b/callsign1/callsign2/etc... to block individual stations.
If you do not like digipeating weather data, use ! s/_ to block the weather station symbol.
Section 9.6 of the User Guide describes Packet Filtering in detail.
?
Patrick (N3TSZ)
?
?
On Monday, March 8, 2021, 03:52:18 PM EST, Patrick Connor via groups.io <n3tsz@...> wrote:
?
?
That is an easy one.
After your digipeater definition add a filter like this:
?
FILTER 0 0 ! d/callsign1/callsign2/etc...
?
You can use this to block one, or more digipeaters.
I use ! d/* to block all digipeater traffic and only digipeat stations heard directly.
?
Good luck
Patrick (N3TSZ)
?
?
On Monday, March 8, 2021, 03:37:11 PM EST, Ivan Nikodijevic <yt1niv@...> wrote:
?
?
Hi all,
Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less, with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?
Thanks!
?
|
Re: How to block specific call?
Travis,
yes, tried several times with nice approach, and of course that I have my email to beacons... Still nothing. I even offered him to give him for free complete digi with Rpi3 plus direwolf, all set and tuned... :(
Thank you Patrick, now will try with filters!!!
|
Re: How to block specific call?
I tried that with a gentleman running WIDE14,14
?
He was all but receptive.
?
-Michael
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Travis Bully
Sent: Monday, March 8, 2021 3:10 PM
To: [email protected]
Subject: Re: [direwolf] How to block specific call?
?
Honest question.? Not trying to be combative as I've learned something in this thread and am thankful for it.
Have you reached out to the offending station to offer guidance/suggestions?? As someone who is fairly new to APRS, I'd welcome an Elmer setting me straight.? I've even put my email address in my beacon in case someone wants to reach me.
?
Or, you could use ! b/callsign1/callsign2/etc... to block individual stations.
If you do not like digipeating weather data, use ! s/_ to block the weather station symbol.
Section 9.6 of the User Guide describes Packet Filtering in detail.
On Monday, March 8, 2021, 03:52:18 PM EST, Patrick Connor via
<n3tsz=[email protected]> wrote:
After your digipeater definition add a filter like this:
FILTER 0 0 ! d/callsign1/callsign2/etc...
You can use this to block one, or more digipeaters.
I use ! d/* to block all digipeater traffic and only digipeat stations heard directly.
On Monday, March 8, 2021, 03:37:11 PM EST, Ivan Nikodijevic <yt1niv@...> wrote:
Hi all,
Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less,
with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done
with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?
Thanks!
|
Re: How to block specific call?
Honest question.? Not trying to be combative as I've learned something in this thread and am thankful for it.
Have you reached out to the offending station to offer guidance/suggestions?? As someone who is fairly new to APRS, I'd welcome an Elmer setting me straight.? I've even put my email address in my beacon in case someone wants to reach me.
73!
Or, you could use ! b/callsign1/callsign2/etc... to block individual stations. If you do not like digipeating weather data, use ! s/_ to block the weather station symbol. Section 9.6 of the User Guide describes Packet Filtering in detail.
Patrick (N3TSZ)
On Monday, March 8, 2021, 03:52:18 PM EST, Patrick Connor via <n3tsz= [email protected]> wrote:
That is an easy one. After your digipeater definition add a filter like this:
FILTER 0 0 ! d/callsign1/callsign2/etc...
You can use this to block one, or more digipeaters. I use ! d/* to block all digipeater traffic and only digipeat stations heard directly.
Good luck Patrick (N3TSZ)
On Monday, March 8, 2021, 03:37:11 PM EST, Ivan Nikodijevic < yt1niv@...> wrote:
Hi all,
Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less, with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?
Thanks!
|
Re: How to block specific call?
Or, you could use ! b/callsign1/callsign2/etc... to block individual stations. If you do not like digipeating weather data, use ! s/_ to block the weather station symbol. Section 9.6 of the User Guide describes Packet Filtering in detail.
Patrick (N3TSZ)
On Monday, March 8, 2021, 03:52:18 PM EST, Patrick Connor via groups.io <n3tsz@...> wrote:
That is an easy one. After your digipeater definition add a filter like this:
FILTER 0 0 ! d/callsign1/callsign2/etc...
You can use this to block one, or more digipeaters. I use ! d/* to block all digipeater traffic and only digipeat stations heard directly.
Good luck Patrick (N3TSZ)
On Monday, March 8, 2021, 03:37:11 PM EST, Ivan Nikodijevic <yt1niv@...> wrote:
Hi all,
Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less, with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?
Thanks!
|
Re: How to block specific call?
That is an easy one. After your digipeater definition add a filter like this:
FILTER 0 0 ! d/callsign1/callsign2/etc...
You can use this to block one, or more digipeaters. I use ! d/* to block all digipeater traffic and only digipeat stations heard directly.
Good luck Patrick (N3TSZ)
On Monday, March 8, 2021, 03:37:11 PM EST, Ivan Nikodijevic <yt1niv@...> wrote:
Hi all,
Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less, with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?
Thanks!
|
How to block specific call?
Hi all,
Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less, with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?
Thanks!
|
Re: Linux AX.25 stack now toxic for connected packet connections with Ubuntu 20.04 / 5.8.0-44-generic #50
The issue here is *connected* AX.25 session so your Winlink
connections would be impacted. APRS would not be impacted since it's
unconnected traffic and still works fine. Yes, I know that but your subject line implies that you already know the problem is in the AX.25 stack and that might/probably not be the case. I am using native Linux AX.25 stack with Dire Wolf DEVELOPMENT version 1.7 A (Feb 15 2021) on 4 different systems and it is working fine. The way the Canonical backports fixes into older kernels is
difficult to track and they aren't dating things in the
changelog but I see this The following is the commit summary from kernel.org for kernel 5.11.4 and ax.25 commits. I looked at each of these commits & none of them should cause your symptom. 2020-11-20 rose: Fix Null pointer dereference in rose_send_frame() Anmol Karn 1 2020-07-23 AX.25: Prevent integer overflows in connect and sendmsg Dan Carpenter 1 2020-07-22 AX.25: Prevent out-of-bounds read in ax25_sendmsg() Peilin Ye 1 2020-07-22 AX.25: Fix out-of-bounds read in ax25_connect() Peilin Ye 1 2020-07-04 Documentation: networking: ax25: drop doubled word Randy Dunlap 1 2020-05-20 ax25: fix setsockopt(SO_BINDTODEVICE) Eric Dumazet 1 2020-04-28 Docs: networking: convert ax25.txt to ReST Mauro Carvalho Chehab 3 2019-09-24 ax25: enforce CAP_NET_RAW for raw sockets Ori Nimron 1 I suggest swapping some big components in your system including NOT using the internal D-710 TNC. Once you do that you can test against the Direwolf user land ax.25 stack & the Linux kernel mode ax.25 stack. Just did a successful connection test between two ARM machines using these kernels 5.10.17-v7l+ and 5.4.79-v7l+. Also there was a massive Linux kernel code merge from the middle of December 2020 to the first week of Jan 2021 that took the kernel from version 5.4.83 to 5.10.11 that caused a few problems. Not sure what that means for Ubuntu. (posted 2021-02-04)
--
* Focal update: v5.4.55 upstream stable release (LP: #1890343)
- AX.25: Fix out-of-bounds read in ax25_connect()
- AX.25: Prevent out-of-bounds read in ax25_sendmsg()
...
- AX.25: Prevent integer overflows in connect and sendmsg
--
* Focal update: v5.4.44 upstream stable release (LP: #1881927)
- ax25: fix setsockopt(SO_BINDTODEVICE)
-- What TNC device are you using? /Basil N7NIX
On this system, it's a D710 in KISS mode connected to a Lenovo T470
(i7-7600U with 16GB RAM) running 64bit Ubuntu 20.04. I'm 99.9% sure
that if I switched away from a serial attached hardware TNC to a
software-based TNC like Direwolf, I would still see the issue. I've
done more testing with reverting the kernel to older versions but the
ones I've tested so far still fail as well:
5.8.0-44 : BAD
5.8.0-43 : BAD
5.8.0-41 : BAD
..
5.8.0-36 : BAD
..
5.4.0-66 : BAD
..
5.4.0-42 : BAD It's clear that my mistake is that after Canonical pushes a
new kernel version and I apply it, I should reboot then test
things to KNOW if the AX25 stack has been impacted. I skipped
a few reboot cycles as different kernels were installed so I
really don't know where to start. Even then, I'm thinking this
issue might be more of a libc interface issue or something
else since going way back to 5.4.0-42 dated 2020-07-10 is
seeing the same issue. root@hampacket3:/var/log/apt# dpkg -l | grep -e libc6 -e linux-libc
ii libc6:amd64 2.31-0ubuntu9.2 amd64 GNU C Library: Shared libraries
ii libc6-dbg:amd64 2.31-0ubuntu9.2 amd64 GNU C Library: detached
debugging symbols ii libc6-dev:amd64 2.31-0ubuntu9.2 amd64 GNU C
Library: Development Libraries and Header Files ii
linux-libc-dev:amd64 5.4.0-66.74 amd64 Linux Kernel Headers for
development
That libc6 was installed on "2021-01-28"
It's frustrating as I have no clue where to start as the machine just locks up and doesn't give any hint of where to start troubleshooting. Could be an 64bit thing. Could be an SMP thing. Dunno,
--David KI6ZHD
|
Tnx for the reply's.? I will do some testing and post results.
Trip - KT4WO
|
Hello Trip,
Per the 2400-4800-PSK-for-APRS-Packet-Radio.pdf document, the "B"
modem is the one you should use.? Neither version of this modem is
superior as it's just a difference in starting "phase".? Read the
PDF for details. ? Btw, you can run this "2400" modem all they way
up to 3600bps using a standard MIC connector and it should work.?
Warning: I did test this but not using real radios.. I was just
testing two sound cards connected back to back.
As for the 4800 modem, you WILL need a connection to the radio's
discriminator (aka the 9600 pin) for this wider mode.
--David
KI6ZHD
On 03/07/2021 08:48 AM, kt67 wrote:
toggle quoted message
Show quoted text
I would like to add a 2nd port (on 440Mhz) at a local
mtn. top node--
As I have users that use UZ7HO I would like to be compatible for
them.
I see there are (2) 2400 modes--A and B in UZ7HO. From the
Direwolf
side of things, which would be better?(line of sight links)
Has anyone tested in real world links?
And what about the 3600 bit modem?
Thoughts?
Oh --also-- the radios I am using DO NOT have the 9600 HS ports
so any mode would need to go thru the MIC connector.
(old public safety radios)
Tnx de Trip - KT4WO
|
Steve-N8AR
Michael Champion
Patrick Connor
Basil Gunn