开云体育

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

Hello Everyone, Just as a heads up but Raspberry Pi OS Bookworm received a major update earlier this week which includes the Linux 6.6.20 kernel and many other changes: https://downloads.raspberrypi.com/raspios_arm64/release_notes.txt In this new OS update, the classic way of interfacing with GPIO pins has now been DEPRECATED and this breaks Direwolf v1.7 if you use GPIO pins to assert the PTT line to your radio, light up an LED with the DCD signal, etc. The solution was already committed to the Direwolf DEV branch back in November 2023 which will eventually become Direwolf v1.8. You can read up about that and how to both recompile DIrewolf and reconfigure your direwolf.conf file to use this new gpiod interface here: https://github.com/wb2osz/direwolf/issues/503 I'm happy to report things are working for me with this new code but I felt compelled to report this as this very disruptive change coming in the middle of the Bookworm OS lifecycle is going to create some pain for some people. I'm also updating my Raspberry Pi docs and automated build script later to day to reflect this change. --David KI6ZHD

I am using a temporary antenna, which I just raised to approximately 20'. However, there are two houses (mine and neighbor) with about 20' between the two "blocking signals". However I still hear the APRS warble in my FTM-500D. The only packets for the most part I am hearing is my VX-8G and a single other station that must have drove buy. Yesterday, I heard about 70 stations. After 1PM I heard nothing. I've turned on logging ( LOGFILE aprs.log) but haven't yet received anything of note. chan,utime,isotime,source,heard,level,error,dti,name,symbol,latitude,longitude,speed,course,altitude,frequency,offset,tone,system,status,telemetry,comment 0,1748982028,2025-06-03T20:20:28Z,KC2NJV-7,KC2NJV-7,7(1/1),0,`,KC2NJV-7,/[,40.656167,-73.522000,6.0,327.0,-13.0,,,,Yaesu VX-8G,Off Duty,,Join ARES and/or REACT and serve your community 0,1748982329,2025-06-03T20:25:29Z,KC2NJV-7,KC2NJV-7,7(1/1),0,`,KC2NJV-7,/[,40.656667,-73.522500,0.0,129.0,-12.0,,,,Yaesu VX-8G,Off Duty,,Join ARES and/or REACT and serve your community What else can I do? My conf file: ADEVICE 0 0 ACHANNELS 1 CHANNEL 0 MYCALL KC2NJV-10 MODEM 1200 PTT COM3 RTS AGWPORT 8000 KISSPORT 8001 PBEACON delay=1 every=2 overlay=S symbol="weather station" lat=40^39.40N long=073^31.19W commentcmd="powershell -command get-content wxnow.txt -tail 1" via=WIDE1-1,WIDE2-1 DIGIPEAT 0 0 ^WIDE[3-7]-[1-7]$|^TEST$ ^WIDE[12]-[12]$ TRACE IGSERVER noam.aprs2.net IGLOGIN KC2NJV-10 xxxxxxx <-passwod PBEACON sendto=IG delay=0:30 every=60:00 symbol="weather station" overlay=R lat=40^39.40N long=073^31.19W power=50 height=40 gain=3 comment="Bellmore, NY iGate" IGTXVIA 0 WIDE1-1,WIDE2-1 IGTXLIMIT 6 10 FX25TX 1 PERSIST 63 SLOTTIME 12 RETRY 5 FRACK 3 MAXFRAME 4 PACLEN 128 DWAIT 0 TXDELAY 25 TXTAIL 25 MAXV22 2 FULLDUP OFF LOGFILE aprs.log

Hello, Wondering if anyone out there that runs Windows 11 and direwolf/rig control would be able to point me in the right direction. I would like to be able to setup direwolf (along with rig control) to auto start at system boot. Windows 11 seems to like to update occasionally and then reboot, would be nice if things started up again. Thanks, -Chris KO4YAW

“APRS is a digital waveform used in amateur radio communication. An example of APRS in GitHub is called “DireWolf”. Can you create a version of APRS in ANSI C that runs in real-time on an ESP32-S3 device under the Arduino IDE? Suggest suitable ADC and DAC auxiliary devices.”

I was working perfectly, then something changed (or I changed it). I set Direwolf up as a weather station and iGate. If I turn on my VX-8G, Direwolf both receives and sends packets to the radio My beacons are: PBEACON delay=1 every=2 overlay=S symbol="weather station" lat=40^39.40N long=073^31.19W commentcmd="powershell -command get-content wxnow.txt -tail 1" via=WIDE1-1 PBEACON sendto=IG delay=0:30 every=60:00 symbol="weather station" overlay=R lat=40^39.40N long=073^31.19W power=50 height=40 gain=3 comment="Bellmore, NY iGate" via=WIDE1-1 Where did I go wrong? Thanks

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