search

wb2osz / direwolf

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
GNU General Public License v2.0
1.56k stars 305 forks source link

Txing with a busy channel. Wait for clear frequency #185

Closed Skinoku closed 5 years ago

Skinoku commented 5 years ago

I was using my station with your fine software and it works very well, but I can't figure out how to prevent it from transmitting when channel is busy, creating collision. I tried keeping squelch from transceiver open in order to delay TX for educational purposes but it still TX immediately any kind of packet, digipeating or iGate. Is it my fault (I have to change the config file) or there's an issue with DW? I'm running on windows latest stable release. Thanks

wb2osz commented 5 years ago

It shouldn't transmit when the channel is busy. Here is how to gather more information for troubleshooting. Use the "-d o" option on the command line. This will display status changes for the modem carrier detect (DCD) and the PTT signal. This will show whether they overlap. What does your configuration file look like? Did you change any of the default transmit timing parameters?

Skinoku commented 5 years ago

I tried with a fresh release of DW, with just audio ports setted up and on multiple PC with different soundcards, nothing fancy. It immediately pops up those two lines and nothing more also with busy channel. I tried hooking up a normal mike and shouting into it and it still prints those two lines and nothing more. Of course all the rest works fine, it decodes and TX packet with no problems. DCD 0 = 1 DCD 0 = 0 If I understand it right it should change DCD 1 when audio is detected and back to 0 when channel free, but it doesn't. After some times it prints two more lines all together like pasted before. Thanks

dranch commented 5 years ago

This isn't a bug so this Github issue should be closed and the conversation moved to the Direwolf Yahoo group at direwolf_packet@yahoogroups.com . Until then, this might help.

Define "channel busy" in your situation? Direwolf is designed to run on a dedicated packet frequency with your radio in open squelch mode where it's always listening. When it hears a valid packet radio preamble (aka. HDLC sequence), it changes the DCD (Data Carrier Detect) to "1". That means the frequency has become busy and it's AX.25 protocol engine is now going to try decoding the incoming packet. DCD does not represent that any "audio" is present and thus is disabling any possibility of Direwolf from transmitting.

If you're looking to have Direwolf run alongside other modes on a non-dedicated packet frequency, it can get very difficult. For example, maybe you're looking to have Direwolf run along side SSB or FM phone (aka spoke words). There are lots of pauses between spoke words, different speaking cadences, etc. that all can false trigger. There is the Direwolf TXINH configuration parameter described in the UserGuide that could be used with an external program to mimic what you want.

This could become very complex to both properly clone the incoming audio to both the program and Direwolf, avoid false positives from blocking Direwolf's TX, etc. as there is a LOT to consider here. For example, see:

https://web.cs.wpi.edu/~cs529/s15/projects/proj1/proj1.pptx

Here are some possible simple examples of how to detect silence:

https://unix.stackexchange.com/questions/384290/detecting-when-only-silence-is-being-played

--David KI6ZHD

Skinoku commented 5 years ago

Thanks a lot for help. I understood what you mean by channel BUSY and it's ok. The problem was probably that some stations were so over deviating and or weak that couldn't even trigger TX inhibition. Issue for me is closed. Cheers