Skip to content
New issue

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

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

Already on GitHub? # to your account

[Feature request] Basic TX support #1336

Open
AsciiWolf opened this issue Feb 12, 2024 · 1 comment
Open

[Feature request] Basic TX support #1336

AsciiWolf opened this issue Feb 12, 2024 · 1 comment
Labels

Comments

@AsciiWolf
Copy link
Contributor

AsciiWolf commented Feb 12, 2024

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!

@argilo argilo added the feature label Feb 12, 2024
@argilo
Copy link
Member

argilo commented Feb 12, 2024

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants