开云体育

Kind of asking John WB2OSZ

What please is the significance of?

// Originally 40.? Version 1.2, try 10 for lower latency.
#define ONE_BUF_TIME 10

in audio.c (also in the portaudio and windows audio code)

Reason I ask is that I have used pulseaudio under direwolf for years that has seen on average 1 in 10 TX packets audio buffer underruns. Changing this from 10 to 40 (Along with some other buffering and CPU speed changes) seems to have resolved them.

Yes I am aware that pulseaudio is not good with direwolf, but I am stuck with it.

With these changes I am not having any TX>RX delay problems that stop decoding of the next 1200AFSK packet.

Cheers Bob VK2YQA

I know this is a busy group so thank you for reading this.

It's been quite some time since I've played with packet radio so I've probably overlooked something obvious.

When I last used my Yaesu radio ADEVICE plughw:1,0 (in the direwolf config file) worked perfectly. Now I want to use SDRconnect instead, just to receive.

arecord -l

**** List of CAPTURE Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
? Subdevices: 0/1
? Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
? Subdevices: 0/1
? Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
? Subdevices: 1/1
? Subdevice #0: subdevice #0

card 0 and device 0 look like the correct device (ADEVICE plughw:0,0) but direwolf returns:

Reading config file /home/phil/direwolf.conf
Audio device for both receive and transmit: plughw:0,0? (channel 0)
Could not open audio device plughw:0,0 for input
Device or resource busy

This is what the audio mixer reports under the playback tab:

ALSA plugin [SDRconnect]: ALSA Playback on

What setting should I be using to have direwolf listen to the output (the speaker) from SDRconnect?

--
Regards,
Phil

开云体育

A little bit off topic.

I have been chasing down an audio buffer underrun problem that only happens with direwolf. I am also running pulseaudio despite not being a good idea for direwolf! I am making some progress with this, that I wont go into with this post though. What I wanted to mention is that part of the problem seems to be that the PTT window time shifts with respect to the audio out. I suspect a hamlib (my rig only) issue rather than a variable audio ring buffer/delay thing. Minimal problem for 30m APRS beacons, but a real mess for 2m ISS passes or AX25 connected mode.

Some time ago I wrote a pulseaudio VOX like PTT script to run EasyDRF (under wine) that I though I would share for interest. I recently reworked it for the fast turnaround needed for ARDOP. It now works "perfectly" in replacing the use of the PTT RIG 2 localhost:4532 line in the direwolf conf file. It detects the presence of flrig or rigctld as needed.

Basically it just sits pushing an audio stream into a FIFO/pipe at 48kHz and samples that 1260 bytes at a time. Any deviation from audio "zero" asserts the PTT. The 1260 I got by first running the dd command without iflag=fullblock and a bs of 4800 odd, then seeing how many bytes were actually read (in stderr), adding maybe 20% and plugging it all back into the dd line. The audio stream is not perfectly synchronous hence the need for the iflag-fullblock. Doing the maths it looks like the worse case delay before PTT assert is in the order of 25-50mS which can easily be countered with an additional TXdelay.

alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor is the pulse device name used for a few types of Icom transceivers. pactl list shows all.

This cured my direwolf PTT/audio window problem.

Cheers Bob VK2YQA

=============

#!/bin/bash

export DRFACTIVE=TRUE
export PTTSTATE=OFF

if [ "`ps -C flrig --no-headers`" != "" ] ; then
??? PTT1=flptt1
??? PTT0=flptt0
elif [ "`ps -C rigctld --no-headers`" != "" ] ; then
??? PTT1=hlptt1
??? PTT0=hlptt0
else
??? /usr/local/bin/rigctld -m 3068 -x 2 -c 0x7c -s 19200 -r /dev/icom9100a &
??? PTT1=hlptt1
??? PTT0=hlptt0
fi

# Output to continuous pipe
killall -TERM parec 2>/dev/null
rm -f /tmp/voxptt.raw /tmp/*drfpttstderr.txt
mkfifo /tmp/voxptt.raw
(sleep 4 && parec --rate=48000 --format=u8 --channels=1 --channel-map=front-left -d alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor >/tmp/voxptt.raw) &


( while [ "$DRFACTIVE" = "TRUE" ] ; do
if [ "`dd bs=1260 count=1 iflag=fullblock 2>>/tmp/main-drfpttstderr.txt | xxd -p -c 1 | grep -v 80`" == "" ] ; then

??????? # Ptt Assert RX
??????? if [ "$PTTSTATE" = "ON" ] ; then
??????????? $PTT0 >/dev/null 2>&1 &
??????????? PTTSTATE=OFF
??????????? echo .
??????????? echo TX2RX | tee -a /tmp/main-drfpttstderr.txt
??????? fi
??????? echo -n "Off "?? ?
else
??????? # Ptt Assert TX
??????? if [ "$PTTSTATE" = "OFF" ] ; then
??????????? $PTT1 >/dev/null 2>&1 &
??????????? PTTSTATE=ON
??????????? echo .
??????????? echo RX2TX | tee -a /tmp/main-drfpttstderr.txt?????? ?
??????? fi
??????? echo -n "On? "
fi

done) </tmp/voxptt.raw

===========

hlppt1

#!/bin/bash
#
echo "\set_ptt 1"|nc -w 1 -q 0 localhost 4532
exit 0

hlppt0

#!/bin/bash
#
echo "\set_ptt 0"|nc -w 1 -q 0 localhost 4532
exit 0

flptt1

#!/bin/bash
curl -X POST -d '<?xml version="1.0"?><methodCall><methodName>rig.set_ptt</methodName><params><param><value><int>1</int></value></param></params></methodCall>'
exit 0

flptt0

#!/bin/bash
curl -X POST -d '<?xml version="1.0"?><methodCall><methodName>rig.set_ptt</methodName><params><param><value><int>0</int></value></param></params></methodCall>'
exit 0

Hi,

The Icom 9700 stops transmitting as soon as the PTT signal is dropped, but it does have some delay in its audio processing. This means that you need to increase TXTAIL in direwolf.conf in order to ensure that the entire audio packet has been transmitted before dropping PTT.

I don't have any Icom radio, let alone a 9700, and therefore can't tell you what the best value for TXTAIL is. I suggest increasing in 100ms steps until connected mode packet operation works and then perhaps stepping back down in 10ms steps to figure out how much delay is needed. Note that TXTAIL is configured in 10ms steps and defaults to 10 (meaning 100ms delay). An initial increase to 200ms would require "TXTAIL 20" in direwolf.conf.

Thanks
Thomas
KK6FPP

开云体育

That is what I was suspecting. This evening I had a few mins to make some changes and send the third party packet in its string representation. Yet there is still something a little off.

[15.is 20250103T20:35:07] X>X:}WT0F-4>APDR16,TCPIP*,qAC,T2CSNGRAD::APRSFL?? :Ping{29
APRS Message, number "29", from "WT0F-4" to "APRSFL", APRSdroid Android App
Ping
[0L 20250103T20:35:07] DELAND>APDW17,WIDE1-1:}WT0F-4>APDR16,TCPIP,DELAND*::APRSFL?? :Ping{29
[0L 20250103T20:35:09] (Not AX.25)X>X:}APRSFL>APZIOR,TCPIP::WT0F-4?? :ack29
[0L 20250103T20:35:11] (Not AX.25)X>X:}APRSFL>APZIOR,TCPIP::WT0F-4?? :0103 2335Z:Pong!<0x20>

Curiously, I am sending back the packet with the third party header, but the packet is being sent out the RF interface instead of the APRS-IS connection.

Direwolf is sending anything that originates from the APRS-IS connection over the KISS connection with the third party header. If I receive a packet without the third party headers, then it was received on the RF interface. Given that it has been pretty consistent on how packets are sent over the KISS connection, I would expect that Direwolf would treat the packets coming back over the KISS connection the same way. If the packet has a third party header then it gets routed to the APRS-IS connection.?

At least decode_aprs sees the packets as valid AX.25 packets.

pi@wt0f-10:~ $ decode_aprs
X>X:}APRSFL>APZIOR,TCPIP::WT0F-4?? :ack29

X>X:}APRSFL>APZIOR,TCPIP::WT0F-4?? :ack29
"APRSFL" ACKnowledged message number "29" from "WT0F-4", Experimental
X>X:}APRSFL>APZIOR,TCPIP::WT0F-4?? :0103 2335Z:Pong!<0x20>

X>X:}APRSFL>APZIOR,TCPIP::WT0F-4?? :0103 2335Z:Pong!<0x20>
APRS Message, with no number, from "APRSFL" to "WT0F-4", Experimental
0103 2335Z:Pong!<0x20>

On Fri, Jan 3, 2025 at 10:26 AM, Gerard Hickey, WT?F wrote:

X>X:}<0x82><0xa0><0xb4><0x92><0x9e><0xa4>`<0x82><0xa0><0xa4><0xa6><0x8c><0x98>`<0xae><0x92><0x88><0x8a>b@c<0x03><0xf0>:WT0F-4?? :ack19

This part needs to be in plain text, not the AX.25 header format with the characters shifted left.

?

<0x82><0xa0><0xb4><0x92><0x9e><0xa4>`<0x82><0xa0><0xa4><0xa6><0x8c><0x98>`<0xae><0x92><0x88><0x8a>b@c<0x03><0xf0>

?

73,

John WB2OSZ

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611

开云体育

I have been doing some reading and experimentation this morning and have a theory. Hopefully you can confirm my theory.

I am using a forked copy of the ioreth script (actually forked copy running APRSPH) and in this script it converts the AX.25 packet to a byte array and transmits the bytes over the KISS connection. In the process of converting to the byte array it shifts all the callsign characters by 1 bit to the left then adds the SSID to the end of the callsign. The result being the non-printable characters shown in my last message.

Also this morning I found the decode_aprs utility and tried some experiments with the hope that it would give me more info as to why the packet was not being seen as an AX.25 packet. What it seems is that if the KISS connection receives the stream of bytes it will transmit the over the RF connection with no errors. If the third party header is added, then Direwolf wants the entire packet to be the string representation of the AX.25 packet.

Does this make sense and could this be what is happening causing Direwolf to flag the packet as an invalid AX.25 packet?

Thanks.

It has helped a little bit, but I tried to send a third party packet back over the KISS connection and I am getting DireWolf telling me that the packet is not AX.25. I have had? very little experience with AX.25 at the protocol level so I am probably missing something pretty basic.

Here is what I just got.

[ig>tx] WT0F-4>APDR16,TCPIP*,qAC,T2SPAIN::APRSFL?? :Ping{19
[15.is 20250102T22:31:42] X>X:}WT0F-4>APDR16,TCPIP*,qAC,T2SPAIN::APRSFL?? :Ping{19
[0L 20250102T22:31:42] DELAND>APDW17,WIDE1-1:}WT0F-4>APDR16,TCPIP,DELAND*::APRSFL?? :Ping{19
[0L 20250102T22:31:44] (Not AX.25)X>X:}<0x82><0xa0><0xb4><0x92><0x9e><0xa4>`<0x82><0xa0><0xa4><0xa6><0x8c><0x98>`<0xae><0x92><0x88><0x8a>b@c<0x03><0xf0>:WT0F-4?? :ack19
[0L 20250102T22:31:45] APRSFL>APZIOR,WIDE1-1::WT0F-4?? :0103 0131Z:Pong!<0x20>

So the initial packet comes in over APRS-IS and my KISS client sees the packet come in with the third party header on the packet.

At this point I am only attempting to put the third party header on the ACK. The response from the KISS client (i.e. "Pong!") is not sent with the third party header hence it is sent out the RF interface.

Any ideas as to why this is not being seen as an AX.25 packet or what my misunderstanding is?

On 1/2/25 11:25 AM, WB2OSZ via groups.io wrote:

?

The KISS frame uses AX.25 formatting for addresses.? This means the addresses are constrained to maximum 6 upper case letters or digits then an SSID in the range of 0 to 15.??? APRS-IS has looser restrictions.? Lower case can be used, station name can exceed 6 characters, and SSID can be up to 2 alphanumeric characters.

Example:

AB1OC-10>APWW11,TCPIP*,qAC,T2SPAIN:>FN42er/-DX: WA1PLE-13 43.7mi 154? 02:35 4208.36N 07113.50W<0x20>

When something from APRS-IS is conveyed over KISS, we add a fake third party header so the original addresses can be preserved.

Example:

X>X:}AB1OC-10>APWW11,TCPIP*,qAC,T2SPAIN:>FN42er/-DX: WA1PLE-13 43.7mi 154? 02:35 4208.36N 07113.50W<0x20>

Discard the first ":}" and everything before it.

Going in the opposite direction, you would need a fake third party header only if any of the addresses violate the AX.25 restrictions.? It might be a good idea to always use it so you don’t need to examine the addresses and have special cases.?

Direwolf will simply discard any third party header before forwarding the rest to APRS-IS.

More complete details are in "Internal-Packet-Routing.pdf" found in .?

I hope this helps.

73,

John WB2OSZ

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611

开云体育

It has helped a little bit, but I tried to send a third party packet back over the KISS connection and I am getting DireWolf telling me that the packet is not AX.25. I have had? very little experience with AX.25 at the protocol level so I am probably missing something pretty basic.

Here is what I just got.

[ig>tx] WT0F-4>APDR16,TCPIP*,qAC,T2SPAIN::APRSFL?? :Ping{19
[15.is 20250102T22:31:42] X>X:}WT0F-4>APDR16,TCPIP*,qAC,T2SPAIN::APRSFL?? :Ping{19
[0L 20250102T22:31:42] DELAND>APDW17,WIDE1-1:}WT0F-4>APDR16,TCPIP,DELAND*::APRSFL?? :Ping{19
[0L 20250102T22:31:44] (Not AX.25)X>X:}<0x82><0xa0><0xb4><0x92><0x9e><0xa4>`<0x82><0xa0><0xa4><0xa6><0x8c><0x98>`<0xae><0x92><0x88><0x8a>b@c<0x03><0xf0>:WT0F-4?? :ack19
[0L 20250102T22:31:45] APRSFL>APZIOR,WIDE1-1::WT0F-4?? :0103 0131Z:Pong!<0x20>

So the initial packet comes in over APRS-IS and my KISS client sees the packet come in with the third party header on the packet.

At this point I am only attempting to put the third party header on the ACK. The response from the KISS client (i.e. "Pong!") is not sent with the third party header hence it is sent out the RF interface.

Any ideas as to why this is not being seen as an AX.25 packet or what my misunderstanding is?

?

The KISS frame uses AX.25 formatting for addresses.? This means the addresses are constrained to maximum 6 upper case letters or digits then an SSID in the range of 0 to 15.??? APRS-IS has looser restrictions.? Lower case can be used, station name can exceed 6 characters, and SSID can be up to 2 alphanumeric characters.

Example:

AB1OC-10>APWW11,TCPIP*,qAC,T2SPAIN:>FN42er/-DX: WA1PLE-13 43.7mi 154? 02:35 4208.36N 07113.50W<0x20>

When something from APRS-IS is conveyed over KISS, we add a fake third party header so the original addresses can be preserved.

Example:

X>X:}AB1OC-10>APWW11,TCPIP*,qAC,T2SPAIN:>FN42er/-DX: WA1PLE-13 43.7mi 154? 02:35 4208.36N 07113.50W<0x20>

Discard the first ":}" and everything before it.

Going in the opposite direction, you would need a fake third party header only if any of the addresses violate the AX.25 restrictions.? It might be a good idea to always use it so you don’t need to examine the addresses and have special cases.?

Direwolf will simply discard any third party header before forwarding the rest to APRS-IS.

More complete details are in "Internal-Packet-Routing.pdf" found in .?

I hope this helps.

73,

John WB2OSZ

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611

开云体育

I am working on bringing up an APRS bot and I am having some troubles. Originally I was running Direwolf 1.6 and was having problems getting packets from the APRS-IS connection to be seen by the KISS client. This evening I compiled Direwolf 1.7 and used the ICHANNEL statement. Now I am getting packets from the APRS-IS connection routed over the KISS connection.

That is the good news. The bad news is that the packets are being received as third party packets and I can not find any references to how packets should be sent over the KISS connection so that the reply packet gets routed back over the KISS connection.

So on the APRS-IS feed, I am seeing the packet come across as

WT0F-4>APDR16,TCPIP*,qAC,T2PRT::APRSFL?? :Test{14

Then on the KISS client, I am seeing the packet come across as

X*>X*:}WT0F-4>APDR16,TCPIP*,qAC,T2PRT::APRSFL?? :Test{14

The response that the client sends back (ACK) is (or close it is as I did not have it handy)

APRSFL>APZIOR,WIDE1-1::WT0F-4?? :ACK{14

This packet goes out the RF interface instead of the APRS-IS connection. So the question is do I need to prepend the packet with X*>X*:} or X>X:} ? Is there any good documentation on how to properly handle third party packets?

Thanks.

-- 
Gerard Hickey / WT?F           IRLP:3067/Echolink:529661
hickey@...     DMR: 3102272
425-395-4554                   Allstar: 531920
MeshPhone: 386-8611