[Discuss-gnuradio] Install gnuradio on E100
Hi, All, I try to reinstall gnuradio (3.5.0rc0) on E100 with $ cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake ../ $ make I got errors when build gruel. How can I fix it? Before this, I got errors for unidentified gcc when cmake, so I opkg remove gcc and then opkg install gcc opkg install gcc-symlink Thanks, Pei [ 2%] Built target gruel make[2]: Warning: File `/usr/lib/libcppunit.so' has modification time 20764434 s in the future Linking CXX executable test_gruel CMakeFiles/test_gruel.dir/test_gruel.cc.o: In function `global constructors keyed to main': test_gruel.cc:(.text+0x2c): undefined reference to `boost::system::generic_category()' test_gruel.cc:(.text+0x34): undefined reference to `boost::system::generic_category()' test_gruel.cc:(.text+0x3c): undefined reference to `boost::system::system_category()' CMakeFiles/test_gruel.dir/test_gruel.cc.o: In function `boost::enable_if, std::allocator >, boost::filesystem2::path_traits> >, bool>::type boost::filesystem2::create_directory, std::allocator >, boost::filesystem2::path_traits> >(boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> const&)': test_gruel.cc:(.text._ZN5boost11filesystem216create_directoryINS0_10basic_pathISsNS0_11path_traitsENS_9enable_ifINS0_13is_basic_pathIT_EEbE4typeERKS7_[boost::enable_if, std::allocator >, boost::filesystem2::path_traits> >, bool>::type boost::filesystem2::create_directory, std::allocator >, boost::filesystem2::path_traits> >(boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> const&)]+0x44): undefined reference to `boost::filesystem2::detail::create_directory_api(std::basic_string, std::allocator > const&)' CMakeFiles/test_gruel.dir/test_gruel.cc.o: In function `boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> boost::filesystem2::current_path, std::allocator >, boost::filesystem2::path_traits> >()': test_gruel.cc:(.text._ZN5boost11filesystem212current_pathINS0_10basic_pathISsNS0_11path_traitsET_v[boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> boost::filesystem2::current_path, std::allocator >, boost::filesystem2::path_traits> >()]+0x20): undefined reference to `boost::filesystem2::detail::get_current_path_api(std::basic_string, std::allocator >&)' CMakeFiles/test_gruel.dir/test_gruel.cc.o: In function `boost::enable_if, std::allocator >, boost::filesystem2::path_traits> >, bool>::type boost::filesystem2::is_directory, std::allocator >, boost::filesystem2::path_traits> >(boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> const&)': test_gruel.cc:(.text._ZN5boost11filesystem212is_directoryINS0_10basic_pathISsNS0_11path_traitsENS_9enable_ifINS0_13is_basic_pathIT_EEbE4typeERKS7_[boost::enable_if, std::allocator >, boost::filesystem2::path_traits> >, bool>::type boost::filesystem2::is_directory, std::allocator >, boost::filesystem2::path_traits> >(boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> const&)]+0x14): undefined reference to `boost::system::system_category()' test_gruel.cc:(.text._ZN5boost11filesystem212is_directoryINS0_10basic_pathISsNS0_11path_traitsENS_9enable_ifINS0_13is_basic_pathIT_EEbE4typeERKS7_[boost::enable_if, std::allocator >, boost::filesystem2::path_traits> >, bool>::type boost::filesystem2::is_directory, std::allocator >, boost::filesystem2::path_traits> >(boost::filesystem2::basic_path, std::allocator >, boost::filesystem2::path_traits> const&)]+0x54): undefined reference to `boost::filesystem2::detail::status_api(std::basic_string, std::allocator > const&, boost::system::error_code&)' collect2: ld returned 1 exit status make[2]: *** [gruel/src/lib/test_gruel] Error 1 make[1]: *** [gruel/src/lib/CMakeFiles/test_gruel.dir/all] Error 2 make: *** [all] Error 2___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Taps in Channel model [1,0] vs [1,1]
In phasor form 1+0j = 1<0deg so no effect on amplitude and angle 0f Input & Output similarly 1+1j = 1.1415<45deg i.e.input is scaled by 1.14(sqrt(2)) and rotated by 45 degrees -Adeel On Mon, Nov 14, 2011 at 8:35 PM, Marcus M wrote: > Hi, > What is the difference between the effect of channel model taps of [1,0] > (i.e. 1+j0) and [1,1] (i.e. 1+1j) have in the output? Frequency offset and > epsilon=1.0 in both cases. > > Thanks > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Taps in Channel model [1,0] vs [1,1]
Hi, What is the difference between the effect of channel model taps of [1,0] (i.e. 1+j0) and [1,1] (i.e. 1+1j) have in the output? Frequency offset and epsilon=1.0 in both cases. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 10:21 AM, Ben Reynwar wrote: > On Mon, Nov 14, 2011 at 11:11 AM, Tom Rondeau wrote: >> On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar wrote: >>> >>> On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau >>> wrote: >>> > On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar wrote: >>> >> >>> >> PSK31 for ham radio uses a raised cosine filter rather than the RRC. >>> > >>> > Interesting. Thanks. >>> > Do you know why the do it? Do they just have the filter on one side? >>> > Tom >>> > >>> I don't think it's for any good reason. The raised cosine filter is >>> on the transmit side and I guess you can put whatever you want on the >>> receive side. I would have thought another raised cosine filter on >>> the receiver side was the best way to go to maximise the signal and >>> then deal with the ISI afterwards. I haven't looked at other peoples >>> code to see how they're doing it. >> >> I would have figured it was on the Tx side for bandwidth control, and you >> could do various things on the receiver side with that. It's of course why >> we normally use RRC filters though; restrict the transmitted signal >> bandwidth, then the receive RRC does both a matched filter and creates >> Nyquist pulses (ignoring multipath). >> Tom >> > Yep. I meant that I don't think there was a good reason for the > author of PSK31 choosing raised cosine over RRC. I spent some time looking at it when I was writing a PSK31 decoder for GR. It seems like the transmit pulse-shaping filter is RC in order to keep the transmitted bandwidth even lower than it would be with RRC. In other words, narrow bandwidth and steep skirts were given priority over ISI performance. PSK31 doesn't specify a receive filter, but the popular implementations (fldigi, G3PLX) seem to share the same filter, which is some weird custom LPF. I can go find the taps if people are interested. I briefly looked into using fred harris's class of "ISI-corrected" filters designed with a modified Remez algorithm (harris p.92) for both TX and RX, but it didn't really net me any more performance than just using a steep LPF, and I couldn't get Remez to converge reliably for the filters required. In any case, PSK31 is enough of a standard that introducing different TX filters would likely result in suboptimal performance for "standard" receivers. --n >> >>> >>> >> >>> >> On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau >>> >> wrote: >>> >> > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Because I need a raised cosine filter. If I convolve root raised >>> >> >> cosine >>> >> >> filter coefficients with themselves (generated with gr_firdes), do I >>> >> >> need to >>> >> >> apply a scaling factor? >>> >> > >>> >> > Ok, but my question was Why do you need a raised cosine filter? I'm >>> >> > just >>> >> > curious about what applications use this instead of RRC filters? >>> >> > Tom >>> >> > >>> >> >> >>> >> >> >>> >> >> >>> >> >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] >>> >> >> Sent: Monday, November 14, 2011 9:56 AM >>> >> >> To: Nowlan, Sean >>> >> >> Cc: discuss-gnuradio@gnu.org >>> >> >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps >>> >> >> implementation >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean >>> >> >> wrote: >>> >> >> >>> >> >> I want to add a raised cosine filter to gr_firdes.* in >>> >> >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a >>> >> >> root-raised >>> >> >> cosine there. After looking through a few sources, I have the >>> >> >> following >>> >> >> time-domain response of an RC filter: >>> >> >> >>> >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / >>> >> >> T_s) / >>> >> >> (1 - (2 * alpha * t / T_s )^2 )] >>> >> >> >>> >> >> As far as I can tell, I should be able to compute the taps using: >>> >> >> >>> >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do >>> >> >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 >>> >> >> * >>> >> >> alpha * n)^2 )] >>> >> >> end_for >>> >> >> >>> >> >> The things I'll have to worry about: >>> >> >> 1) if n is 0: h(n) = 1 >>> >> >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / >>> >> >> (2 * >>> >> >> alpha) ) #I think I did this right... >>> >> >> 3) rounding errors: not sure what to do here given we're operating >>> >> >> with >>> >> >> floats. >>> >> >> >>> >> >> Any tips/suggestions? >>> >> >> >>> >> >> Thanks, >>> >> >> Sean >>> >> >> >>> >> >> >>> >> >> >>> >> >> Sean, >>> >> >> >>> >> >> We've gotten this question before, and I'm again curious why you >>> >> >> want a >>> >> >> raised cosine filter? If you really are using it for something, the >>> >> >> easiest >>> >> >> thing to do is just create a root raised cosine filter and convolve >>> >> >> it >>> >> >> with >>> >> >> itself. >>> >> >> >>> >> >> >>> >> >> >>> >> >> Tom >>> >> >> >>> >> >> >>> >> > >>> >> > ___
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 11:21 AM, Ben Reynwar wrote: > On Mon, Nov 14, 2011 at 11:11 AM, Tom Rondeau wrote: >> On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar wrote: >>> >>> On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau >>> wrote: >>> > On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar wrote: >>> >> >>> >> PSK31 for ham radio uses a raised cosine filter rather than the RRC. >>> > >>> > Interesting. Thanks. >>> > Do you know why the do it? Do they just have the filter on one side? >>> > Tom >>> > >>> I don't think it's for any good reason. The raised cosine filter is >>> on the transmit side and I guess you can put whatever you want on the >>> receive side. I would have thought another raised cosine filter on >>> the receiver side was the best way to go to maximise the signal and >>> then deal with the ISI afterwards. I haven't looked at other peoples >>> code to see how they're doing it. >> >> I would have figured it was on the Tx side for bandwidth control, and you >> could do various things on the receiver side with that. It's of course why >> we normally use RRC filters though; restrict the transmitted signal >> bandwidth, then the receive RRC does both a matched filter and creates >> Nyquist pulses (ignoring multipath). >> Tom >> > Yep. I meant that I don't think there was a good reason for the > author of PSK31 choosing raised cosine over RRC. >> I just remembered it's raised cosine in time not raised cosine in frequency space, and so completely different from what the original question was about. Oh well. Cheers, Ben >>> >>> >> >>> >> On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau >>> >> wrote: >>> >> > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Because I need a raised cosine filter. If I convolve root raised >>> >> >> cosine >>> >> >> filter coefficients with themselves (generated with gr_firdes), do I >>> >> >> need to >>> >> >> apply a scaling factor? >>> >> > >>> >> > Ok, but my question was Why do you need a raised cosine filter? I'm >>> >> > just >>> >> > curious about what applications use this instead of RRC filters? >>> >> > Tom >>> >> > >>> >> >> >>> >> >> >>> >> >> >>> >> >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] >>> >> >> Sent: Monday, November 14, 2011 9:56 AM >>> >> >> To: Nowlan, Sean >>> >> >> Cc: discuss-gnuradio@gnu.org >>> >> >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps >>> >> >> implementation >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean >>> >> >> wrote: >>> >> >> >>> >> >> I want to add a raised cosine filter to gr_firdes.* in >>> >> >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a >>> >> >> root-raised >>> >> >> cosine there. After looking through a few sources, I have the >>> >> >> following >>> >> >> time-domain response of an RC filter: >>> >> >> >>> >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / >>> >> >> T_s) / >>> >> >> (1 - (2 * alpha * t / T_s )^2 )] >>> >> >> >>> >> >> As far as I can tell, I should be able to compute the taps using: >>> >> >> >>> >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do >>> >> >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 >>> >> >> * >>> >> >> alpha * n)^2 )] >>> >> >> end_for >>> >> >> >>> >> >> The things I'll have to worry about: >>> >> >> 1) if n is 0: h(n) = 1 >>> >> >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / >>> >> >> (2 * >>> >> >> alpha) ) #I think I did this right... >>> >> >> 3) rounding errors: not sure what to do here given we're operating >>> >> >> with >>> >> >> floats. >>> >> >> >>> >> >> Any tips/suggestions? >>> >> >> >>> >> >> Thanks, >>> >> >> Sean >>> >> >> >>> >> >> >>> >> >> >>> >> >> Sean, >>> >> >> >>> >> >> We've gotten this question before, and I'm again curious why you >>> >> >> want a >>> >> >> raised cosine filter? If you really are using it for something, the >>> >> >> easiest >>> >> >> thing to do is just create a root raised cosine filter and convolve >>> >> >> it >>> >> >> with >>> >> >> itself. >>> >> >> >>> >> >> >>> >> >> >>> >> >> Tom >>> >> >> >>> >> >> >>> >> > >>> >> > ___ >>> >> > Discuss-gnuradio mailing list >>> >> > Discuss-gnuradio@gnu.org >>> >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> > >>> >> > >>> > >>> > >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 11:11 AM, Tom Rondeau wrote: > On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar wrote: >> >> On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau >> wrote: >> > On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar wrote: >> >> >> >> PSK31 for ham radio uses a raised cosine filter rather than the RRC. >> > >> > Interesting. Thanks. >> > Do you know why the do it? Do they just have the filter on one side? >> > Tom >> > >> I don't think it's for any good reason. The raised cosine filter is >> on the transmit side and I guess you can put whatever you want on the >> receive side. I would have thought another raised cosine filter on >> the receiver side was the best way to go to maximise the signal and >> then deal with the ISI afterwards. I haven't looked at other peoples >> code to see how they're doing it. > > I would have figured it was on the Tx side for bandwidth control, and you > could do various things on the receiver side with that. It's of course why > we normally use RRC filters though; restrict the transmitted signal > bandwidth, then the receive RRC does both a matched filter and creates > Nyquist pulses (ignoring multipath). > Tom > Yep. I meant that I don't think there was a good reason for the author of PSK31 choosing raised cosine over RRC. > >> >> >> >> >> On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau >> >> wrote: >> >> > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean >> >> > >> >> > wrote: >> >> >> >> >> >> Because I need a raised cosine filter. If I convolve root raised >> >> >> cosine >> >> >> filter coefficients with themselves (generated with gr_firdes), do I >> >> >> need to >> >> >> apply a scaling factor? >> >> > >> >> > Ok, but my question was Why do you need a raised cosine filter? I'm >> >> > just >> >> > curious about what applications use this instead of RRC filters? >> >> > Tom >> >> > >> >> >> >> >> >> >> >> >> >> >> >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] >> >> >> Sent: Monday, November 14, 2011 9:56 AM >> >> >> To: Nowlan, Sean >> >> >> Cc: discuss-gnuradio@gnu.org >> >> >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps >> >> >> implementation >> >> >> >> >> >> >> >> >> >> >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean >> >> >> wrote: >> >> >> >> >> >> I want to add a raised cosine filter to gr_firdes.* in >> >> >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a >> >> >> root-raised >> >> >> cosine there. After looking through a few sources, I have the >> >> >> following >> >> >> time-domain response of an RC filter: >> >> >> >> >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / >> >> >> T_s) / >> >> >> (1 - (2 * alpha * t / T_s )^2 )] >> >> >> >> >> >> As far as I can tell, I should be able to compute the taps using: >> >> >> >> >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do >> >> >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 >> >> >> * >> >> >> alpha * n)^2 )] >> >> >> end_for >> >> >> >> >> >> The things I'll have to worry about: >> >> >> 1) if n is 0: h(n) = 1 >> >> >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / >> >> >> (2 * >> >> >> alpha) ) #I think I did this right... >> >> >> 3) rounding errors: not sure what to do here given we're operating >> >> >> with >> >> >> floats. >> >> >> >> >> >> Any tips/suggestions? >> >> >> >> >> >> Thanks, >> >> >> Sean >> >> >> >> >> >> >> >> >> >> >> >> Sean, >> >> >> >> >> >> We've gotten this question before, and I'm again curious why you >> >> >> want a >> >> >> raised cosine filter? If you really are using it for something, the >> >> >> easiest >> >> >> thing to do is just create a root raised cosine filter and convolve >> >> >> it >> >> >> with >> >> >> itself. >> >> >> >> >> >> >> >> >> >> >> >> Tom >> >> >> >> >> >> >> >> > >> >> > ___ >> >> > Discuss-gnuradio mailing list >> >> > Discuss-gnuradio@gnu.org >> >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > >> >> > >> > >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar wrote: > On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau > wrote: > > On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar wrote: > >> > >> PSK31 for ham radio uses a raised cosine filter rather than the RRC. > > > > Interesting. Thanks. > > Do you know why the do it? Do they just have the filter on one side? > > Tom > > > I don't think it's for any good reason. The raised cosine filter is > on the transmit side and I guess you can put whatever you want on the > receive side. I would have thought another raised cosine filter on > the receiver side was the best way to go to maximise the signal and > then deal with the ISI afterwards. I haven't looked at other peoples > code to see how they're doing it. > I would have figured it was on the Tx side for bandwidth control, and you could do various things on the receiver side with that. It's of course why we normally use RRC filters though; restrict the transmitted signal bandwidth, then the receive RRC does both a matched filter and creates Nyquist pulses (ignoring multipath). Tom > >> > >> On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau > >> wrote: > >> > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean > >> > > >> > wrote: > >> >> > >> >> Because I need a raised cosine filter. If I convolve root raised > cosine > >> >> filter coefficients with themselves (generated with gr_firdes), do I > >> >> need to > >> >> apply a scaling factor? > >> > > >> > Ok, but my question was Why do you need a raised cosine filter? I'm > just > >> > curious about what applications use this instead of RRC filters? > >> > Tom > >> > > >> >> > >> >> > >> >> > >> >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] > >> >> Sent: Monday, November 14, 2011 9:56 AM > >> >> To: Nowlan, Sean > >> >> Cc: discuss-gnuradio@gnu.org > >> >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps > >> >> implementation > >> >> > >> >> > >> >> > >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean > >> >> wrote: > >> >> > >> >> I want to add a raised cosine filter to gr_firdes.* in > >> >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a > >> >> root-raised > >> >> cosine there. After looking through a few sources, I have the > following > >> >> time-domain response of an RC filter: > >> >> > >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / > >> >> T_s) / > >> >> (1 - (2 * alpha * t / T_s )^2 )] > >> >> > >> >> As far as I can tell, I should be able to compute the taps using: > >> >> > >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do > >> >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 > * > >> >> alpha * n)^2 )] > >> >> end_for > >> >> > >> >> The things I'll have to worry about: > >> >> 1) if n is 0: h(n) = 1 > >> >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / > (2 * > >> >> alpha) )#I think I did this right... > >> >> 3) rounding errors: not sure what to do here given we're operating > with > >> >> floats. > >> >> > >> >> Any tips/suggestions? > >> >> > >> >> Thanks, > >> >> Sean > >> >> > >> >> > >> >> > >> >> Sean, > >> >> > >> >> We've gotten this question before, and I'm again curious why you > want a > >> >> raised cosine filter? If you really are using it for something, the > >> >> easiest > >> >> thing to do is just create a root raised cosine filter and convolve > it > >> >> with > >> >> itself. > >> >> > >> >> > >> >> > >> >> Tom > >> >> > >> >> > >> > > >> > ___ > >> > Discuss-gnuradio mailing list > >> > Discuss-gnuradio@gnu.org > >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > >> > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau wrote: > On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar wrote: >> >> PSK31 for ham radio uses a raised cosine filter rather than the RRC. > > Interesting. Thanks. > Do you know why the do it? Do they just have the filter on one side? > Tom > I don't think it's for any good reason. The raised cosine filter is on the transmit side and I guess you can put whatever you want on the receive side. I would have thought another raised cosine filter on the receiver side was the best way to go to maximise the signal and then deal with the ISI afterwards. I haven't looked at other peoples code to see how they're doing it. >> >> On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau >> wrote: >> > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean >> > >> > wrote: >> >> >> >> Because I need a raised cosine filter. If I convolve root raised cosine >> >> filter coefficients with themselves (generated with gr_firdes), do I >> >> need to >> >> apply a scaling factor? >> > >> > Ok, but my question was Why do you need a raised cosine filter? I'm just >> > curious about what applications use this instead of RRC filters? >> > Tom >> > >> >> >> >> >> >> >> >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] >> >> Sent: Monday, November 14, 2011 9:56 AM >> >> To: Nowlan, Sean >> >> Cc: discuss-gnuradio@gnu.org >> >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps >> >> implementation >> >> >> >> >> >> >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean >> >> wrote: >> >> >> >> I want to add a raised cosine filter to gr_firdes.* in >> >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a >> >> root-raised >> >> cosine there. After looking through a few sources, I have the following >> >> time-domain response of an RC filter: >> >> >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / >> >> T_s) / >> >> (1 - (2 * alpha * t / T_s )^2 )] >> >> >> >> As far as I can tell, I should be able to compute the taps using: >> >> >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do >> >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * >> >> alpha * n)^2 )] >> >> end_for >> >> >> >> The things I'll have to worry about: >> >> 1) if n is 0: h(n) = 1 >> >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * >> >> alpha) ) #I think I did this right... >> >> 3) rounding errors: not sure what to do here given we're operating with >> >> floats. >> >> >> >> Any tips/suggestions? >> >> >> >> Thanks, >> >> Sean >> >> >> >> >> >> >> >> Sean, >> >> >> >> We've gotten this question before, and I'm again curious why you want a >> >> raised cosine filter? If you really are using it for something, the >> >> easiest >> >> thing to do is just create a root raised cosine filter and convolve it >> >> with >> >> itself. >> >> >> >> >> >> >> >> Tom >> >> >> >> >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on using USRP sink/sources in GNU Radio recent release
> However, as I had attempted earlier installs, some old files remain. My I recommend cleaning out old installations before reinstalling gnuradio. Not doing so has caused many problems. > question is: are the files provided in the following list already > deprecated? The majority of them include "from gnuradio import usrp" or > "from gnuradio import usrp2" string in their header, and I have confirmed > even the most basic example listed in http://www.joshknows.com/gnuradio I will update my website. That page is very "stale". > (See USRP Examples) fails. So, is there a recommended way to modify these > python files to use the UHD driver instead of (missing?) USRP or USRP2 I believe all USRP1 examples have been modified for UHD in the current master. > blocks? If these files will not be needed anymore (as UHD supercedes > USRP), why keep them around on public websites? But if they have any Well, I can only update my website and the gnuradio wiki. Theres a lot of websites out there... Cheers! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar wrote: > PSK31 for ham radio uses a raised cosine filter rather than the RRC. Interesting. Thanks. Do you know why the do it? Do they just have the filter on one side? Tom > On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau > wrote: > > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean < > sean.now...@gtri.gatech.edu> > > wrote: > >> > >> Because I need a raised cosine filter. If I convolve root raised cosine > >> filter coefficients with themselves (generated with gr_firdes), do I > need to > >> apply a scaling factor? > > > > Ok, but my question was Why do you need a raised cosine filter? I'm just > > curious about what applications use this instead of RRC filters? > > Tom > > > >> > >> > >> > >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] > >> Sent: Monday, November 14, 2011 9:56 AM > >> To: Nowlan, Sean > >> Cc: discuss-gnuradio@gnu.org > >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation > >> > >> > >> > >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean > >> wrote: > >> > >> I want to add a raised cosine filter to gr_firdes.* in > >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a > root-raised > >> cosine there. After looking through a few sources, I have the following > >> time-domain response of an RC filter: > >> > >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / > T_s) / > >> (1 - (2 * alpha * t / T_s )^2 )] > >> > >> As far as I can tell, I should be able to compute the taps using: > >> > >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do > >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * > >> alpha * n)^2 )] > >> end_for > >> > >> The things I'll have to worry about: > >> 1) if n is 0: h(n) = 1 > >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * > >> alpha) )#I think I did this right... > >> 3) rounding errors: not sure what to do here given we're operating with > >> floats. > >> > >> Any tips/suggestions? > >> > >> Thanks, > >> Sean > >> > >> > >> > >> Sean, > >> > >> We've gotten this question before, and I'm again curious why you want a > >> raised cosine filter? If you really are using it for something, the > easiest > >> thing to do is just create a root raised cosine filter and convolve it > with > >> itself. > >> > >> > >> > >> Tom > >> > >> > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
PSK31 for ham radio uses a raised cosine filter rather than the RRC. On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau wrote: > On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean > wrote: >> >> Because I need a raised cosine filter. If I convolve root raised cosine >> filter coefficients with themselves (generated with gr_firdes), do I need to >> apply a scaling factor? > > Ok, but my question was Why do you need a raised cosine filter? I'm just > curious about what applications use this instead of RRC filters? > Tom > >> >> >> >> From: Tom Rondeau [mailto:trondeau1...@gmail.com] >> Sent: Monday, November 14, 2011 9:56 AM >> To: Nowlan, Sean >> Cc: discuss-gnuradio@gnu.org >> Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation >> >> >> >> On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean >> wrote: >> >> I want to add a raised cosine filter to gr_firdes.* in >> gnuradio/gnuradio-core/src/lib/general/. I see there's already a root-raised >> cosine there. After looking through a few sources, I have the following >> time-domain response of an RC filter: >> >> h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / >> (1 - (2 * alpha * t / T_s )^2 )] >> >> As far as I can tell, I should be able to compute the taps using: >> >> for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do >> h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * >> alpha * n)^2 )] >> end_for >> >> The things I'll have to worry about: >> 1) if n is 0: h(n) = 1 >> 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * >> alpha) ) #I think I did this right... >> 3) rounding errors: not sure what to do here given we're operating with >> floats. >> >> Any tips/suggestions? >> >> Thanks, >> Sean >> >> >> >> Sean, >> >> We've gotten this question before, and I'm again curious why you want a >> raised cosine filter? If you really are using it for something, the easiest >> thing to do is just create a root raised cosine filter and convolve it with >> itself. >> >> >> >> Tom >> >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean wrote: > Because I need a raised cosine filter. If I convolve root raised cosine > filter coefficients with themselves (generated with gr_firdes), do I need > to apply a scaling factor? > Ok, but my question was Why do you need a raised cosine filter? I'm just curious about what applications use this instead of RRC filters? Tom > > > *From:* Tom Rondeau [mailto:trondeau1...@gmail.com] > *Sent:* Monday, November 14, 2011 9:56 AM > *To:* Nowlan, Sean > *Cc:* discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] raised cosine filter taps implementation > > > ** ** > > On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean > wrote: > > I want to add a raised cosine filter to gr_firdes.* in > gnuradio/gnuradio-core/src/lib/general/. I see there's already a > root-raised cosine there. After looking through a few sources, I have the > following time-domain response of an RC filter: > > h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / > (1 - (2 * alpha * t / T_s )^2 )] > > As far as I can tell, I should be able to compute the taps using: > > for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do > h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * > alpha * n)^2 )] > end_for > > The things I'll have to worry about: > 1) if n is 0: h(n) = 1 > 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * > alpha) )#I think I did this right... > 3) rounding errors: not sure what to do here given we're operating with > floats. > > Any tips/suggestions? > > Thanks, > Sean > > ** ** > > Sean, > > We've gotten this question before, and I'm again curious why you want a > raised cosine filter? If you really are using it for something, the easiest > thing to do is just create a root raised cosine filter and convolve it with > itself. > > ** ** > > Tom > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] new stream selector block in gr-basic
Hey list, I have noticed that many user's have found the need to mux a stream. Either to dynamically select an alternative data source or to mux an output to an alternative sink like a different demodulator. Currently, GRC has come with selector (and valve). These blocks implement stream muxing by dynamically reconfiguring the flow graph. However, this method seems to be slow and error prone. So, I have created a stream selector block in gr-basic. Stream selector has N inputs and M outputs and allows the user to dynamically change the stream routing without flow graph reconfiguration. The good: - the switchover is immediate - no lock/unlock start/stop, so no errors - unused inputs can be put into blocking or consume mode The bad: - The post-reconfiguration overhead is an extra memcpy from source port to destination port The work is here, and grc demo attached: http://gnuradio.org/cgit/jblum.git/tree/gr-basic/include/gr_basic_stream_selector.h?h=gr_basic -Josh stream sel test.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on using USRP sink/sources in GNU Radio recent release
Hello, as some of you may know I recently installed a fresh GNURADIO package, after a manual install of a UHD package on my Ubuntu 10.04 LTS workstation. dpkg -i UUHD-003.003.001-Ubuntu-10.04-x86_64.deb (from git) cat version.sh MAJOR_VERSION=3 API_COMPAT=5 MINOR_VERSION=0rc0 MAINT_VERSION=0 So far so good, Gnu Radio Companion works etc., uhd_fft.py, Audio examples work etc. My test setup: USRP/TVRX2 -- USB -- USB (UHD) -- HOST However, as I had attempted earlier installs, some old files remain. My question is: are the files provided in the following list already deprecated? The majority of them include "from gnuradio import usrp" or "from gnuradio import usrp2" string in their header, and I have confirmed even the most basic example listed in http://www.joshknows.com/gnuradio (See USRP Examples) fails. So, is there a recommended way to modify these python files to use the UHD driver instead of (missing?) USRP or USRP2 blocks? If these files will not be needed anymore (as UHD supercedes USRP), why keep them around on public websites? But if they have any educational value, then why not keep a "stub" usrp entry that spits out an error message to the calling script with a blurb of something like "feature deprecated, please use UHD".. so that old code examples can be ported to newer coding standards? Traceback (most recent call last): File "foo.py", line 2, in from gnuradio import usrp ImportError: cannot import name usrp Now a general question for the archive-maintainers, is there a handy reference of the supported/tested status of each of these files? I see that (I believe..) none of the files have a timestamp or author information, or even a specification block as to the exact test environment this code was executed in. Is that information available elsewhere as a release note accompanying the package or only available through a git log entry? Regards, Samudra N3RDX usrp2_fft.py usrp_oscope.py usrp_rx_nogui.py usrp_siggen_gui.py usrp_siggen.py usrp_fft.py usrp_sounder.py qt_digital_window.ui usrp_display_qtgui.ui usrp_psr_receiver.py usrp_ra_receiver.py usrp_radar_mono.py file_rx_lrit.py usrp_rx_lrit.py gpio_rx_sfile.py gpio_usrp_fft.py gpio_usrp_siggen.py usrp2_probe usrp2_rx_cfile.py usrp_probe lsusrp usrp_print_db.py usrp_rx_cfile.py usrp_test_counting.py usrp_test_loopback.py usrp2_burn_mac_addr find_usrps usrp2_socket_opener usrp_cal_dc_offset usrper bitbake ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Radio astronomy question
On 14/11/11 10:42 AM, Sudhir | NetworthS wrote: > Could you pl name the author and title. Thanks in advance. 'S. > http://www.aspbooks.org/a/volumes/table_of_contents/?book_id=118 (Sorry, it's a 477-page book, not 800 pages. An easy bedtime read :-) ) -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Radio astronomy question
Could you pl name the author and title. Thanks in advance. 'S. On 11/14/11, Marcus D. Leech wrote: > On 14/11/11 06:24 AM, Andrew Rich wrote: >> >> How does a radio telescope make a picture ? >> >> Sent from my iPhone >> Andrew Rich >> >> > Phase-array imaging. I have a 800-page book that explains it Basically > you have a whole lot of > two-element interferometers at different spacings, and then feed that > into a big pile of math. > > > -- > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Sent from my mobile device ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
Because I need a raised cosine filter. If I convolve root raised cosine filter coefficients with themselves (generated with gr_firdes), do I need to apply a scaling factor? From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Monday, November 14, 2011 9:56 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean mailto:sean.now...@gtri.gatech.edu>> wrote: I want to add a raised cosine filter to gr_firdes.* in gnuradio/gnuradio-core/src/lib/general/. I see there's already a root-raised cosine there. After looking through a few sources, I have the following time-domain response of an RC filter: h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / (1 - (2 * alpha * t / T_s )^2 )] As far as I can tell, I should be able to compute the taps using: for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * alpha * n)^2 )] end_for The things I'll have to worry about: 1) if n is 0: h(n) = 1 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * alpha) )#I think I did this right... 3) rounding errors: not sure what to do here given we're operating with floats. Any tips/suggestions? Thanks, Sean Sean, We've gotten this question before, and I'm again curious why you want a raised cosine filter? If you really are using it for something, the easiest thing to do is just create a root raised cosine filter and convolve it with itself. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Absolute time reception through pythoninterface
On 11/14/2011 06:38 AM, Nicholas Lan wrote: > Dear Josh, > > Thanks for your reply. Does this mean that there is no method to implement > the C++ recv and stream commands using an absolute start time in the > currently implemented gnuradio python api? > You may set absolute time on the device, and receive downstream tags with absolute timestamps. However, you cannot *yet* tell the block to stream at a specific time. I believe this to be a trivial change. One may imagine a call that sets the time into the source block, and when the source block's start() routine is called, it uses the time programmed by the user. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean wrote: > I want to add a raised cosine filter to gr_firdes.* in > gnuradio/gnuradio-core/src/lib/general/. I see there's already a > root-raised cosine there. After looking through a few sources, I have the > following time-domain response of an RC filter: > > h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / > (1 - (2 * alpha * t / T_s )^2 )] > > As far as I can tell, I should be able to compute the taps using: > > for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do > h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * > alpha * n)^2 )] > end_for > > The things I'll have to worry about: > 1) if n is 0: h(n) = 1 > 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * > alpha) )#I think I did this right... > 3) rounding errors: not sure what to do here given we're operating with > floats. > > Any tips/suggestions? > > Thanks, > Sean > Sean, We've gotten this question before, and I'm again curious why you want a raised cosine filter? If you really are using it for something, the easiest thing to do is just create a root raised cosine filter and convolve it with itself. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Absolute time reception through pythoninterface
Dear Josh, Thanks for your reply. Does this mean that there is no method to implement the C++ recv and stream commands using an absolute start time in the currently implemented gnuradio python api? Regards Nicholas Lan This e-mail communication contains confidential information that may also be privileged. It is intended for the exclusive use of the addressees. If you are not the person or organization to whom it is addressed, you must not copy, distribute or take any action based on the information contained within. If you have received this communication in error, please notify Ursa Minor B.V. immediately [telephone +31 (0) 15 2682559]. Ursa Minor B.V. will not accept liability for contractual commitments made by individuals employed by this company outside the scope of our business. -Original Message- From: discuss-gnuradio-bounces+nicholas.lan=ursaminor...@gnu.org [mailto:discuss-gnuradio-bounces+nicholas.lan=ursaminor...@gnu.org] On Behalf Of Josh Blum Sent: 11 November 2011 16:01 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Absolute time reception through pythoninterface On 11/11/2011 04:23 AM, Nicholas Lan wrote: > Hello, > > > > I am able to use UHD C++ code to have an ettus device record data at a > specified absolute time. I am trying to implement this functionality in > python. I have read in a discussion topic that the recv command used in C++ > to start receiving at a specified absolute time is not implemented through > SWIG in gnuradio and that gnuradio scheduler should be used instead. I have > looked through the code files including 'scheduler' in gnuradio as well as > gr_flat_flowgraph and can't see how to implement an absolute timed start > through these codes. I also looked at gr_timer but read that this is not > currently fully implemented. Could someone point me in the right direction > in terms of starting reception at a specified absolute time through > gnuradio/grc please? > > If you use my next branch you can write blocks in python. All facilities of tags and message passing are available in python: http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython Also, look at gr-uhd/examples/tags_demo.cc for an example of how to intercept and use the tags. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 108, Issue 13
Bill, Automatic Modulation Classification (AMC) is still a heavily researched area, and you should be able to find hundreds of papers on the topic by searching IEEE for 'automatic modulation classification'. There are algorithms that use energy analysis, imaging techniques, cyclostationarity analysis, and many, many more. Happy hacking, Ben On Sun, Nov 13, 2011 at 10:21 AM, Achilleas Anastasopoulos < anas...@umich.edu> wrote: > You can find some literature on this topic by searching under > "modulation classification". > I know that in the 90's a lot of work in this area came from the USC group. > > Achilleas > > > > > Message: 1 > > Date: Sat, 12 Nov 2011 18:22:43 -0500 > > From: "William Pretty Security Inc" > > To: > > Subject: [Discuss-gnuradio] Auto Detecting Modulation Type > > Message-ID: <059f01cca192$0be92e30$23bb8a90$@pre...@xplornet.com> > > Content-Type: text/plain; charset="us-ascii" > > > > Hello All; > > > > I was wondering if anyone has done any work with auto-detection of > > modulation type ? > > Not necessarily with the USRP. It is the algorithm that interests me. > > > > Thanks; > > > > Bill > > > > "Strategy without tactics is the slowest route to victory. > > Tactics without strategy is the noise before defeat. " Sun Tzu > > > > > > > > > > > > > > -- > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > End of Discuss-gnuradio Digest, Vol 108, Issue 13 > > * > > > > > > -- > ___ > Achilleas Anastasopoulos > Associate Professor > EECS Department Voice : (734)615-4024 > UNIVERSITY OF MICHIGANFax : (734)763-8041 > Ann Arbor, MI 48109-2122 E-mail: anas...@umich.edu > URL: http://www.eecs.umich.edu/~anastas/ > ___ > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Radio astronomy question
On 14/11/11 06:24 AM, Andrew Rich wrote: > > How does a radio telescope make a picture ? > > Sent from my iPhone > Andrew Rich > > Phase-array imaging. I have a 800-page book that explains it Basically you have a whole lot of two-element interferometers at different spacings, and then feed that into a big pile of math. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM on E100
On 11/13/2011 11:10 PM, Marcus D. Leech wrote: > On 11/13/2011 11:00 PM, Josh Blum wrote: >> It looks like the ofdm blocks are using a fair amount of multiply and >> multiply const blocks: >> >>> gr-digital$ find -name "*ofdm*" | xargs grep mult >>> ./python/ofdm_sync_ml.py:self.mixer = gr.multiply_cc(); >>> ./python/ofdm_sync_ml.py:# The output theta of the correlator >>> above is multiplied with this correlation to >>> ./python/ofdm_sync_ml.py:self.mul = gr.multiply_ff() >>> ./python/ofdm_receiver.py:self.chan_filt = >>> gr.multiply_const_cc(1.0) >>> ./python/ofdm_receiver.py:self.sigmix = gr.multiply_cc() >>> ./python/ofdm_sync_pn.py:self.corr = gr.multiply_cc(); >>> ./python/ofdm_sync_pn.py:self.square = gr.multiply_ff() >>> ./python/ofdm_packet_utils.py:to get to a multiple of 8. >>> ./python/ofdm_packet_utils.py:# pad to multiple of 8 >>> ./python/ofdm_packet_utils.py:up being a multiple of 512 bytes >>> when sent across the USB. We >>> ./python/ofdm_packet_utils.py:is a multiple of 128 samples. >>> ./python/ofdm.py:@param pad_for_usrp: If true, packets are >>> padded such that they end up a multiple of 128 samples >>> ./python/ofdm.py:self.scale = gr.multiply_const_cc(1.0 / >>> math.sqrt(self._fft_length)) >>> ./python/ofdm_sync_pnac.py:self.corr = gr.multiply_cc(); >> I bet many of these multiply consts could be simplified out. But, doing >> little things like replacing the multiplier implementation with one >> optimized with the SIMD unit makes a big difference, especially on a arm >> where NEON>> FPU. >> >> So, there is a multiply and multiply const for floats that has been >> optimized in my gr-basic branch. You may want to try using those blocks >> instead. http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic >> >> -Josh > The main transform in an OFDM transmitter, though, is an inverse FFT, > and I assume those blocks use the built-in FFTW implementation, > rather than doing their own. > Make sure you are using the fftw 3.3.1 beta that includes the NEON SIMD code. The OpenEmbedded recipe is updated to use that version now. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Radio astronomy question
How does a radio telescope make a picture ? Sent from my iPhone Andrew Rich On 14/11/2011, at 14:10, "Marcus D. Leech" wrote: > On 11/13/2011 11:00 PM, Josh Blum wrote: >> It looks like the ofdm blocks are using a fair amount of multiply and >> multiply const blocks: >> >>> gr-digital$ find -name "*ofdm*" | xargs grep mult >>> ./python/ofdm_sync_ml.py:self.mixer = gr.multiply_cc(); >>> ./python/ofdm_sync_ml.py:# The output theta of the correlator above >>> is multiplied with this correlation to >>> ./python/ofdm_sync_ml.py:self.mul = gr.multiply_ff() >>> ./python/ofdm_receiver.py:self.chan_filt = >>> gr.multiply_const_cc(1.0) >>> ./python/ofdm_receiver.py:self.sigmix = gr.multiply_cc() >>> ./python/ofdm_sync_pn.py:self.corr = gr.multiply_cc(); >>> ./python/ofdm_sync_pn.py:self.square = gr.multiply_ff() >>> ./python/ofdm_packet_utils.py:to get to a multiple of 8. >>> ./python/ofdm_packet_utils.py:# pad to multiple of 8 >>> ./python/ofdm_packet_utils.py:up being a multiple of 512 bytes when >>> sent across the USB. We >>> ./python/ofdm_packet_utils.py:is a multiple of 128 samples. >>> ./python/ofdm.py:@param pad_for_usrp: If true, packets are padded >>> such that they end up a multiple of 128 samples >>> ./python/ofdm.py:self.scale = gr.multiply_const_cc(1.0 / >>> math.sqrt(self._fft_length)) >>> ./python/ofdm_sync_pnac.py:self.corr = gr.multiply_cc(); >> I bet many of these multiply consts could be simplified out. But, doing >> little things like replacing the multiplier implementation with one >> optimized with the SIMD unit makes a big difference, especially on a arm >> where NEON>> FPU. >> >> So, there is a multiply and multiply const for floats that has been >> optimized in my gr-basic branch. You may want to try using those blocks >> instead. http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic >> >> -Josh > The main transform in an OFDM transmitter, though, is an inverse FFT, and I > assume those blocks use the built-in FFTW implementation, > rather than doing their own. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem running GRC
Hello,
thanks for the help.
The build script by Marcus Leech finally solved my
problem.
Regards
Sebastian
On Thu, 10 Nov 2011 07:08:53 -0800
Josh Blum wrote:
On 11/10/2011 03:55 AM, sdoer...@rhrk.uni-kl.de wrote:
Hello list,
I have already found this topic in an older post, but it
ended after two
mails.
I have installed the latest gnuradio version via git on
Ubuntu 11.10.
Everything else is just the same like in the older post
I just found
except the version of GNURadio:
[quote]
I have the following exports added to bash.bashrc:
# GNU Radio installation
export PATH=$PATH:/usr/local/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export
PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/site-packages
Ubuntu 11.10 doesnt use python 2.6, perhaps that
explains it?
I recommend you clean out all gnuradio installs first.
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs
(I have checked that these default paths exist)
When I try to launch grc from the terminal, I get a
popup saying:
"cannot import gnuradio. Are your PYTHONPATH and
LD_LIBRARY_PATH set
correctly?"
[quote]
The top of the popup is saying:
/usr/local/lib/libgnuradio-core-3.5git.so.0: unde...
[quote]
When I try "python -c "import gnuradio" " i the terminal
window, I get
no error messages.
[quote]
When I run "python -c "from gnuradio import gr" " I get
an import error
(".../usr/local/lib/libgnuradio-core-3.5.0rc0.so.0:
undefined symbol:
_ZTIN5gruel12msg_accepterE").
"sudo ldconfig" does not change anything.
I would really appreciate your help.
Regards
Sebastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
