Skip to content
This repository has been archived by the owner on Jan 13, 2020. It is now read-only.

Adding Multimon-NG support #97

Open
DanielCraig opened this issue Oct 4, 2017 · 6 comments
Open

Adding Multimon-NG support #97

DanielCraig opened this issue Oct 4, 2017 · 6 comments

Comments

@DanielCraig
Copy link

DanielCraig commented Oct 4, 2017

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
Copy link
Owner

ha7ilm commented Oct 5, 2017

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
Copy link
Author

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
Copy link
Owner

ha7ilm commented Oct 8, 2017

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
Copy link
Owner

ha7ilm commented Oct 8, 2017

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
Copy link
Author

DanielCraig commented Oct 11, 2017

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
Copy link
Owner

ha7ilm commented Oct 11, 2017

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

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

No branches or pull requests

2 participants