Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Skinoku opened this issue Dec 29, 2018 · 4 comments
Closed

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

Skinoku opened this issue Dec 29, 2018 · 4 comments

Comments

@Skinoku
Copy link

Skinoku commented Dec 29, 2018

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
Copy link
Owner

wb2osz commented Dec 30, 2018

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
Copy link
Author

Skinoku commented Dec 30, 2018

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
Copy link
Collaborator

dranch commented Dec 30, 2018

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
Copy link
Author

Skinoku commented Feb 21, 2019

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

@Skinoku Skinoku closed this as completed Feb 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants