19 Sep
2013
19 Sep
'13
4:09 p.m.
Ok, what kind of excuse can I make up for such a stupid reply?
Anyway, I read in some blog post about DC-offset issues when piping data
between mulitimon and rtl_fm. The author claimed to fix the problem by
adding a pole-zero filter inbetween. So it a surpirse to read about using
the programs without removing DC.
Could the new version of rtl_fm apply some offset that previously was not
preset?
It might be possible for you to compare the outputs to get a better
understaning of why your commande pipeline hase ceased to work.
Olof
2013/9/16 Ewan Meadows <ewan.meadows(a)gmail.com>
The problem is with the recent changes to rtl_fm, as I
can roll back
to the commit before scanning was fixed and it works fine.
On 16 September 2013 17:43, Olof Tangrot <olof.tangrot(a)gmail.com> wrote:
I am not sure this is the right list for bug
reports for multimon-ng.
There
is a tracker on github where it is possible
submit issues though.
Hi all,
I've been using rtl_fm piped into multimon-ng for a while now which
has been working pretty well for decoding POCSAG, I use this command
line:
rtl_fm -f 153.350M -r 22050 - | ./multimon-ng -t raw -a POCSAG512 -a
POCSAG1200 -a POCSAG2400 -f alpha -D pocsag.db -
I updated rtl_sdr today and now all I get is junk decodes
POCSAG2400-: Address: 1318769 Function: 255
POCSAG2400-: Alpha: KA^MA
POCSAG1200-: Address: 1700218 Function: 255
POCSAG1200-: Alpha: )"<DLE>'f
POCSAG1200-: Address: 143961 Function: 255
I rolled back to an earlier version using git checkout commit and it
appears the following commit broke it:
c4fcfbb46e0a432902a2b78db4951bd20f68b9b2
Commit 8c3a99c8f7a88d7d2a05845d4b20cfcdacac4054 works fine, whereas
the commit after causes multimon_ng to spit out garbage :-(