argilo
commented
5 months ago I wouldn't be against adding some TX capabilities, but don't have any plans to work on it myself.
I did once build a basic transceiver using GNU Radio: https://github.com/argilo/contest-sdr
Unfortunately, what I found is that most SDRs and their associated drivers (with the exception of USRP) are built only with continuous transmit in mind; burst transmissions and T/R switching usually don't work well. Samples are often dropped from the start and/or end of a transmission, and buffered samples from the end of one transmission often reappear at the start of the next transmission. In contest-sdr I worked around that by padding transmissions with silence, but I had to manually adjust the amount of silence for each SDR, which was a pain. This also means that T/R switching is painfully slow for some SDRs.
Keeping latency under control in a GNU Radio flow graph can also be a challenge. (A possible solution: https://www.youtube.com/watch?v=jq0RewceCwc)
Most SDRs supported by gr-osmosdr / SoapySDR are also not really useful for over-the-air transmission out of the box, since they need external amplification, as well as filtering to remove harmonics.
So I certainly wouldn't place a high priority on adding TX support, but if someone wants to take a crack at it and has the patience to deal with poorly behaving hardware then go for it. If the code is maintainable and it performs well, then I would consider merging it.
I know that Gqrx is a RX (not TX) focused SDR software, however it could also be used as a basic TX SDR as well since it already supports multiple devices with TX abilities. Good start could be adding some basic AM/SSB and NFM modulators.
Feel free to close this ticket if you believe that it is not a good idea. :-)
Thanks!