jopohl
commented
4 years ago Sounds like a useful addition to URH for me. I can give you some thoughts on how the integration should be done.
Since this is not really the core functionality I suggest you develop the RFQuack support as a plugin. You can find some examples for plugin development in src/urh/plugins.
On the backend side, it should not be too much of an effort, as you would just create urh.signalprocessing.Message objects from the received bits.
For GUI integration I suggest you design a custom dialog. You can use data/ui/send_recv_device_settings.ui and data/ui/send_recv.ui as templates (edit with QtDesigner). You can then place the custom dialog(s) directly in the folder of your plugin and render them at runtime (as done in the InsertSine plugin for example).
Is your feature request related to a problem?
I know there have been some attempts to propose an integration with non-SDR sources (e.g., CC1101). There's even an open issue #540, but no one has contributed yet AFAIK. I'd like to kickoff a discussion on how to concretely integrate post-interpretation sources (embedded radios can provide bitstreams directly).
Describe the solution you'd like
As one of the early developers of RFQuack, I'm pretty proud of the progress we're making (thanks to the current developer @Guglio95): we now have a uniform abstraction layer with a protobuf-based API transported over serial or MQTT, which can be used to configure the radio, put it into promiscuous mode, obtain a rough spectrum, etc. It's not like having an SDR, but close enough. In terms of configurability and parametrization, we have all sorted out and can do whatever we want with the radio (CC1101, RF69, nRF24L01). We can add more radios in the future, and have multiple radios, as RFQuack is modular (both hardware-wise and firmware-wise).
Here you can see a couple of demos (a new one is coming up soon):https://www.youtube.com/playlist?list=PL8hbvIylvVegA6ES-UUfd6sgK-MFNciz5
We're now ready to make the next step and start bridging RFQuack with existing solutions, among which URH is our to-go choice. What we'd like to do is the following:
The thing is that we have very little familiarity with URH's internals, but we'd like to start from somewhere. As in any mature project, the code base is quite big, so in addition to any comments you might have on the above, we'd like to have a couple of suggestions on where to start.