Connecting GQRX and multimon-ng

[Robin Sheat]

Hi, I've been trying to get multimon-ng and GQRX to talk to each other so that I can have both running at the same time, one for browsing, one for decoding. So far I've had very limited success, and would like to know if anyone has any helpful ideas.

I'm using GQRX 2.3.1 (via Ubuntu PPA) and multimon-ng built from latest git, using an RTL.

I've been experimenting with POCSAG, and locally this works:

rtl_fm -f 157.950e6 -g 100 -s 22050 -l 310 - |./multimon-ng -t raw -c -a POCSAG512 -a POCSAG1200 -a POCSAG2400 -a SCOPE /dev/stdin

I've told GQRX to output to localhost, and try this:

nc -l -u 7355  |sox -r 48000 -t raw -b 16 -c 2 -e signed-integer /dev/stdin -r 22050 -t raw -b 16 -c 1 -e signed-integer - |./multimon-ng -t raw -c -a POCSAG512 -a POCSAG1200 -a POCSAG2400 -a SCOPE /dev/stdin

With this, multimon-ng shows some partial messages, but rarely the complete ones that it can see with rtl_fm. I have GQRX tuned to the same frequency.

I also tried saving as a .wav and running that through multimon-ng, but that caused it trouble (as in, spinning to 100% CPU.)

It might be of note that the waveforms when seen in the scope are a lot cleaner looking using rtl_fm.

Perhaps of more important note that when multimon-ng detects something via rtl_fm it's either POCSAG512/1200, but when it's via GQRX it's always POCSAG2400. This suggests to me that something is messing up the waveform, and it's just luck that it squeezes content out even when it's detected it wrong.

Anyone have any ideas?

Thanks, Robin.

[Alexandru Csete]

Hi Robin,

Perhaps the signal received in gqrx is too weak because the gain
setting in gqrx is not optimal. Try adjusting the device gai. Under
"Input control" try toggling the Hardware AGC and adjusting the gain
manually.

The best is probably to use HArdware AGC but in some cases this
setting is not restored between sessions and the initial gain is very
low.

Alex

[Robin Sheat]

Op zaterdag 15 november 2014 22:29:38 UTC+13 schreef Alexandru Csete:

The best is probably to use HArdware AGC but in some cases this
setting is not restored between sessions and the initial gain is very
low.

I've been using the hardware gain, and have found I need to toggle it on start to get good results. Manually playing with it made no change.

I took some screenshots of the scope, to show the difference in waveform. However (it's hard to tell for sure given they use POCSAG512 and 1024) it looks like there might be an issue with sampling rate somewhere.

What form does the data being sent to the UDP port come in? Maybe the sox params are wrong.

Thanks, Robin.

[Alexandru Csete]

Ho Robin,

The data is signed 16 bit int, little endian, one channel:
http://gqrx.dk/doc/streaming-audio-over-udp

Now I see that you used two channels in your sox line.

Alex

[Robin Sheat]

Op zondag 16 november 2014 13:19:59 UTC+13 schreef Alexandru Csete:

Now I see that you used two channels in your sox line.

Ah, good spotting :) (I had appropriated that sox line from somewhere else and guess I missed that bit)

With -c 1, it decodes properly, though the waveform is "mushier", this may be due to the conversion.

For anyone finding this thread, this is the command I'm now using:

nc -l -u 7355  |sox -r 48000 -t raw -b 16 -c 1 -e signed-integer /dev/stdin -r 22050 -t raw -b 16 -c 1 -e signed-integer - |./multimon-ng -t raw -c -a POCSAG512 -a POCSAG1200 -a POCSAG2400 -a SCOPE -f alpha  /dev/stdin

Thanks! Robin.

[Robin Gape]

There are two possible reasons for the difference in waveform shape:

1) a difference in received bandwidth, or in the slope of the skirts (the steeper the skirts, the more rounded the waveform), or both;

2) issues of group delay across the passband (not very relevant for speech, but vital where data is concerned). Generally, an FIR filter will not have group delay issues (unless it is asymmetric), but an IIR filter will. (That said, most SDR chains use FIR filters for simplicity, but this is not always the case.)

3) What really counts points is the eye diagram, and for that a "mushier" waveform is not necessarily a disadvantage.

Well done on getting it all working!

73,

Robin, G8DQX

[Robin Sheat]

Thanks for the keywords, I'll check them out and experiment some.

73 de ZL4TRS, though it's been a while since I was active :-)

Op zondag 16 november 2014 23:30:19 UTC+13 schreef Robin, G8DQX:

[Mohammad Bahathir Hashim]

Try to reduce the sampling rate. 1.5MS/s or less works best for most my need.

73,
9W2GNU

[Mohammad Bahathir Hashim]

After experimenting/testing the UDP audio streaming to use with DSD. I agreed with Mr. Robin Sheat findings. The gqrx's audio output somehow 'not accurate' enough to be decoded by DSD (in my case).


$ nc -lup 7355 | dsd -i - -w dsd.wav

On other terminal,
$ ffplay dsd.wav

I got lot's of 'miss'es or 'unknown protocol/uuid'  and only fragments of the audio is being decoded by the dsd. but, if I use

$ rtl_fm -f 420.7625M -p 6 -s 48k  | dsd -i - -w dsd.wav

I got a very good result and complete audio decoding.

Thank you.

73,
9W2GNU

[Alexandru Csete]

On Mon, Nov 24, 2014 at 3:51 AM, Mohammad Bahathir Hashim
<baha...@gmail.com> wrote:
>
> After experimenting/testing the UDP audio streaming to use with DSD. I
> agreed with Mr. Robin Sheat findings. The gqrx's audio output somehow 'not
> accurate' enough to be decoded by DSD (in my case).

You must turn de-emphasis off for FM-based digital modes (the tool
button right to the mode selector).

Alex

[Mohammad Bahathir Hashim]

Ok, there are 2 settings for the mode.
Max dev and Tau

I set Tau=OFF, and still not improving, for DSD. Not tested  with other signal decoding yet, such as multimon-ng.

Thank you.