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

[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.

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

No branches or pull requests

2 participants