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
|
And what about the 3600 bit modem? 3600 may be a good option sometimes when the radio won't work at 4800.? Research needs to be done.
|
Re: Linux AX.25 stack now toxic for connected packet connections with Ubuntu 20.04 / 5.8.0-44-generic #50
Hello Basil,
I am NOT seeing your described symptom on various (7) Raspberry
Pis running the Linux AX.25 stack with Winlink, APRS &
Chattervox at 1200 & 9600 baud.
My hardware is mainly RPi 4's and sound cards using direwolf.
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.
The two kernels I am using from the Raspberry Pi
Foundation (raspbian):
Linux test119022321 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT
2020 armv7l GNU/Linux
Linux pi400 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021
armv7l GNU/Linux
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
????
(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
|
On Sun, Mar 7, 2021 at 08:48 AM, kt67 wrote:
And what about the 3600 bit modem?
That should have been 4800 bit modem.
|
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
|
Re: Linux AX.25 stack now toxic for connected packet connections with Ubuntu 20.04 / 5.8.0-44-generic #50
I am NOT seeing your described symptom on various (7) Raspberry Pis
running the Linux AX.25 stack with Winlink, APRS & Chattervox at 1200 & 9600 baud.
My hardware is mainly RPi 4's and sound cards using direwolf.
I do NOT use Linpac or Gnome3
The two kernels I am using from the Raspberry Pi Foundation (raspbian):
Linux test119022321 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
Linux pi400 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux
What TNC device are you using?
/Basil N7NIX
|
Michael Champion
Patrick Connor
Basil Gunn