开云体育

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'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?

Greetings, does anyone have insight into the current status of the ISS digipeater? https://ariss.org/current-status-of-iss-stations.html indicates the "Service Module radio" as configured and functional, yet the "Station List" at http://ariss.net/ shows no traffic for the past 11+ days, nor have I heard anything here. The Kenwood TK-762GH radio with CM108 is both Tx/Rx on 145.825 MHz. I thought direwolf 1.8D might be malfunctioning, but it works properly on 144.390 MHz. Can anyone verify ISS digipeater functionality, please?

Good day! I’m using a signalink with a mobile rig along with Direwolf. The OS is Linux Mint. I made good progress last night with the aprs setup but noticing “audio input too high” I’ve made some adjustments but wondering about your experience and advice for adjusting the audio input on the signalink and in Linux. Direwolf is great, btw.

Hi to all!!! I have an FT-991, an FT-897 and FT-817. The FT-991 have the built-in serial defunct (only the audio section is working) and I use an RS232 adapter connected to the DB-9 (GPS/CAT) connector on the rear. The other ones uses the original SCU-17 interface, that provide 2 Serials and the 2 audio devices. Is there a solution to use the CAT with Direwolf (for APRS or packet) instead the RTS?