[Discuss-gnuradio] NetBSD GNU Radio 2.8 packages
G'day, NetBSD users may be interested to learn that GNU Radio 2.8 modules are now available from the NetBSD Packages Collection (pkgsrc). I'm currently working on getting ham/gnuradio-audio-jack and ham/gnuradio-audio-portaudio. There are some issues that I need to resolve before they can be submitted. 73, Berndt VK5ABN pgpMrCTkVuKhO.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make check in gr-atsc fails
G'day, Is make check in gr-atsc know to complete? It currently fails to complete with the following message. Making check in python make check-TESTS ... sched: gr_block atsc_viterbi_decoder (31) is requesting more input data than we can provide. ninput_items_required = 12 max_possible_items_available = 7 If this is a filter, consider reducing the number of taps. F == FAIL: test_loopback_003 (__main__.qa_atsc) -- Traceback (most recent call last): File ./qa_atsc.py, line 207, in test_loopback_003 self.assertEqual (expected_result, result_data) AssertionError: (71, 65, 38, 46, 28, 211, 28, 167, 63, 183, 65, 28, 239, 239, 22 6, 99, 85, 148, 139, 146, 28, 205, 9, 120, 44, 4, 200, 122, 9, 97, 122, 232, 45, 207, 16, 221, 21, 138, 45, 198, 48, 16, 94, 23, 254, 34, 245, 128, 39, 191, 67, [...] -- Ran 4 tests in 4.144s FAILED (failures=1) FAIL: run_tests === 1 of 1 tests failed === *** Error code 1 cheerio Berndt pgpgT3a2LmnMz.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] undefined symbols, causes?
On Fri, 2006-04-28 at 15:16 -0400, Ilia Mirkin wrote:
Usually when something like this happens, you have some versioning problems
between interfaces. And indeed your files reveal this:
.h:
atsc_fpll_sptr atsc_make_fpll();
.cc:
atsc_fpll_sptr atsc_make_fpll(double a_initial_freq) { ... }
You need to figure out which interface is the right one, and use that.
Ok, changed all to atsc_make_fpll() and that works.
Ideally it would take an argument for initial_freq but I'll sort that
out 'later'.
Tks
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] undefined symbols, causes?
On Fri, 2006-04-28 at 15:16 -0400, Ilia Mirkin wrote: You need to figure out which interface is the right one, and use that. In small repayment for your assistance, here's two screenshots. First is a local station live off the air, in 20MSps float centered on 5.75Mhz: http://webpages.charter.net/cswiger/wchs_fc5.75.jpg and the same after FPLL processing in gnuradio 2.x : http://webpages.charter.net/cswiger/wchs_fc0.jpg with the mixer image not yet filtered out. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] inputs with different samplerates
Hi all, Is there any way for a block to process two signals at different samplerates? In my work for videodemodulation and synchronisation with gnuradio I need to process two versions of the data in the same block. I need the original samplestream at 8 MSPS. I also need a decimated/lowpassed version of the same signal at a much lower samplerate. I can't connect the original and the decimated version to the same block can I. The only thing I can do is leave out the decimation, but this would increase the computational needs enormously. Is there any trick for doing this. My only other solution is to reimplement the decimating fir-filter block inside my new block. greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inputs with different samplerates
On Sat, Apr 29, 2006 at 03:28:58AM +0200, Martin Dvh wrote: Hi all, Is there any way for a block to process two signals at different samplerates? There's no problem consuming inputs at different rates. The forecast routine just needs to do the right thing. However, all outputs must be produced at the same rate. There's no quick way to work around this. The immediate problem is that work and general_work return a single value giving the amount of output produced on all output streams. There's a reason that more advanced languages support mutliple return values... In my work for videodemodulation and synchronisation with gnuradio I need to process two versions of the data in the same block. I need the original samplestream at 8 MSPS. I also need a decimated/lowpassed version of the same signal at a much lower samplerate. I can't connect the original and the decimated version to the same block can I. The only thing I can do is leave out the decimation, but this would increase the computational needs enormously. Is there any trick for doing this. My only other solution is to reimplement the decimating fir-filter block inside my new block. greetings, Martin Not sure if this helped or not ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inputs with different samplerates
Eric Blossom wrote: On Sat, Apr 29, 2006 at 03:28:58AM +0200, Martin Dvh wrote: Hi all, Is there any way for a block to process two signals at different samplerates? There's no problem consuming inputs at different rates. The forecast routine just needs to do the right thing. However, all outputs must be produced at the same rate. There's no quick way to work around this. The immediate problem is that work and general_work return a single value giving the amount of output produced on all output streams. There's a reason that more advanced languages support mutliple return values... In my work for videodemodulation and synchronisation with gnuradio I need to process two versions of the data in the same block. I need the original samplestream at 8 MSPS. I also need a decimated/lowpassed version of the same signal at a much lower samplerate. I can't connect the original and the decimated version to the same block can I. The only thing I can do is leave out the decimation, but this would increase the computational needs enormously. Is there any trick for doing this. My only other solution is to reimplement the decimating fir-filter block inside my new block. greetings, Martin Not sure if this helped or not ;) Yes id did. I only output at a single rate. Thanks, Martin Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
