¿ªÔÆÌåÓý

  1. Direwolf
  2. Messages
Expanded Topics Messages Polls
Date
Re: Using "TRANSMIT INHIBIT INPUT"

 

Hi all,

I'm about to implement and test with the TRANSMIT INHIBIT INPUT too for some special purpose. For success it's imported it queues the frames and TX-es them when the TXINH input is released. Therefore I'm curious about its behaviour too.

Currently my thoughts are to use the TXINH input for a PTT interlock and DCD 'sharing' function as they're both not possible (yet) in software I think, or I missed something in the documentation...

To prohibit the 2nd radio from TX-ing when the 1st radio is TX-ing OR receiving frames (or vice versa), I already made some circuitry which can toggle each channel's TXINH input.

73! Dave
Re: Direwatch tft display driver for direwolf

 

¿ªÔÆÌåÓý


That looks very nice Craig and some of your other projects on Github look pretty interesting as well!? Thanks for posting those.

--David
KI6ZHD


On 07/10/2021 06:23 AM, Craig, KM6LYW wrote:

if anyone is interested,






Re: KISSPORT #### does not override 8001

 

I have used Direwolf on Pis and never seen this message with GPIO, or VOX.

Since this was a slightly different installation of my client, I looked through my APRS client to see if there were any settings (TXTAIL) that it changes to cause this.? The client does not change any settings.

I glanced through the file around line 910 and worked in both directions.
?? Line 756 turns PTT ON
?? Line 860 seems to do TXTAIL timing, but I still don't see what it is "looking at" to determine PTT is still active - in this case there is nothing it CAN check.
?? And line 931 disable PTT

The computer is a quad core AMD (4 thread) running 3.5 GHz.? Direwolf (2 audio channels) and APRSIS32 running under WINE was pretty much the only thing running.? That's much more than any Pi - even with the extra overhead of a desktop.
Re: Audio Level Reporting (Inaccurate)

 

Audacity and or AlsaMixer are relative readings, similar to an uncalibrated S-meter.
You can read the manuals and know what the radio is outputting - especially when using the radio's data jack.? They are typically about 300mVp-p for 1200 baud pin and 500mVp-p on the 9600 baud pin.? That is out of the Yaesu manual and I find others very similar.

What you don't know is how "hot" the input circuit is on the sound card.?
If using a mic input, many have pre-amps (typically called boost) that can heavily influence the readings.
I have found some with adjustable boost, while others are set.? I think this is a way to use the same port as 'line in' or 'mic'.

As David stated, adjust to a reading of 50 is the best way to get the most out of Direwolf, as that is using its internal 'strategy' to determine what it "likes".

Robert Giuliano
KB8RCO



On Saturday, July 10, 2021, 1:34:14 AM EDT, David Ranch <direwolf-groupsio@...> wrote:



Direwolf is really very forgiving on RX levels but the general guidance is that it's average receive level is around 50.? I can't comment on how the alsamixer setting might look within in a zoomed in Audacity but if Direwolf is happy, that's all that matters for proper decodes.? When in doubt, make your levels LOWER than 50 to avoid clipping, etc.

--David
KI6ZHD



On 06/30/2021 06:53 PM, Michael - NA7Q wrote:

I always setup my installs using Audacity to fine tune the receiver audio. I usually adjust it with an open squelch then put it around the 0.60-0.75 mark on the Audacity level. 1.0 is maximum and of couse I never get anywhere near that. I do this to check for any audio issues, like potentional noise, or just too much audio on the line.

Getting to my point. I have done this on a Pi Zero W running Jessie and the latest compiled Direwolf beta build. I'm using a custom built HAT sound card, similar to the Fe-Pi.?
I get audio reports that range from 100 to 150. With parenthesis markings ranging from 20 to 40. So a station might be a 128 (35/20). Performance seems to be fine.

So I'm wondering if this audio level is being all out of whack because of an older version of Jessie that I used, which typically I use an older version, or Stretch. But it's what I had on hand. Any ideas??

Direwatch tft display driver for direwolf

 

if anyone is interested,

https://www.youtube.com/watch?v=NJ_IJNU7NA0&t=7s

https://github.com/craigerl/direwatch

http___craiger.org_patreon_symbols.jpg

Re: USB audio problems; need recovery help

 

¿ªÔÆÌåÓý


This is why I ONLY use HAT sound cards, like Fe-Pi, and now my soon to be released sound card HAT that's similar to the Fe-Pi. HATs have never given me issue. So that's what I suggest anyone do is use HATs where possible. Fe-Pi sound cards are no longer made, so that's unfortunate.?

You can buy the Fe-Pi designed HAT from the new design owners below:

??

--David
KI6ZHD
Re: Audio Level Reporting (Inaccurate)

 

¿ªÔÆÌåÓý


Direwolf is really very forgiving on RX levels but the general guidance is that it's average receive level is around 50.? I can't comment on how the alsamixer setting might look within in a zoomed in Audacity but if Direwolf is happy, that's all that matters for proper decodes.? When in doubt, make your levels LOWER than 50 to avoid clipping, etc.

--David
KI6ZHD



On 06/30/2021 06:53 PM, Michael - NA7Q wrote:

I always setup my installs using Audacity to fine tune the receiver audio. I usually adjust it with an open squelch then put it around the 0.60-0.75 mark on the Audacity level. 1.0 is maximum and of couse I never get anywhere near that. I do this to check for any audio issues, like potentional noise, or just too much audio on the line.

Getting to my point. I have done this on a Pi Zero W running Jessie and the latest compiled Direwolf beta build. I'm using a custom built HAT sound card, similar to the Fe-Pi.?
I get audio reports that range from 100 to 150. With parenthesis markings ranging from 20 to 40. So a station might be a 128 (35/20). Performance seems to be fine.

So I'm wondering if this audio level is being all out of whack because of an older version of Jessie that I used, which typically I use an older version, or Stretch. But it's what I had on hand. Any ideas??

Re: KISSPORT #### does not override 8001

 

¿ªÔÆÌåÓý


The error came on a older x86_64 KUbuntu desktp homebrew computer, with the motherboard sound card, and no PTT setting (VOX).? Direwolf has "no clue' how the PTT is being handled.

Ok.. that takes the iffy Raspberry Pi USB stack out of the running.



In fact, the testing was originally started with no radio connected at all.? How can the PTT be on for too long when thd non-connected radio has no connection to Direwolf to be measured (timed)?

When no PTT is configured, it's assume you're using VOX or using a sound device like a Signalink that asserts PTT for you.? Per the previous thread found via Google, if you look at like 910 at:

??

You can see where this message is coming from but it's not totally clear why you're seeing this.? I would argue that ANY 64bit x86 machine should be more than fast enough but maybe it's under a lot of other load or something?? I've personally never seen this error.

--David
KI6ZHD
Re: KISSPORT #### does not override 8001

 

The error came on a older x86_64 KUbuntu desktp homebrew computer, with the motherboard sound card, and no PTT setting (VOX).? Direwolf has "no clue' how the PTT is being handled.

In fact, the testing was originally started with no radio connected at all.? How can the PTT be on for too long when thd non-connected radio has no connection to Direwolf to be measured (timed)?


On Fri, Jul 9, 2021 at 18:40, David Ranch
<direwolf-groupsio@...> wrote:

Hello Rob,

If you google the following term:

?? direwolf "Transmit timing error: PTT is on" "mSec too long"

You'll see a few hits and one one of these talks about the issue being known on non-Raspberry Pi 4 and newer hardware with it's older USB stack.? What hardware are you using with your setup?? If you are using older Raspberry Pi hardware, there is a workaround you can try:

??

--David
KI6ZHD




On 07/09/2021 07:19 AM, Rob Giuliano via groups.io wrote:
I used the config file you proposed and it appears to be behaving now.

I am getting an error 1.7-dev-A that is
????? Transmit timing error: PTT is on 104 mSec too long.?
I am using VOX (no PTT settings), so not sure where this is coming from.
The times vary from about 100 mSec too long to maybe 250 mSec too long

This seems to be shorter ('too long time') and less often with the updated config.c file.
With the original config.c, they were as long as 500 mSec.
They only seem happen on TX from an attached client (either [0L] or [1L], but not both), or for PBEACON on the [1L] stream

Robert Giuliano
KB8RCO



On Thursday, July 8, 2021, 3:36:49 PM EDT, Brent WG0A <bjpetit@...> wrote:


I bumped into this when trying to run two separate instances of direwolf. One for VHF and one for HF. In that case I would see a collision on port 8001. After digging around a bit I found that the way to turn off the 8001 default is to set KISSPORT 0 before any other KISSPORT settings in the config.?

I also proposed a code change to the KISSPORT default behavior here.
Re: option digipeater no work in mi direwolf

 

¿ªÔÆÌåÓý


Hello Alejandro,

I would recommend to start with confirming that your HT can hear your Direwolf station (XE1GNU-1) beacons.? Per your configuration, those beacons should be sent every 5 minutes.? Is Direwolf keying up your radio?? Do you hear the modem burst on your HT?? If not, check your sound card mixer settings and make sure the levels are correctly set.?? Once you get past that, then we can help with any digipeating issue with Direwolf.

--David
KI6ZHD


On 06/30/2021 11:13 PM, Alejandro G S¨¢nchez Mart¨ªnez wrote:

Hello, I compiled on a raspberry pi zero W direwolf 1.6 as indicated in the manual, my intention is to configure an aprs repeter (digipeater).

The problem is that when I turn on a handheld radio with aprs and it sends its beacom, direwolf if it hears it but does not broadcast the information, when I see the linux shell it says that it does but in reality it does not send it to the radio, it even see on the radio that it is connected to the raspberry that changes the display light because the ptt is activated, but it is as if it does not send the audio, only repeater, because when it sends the audio of the direwolf beacom it does it well.
If I activate the igate direwolf option, it registers the data from the handheld radio on the internet without problem and I see it in aprs.fi.

This in my understanding is that if it is receiving the packets from the handheld radio well.
xe1gnu-1 is direwolf and xe1gnu-7 is other radio

 I compiled it wrong ?.
 Do I get a package on the raspberry?
 Any configuration problems?
 I have 7 days on that and I have no idea where you could see the problem.

 Thank you and 73 from xe1gnu is an important project for my SOTA activity.

this is my configuration.

ADEVICE? plughw:2,0
CHANNEL 0
MYCALL XE1GNU-1
MODEM 1200
PTT GPIO 25
AGWPORT 8000
KISSPORT 8001
PBEACON delay=1 ?every=5 overlay=S symbol="digi" lat=19^28.025N long=099^6.383438W power=25 height=20 gain=4 comment="Iniciando" via=WIDE1-1,WIDE2-1
DIGIPEAT 0 0 ^WIDE[3-7]-[1-7]$|^TEST$ ^WIDE[12]-[12]$ TRACE


TTPOINT ?B01 ?37^55.37N ?81^7.86W
TTPOINT ?B7495088 ?42.605237 ?-71.34456
TTPOINT ?B934 ?42.605237 ?-71.34456
TTPOINT B901 ?42.661279 ?-71.364452
TTPOINT B902 ?42.660411 ?-71.364419
TTPOINT B903 ?42.659046 ?-71.364452
TTPOINT B904 ?42.657578 ?-71.364602
TTVECTOR ?B5bbbddd ?37^55.37N ?81^7.86W ?0.01 ?mi
TTGRID ??Byyyxxx ???37^50.00N ?81^00.00W ?37^59.99N ?81^09.99W
TTUTM ?B6xxxyyy ?19T ?10 ?300000 ?4720000
TTCORRAL ??37^55.50N ?81^7.00W ?0^0.02N
TTMACRO ?xx1yy ?B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO ?xx2yy ?B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO ?xxyyy ?B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO ?z ?Cz

this is the sell

direwolf -t 2
Dire Wolf version 1.6
Includes optional support for: ?cm108-ptt

Reading config file direwolf.conf
Audio device for both receive and transmit: plughw:2,0 ?(channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...

[0L] XE1GNU-1>APDW16,WIDE1-1,WIDE2-1:!1928.03NS09906.38W#PHG5140Iniciando

XE1GNU-7 audio level = 105(55/32) ??[NONE] ??__||||||_
[0.4] XE1GNU-7>Q9RX0S,WIDE1-1,WIDE2-1:`<0x7f>^C<0x1c><0x1f>SP\`"L6}HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05
MIC-E, Parking, Mic-Emsg, In Service
N 19 28.0300, W 099 06.3900, 0 MPH, course 355, alt 7267 ft
HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05
[0H] XE1GNU-7>Q9RX0S,XE1GNU-1*,WIDE2-1:`<0x7f>^C<0x1c><0x1f>SP\`"L6}HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05

Re: KISSPORT #### does not override 8001

 

¿ªÔÆÌåÓý


Hello Rob,

If you google the following term:

?? direwolf "Transmit timing error: PTT is on" "mSec too long"

You'll see a few hits and one one of these talks about the issue being known on non-Raspberry Pi 4 and newer hardware with it's older USB stack.? What hardware are you using with your setup?? If you are using older Raspberry Pi hardware, there is a workaround you can try:

??

--David
KI6ZHD




On 07/09/2021 07:19 AM, Rob Giuliano via groups.io wrote:

I used the config file you proposed and it appears to be behaving now.

I am getting an error 1.7-dev-A that is
????? Transmit timing error: PTT is on 104 mSec too long.?
I am using VOX (no PTT settings), so not sure where this is coming from.
The times vary from about 100 mSec too long to maybe 250 mSec too long

This seems to be shorter ('too long time') and less often with the updated config.c file.
With the original config.c, they were as long as 500 mSec.
They only seem happen on TX from an attached client (either [0L] or [1L], but not both), or for PBEACON on the [1L] stream

Robert Giuliano
KB8RCO



On Thursday, July 8, 2021, 3:36:49 PM EDT, Brent WG0A <bjpetit@...> wrote:


I bumped into this when trying to run two separate instances of direwolf. One for VHF and one for HF. In that case I would see a collision on port 8001. After digging around a bit I found that the way to turn off the 8001 default is to set KISSPORT 0 before any other KISSPORT settings in the config.?

I also proposed a code change to the KISSPORT default behavior here.
Re: KISSPORT #### does not override 8001

 

I used the config file you proposed and it appears to be behaving now.

I am getting an error 1.7-dev-A that is
????? Transmit timing error: PTT is on 104 mSec too long.?
I am using VOX (no PTT settings), so not sure where this is coming from.
The times vary from about 100 mSec too long to maybe 250 mSec too long

This seems to be shorter ('too long time') and less often with the updated config.c file.
With the original config.c, they were as long as 500 mSec.
They only seem happen on TX from an attached client (either [0L] or [1L], but not both), or for PBEACON on the [1L] stream

Robert Giuliano
KB8RCO



On Thursday, July 8, 2021, 3:36:49 PM EDT, Brent WG0A <bjpetit@...> wrote:


I bumped into this when trying to run two separate instances of direwolf. One for VHF and one for HF. In that case I would see a collision on port 8001. After digging around a bit I found that the way to turn off the 8001 default is to set KISSPORT 0 before any other KISSPORT settings in the config.?

I also proposed a code change to the KISSPORT default behavior here.
https://github.com/wb2osz/direwolf/pull/333

Re: KISSPORT #### does not override 8001

 

I bumped into this when trying to run two separate instances of direwolf. One for VHF and one for HF. In that case I would see a collision on port 8001. After digging around a bit I found that the way to turn off the 8001 default is to set KISSPORT 0 before any other KISSPORT settings in the config.?

I also proposed a code change to the KISSPORT default behavior here.
https://github.com/wb2osz/direwolf/pull/333
Re: KISSPORT #### does not override 8001

 

¿ªÔÆÌåÓý


Hello Roger,

Ok.. and btw, I've created a Github issue to track this issue for you:

??


--David
KI6ZHD
??

On 07/07/2021 06:29 PM, Roger wrote:

Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:

Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP
Re: KISSPORT #### does not override 8001

 

In addition, I connected both TCP ports using APRSIS32
[0L] KB8RCO-2>APWW11,WIDE1-1,WIDE2-1:@173559h4209.35N/08346.30W1 EXPERIMENTATION
[1L] KB8RCO-2>APWW11,WIDE1-1,WIDE2-1:@173559h4209.35N/08346.30W1 EXPERIMENTATION
[0L] KB8RCO-2>APWW11,WIDE1-1,WIDE2-1:@173559h4209.35N/08346.30W1 EXPERIMENTATION
[0L] KB8RCO-3>APDW17:!4209.35N008346.30W-Saline MI Testing Ch0
[1L] KB8RCO-4>APDW17:!4209.35N108346.30W-Saline MI Testing Ch1?

I enabled 3 RF ports (8001, 8010, 8011) and opened log files for each.
There is a delay between 8001 opening and 8010 and 8011 opening - which implies my theory is correct.
Although it opens a TCP port and the port is there (available), APRSIS32 does not appear to do anything with 8001.
When APRSIS32 beacons, there appears 2x the message for [0L] implying it sends on 8001 and then again on 8010.

Robert Giuliano
KB8RCO



On Thursday, July 8, 2021, 1:01:28 PM EDT, Rob Giuliano <kb8rco@...> wrote:


I just compiled V1.7 and tried to change the TCP KISS port.
As stated, the 'default' port does not change, however when specifying a port, it looked like this:
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 8 2021)
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept AGW client application 0 on port 8010 ...
Ready to accept KISS TCP client application 0 on port 8011 (radio channel 0) ...

So it appears you can assign the new port by radio channel.
Both appeared to be active, so it appears the issue is with the generic port being set to the default and not re-assigned.

So I went with
? KISSPORT 8010 0
? KISSPORT 8011 1
And 3 KISS TCP ports were open:
Ready to accept KISS TCP client application 0 on port 8001
Ready to accept AGW client application 0 on port 8000
Ready to accept KISS TCP client application 0 on port 8010 (radio channel 0)
Ready to accept KISS TCP client application 0 on port 8011 (radio channel 1)
So it looks to me like the default KISS TCP port is being opened before the config file is read with the information needed to open it, so a default port is always opened.

Robert Giuliano
KB8RCO



On Wednesday, July 7, 2021, 9:29:55 PM EDT, Roger <roger@...> wrote:


Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:

Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP
Re: KISSPORT #### does not override 8001

 

I just compiled V1.7 and tried to change the TCP KISS port.
As stated, the 'default' port does not change, however when specifying a port, it looked like this:
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 8 2021)
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept AGW client application 0 on port 8010 ...
Ready to accept KISS TCP client application 0 on port 8011 (radio channel 0) ...

So it appears you can assign the new port by radio channel.
Both appeared to be active, so it appears the issue is with the generic port being set to the default and not re-assigned.

So I went with
? KISSPORT 8010 0
? KISSPORT 8011 1
And 3 KISS TCP ports were open:
Ready to accept KISS TCP client application 0 on port 8001
Ready to accept AGW client application 0 on port 8000
Ready to accept KISS TCP client application 0 on port 8010 (radio channel 0)
Ready to accept KISS TCP client application 0 on port 8011 (radio channel 1)
So it looks to me like the default KISS TCP port is being opened before the config file is read with the information needed to open it, so a default port is always opened.

Robert Giuliano
KB8RCO



On Wednesday, July 7, 2021, 9:29:55 PM EDT, Roger <roger@...> wrote:


Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:

Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP
Re: KISSPORT #### does not override 8001

 

¿ªÔÆÌåÓý

Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:


Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP
TNC exporter: metrics collection and visualization for direwolf

Ross Young
 

Hi direwolf community,
I'd like to introduce my open source project, , which provides a legible, information-dense and customizable interface to view and analyze TNC activity over time. It is a prometheus exporter and grafana dashboard for direwolf (and other software TNCs) that collects packet metrics using the AGW or KISS TCP/IP interfaces. Please see the project's README file for additional information about requirements, installation, configuration etc. TNC exporter is released under the MIT license.

I built this in my spare time over the past few months, mostly because it was an interesting challenge dealing with several technologies I wanted to learn more about. Despite this, I have tried to make it a fully featured, decently documented piece of software that is of use to packet radio operators, particularly folks who would like to track ongoing usage of infrastructure such as digipeaters and iGates. I still have some additional features planned (namely Mic-E and compressed position report parsing) but at this point I think it's quite useful and want to get the word out. I'm looking forward to hearing if folks here find it a good addition to their shack, and I'm happy to provide support or answer questions.

Bug reports, suggestions and code contributions are welcome, through the github repo linked above or directly via email if you prefer.

Ross KJ7GES
option digipeater no work in mi direwolf

 

Hello, I compiled on a raspberry pi zero W direwolf 1.6 as indicated in the manual, my intention is to configure an aprs repeter (digipeater).

The problem is that when I turn on a handheld radio with aprs and it sends its beacom, direwolf if it hears it but does not broadcast the information, when I see the linux shell it says that it does but in reality it does not send it to the radio, it even see on the radio that it is connected to the raspberry that changes the display light because the ptt is activated, but it is as if it does not send the audio, only repeater, because when it sends the audio of the direwolf beacom it does it well.
If I activate the igate direwolf option, it registers the data from the handheld radio on the internet without problem and I see it in aprs.fi.

This in my understanding is that if it is receiving the packets from the handheld radio well.
xe1gnu-1 is direwolf and xe1gnu-7 is other radio

 I compiled it wrong ?.
 Do I get a package on the raspberry?
 Any configuration problems?
 I have 7 days on that and I have no idea where you could see the problem.

 Thank you and 73 from xe1gnu is an important project for my SOTA activity.

this is my configuration.

ADEVICE? plughw:2,0
CHANNEL 0
MYCALL XE1GNU-1
MODEM 1200
PTT GPIO 25
AGWPORT 8000
KISSPORT 8001
PBEACON delay=1 ?every=5 overlay=S symbol="digi" lat=19^28.025N long=099^6.383438W power=25 height=20 gain=4 comment="Iniciando" via=WIDE1-1,WIDE2-1
DIGIPEAT 0 0 ^WIDE[3-7]-[1-7]$|^TEST$ ^WIDE[12]-[12]$ TRACE


TTPOINT ?B01 ?37^55.37N ?81^7.86W
TTPOINT ?B7495088 ?42.605237 ?-71.34456
TTPOINT ?B934 ?42.605237 ?-71.34456
TTPOINT B901 ?42.661279 ?-71.364452
TTPOINT B902 ?42.660411 ?-71.364419
TTPOINT B903 ?42.659046 ?-71.364452
TTPOINT B904 ?42.657578 ?-71.364602
TTVECTOR ?B5bbbddd ?37^55.37N ?81^7.86W ?0.01 ?mi
TTGRID ??Byyyxxx ???37^50.00N ?81^00.00W ?37^59.99N ?81^09.99W
TTUTM ?B6xxxyyy ?19T ?10 ?300000 ?4720000
TTCORRAL ??37^55.50N ?81^7.00W ?0^0.02N
TTMACRO ?xx1yy ?B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO ?xx2yy ?B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO ?xxyyy ?B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO ?z ?Cz

this is the sell

direwolf -t 2
Dire Wolf version 1.6
Includes optional support for: ?cm108-ptt

Reading config file direwolf.conf
Audio device for both receive and transmit: plughw:2,0 ?(channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...

[0L] XE1GNU-1>APDW16,WIDE1-1,WIDE2-1:!1928.03NS09906.38W#PHG5140Iniciando

XE1GNU-7 audio level = 105(55/32) ??[NONE] ??__||||||_
[0.4] XE1GNU-7>Q9RX0S,WIDE1-1,WIDE2-1:`<0x7f>^C<0x1c><0x1f>SP\`"L6}HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05
MIC-E, Parking, Mic-Emsg, In Service
N 19 28.0300, W 099 06.3900, 0 MPH, course 355, alt 7267 ft
HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05
[0H] XE1GNU-7>Q9RX0S,XE1GNU-1*,WIDE2-1:`<0x7f>^C<0x1c><0x1f>SP\`"L6}HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05

GPIO permission denied, udev racing

 

This bug was supposedly fixed in direwolf 1.6 by adding 250ms before gpio initialization.??
I'm still observing it on a raspberry pi zero.? Does anyone have a workaround or defensive
code/patch to make direwolf more deterministic?? ?I just upped the wait to 500ms to see
if that helps, in ptt.c.

this is rare, but it still happens,

pi@gtown:~ $ tail -f /run/direwolf.log 
Audio device for both receive and transmit: plughw:0,0  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
You don't have the necessary permission to access GPIO.
There are three different solutions: 
 1. Run as root. (not recommended)
 2. If operating system has 'gpio' group, add your user id to it.
 3. Configure your user id for sudo without a password.
?
5181 - 5200 of 10517