IF tap sync support and example #1422
Conversation
|
The build failures are unrelated to your changes. I pushed fixes to the master branch. |
…e control. This commit is intended to support SDRs used as an IF Tap in an existing radio, such as https://github.com/rfrht/FT991A-PAT
| * Updating the widgets causes setNewFrequency to be called, so a remote control | ||
| * client has to set both lnb_lo and the filter offset to zero first. | ||
| * Perhaps that's all that needed to be done in the first place, but for now this | ||
| * works perfectly to support an sdr attached to an IF tap being used as a panadapter. |
There was a problem hiding this comment.
This sounds ugly. Is there a way to make this work better?
There was a problem hiding this comment.
It is ugly. Just like me. 👴 - Thanks for looking at it regardless.
Probably! In the context of this repository: I have no idea what I'm doing. That's why I asked for a contribution guide! 🙂
Once I have some fresh eyes, I will look at it again. I was just happy that it worked for me, finally.
Do you have an opinion on how that should be implemented instead?
I am not used to the github culture - I suppose a 'draft PR' would have been better - as I am not 100% certain how each element of the features I want to make should be implemented, mostly because of a 'forest for the trees' sort of situation where I only have so much time in the day to study and understand a repository. Looking back it's obvious: a PR means "This code is ready and can be merged now, in the author's opinion."
Some thoughts I have thought about over the last few days:
-
Maybe there is a more fundamental architectural problem in Gqrx? Why does updating the widgets cause a signal to be sent to setNewFrequency again (if the functions that send the signals are called from there to begin with?) - if they really are supposed to update the UI? Aren't Qt signals and modules meant to reduce the interdependence of sections of code and make it more managable?
-
How much of a role should be placed on an external script communicating via a socket vs just implementing the logic in the program as a feature?
-
Why am I so dumb?
But it's more likely that I, again, don't understand how it's written. I was happy I was able to get it to work, but would also like to learn how to work together in a repository.
I'll look at it again with fresh eyes later. At the very minimum, at least knowing the current hardware frequency is absolutely required for making a feature like this work - but I'd rather it feel like less of a "hack" and more of a "well designed feature" - I'll get back to you sometime soon.
There was a problem hiding this comment.
I am not used to the github culture - I suppose a 'draft PR' would have been better
Draft makes sense if you're still planning to do some further work or cleanup, and want to get some early feedback on your work-in-progress. Anyway, it doesn't matter too much for a small project like Gqrx where it will be clear from the discussion thread whether the code is ready for a final review.
Maybe there is a more fundamental architectural problem in Gqrx?
There are definitely architectural problems in Gqrx. It's a hobby project that has been developed over time by volunteers whose specialty is signal processing and not software engineering.
Why does updating the widgets cause a signal to be sent to setNewFrequency again
To be honest, I don't know Qt that well. The changes I have made since taking over as maintainer have mostly been small enough that I've been able to copy over existing patterns.
I do know that signals can be temporarily blocked, if necessary, with blockSignals, and Gqrx does this in various places.
How much of a role should be placed on an external script communicating via a socket vs just implementing the logic in the program as a feature?
Good question. Both are possible, and each option has different advantages and disadvantages.
Building in a new feature requires ongoing maintenance and testing. It makes sense to do that if the feature will be used by a large enough subset of users, and there is someone willing to keep the feature maintained.
Do you have an opinion on how that should be implemented instead?
I don't. But I do expect that one way or another the limitations on gqrx_set_hw_freq could be removed, thereby making the command easier to use.
There was a problem hiding this comment.
I spent some time looking at it again. Without significantly restructuring how Gqrx handles its UI update methods, as a very major refactor that would require strongly separating the UI from IO (a good idea - just well beyond this PR's scope and somthing that I don't think any of us have time for), I think my commits are the most reasonable compromise to get the desired IF tap panadapter functionality to Gqrx, with the least amount of changes to Gqrx, meaning the least amount of 'messing' with how Gqrx works internally, and provides a working example with reasonable inline documentation for those who would desire this feature for their own radios. It may not be very many people who have my use case, but I will share with sdr-kits that it's a possibility with Gqrx, if merged.
Additionally, I was looking at the open PR history - and there are a lot of really cool PRs! But most significantly change how Gqrx works internally, and are unlikely to be merged because of both that by itself, relatively poor internal documentation, and relatively poor (at least publically facing) communication with maintainers.
Naturally I'd rather just provide this feature WITHIN Gqrx with no need for an external interpreted script - but the archetecture of Gqrx is too delicate to permit it without major refactor, in my brief experience with the program and my own experimentation over the last year or so. Without authoritative guidance for future development, the reasonable default is to make as little of changes as possible, in the same spirit and style as what already exists.
At this time, I think it's reasonable to have most of the work done in the script, although I certainly agree that gqrx_set_hw_freq should just do what it says on its face and feel less hacky... - it also currently has documentation to say what needs to be done first to be deterministic.
TL;DR: I don't feel comfortable messing too much with how Gqrx works internally to support this feature when an external script and some inline documentation work fine to do the job.
There was a problem hiding this comment.
What do you think about enabling the "discussions" feature for this repository, so something like a documentation of the existing gqrx repository can be analyzed and broken down into functional descriptive sections?
This adds preliminary support for synchronizing the frequency labels in Gqrx with the dial frequency of a radio much like HDSDR does: https://sites.google.com/site/g4zfqradio/hdsdr-if-pano/#h.fo3d1pm8gecj
This has been an unsolved problem for about 8 years, and the existing remote control interface did not give enough control to the user to manipulate the device's hardware frequency. Now, the tuning frequency can be locked to the IF frequency, and the dial frequency of the radio can be accommodated for by modifying the LNB LO (although this is an inelegant solution).
This has been tested only with a FT-991/A and a hackrf, but it should work with most IF taps and SDRs, as long as they modify the working example at ./resources/gqrx-panadapter-ft991a.py with the quirks of their radio.
This implementation isn't perfect, and I would rather just support it directly in Gqrx by having it talk to a rigctld socket, and do the logic internally, but I am not experienced enough yet with QT signals and how Gqrx uses them. Maybe in the future I will tackle this, and basic transceiver control (tune radio to signal of interest on SHIFT+CLICK?)