TX only with direwolf?

[budude2]

Is it possible to use direwolf as a TX only node with the onboard raspberry pi soundcard? When I try to run it it complains that it cannot open the audio port for input; this doesn't matter to me though because I don't care about input, I want output only.

[dranch]

While I think this would be technically possible and the idea has merit (would need code changes), Direwolf would have no idea if the frequency is in use. As such, it could very easily create packet collisions, interfere with ongoing packet QSOs, etc.

[budude2]

What about in a HAB case? It will be receiving so many stations that it would never end up transmitting. Thus, I need to ignore incoming packets.

[dranch]

Hmmm.. that's an interesting use case. I can't say I know what the RF reception up at say 80,000+ ft but I would hope you'd be using less busy frequencies (for example, NOT using 144.390 here in the US). Anyway, does seem like a viable use case to me though it would need a config option to allow for this within Direwolf. Alternatively, seems an ALSA device configuration could be created to fake having a microphone. Try this: https://www.raspberrypi.org/forums/viewtopic.php?&t=42285

[wb2osz]

You should be able to use either of these:

ADEVICE - default
ADEVICE udp:12345 default

Audio input would come from stdin or a UDP port. The demodulator would then just sit there waiting for input that never arrives. You don't want to use "null" for the input because it will provide zero bytes at an unlimited rate and the demodulator will devour all of the CPU time..

Let's leave this open as a reminder to go back and check for that case.

[dranch]

I think this is worth a clear mention in the documentation John for HAB (high altitude balloon) needs

[radar27]

One other thing to consider here would be the possible usage of the transmit inhibit option (TXINH). One could either wire up a line to some sort of COR/COS point within the radio to toggle a GPIO pin high or low when a signal is present, even if there is no actual audio input to run the decode. This would depend upon the signal breaking the squelch (and disabled CTCSS), which could possibly miss some, but it should decrease the chance of collisions considerably without requiring an actual audio input line. This is not readily available in most portable radios, but even a small line coming from a RX/Busy LED indicator would be sufficient.

[doctaweeks]

There should be an option to allow no audio device (i.e. TX-only mode) since:

It's not possible to use stdin and sanely background the process (closing stdin will cause direwolf to exit).

Using UDP leaves a wide-open port on a poorly configured system since it's not possible to bind to a loopback address (see #249).