| 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 |
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@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 :-(
>