开云体育

It's hard to find good information on APRS. A web search produces mostly outdated misinformation and little of value. Some of it is just plain wrong. The APRS Foundation is trying to improve the situation by collecting the best existing material, writing new material, and putting it all in one place, with an easy to remember name. https://how.aprs.works is the new place to find the best, most up to date, information on APRS. Bookmark it and check back back often for updates. The article called Understanding APRS Packets is recommended reading for everyone. About 1/3 of the document is errors seen on the air locally. Some of the problems are caused by defective implementations. Other problems are caused by user error, because they were not aware of the relevant documentation. Read it carefully if you don't want to be used as an example of what not to do. 73, John WB2OSZ

I want to link two separate PCs (or raspberry pi's) running on two separate routed networks similar to a KISS client/server configuration. Both networks have access to each other but only one has a radio resource and internet connection; I would like to send APRS data from one network without resources to the network that does. Is there a method for achieving this? The ICHANNEL feature looks like it would be able to do this but direwolf does not act as a KISS client. I have a work around that uses another program to receive data via KISS and pass it to the internet via APRS-IS. I would like to use direwolf, if possible, to keep the installations lightweight.

Good day Direwolf Users, I'm trying to setup my Raspberry Pi with Direwolf, and I'm just having a few issues. Each time I boot up Direwolf, it's telling me that my USB audio dongle is in use. This is the output of arecord -l: card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio] Subdevice: 1/1 Subdevice #0: subdevice #0 This is the output of sudo lsof /dev/snd/*: lsof: Warning: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. Command PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 767 jtwist 36u CHR 116,32 0t0 272 /dev/snd/controlC1 I installed pavucontrol as the pdf suggests for pulse audio, and I'm not exactly sure what setting to adjust within that, everything looks right as far as I can tell. Thanks in advance, Johnny W5KV

I've incorporated two radios into my RPI setup. I have two digirig soundcards configured as channels 0 and 2 in the .conf file They's both USB audio. When rebooting Pi, the addresses (device IDs) swap requiring a swap of the USB cables to the digirigs. Its a PITA. Is there some way to code each of these USB devices to prevent this? I realize the problem may be more a Linux issue.

Its funny what you find when you google search direwolf while trying to get your packet station fixed :) https://www.wired.com/story/scientists-brought-back-dire-wolf-deextinct/ https://time.com/7274542/colossal-dire-wolf/ https://www.google.com/search?q=direwolf&tbm=nws

I have CumulusMX running on a PI3 feeding YAAC with the output sent to Direwolf. All is well. Packets sent with weather and packets received. The weather starts out reporting Celsius but it is transmitted from Direwolf in Fahrenheit. I must be missing something, but what? Help would be appreciated. Ian - VE3EP

All, As an adjunct topic to some other posts I made earlier, I wonder about proper division of resources in the chain of events of a packet system that can include the impressive decode abilities of the DireWolf Modem. The goal is to hook up multiple Radio/TNC combinations to one copy of BPQ32 running on a nice stable Linux box in the radio rack. John Wiseman (BPQ32 guy) suggests using a TNC in "host" mode may provide noticeably better AX.25 link management than if using KISS mode. The quick way to solve this is with a traditional hardware TNC with host mode capabilities... [RADIO]---audio---[TNC:Modem/HostMode]---USB---[PC:Linux&BPQ32] ...but let's say we loathe modems using a hardware modem chip. We might consider a TNC advertising the use of a real DSP chip within to yield... [RADIO]---audio---[SCSTrkrTNC:Modem/HostMode]---USB---[PC:Linux&BPQ32] Note the SCS Tracker TNC is primarily designed for HF Robust Packet use, but does sport a full suite of modes including 1200 and 9600. What I don't know is if the touted "1200 DSP" benefits on their sales slicks really match up with what DireWolf gives us and they aren't talking. It's probably safe to say it is at least as good as any previous hardware modem chip TNC. Anyway, let's move on... [RADIO]---audio---[R-Pi:DireWolf/KISS]---TCPStack---[PC:Linux&BPQ32] I've actually gotten the above to work very well. Note, however, BPQ32 is managing the AX.25 link management (I think). [RADIO]---audio---[R-Pi:DireWolf/HostMode]---TCPStack---[PC:Linux&BPQ32] So here I've moved the "HostMode" AX.25 link management from BPQ32 to the processor closest to the modem... the R-Pi (or equivalent)... in an attempt to improve performance and inch timing settings ever closer towards optimum data throughput. All this while leaving the BPQ32 PC to just be the BBS/Chat machine and not much else... a leisurely high-reliability life. As I understand it, DireWolf doesn't perform any hostmode functions and perhaps never should. If true, is there a program that can run in the Linux regime to perform just the host AX.25 management functions plus serve as go-between the DireWolf modem and the network port/BPQ32? Thanks. John, kx4o

Folks - I can't seem to find anything on this, so hoping someone has some experience with this. I'm trying to ditch UZ7HO soundmodem and get back to Direwolf, and now working through config issues on my Windows 11 machine. I have multiple DRA-50s connected, and am using the "cm108" utility to identify the (long) string which identifies the devices. I would then use lines like this to point to them: ADEVICE USB "\\?\hid#vid_0d8c&pid_013a&mi_03#8&2434851&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" #ADEVICE USB "\\?\hid#vid_0d8c&pid_013a&mi_03#9&42f53e8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" PTT CM108 "\\?\hid#vid_0d8c&pid_013a&mi_03#8&2434851&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" #PTT CM108 "\\?\hid#vid_0d8c&pid_013a&mi_03#9&42f53e8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" (note the two different identifiers here) However, I get errors at Direwolf boot warning me that some of the settings lines are too long... and then you can see that the name of the device was truncated and then not identified correctly. === snip ================= WARNING: strlcpy result length 87 exceeds maximum length 79. (/home/John/src/direwolf-dev/src/config.c config_init 1053) WARNING: strlcpy result length 135 exceeds maximum length 127. (/home/John/src/direwolf-dev/src/cm108.c cm108_inventory 570) WARNING: strlcpy result length 155 exceeds maximum length 127. (/home/John/src/direwolf-dev/src/cm108.c cm108_inventory 570) WARNING: strlcpy result length 155 exceeds maximum length 127. (/home/John/src/direwolf-dev/src/cm108.c cm108_inventory 570) WARNING: strlcpy result length 159 exceeds maximum length 127. (/home/John/src/direwolf-dev/src/cm108.c cm108_inventory 570) WARNING: strlcpy result length 131 exceeds maximum length 127. (/home/John/src/direwolf-dev/src/cm108.c cm108_inventory 570) There are multiple USB Audio Devices with GPIO capability. Explicitly specify one of them for more predictable results: "\\?\hid#vid_0d8c&pid_013a&mi_03#8&2434851&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" "\\?\hid#vid_0d8c&pid_013a&mi_03#9&42f53e8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Run the "cm108" utility for more details. "\\?\hid#vid_0d8c&pid_013a&mi_03#8&2434851&0&0000#{4d1e55b2-f16f-11cf-88cb-00111" doesn't match any of the output devices. Available audio input devices for receive (*=selected): * 0: DRA50 #2 RX (2- USB PnP Sound D (channel 0) 1: SCU-17 HF (RX) (2- USB Audio CO 2: DRA-50 (RX) (USB PnP Sound Devi Available audio output devices for transmit (*=selected): 0: Sceptre F27 (HD Audio Driver fo 1: DRA50 #2 TX (2- USB PnP Sound D 2: SCU-17 HF (TX) (2- USB Audio CO 3: DRA-50 (TX) (USB PnP Sound Devi 4: speakers? (Realtek(R) Audio) Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate. Using \\?\hid#vid_0d8c&pid_013a&mi_03#8&2434851&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} GPIO 3 for channel 0 PTT control. Ready to accept AGW client application 0 on port 8000 ... Ready to accept KISS TCP client application 0 on port 8001 ... === /snip ================================= Two questions, then: (1) How to get around this strlcpy character limit for long USB device names in the Windows config file, and (2) How to point to a specific ADEVICE? On #2, there is documentation about how to point to a specific PTT device, but I'm only guessing that I can point to an ADEVICE like this: ADEVICE USB "\\?\hid#vid_0d8c&pid_013a&mi_03#9&42f53e8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Thanks for any help, Brian AG6WR

While checking in User-Guide.pdf supplied with the latest dev download and searching for details related to kissutil command line parameters the search includes a reference on page 135 in the section discussing command line parameters for direwolf. Although the syntax for the -T parameter is the same for kissutil as it is for direwolf the reference on page 135 "If you want UTC, rather than local time, set the TZ environment variable before running kissutil." should more accurately be "If you want UTC, rather than local time, set the TZ environment variable before running direwolf." 73 de Rich WA3WLH

Good evening. I am new to APRS, direwolf and Igate i have installed direwolf on a Raspbeery Pi 4 direwolf opens without any errors. I am not decoding any packets. I can hear them on another radio. unfortunately i don't have a APRS capable radio yet so i am limited to hearing packets from Beacons of other stations The audio source is a Kenwood TM261 via the external speaker jack. Below is the information from my setup. What am I missing? Dire Wolf version 1.7 Includes optional support for: cm108-ptt Reading config file direwolf.conf Audio device for both receive and transmit: plughw:3,0 (channel 0) Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate. Note: PTT not configured for channel 0. (Ignore this if using VOX.) Ready to accept AGW client application 0 on port 8000 ... Ready to accept KISS TCP client application 0 on port 8001 ... Now connected to IGate server noam.aprs2.net (96.53.142.57) Check server status here http://96.53.142.57:14501 [ig] # aprsc 2.1.14-g5e22b37 [ig] # logresp KO4TDD-10 verified, server T2EDM [ig] KO4TDD-10>APDW17:!3606.76NR08916.55W& [0L] KO4TDD-10>APDW17,WIDE1-1:!3606.76NS08916.55W#PHG7140DigiPi/Igate (open squelch) ADEVICE0: Sample rate approx. 44.2 k, 0 errors, receive audio level CH0 24 ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 23 from direwolf.conf ADEVICE plughw:3,0 CHANNEL 0 MYCALL KO4TDD-10 MODEM 1200 AGWPORT 8000 KISSPORT 8001

Hello folks, I'm running Direwolf in Windows 11. Using a Digirig Mobile, connecting both of the two (black and green) Digirig cables for my Kenwood TM-V71A. I edited the direwolf config file to add the line "PTT COM6 RTS" Direwolf reports "Note: PTT not configured for channel 0, (Ignore this if using VOX.) Tried the TM-V71A in EchoLink Sysop mode and not in that mode. No difference. I don't see the power scale light up in the radios display indicating transmission. Paracon times out. I soldered the 3 pad pairs inside the Digirig to enable RS-232. Tested everything with a multimeter. I do notice the Digirig case runs warm. Is that because RS-232 uses 12v while logic levels uses 3.3v? I've been googling all day and don't know what is wrong. Would someone please help me out. Dave N3DZ

Hello, I have trouble with PTT, it does not switch to TX, everything else seems to be working fine. Using Digirig Mobile, interfacing IC-207 via digital audio connector, pins used: GND, Audio IN, 9600 bps out, PTT. When I transmit a packet, it appears in the output by Direwolf but PTT is actually not activated. Setting in direwolf.conf: PTT COM5 RTS I tested this: 1. shorting GND and PTT contacts on the Digirig cable (shorting shield and the nearest ring): WORKS 2. controlling PTT by FLRig (just the serial port) with serial port RTS configured as PTT: WORKS 3. using VARA FM, configuring RTS of the serial port as PTT: WORKS 4. setting direwolf.conf PTT COM5 -RTS: immediately after launching direwolf.exe the IC-207 switched to TX and remained so until I quit Direwolf => direwolf.exe does control RTS of the COM port. The same Digirig Mobile physical interface works fine with any other software (except UZ7HO soundmodem, see below) in any other O/S (Windows, Linux x64, Raspberry Pi). Audio reception in Direwolf is flawless. Question: what can I do to fix this? At the moment I am not ready yet to switch packet to a Linux machine. If it helps, I have exactly the same problem with UZ7HO soundmodem, except that Soundmodem does not bother mentioning in documentation or configuration dialog whether RTS or DTR are used specifically to control PTT, but I suppose it does exactly the same thing as Direwolf. Thank you, Jindra OK4RM

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>' http://127.0.0.1:12345 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>' http://127.0.0.1:12345 exit 0

I compiled/updated Direwolf on Kubuntu today using "git checkout dev". Starting Direwolf report 1.8 A which has a reasonable length VOX comment. Then I starting from a new Raspberry Pi build (New Pi5) and downloading/compiling from github also with "git checkout dev". That gives me 1.8 D that has 20 lines of VOX commentary. I think that is a bit much and it is repeated for each configured device (I have 2). REQUEST: Suppress the VOX warning when Audio out device for transmit: null Another idea would be to add this option to -q v to suppress VOX messages or BOTH The VOX warning has no value if there is no transmit audio device, so it makes sense to eliminate the warning. Adding an option of '-q v' to "quiet the VOX warning" would allow those who use the application often and have read the warning to suppress it in future start-ups. Robert Giuliano KB8RCO

I observed that other tnc?s ehen digipeat various sequential frames (i.e. telemetry) without time for transmitit each one, when the channel is clear, digipeat all the pendings frames in a only one transmit without release the ptt. Direwolf transmit one by one separately with the tx delay.... tx tail... etc. Is possible change it and repeat in this cases with only one transmision?

Is anyone familiar with configuring Direwolf to run on Raspberry Pi with an IC-705? Basically I can transmit a packet out but Direwolf doesn't seem to hear incoming packets. It is worth mentioning all other amateur radio software I am using does work (ie: FLRIG, FLDIGI, WSJTX, JS8call, Pat Winlink with ARDOP modem) Hardware: Raspberry Pi 4, Icom IC-705, USB cable (interface) OS: Raspbian GNU/Linux 10 (buster) Firmware: Icom v1.24 Software: Direwolf v1.6 (from KM4ACK Build-a-pi) Symptom: Direwolf will transmit packets from software (ie:Xastir) but does not decode incoming packets. Icom IC-705 Audio Setting AF Output Level 50% Direwolf config: FIRST AUDIO DEVICE PROPERTIES ADEVICE default ACHANNELS 1 CHANNEL 0 PROPERTIES CHANNEL 0 MYCALL KJ7RNY-6 MODEM 1200 PTT RIG 3085 /dev/serial/by-id/usb-Icom_Inc._IC-705_IC-705_12003982-if00 VIRTUAL TNC SERVER PROPERTIES AWGPORT 8000 KISSPORT 8001 When I open PulseAudio Volume Control I see the following under the tabs: -Playback ALSA plug-in [direwolf]: ALSA playback on PCM2901 Audio Codec Analog Stereo Level set 100% **when i send a packet from Xastir the bar below the level slider moves (audio out working)** -Recording ALSA plug-in [direwolf]: ALSA capture from PCM2901 Audio Codec Analog Stereo Level set 100% **the bar below level slider is moving with radio noice from APRS frequency 144.390 (audio in working)** Brian Blanchard Brian.j.blanchard@... KJ7RNY

Ok, by adding: sendto=IG to the TBEACON statement, beacons go out over the Igate. But now they never go out over RF. I need the beacons to go out over both RF and the Igate. So it looks like I still have an issue. Thoughts? Thanks! -- 73, AB1PH Don Rolph