开云体育

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?

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

So I have configured the IGATE servers and logged in. I would now like to beacon over the iGate port if it is connected over internet. Since I am moving PBEACON does not seem like it would work. So how does one do this? -- 73, AB1PH Don Rolph

Hi Finally my cable for the digirig cable has shown up and I have installed it. I am changing the cable from the kenwood cable so that I can use the diigirig unit. As some of you already are aware, I previously was using audio usb cable for receive and ptt from the cat connector on the kenwood. I am hoping to change that to work with the digrig mobile. It is working fine for receive but I cannot send ptt. I am using one cable from the audio to the 6 pin connector on the d710G. Apparently there are settings so that ptt can be asserted through the same cable. Can someone please help me with the settings or direct me where to find the information. The radio works perfectly on receive. Thanks as always and please ask any questions. Joe VA3TV

When configuring an object with OBEACON, is there a way to configure it so time is sent other than *010000zH possibly local time ? I can make the object, and it is sent properly, but I guess I don't understand the time thing. Thanks Arnold, KQ6DI

I don't have a build of direwolf in front of me now, but the question is simple: can I use tactical calls like SAG01, SAG02, EAGLE, DOG, MTNTOP, etc., essentially any combo of 6 characters, so long as I have a legal callsign in a beacon that is transmitted no more than every 10 minutes? Cheer and 73 - Jon N7UV

Hello, successfully built Direwolf on a Linux machine. Now I would like to distribute the compiled version to other club members. Rebuilding from source on the other devices is out of question: we use reflashed chromebooks for field activities, not intended to have complete build stack installed. I noticed there is directory 'debian' which includes files resembling package configuration, but apparently not to be used as-is. I miss any documentation as to how to build .deb package. Can you help please? Thank you Jindra OK4RM

Silly question. Is there an icon for Direwolf that can be used for the shortcut on the main screen? Or did I just create the shortcut wrong? I thought there was one at one time. Arnold, KQ6DI

Apologize if all I need is a pointer to read the docs, but.... I have a telemetry application that normally talks KISS to direwolf and it sends out via the radio. My understanding is that if I want to send out via iGate, I would do that via my KISS program and direwolf would just send to whichever I choose. Is there a way to configure things so that if the packet fails sending to one of the iGate servers I have listed (like my starlink is down) it will automatically route start using the radio?

As requested. I've been running RTLSDR_Airband from the day I found out about it. I was trying to write code for a multi-channel FM receiver and it was proving quite difficult, and I dropped the effort once I found out about it. It uses a very efficient algorithm mix and filter multiple frequencies to baseband RF, where AM and FM demodulation can be applied. FM demodulation is very efficient as well. On my Raspberry Pi I'm running 10 channels at present, with 4 recording audio from repeater outputs, 4 recording baseband RF from repeater inputs, and 2 FM audio channels piped into Direwolf. This consumes about 10% of one of the 4 processor cores on a Raspberry Pi 4. It is supposed to work on a Raspberry Pi 2 and Pi 3, using the on-board GPU to accelerate computation, but I've never tried it. It is also quite reliable, and I've had it running over a month at a time on the Pi. The reason I was doing this was to hunt a repeater jammer in the area, and APRS was an afterthought. The jammer is now gone but new ones come from time to time so I record 4 repeaters 24 hours/day. The audio recordings are used for evidence, and the IQ recordings for analysis, especially experimentally with transmitter profiling. Experience using Direwolf made it obvious it would be a good fit - and it almost was. I now have about 40 GB of recordings. I also encouraged some fellow club members to run similar setups and devised a method by which they could upload their recordings to my system, making them all available for review or analysis. It still has some rough edges but basically works. The most difficult thing is managing security. I called the system Dragnet, which if you look at the files you'll see this as the user account for the programs. The biggest issue I had, which I was dealing with today, was that Airband emits 32-bit floating point samples and Direwolf wants 8 bit unsigned or 16 bit signed integers. There are programs that would do the conversion but they are rather complex, so I decided to write one for the purpose to act as an intermediary between Airband and Direwolf. Initially I tried reading from Airband using an Internet socket, and writing to a socket for Direwolf to read but I ran into difficulties and just wrote the output to stdout and piped it into Direwolf. That worked well for APRS traffic on 144.390 and a couple of weeks ago I added the ISS APRS RS0ISS as a second channel. Yesterday I checked the logs and found that I was receiving the ISS about once per day with several transmissions during the pass and was pleased. I started thinking that because I had two instances of Direwolf I would have 2 igate connections and thought that wasteful, so I decided to pursue the socket to socket sample format conversion again. This time I used Microsoft Copilot which sped things up a lot. The last thing I asked Copilot to do was add GPL V3 terms and conditions to make the code open source. After much back and forth I now have a version which will forward samples to another socket or to stdin based on the command line options. I wrote simple system services for airband, the two instances of the format converter (Terrestrial and ISS APRS) and one instance of Direwolf. It's all running nicely as I write. The main components are Configuration files for airband and Direwolf Systemctl .service files for the 4 system services. The sample converter code, which I called f32_i16.c due to lack of imagination (maybe I should call it AirWolf) I'm happy to share all of it and will post some stuff in the replies. Use at your own risk of course.

Compilation is: gcc f32_i16.c -o f32_i16 -lm You can find the code at https://github.com/SullivanChrisJ/AirWolf.git I run it as a system service with the following .service file (installed in /etc/systemd/system, with $ sudo systemctl enable --now f32_i16_1.service. One of these is needed for each of the channels. Service file would be something like. It could probably be improved. [Unit] Description=Sample conversion for Direwolf Instance #1 Wants=network.target After=network.target [Service] Type=simple ExecStart=/bin/sh -c '/usr/local/bin/f32_i16 7355 7455' WorkingDirectory=/home/dragnet Restart=no User=dragnet [Install] WantedBy=multi-user.target Sample for airband.service [Unit] Description=SDR AM/NFM demodulator Documentation=https://github.com/charlie-foxtrot/RTLSDR-Airband/wiki Wants=network.target After=network.target # Dependencies: # RTLSDR-Airband binary is assumed to be in /usr/local/bin # The configuration file is assumed to be in /usr/local/etc/rtl_airband.conf [Service] Type=simple ExecStart=/usr/local/bin/rtl_airband -Fe -c /usr/local/etc/rtl_airband.conf WorkingDirectory=/mnt/sftp/ve3nrt # Bumping the dongle sometimes causes a read failure which will cause the program # to exit. Tell it to restart, with a small delay in case of presistent failure. Restart=always RestartSec=60 User=ve3nrt [Install] WantedBy=multi-user.target Sample for aprs.service (direwolf). You will need to create the airband directory in /var/log with permissions the program can access, or put the file somewhere else. [Unit] Description=AX.25 APRS Packet Monitor on port 7455 & 7456 Wants=network.target After=network.target [Service] Type=simple ExecStart=/bin/sh -c '/usr/local/bin/direwolf -t 0 -c /usr/local/etc/aprs.conf >> /var/log/airband/aprs.log' WorkingDirectory=/home/dragnet Restart=no User=dragnet [Install] WantedBy=multi-user.target

I've been using RTLSDR_Airband with Direwolf for APRS for some time now. Originally I tried converting the socket output from Airband from f32 to i16 and sending the output to another socket for Direwolf to read, but couldn't get it to work. I abandoned that idea and sent the converted output to stdout instead and it worked perfectly. Recently though, I added the ISS to my receive list in Airband, and that worked nicely as well, and I pick it up every day or so. I I though it would be nice to use 1 Direwolf instance to handle both APRS sources, so I have resumed work on socket output from the conversion program and socket input to Direwolf. I now have it to the point where the Direwolf opens the socket successfully and says it is listening. The problem is no decodes. However, if I listen to the socket with netcat and pipe the output to Direwolf stdin, it works. This uses 7358 as the output port from the converter. When I run Direwolf like this: direwolf -a 10 -r 16000 -n 1 -b 16 -B1200 -t 0 UDP:7358 I get. Dire Wolf version 1.7 Includes optional support for: hamlib cm108-ptt dns-sd Reading config file /home/dragnet/direwolf.conf Audio input device for receive: UDP:7358 (channel 0) Audio out device for transmit: default (channel 0) Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 16000 sample rate, DTMF decoder enabled. Note: PTT not configured for channel 0. (Ignore this if using VOX.) Disabled AGW network client port. DNS-SD: Avahi: Announcing KISS TCP on port 0 as 'Dire Wolf on airband' DNS-SD: Avahi: Service name collision, renaming service to 'Dire Wolf on airband #2' DNS-SD: Avahi: Announcing KISS TCP on port 0 as 'Dire Wolf on airband #2' DNS-SD: Avahi: Service 'Dire Wolf on airband #2' successfully registered. ADEVICE0: Sample rate approx. 8.0 k, 0 errors, receive audio level CH0 34 Note the last line. It doesn't matter which sample rate I choose, it always says 8.0k, and doesn't decode. I have also tried 1.8A & 1.8D, which are no different. This is what I get when I use netcat as an intermediary. netcat -u -l -p 7358 | direwolf -r 16000 -a 10 -n 1 -b 16 -B1200 -t 0 - Dire Wolf version 1.7 Includes optional support for: hamlib cm108-ptt dns-sd Reading config file /home/dragnet/direwolf.conf Audio input device for receive: stdin (channel 0) Audio out device for transmit: default (channel 0) Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 16000 sample rate, DTMF decoder enabled. Note: PTT not configured for channel 0. (Ignore this if using VOX.) Disabled AGW network client port. DNS-SD: Avahi: Announcing KISS TCP on port 0 as 'Dire Wolf on airband' DNS-SD: Avahi: Service name collision, renaming service to 'Dire Wolf on airband #2' DNS-SD: Avahi: Announcing KISS TCP on port 0 as 'Dire Wolf on airband #2' DNS-SD: Avahi: Service 'Dire Wolf on airband #2' successfully registered. Digipeater VA3BAL-4 audio level = 35(10/8) |||||_|__ [0.2] VE3GIF-2>APDW17,VA3BAL-4*,DISCVR:}VA3VWX-13>APRS,TCPIP,VE3GIF-2*:@091753z4337.37N/07929.87W_288/008g015t033r000p000P000h76b10204.DsVP Weather Report, WEATHER Station (blue) Use of "APRS" in the destination field is obsolete. You can help to improve the quality of APRS signals. Tell the sender (VA3VWX-13) to use the proper product identifier from https://github.com/aprsorg/aprs-deviceid N 43 37.3700, W 079 29.8700 wind 9.2 mph, direction 288, gust 15, temperature 33, rain 0.00 in last hour, rain 0.00 in last 24 hours, rain 0.00 since midnight, humidity 76, barometer 30.14, ".DsVP" Opening log file "2025-02-09.log". Digipeater VA3BAL-4 audio level = 35(10/8) _|||||___ [0.3] VE3GIF>APK102,VA3BAL-4*,DISCVR:=4345.72N/07911.10W_234/011g t031r000p000P h82b10195KDvs<0x0d> Weather Report, WEATHER Station (blue), Kenwood D710 N 43 45.7200, W 079 11.1000 wind 12.7 mph, direction 234, temperature 31, rain 0.00 in last hour, rain 0.00 in last 24 hours, humidity 82, barometer 30.11, "KDvs" ADEVICE0: Sample rate approx. 16.0 k, 0 errors, receive audio level CH0 52 That is, not only does it report the correct sample rate, it decodes just fine. Any ideas? Or is it time for a bug report? 73, Chris

I have an RTL-SDR receiver I use for monitoring ACARS, and APRS. I am interested in monitoring just for fun other signals on the uhf/vhf bands. I have an OMNI X scanner antenna up pretty high so I get decent reception. I live close to a large metropolitan area. There is an industrial area where there are ships and barges. APRS is kind of boring, but ACARS is interesting. I have used in the past my dongle with DSD plus and SDR Trunk for monitoring the state communication system. DSD Plus is too unwieldy to use. But I like SDR Trunk. Anyway what other entities are possible to configure to listen to? i use MX Linux.

Does anyone know if it is possible to add a JSON Post output to Direwolf. In addition to saving the GPS data to a logfile I would like to also send the data to a website. The preferred delivery to the website is JSON POST. Jakob

Hello again to the group! I start Direwolf via cron with dw-start.sh. I’d like to add -dgt to the startup command. My question is, which line (number) do I add -dgt to? Thanks in advance for any replies. Doug AE9DM

Where is ISOTIME derived from in the Direwolf logfile? Is this time info received from APRS messages or is it a timestamp added to the log derived from the local time on the PC running Direwolf?