search

gqrx-sdr / gqrx

Software defined radio receiver powered by GNU Radio and Qt.
http://gqrx.dk
GNU General Public License v3.0
3.02k stars 539 forks source link

Add support for external data decoders #100

Open csete opened 11 years ago

csete commented 11 years ago

Qt has a very nice option to interact with command line applications through stdin, stdout and stderr. We can take advantage of this and create a simple interface that can be used to interact with various data decoders, e.g. multimon-ng

vicendominguez commented 11 years ago

do you think it is possible to include the DSD???. Now it is a block of GNURadio: http://www.rtl-sdr.com/new-dsd-block-available-gnu-radio/

Thks...

Vicente

csete commented 11 years ago

No. This task is not about including any specific decoder. It is about providing a generic interface to use any decoder that works via stdin and stdout. People can then use that interface to whatever proprietary crap they want to use.

vicendominguez commented 11 years ago

Ok, thanks for answering Alex. Any possibility to include in other task? or is it discarded?

Thanks...

Vicente

csete commented 11 years ago

Vincente, I don't think so. I want to get rid of all internal decoders and not add new ones. Also note that with the interface described here, integration of external decoders will be seamless and a user will not even notice that it is an external application doing the decoding. The user will be able to store decoder configurations so it will practically be the same as an internal decoder.

vicendominguez commented 11 years ago

Ok buddy.

Thanks a lot for your dedication.... thank you very much for your good job!

Vicente

asdil12 commented 10 years ago

As a workaround until this is implemented, it is possible to set the input of any Pulseaudio capable software to Monitor via pavucontrol.

Still it would be nice to have (multimon-ng based) support for ZVEI and POCSAG like it is currently the case with AFSK1200.

csete commented 10 years ago

@asdil12 : It's already possible without having pulseaudio in the loop, check out: http://gqrx.dk/doc/streaming-audio-over-udp

alexf91 commented 6 years ago

I'm writing this here, because it's the issue referenced every time when someone requests a new decoder or plugins.

@csete @gat3way After reading yesterday's discussion in #573, I looked into Qt-Plugins. Apparently, Qt supports loading QObjects as plugins from shared libraries at runtime.

So far, I've implemented the minimum requirements necessary to load plugins and I've moved the AFSK1200 decoder into a plugin. It's far from stable, doesn't handle a lot of errors and is missing functionality to unload plugins or show windows after they are closed. It doesn't make writing extensions easier, but it provides a way to write decoders that are integrated into Gqrx.

The two plugins I've written are built together with Gqrx and can be loaded in the File-menu. One is the AFSK decoder and the other one just prints to stdout.

Plugins are located in the plugins directory, the current interface is defined in src/plugins. All other changes are in mainwindow.{h,cpp}.

Even if it's not going to get merged (at least not yet), I thought it's worth sharing.

https://github.com/alexf91/gqrx/tree/qt-plugins

csete commented 6 years ago

Thanks @alexf91, but I have already rejected the idea of using plugins like this in gqrx many years ago. I didn't feel that the gqrx architecture (including the many dependencies) was robust enough for this kind of extension. Unfortunately, I was right, so dynamic loading of shared object is out of the question. Not on my watch, anyway.

Note that the Qt-plugin framework is (probably) just a Qt-fied version of the more generic dlopen & co functions. Using the Qt framework would make sense for plugins that require the GUI but would be pretty hopeless to require Qt dependency for e.g. a decoder that doesn't really require anything else than stdlib, wouldn't you agree?

Anyway, I proposed a very simple method to interface with command line tools. It would require a minimal amount of design and implementation in gqrx, would be very robust and work with already existing programs like direwolf and freedv_rx. It wouldn't even matter which language the decoder is written in. People could write decoders in GNU Radio Companion and use the generated python program from within gqrx. Really simple and powerful.

alexf91 commented 6 years ago

Fair enough, but I had to try.

csete commented 6 years ago

By all means, please do experiment!

gat3way commented 6 years ago

I kind of like the approach of the AFSK1200 decoder really. It's not quite easy and it's not quite modular and I also don't like the idea of having bunch of decoding code just for the sake of it. On the other hand, as a user I really miss some quick stuff that could be done from inside gqrx (e.g the signal in question is transient and disappears long before you set up pipes, audio sinks and stuff). There are some other things that could integrate better with gqrx - such as decoding trunk control signals like e.g MPT-1327 or Motorola Type II and providing minimal support to follow calls. Not something complete like unitrunker, just basic. Anyway it got quite off-topic.