ha7ilm / openwebrx

Open source, multi-user SDR receiver software with a web interface
https://sdr.hu/openwebrx
GNU Affero General Public License v3.0
980 stars 462 forks source link

Adding Multimon-NG support #97

Open DanielCraig opened 6 years ago

DanielCraig commented 6 years ago

Multimon-ng decodes pager message traffic after the signal is fm demodulated. How much trouble would it be to add this as a feature? Edit: It could be an option similar to the DIG-BPSK mode, and could probably use the same text window to display output. It would require the multimon-ng dependency, an fm demoded signal passed to multimon-ng, and that output passed to the text box.

Edit: Trying to figure out the code flow, but I think I get it. The primary mod parameter, "mod", would be the already implemented NFM. Then, with a flow similar to the digimodes, there would need to be a "secondary_mod" and "cfg.multimon_enable" that redirects the data through the multimon-ng tools.

ha7ilm commented 6 years ago

Well, the secondary demodulator gets the I/Q data after downconversion and filtering (the BPF you set on the frequency scale). This means that you need to add the FM demodulator to the secondary chain as well (e.g. csdr fmdemod_quadri_cf)

DanielCraig commented 6 years ago

Ok, I've mixed in the wrong terminology. The FLEX/POCSAG pager signals only need to be NFM demodulated, and the multimon tool then decodes the messages. It should not need to be down converted. The pager traffic I've seen is in the 900MHz range. From what I gathered, you're using named pipes as "chains" to pass the sample date to various DSP routines. Is this correct? I should probably read your thesis :/

ha7ilm commented 6 years ago

Ok, I've mixed in the wrong terminology. The FLEX/POCSAG pager signals only need to be NFM demodulated, and the multimon tool then decodes the messages. It should not need to be down converted.

You need a downconversion if you want receive a signal which is not in the center of the waterfall diagram. You can find the block diagram of the channelizer in my BSc thesis paper.

ha7ilm commented 6 years ago

From what I gathered, you're using named pipes as "chains" to pass the sample date to various DSP routines. Is this correct?

Yes, I use named pipes, and also anonymous pipes, and sockets to build these chains. Somewhere in the BSc thesis you can find a block diagram that shows how various components of the system connect together. (The MSc thesis is only linked from my blog post by now, so I'm also putting it here so that you can find it easily.)

DanielCraig commented 6 years ago

Okay, so conceivably, I should be able to create a pipe for raw IQ data (or for NFM demoded data, in this case), and use that as an input to some other RTL software. Then, create another pipe to pass the data back to the OpenWebRx web interface (to the text box that comes up for the digital modes). This seems like a neat feature that would allow use of many RTL software tools that are available. The other one I am now thinking of is called rtlamr, for monitoring smart energy meters.

ha7ilm commented 6 years ago

Yes, it is possible. Another similar tool is rtl_433. (Some rtl_* tools don't work on an arbitary I/Q input, and/or stick to unsigned 8 bit input format. The latter can be solved by doing format conversion with csdr convert_f_u8, although that also means loss of dynamic range.)