开云体育

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

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?

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.