Its the UDP sink. If I use File Sink to a named pipe file multimon-ng can decode it by using cat pipe | multimon-ng -Aq - but if I use the UDP port and netcat -ulk localhost 8000 | multimon-ng -Aq - it doesn't decode, so the resampler does work but somewhere in the UDP channel something corrupts the data
On Sun, May 19, 2019 at 1:50 AM Kevin Reid <kpr...@switchb.org> wrote: > > On Sat, May 18, 2019 at 12:07 AM Albin Stigö <albin.st...@gmail.com> wrote: >> >> You need to use a low pass filter (taps) in you resampler. Look at the >> spectrum after the resampler and this will be obvious to you. A lowpass >> filter with a cutt off at 3-4kHz or so should do it. > > > This cannot be the problem, because rational_resampler automatically > calculates a filter if taps are not specified: > https://github.com/gnuradio/gnuradio/blob/4e4f44c726556496c420bceb87ccafe6843916f7/gr-filter/python/filter/rational_resampler.py#L107 > > (I also checked the GRC file, and the fractional bandwidth is also None > (auto-set) despite appearing as "0" in the screenshot.) > > Unfortunately, I don't have any ideas what the problem is. For what it's > worth, I have successfully integrated multimon-ng into a flow graph > (https://github.com/kpreid/shinysdr/blob/master/shinysdr/plugins/multimon.py) > but the code is very differently structured so it would be hard to transfer > the knowledge into GRC. > > As a next troubleshooting step I would recommend adding GUI sinks at various > parts of the flow graph so that you can check the signal integrity. (For an > example, consider adding after the float-to-short a short-to-float and QT GUI > Sink — to ensure the signal hasn't gotten lost in quantization noise and just > needs to be amplified before converting to short, as well as checking that > the bandwidth/resampling is good.) _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
