开云体育

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

Perplexity just solved a long-term problem that I was having with Direwolf 1.7 in Win11, shutting down any time the HDMI monitor was turned off. Numerous searches using Google did not pay off, but the first time I used Perplexity this is what solved it: System > Sound > Properties > HDMI: Don't Allow Go into sound settings, select HDMI, and choose "Don't Allow Windows or Apps to use this Device". Interestingly, using Device Manager and selecting "Disable this Device" did NOT work, so I re-enabled HDMI in Device Manager, and did what Perplexity suggested, and it worked. To double check, I went back in Device Manager to Sound Devices > HDMI , and it was enabled, so it appears the Sound settings do not affect the Device Manager setting. Now when I shut off the hdmi monitor, the Direwolf app is minimized (not by me), but it is STILL RUNNING, and the mapping application (APRSIS32) has changed windows size, but still getting data from Direwolf. I had been looking for a solution for months! Thanks to AA6YQ, Dave for pointing to Perplexity. 73, N0AN

Hi all, after I got resolve the audio device problems with my configuration thanks to the members of this group now I'm trying to work with decoding and coding with APRS. For this purpose I use an AnyTone AT878UVII-Plus which is capable to receive and transmit APRS frames. In summarize I can transmit "APRS sounds" with my Yaesu FT-847 and I can hear them in the AnyTone and them can be decodified. Contrary I transmit APRS with the AnyTone that the FT-847 can receive but Direwolf not decodify it. I also usually use the FT-847 in SSB FT8 modes succesfully. I'll try to detail the devices and configurations chain next: · Yaesu FT-847: - RF PWR: about 10% - SQL: open - RF selector: about 40% - Modulation: FM (I don't know if NAR mode should be selected) - Menu #23 (FM Packet Baud Rate): 1200 - Menu #37 (CAT Data-Transfer Baud Rate): 57600 · A homemade connection box between FT-847 and Yaesu SCU-17 as follows: - A stereo jack to FT-847 DATA IN/OUT rear connector - A stereo jack to SCU-17 PTT FSK - A stereo jack to SCU-17 AUDIO IN OUT This works fine for me in HF SSB modes like FT8, FreeDV and other. The constructive details can be found here in japanese but the diagram can be perfectly understood: https://www.iyo.ne.jp/tamai/oa-04/oa-04-04/oa-04-04-03/index.html Anyway I think this box be only used in APRS HF modes and to do PTT in other way in this case. · Yaesu SCU-17: - PTT FSK stereo jack connected to the box - AUDIO IN OUT stereo jack connected to the box - CAT/RS-232C 9 pin connected to the CAT rear connector from FT-847 - DATA miniDIN 6 pin connected to the PKT rear connecto from FT-847 (I think this connection is mandatory if PACKET/APRS is made in FM mode) - USB to the computer · Computer: - Linux Debian Testing x64 with the commonly software and sound and USB controllers working fine - Direwolf 1.7 from Debian official repositories with the next basic config: ADEVICE plughw:CODEC,0 ACHANNELS 1 CHANNEL 0 MYCALL EA4GRG-10 MODEM 1200 PTT /dev/ttyUSB1 DTR RTS # Ports used by other applications AGWPORT 8000 KISSPORT 8001 # Test beacon. Commented when other applications are used PBEACON delay=0:30 every=1:00 overlay=S symbol="digi" lat=38^59.71N long=1^52.14W power=5 height=10 gain=4 comment="EA4GRG-10 IM98bx" via=WIDE1-1 TXDELAY 30 TXTAIL 15 - Another software I use: YAAC, Xastir - Sound levels are adjusted by QasMixer or alsamixer utilities · AnyTone AT878UVII-Plus: - APRS type: analog - Push PTT: off (when it gets GPS it launchs an APRS frame every 60 seconds) - Signal route: WIDE1-1,WIDE-2-1 - All analogic APRS filters are ON - TX power: low (both FT-847 antenna and AnyTone are a few meters length each other). - Tuned with a created APRS channel to 144.800 MHz Operating: - I start direwolf from Linux. Every 60 seconds the AnyTone receives APRS and decodifies it fine. - When AnyTone gets GPS data it transmits every 60 seconds. I can hear "APRS sounds" in FT-847 but direwolf doesn't decodified anything. Also I try with "arecord -D plughw:CODEC,0 /tmp/audio.wav" and I can record the APRS sounds fine. Has anybody a similar configuration like me? What am I doing wrong? Thanks in advance. Regards.

Here's a strange one. I have a Raspberry Pi 4 running Raspbian OS Lite 64-bit. I have my Icom 705 plugged into it and have it setup as a digipeater. That part works fine. The GPS is what isn't working inside of Direwolf. When Direwolf first loads, it gets a "No location fix" from GPSD. Then I get the dwgpsd timeout error as seen below. However, as soon as I run cgps -s, Direwolf shows "Location fix is now 3D". It's like something needs to trigger it before Direwolf can see it. Here is the Direwolf log. Reading config file /home/pi/direwolf.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. Hamlib determined CAT control serial port rate of 19200. Ready to accept AGW client application 0 on port 8000 ... Ready to accept KISS TCP client application 0 on port 8001 ... DNS-SD: Avahi: Announcing KISS TCP on port 8001 as 'Dire Wolf on pi-aprs' GPSD: No location fix. DNS-SD: Avahi: Service 'Dire Wolf on pi-aprs' successfully registered. ------------------------------------------ dwgpsd: Timeout waiting for GPS data. Is GPSD daemon running? Troubleshooting tip: Try running cgps or xgps. ------------------------------------------ As soon as I run cgps -s, Direwolf sees GPSD. GPSD: No location fix. GPSD: Location fix is now 3D. Here is my /etc/default/gpsd file. START_DAEMON="true" USBAUTO="true" DEVICES="/dev/ttyACM1" GPSD_OPTIONS="-n" Here is my /home/pi/direwolf.conf file. CHANNEL 0 MYCALL K9SWX-1 MODEM 1200 AGWPORT 8000 KISSPORT 8001 ADEVICE plughw:1,0 GPSD localhost PTT RIG 3085 /dev/ttyACM0 DIGIPEAT 0 0 ^WIDE1-1$ ^WIDE1-1$ TBEACON delay=00:05 every=30:00 symbol=1# via=WIDE2-1 power=5 height=5 gain=3 comment="Portable WIDE1-1 digipeater" Any thoughts? Thanks! Stan

I'm rebuilding a RPi 4 system and got a strange error when exiting DW. I'm running a RPi 4 Bookworm 64-bit/No Desktop Fresh compile of DW 1.8D as of today (5/26/25). Here is my startup (a few beacons), exit (tons of errors) and at the bottom is my config file: Dire Wolf DEVELOPMENT version 1.8 D (May 26 2025) Includes optional support for: gpsd cm108-ptt libgpiod Reading config file dual.conf Audio device for both receive and transmit: plughw:drig1,0 (channel 0) Audio device for both receive and transmit: plughw:drig2,0 (channel 2) Channel 0: 2400 bps, QPSK, PQRS, 48000 sample rate, Tx AX.25, compatible with MFJ-2400. Channel 2: 9600 baud, K9NG/G3RUH, +, 48000 sample rate x 3, Tx AX.25. The ratio of audio samples per sec (48000) to data rate in baud (9600) is 5.0 Increasing the sample rate should improve decoder performance. Ready to accept AGW client application 0 on port 8000 ... Ready to accept KISS TCP client application 0 on port 8001 (radio channel 0) ... Ready to accept KISS TCP client application 0 on port 8021 (radio channel 2) ... Virtual KISS TNC is available on /dev/pts/1 Created symlink /tmp/kisstnc -> /dev/pts/1 [0L] N1OBU-1>APDW18,WIDE1-1:!4100.00N/07100.00W1PHG2030DW 1.8D Port 1 [2L] N1OBU-1>APDW18,WIDE1-1:!4100.00N/07100.00W1PHG2030DW 1.8D Port 2 [0L] N1OBU-1>APDW18,WIDE1-1:!4100.00N/07100.00W1PHG2030DW 1.8D Port 1 [2L] N1OBU-1>APDW18,WIDE1-1:!4100.00N/07100.00W1PHG2030DW 1.8D Port 2 QRT ^C?WATCH={"enable":false,"json":false}; Received frame queue is out of control. Length=11. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=12. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=13. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=14. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=15. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=16. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=17. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=18. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=19. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=20. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=21. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=22. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=23. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=24. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=25. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=26. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=27. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=28. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=29. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=30. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=31. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=32. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=33. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=34. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=35. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=36. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=37. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=38. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=39. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=40. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=41. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=42. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=43. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=44. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=45. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=46. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=47. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=48. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=49. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=50. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=51. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=52. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=53. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=54. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=55. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=56. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=57. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=58. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=59. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=60. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=61. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=62. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=63. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=64. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=65. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=66. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=67. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=68. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=69. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=70. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=71. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=72. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=73. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=74. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=75. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=76. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=77. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=78. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=79. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=80. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=81. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=82. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=83. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=84. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=85. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=86. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=87. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=88. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=89. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=90. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=91. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=92. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=93. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=94. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=95. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=96. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=97. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=98. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=99. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=100. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=101. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=102. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=103. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=104. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=105. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=106. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=107. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=108. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=109. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=110. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=111. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=112. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=113. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=114. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=115. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=116. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=117. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. Received frame queue is out of control. Length=118. Reader thread is probably frozen. This can be caused by using a pseudo terminal (direwolf -p) where another application is not reading the frames from the other side. ###CONFIG### # (Channel 0 + 1 if in stereo) # ADEVICE plughw:drig1,0 ACHANNELS 1 ARATE 48000 CHANNEL 0 MYCALL N1OBU-1 #MODEM 1200 E+ /3 MODEM 2400 V26B #MODEM 9600 TXDELAY 40 TXTAIL 5 DWAIT 5 SLOTTIME 10 PERSIST 64 PTT /dev/ttyDRIG1 RTS # (Channel 2 + 3 if in stereo) # ADEVICE1 plughw:drig2,0 ACHANNELS 1 ARATE 48000 CHANNEL 2 MYCALL N1OBU-1 #MODEM 1200 E+ /3 #MODEM 2400 V26B MODEM 9600 TXDELAY 40 TXTAIL 5 DWAIT 5 SLOTTIME 10 PERSIST 64 PTT /dev/ttyDRIG2 RTS # VIRTUAL TNC SERVER PROPERTIES # AGWPORT 8000 KISSPORT 8001 0 KISSPORT 8021 2 # FIXED POSIION BEACONING PROPERTIES # PBEACON sendto=0 delay=00:15 every=5:00 symbol=/1 lat=41^00.0000N long=071^00.0000W power=5 height=5 gain=3 comment="DW 1.8D Port 1" via=WIDE1-1 PBEACON sendto=2 delay=00:20 every=5:00 symbol=/1 lat=41^00.0000N long=071^00.0000W power=5 height=5 gain=3 comment="DW 1.8D Port 2" via=WIDE1-1

Hi members, I started to work on the IL2P CRC implementation. You may want to check it out here: https://github.com/leventelist/direwolf/tree/il2p_crc 73s de HA5OGL -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

Hi members, I have my simple BBS running, if someone is interested, you may check it out: https://github.com/leventelist/oglbbs Patches, PRs are welcome. 73s de HA5OGL -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

I started to develop a connection oriented BBS. Things on the AX.25 side started to work, but I want to have extensive testing. I use paracon as my terminal using the AGWPE interface. My question if it is possible to loop back my BBS and paracon without getting on air? My obvious solution would be to run two direwolf instances and somehow route the audio back and forth, but I'm very lazy doing that. I tried connecting to direwolf from my BBS and paracon, but they did not find each other. Thanks, HA5OGL Lev -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

All, If I see a value for audio level as in the packet below, does this mean that the station was heard directly by my digi-peater? The packet above the one with the audio level seems to have originated from the internet. [ig>tx] MB7URG>APRX28,TCPIP*,qAC,T2CZECH:T#353,11.1,0.7,51.0,4.0,3.0,00000000 i/180 returns FALSE for not an APRS 'message' Packet filter from IGate to radio channel 0 returns FALSE MB7URG audio level = 80(16/10) _____|___ [0.5 20:05:2025Y:-:08:24:24] MB7URG>APRX28,TRACE1:T#353,11.1,0.7,51.0,4.0,3.0,00000000 Telemetry, >40 APRSmax Seq=353, A1=11.1, A2=0.7, A3=51.0, A4=4.0, A5=3.0, D1=0, D2=0, D3=0, D4=0, D5=0, D6=0, D7=0, D8=0 The reason for asking is that I see a lot of similar activity in the Direwolf terminal window but these stations never seem to appear in my 'Stations heard directly by MB7UEY' listing on the aprs.fiwebsite. MB7UEY is my digi-peater. Tom.

I have autostarted Direwolf with sytemD by following the instructions at https://www.f4fxl.org/start-direwolf-at-boot-the-systemd-way/ Everything is working fine and I would recommend it. But, I am studying the method and I've been through a couple of youTube tutorials on systemD and tmux so I have a general idea of what is happening. But I'm not exactly sure of sequence of events for tmux role in direwolf.system. This is the line in question: ExecStart=/usr/bin/tmux new-session -d -s direwolf '/usr/local/bin/direwolf -c /home/clubadmin/direwolf.conf' It looks to me that a new session (-s) is started and everything inside of the single quotes (') is executed. My goal here is to write some systemD service files for other programs and I need to be sure of the syntax. In particulate the roll of -d, -s and the command path. Thanks Dave WB9TEN

Is it possible to add a comment to the weather? I cannot use comment and COMMENTCMD in the same beacon Ian, VE3EP

Well, several years ago I went through this but cannot recall the fix. Direwolf startup recognizes Log file is "~/direwolf/direwolf.log" However no log is written. Thanks for any feedback

Good day When using DIREWOLF for KISS with BPQ32, should I set the KISS options in BPQ or DIREWOLF? Thank you

Does anyone currently work on the optional CRC of IL2P? If not, I might try to implement it.

I started playing with DW, and things are working. At least I can decode some HF traffic. I wanted to try out IL2P, and read through the documentation. I have a few questions: Does DW implement all L1 suggested bt IL2P v0.6 spec, like QPSK and PSK? Do you know any BBS or other station I can test with? I use DW 1.7 Thanks and 73 de HA5OGL -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

I have reviewed the many posts on this subject but did not find anything that has worked in my case. Running Mac OS 15.3 Installed Mac Ports Installed Direwolf, building from source. I installed the latest developmental version (1.8 D (April 26, 2025) In config file, set Adevice to "USB audio device" Set PTT CM108 Run dire wolf, get error: Config file line 152: PTT with CM108 is only available when USB Audio GPIO support is enabled. You must rebuild direwolf with CM108 Audio Adapter GPIO PTT support. Also, I did make the file 99-direwolf-cmedia.rules and placed it in /etc/udev/rules.d/ Inside the file was the line: SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0d8c", GROUP="audio", MODE="0660" From another post, changed this line to SUBSYSTEM=="usb", ATTRS{idVendor}=="0d8c", GROUP="audio", MODE="0660", SYMLINK ="cm108_0" No change in error message for either case. If PTT not enabled, direwolf works fine and decodes packets. I can interface it to the QTH app and it works fine. (Somehow, QTH app can key the transmitter, even though dire wolf has no PTT configured) After all that, what am I not doing to get dire wolf to use CM108 for PTT? Larrie AF7NU

Good morning Anyone ran across this? KISS SEND - Discarding message because no one is listening. This happens when you use the -p option and don't read from the pseudo terminal

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.

Good evening It's been a while since I've used Direwolf - I am using Linux and a Signalink...Trying to jog my memory about the following: Here is one example: N901EN audio level = 118(10/9) ||||||___ Audio input level is too high. Reduce so most stations are around 50. [0.2] N901EN>APT314,WIDE2-1:/005326h3852.79N/08518.26W'008/080/A=002611|!l%p'd|!w0:! Is there something I need to do on my end?