[Discuss-gnuradio] How can I skip N ites for each input?
I know there is a block 'Skip Head' When I use it, however, I don't think that it works as I expected I expected that like this: Suppose a sequence 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 (one 1, seven 0's and repeat forever) I want to take just '1' for EVERY time So I place and connect 'Skip Head' block and set 'Num items' 7, which means it skips first 7 items. In fact, as my guess and experiment, it just skips the very first 7 items! In short, I have 800 items and use 'Skip Head' with 7 skips, it passes 793 items. I expected 100 items! (800 / (7 + 1)) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I skip N ites for each input?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2010 08:39 AM, Songsong Gee wrote: Suppose a sequence 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 (one 1, seven 0's and repeat forever) I want to take just '1' for EVERY time So I place and connect 'Skip Head' block and set 'Num items' 7, which means it skips first 7 items. Is there a specific reason to not just skip the first seven items in your block? Something like starting your processing at in[7] instead of in[0] with a sync/sync decimator block? Happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7iODAAoJEOjnDXL6I0uZMvMQALmr002jAAP+E59JTz1tIEmv tTN1W6ddzFvJQwypiUOg0BMwIp+vd8PprdEI/HaqSsJx5o/gQNgTzFc1zjz7Mcx3 UrTPiqLY96h4RU6vikLJEHWk437R2kNXZBEKJ+/gY4ImzJk6IzZ5XMyrKFkqLEMG rAvEFKPr0r+wl8ERhERrAK7KtRnUTLU8vWWnr8oLLB0aPTlXx6JxTYwKMFyUsPgi VaqdiT/b4xqd0txRgVcYYpji/T09Nz4FSLAF3EmL7bOf1PLhiCcFOSLIFs+4sEvW XTfios1wC8MgQWdeBSCRChShsC7vCksvvJCtuFN/8SUAQ/EwVplQgj2KW/Pbu5Jv vejR4QgTx9xokLo0uamph3/2KkujxmEvz5n0FUk9l0GlZ5yuBXc5l50fi3rzo9Rd 0ogQIxxl+g/T88JxgBBkDq+sV8Vmvl+B/bx90+0eBIY0Qatu+Vo5+5wCs5dYsOqb 7MrNeXa4Xyp5Kzea1nz4nA4ZKArxjdFS3evUkjNZSEGv6EbSBiqy/SRDoBMJZ2si WytoKAfvq7ejpA7wpZ10VZEQNXE1QB9NdCKKiDC7BPS/DcdVMOAzcv1WDj49pUH2 cyg9WCS8ksm+FpPlON/ZVcQl49fyapnnr2HE6h6wKL+EswBVsq4F+qAiHjrugYrp WcLDAtLx3LaeCWIxSAXa =Kuz6 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I skip N ites for each input?
There is a block called keep one in n. Is that what you are looking for? http://gnuradio.org/doc/doxygen/classgr__keep__one__in__n.html -Josh On 11/24/2010 11:39 PM, Songsong Gee wrote: I know there is a block 'Skip Head' When I use it, however, I don't think that it works as I expected I expected that like this: Suppose a sequence 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 (one 1, seven 0's and repeat forever) I want to take just '1' for EVERY time So I place and connect 'Skip Head' block and set 'Num items' 7, which means it skips first 7 items. In fact, as my guess and experiment, it just skips the very first 7 items! In short, I have 800 items and use 'Skip Head' with 7 skips, it passes 793 items. I expected 100 items! (800 / (7 + 1)) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Data transmission in bursts using uhd
Hello,
I implemented a selective repeat ARQ-protocol using the USRP2.
Up til now I used the USRP2 driver.
Now I want to upgrade my system to use UHD.
I upgrade the to hosts, the FPGA image and the firmware of my USRP2s.
Now the continous data transmission works fine.
But the bursty protocol communication doesn't work.
I used this code form the ursp sink in the downstream part of the transmitter:
if not self.usrp:
self.usrp2_sink = uhd.single_usrp_sink(
device_addr=addr=192.168.10.2,
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
self.usrp2_sink.set_samp_rate(self.output_samp_rate)
self.usrp2_sink.set_center_freq(self.center_frequency, 0)
self.usrp2_sink.set_gain(self.tx_gain, 0)
else:
self.usrp2_sink = usrp2.sink_32fc('eth1','')
self.usrp2_sink.set_interp(self.usrp_interp_rate)
self.usrp2_sink.set_center_freq(self.center_frequency)
self.usrp2_sink.set_gain(self.tx_gain)
And this one for the usrp source for the resceiving part of the feedback
channel in the transmitter of the overall system.
if not self.usrp:
self.usrp_source = uhd.single_usrp_source(
device_addr=addr=192.168.10.2,
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
self.usrp_source.set_samp_rate(self.input_samp_rate)
self.usrp_source.set_center_freq(self.center_frequency, 0)
self.usrp_source.set_gain(self.rx_gain, 0)
self.usrp_rate = self.input_samp_rate
else:
self.usrp_source = usrp2.source_32fc('eth1','')
self.usrp_source.set_decim(self.usrp_decim_rate)
self.usrp_source.set_center_freq(self.center_frequency)
self.usrp_source.set_gain(self.rx_gain)
self.usrp_rate = int(self.usrp_source.adc_rate() /
self.usrp_decim_rate) # sample rate from USRP
Do I have to do something in addition to make it work for bursty transmissions.
Furthermore I get an 'U' in terminal of the transmitter after each burst. Is
this the same problem?
Thanks for your help.
Regards,
Tobias
___
WEB.DE DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] call set_output_multiple() on the fly
I am writing a module that might need dynamic change to the block length. So I want to call set_output_multiple(blk_len) when the flow graph is running. Firstly, is this allowed? Secondly, what are the effects? If I have a noutput_items%blk_len==0 checking in work(), will it fail during the transition? Thanks Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I skip N ites for each input?
Thank you very much You are must be a genius 2010/11/25 Josh Blum j...@joshknows.com There is a block called keep one in n. Is that what you are looking for? http://gnuradio.org/doc/doxygen/classgr__keep__one__in__n.html -Josh On 11/24/2010 11:39 PM, Songsong Gee wrote: I know there is a block 'Skip Head' When I use it, however, I don't think that it works as I expected I expected that like this: Suppose a sequence 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 (one 1, seven 0's and repeat forever) I want to take just '1' for EVERY time So I place and connect 'Skip Head' block and set 'Num items' 7, which means it skips first 7 items. In fact, as my guess and experiment, it just skips the very first 7 items! In short, I have 800 items and use 'Skip Head' with 7 skips, it passes 793 items. I expected 100 items! (800 / (7 + 1)) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd::tune_result_t vs. usrp2::tune_result
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, I'm currently trying to adapt the gnuradio-core/src/python/gnuradio/blks2impl/generic_usrp.py to work with the gr-uhd modules to (re)enable the use of UHD with the gnuradio-examples/python/digital stuff. I'm a bit confused with the return value of the set_center_freq of the uhd_single_usrp_source. What I tried was to map the values of the uhd::tune_result_t into a usrp_tune_result. Does this make any sense to you guys? ;-) Another question that arose while looking at the code concerns the change in the way we set the sample rate: Why do we have in the new UHD source: set_samp_rate (double rate) versus: set_decim (int decimation_factor) in the old USRP source? Thanks for your time again happy hacking - -Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7mLVAAoJEOjnDXL6I0uZpHMP/28s/A98djBGYaeanGp54MXY khFV6Ltx0vsCNv6Uf4oJTsBdxhcqPX3x3YYbXCf5k7MXyQXxj23OrHVMtl2niVbc kbh2V710OTQEIC940ARrumPVTVDJ+A8vN76XGGGowZtJjMGaPYb20vyKkhqN5FWC k6+xhi/DUBCWIWWE/fyefP0zl3VhSIbV4L5zjWtoX/A1NTeTKZsq+UcsKz6ZVDCl UmZPBvav2PAIYpo99zvB3qZcxCPaGata09ZKsV03OeiUKG9yI1yUCXgj5tzhRNs2 dJFIAJAhkvI4rzV/GCYHI2WUuql758iCCPTbE4DLYBzyST/Eg5h1jveQetObIGpy PGMRGKv4jXg3BUQN6gxrI7SN2ZGSs8i+oxJdmu7pr1Zwnc3DxAVX9HgupfjARray MbO9RqbFKPoaWSwIJj6/SpNvVb/0b9zHPrN2UQWW31LfL4NS/3Ku5iTf3Fm5lx8l 7qLg+vJ4K35FO0iV/WIrOu+SHLPE8jiqlaaOgMC2pFfpqueLIMf5EXn0usiDgLjl IrvdxBzvMfPI4H+4UiNoMq3OD9v0jBFvaIGcFqPmVlqKr93N/GNT/sRYgxxOIXpw +4nzu5sRB2uFJa+4ABUs6RrJ8QvSzzkZW72rXk0hYNygn8IuUX8YkQMgifEQ19KZ WLgxSrO5FnWPUkYL+X7i =EbAB -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd::tune_result_t vs. usrp2::tune_result
to work with the gr-uhd modules to (re)enable the use of UHD with the gnuradio-examples/python/digital stuff. awesome I'm a bit confused with the return value of the set_center_freq of the uhd_single_usrp_source. What I tried was to map the values of the uhd::tune_result_t into a usrp_tune_result. Does this make any sense to you guys? ;-) Its not quite a 1:1 mapping. I dont believe that any of the examples that use generic USRP even bother to look at the tune result. I would ignore this. Another question that arose while looking at the code concerns the change in the way we set the sample rate: In UHD, you set the sample rate. However for usrp2 and usrp1 gnuradio drivers, you set the decimation and interpolation and the sample rate is implied to be codec_rate/decim. I see two options: 1) change the options for the generic usrp to take a sample rate and internally (in generic_usrp.py) translate this into a decimation/interpolation number for non UHD case. or 2) add a new option that specifies the codec rate that can be used to calculate the sample rate from decim/interp for the UHD case. -josh Why do we have in the new UHD source: set_samp_rate (double rate) versus: set_decim (int decimation_factor) in the old USRP source? Thanks for your time again happy hacking - -Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM7mLVAAoJEOjnDXL6I0uZpHMP/28s/A98djBGYaeanGp54MXY khFV6Ltx0vsCNv6Uf4oJTsBdxhcqPX3x3YYbXCf5k7MXyQXxj23OrHVMtl2niVbc kbh2V710OTQEIC940ARrumPVTVDJ+A8vN76XGGGowZtJjMGaPYb20vyKkhqN5FWC k6+xhi/DUBCWIWWE/fyefP0zl3VhSIbV4L5zjWtoX/A1NTeTKZsq+UcsKz6ZVDCl UmZPBvav2PAIYpo99zvB3qZcxCPaGata09ZKsV03OeiUKG9yI1yUCXgj5tzhRNs2 dJFIAJAhkvI4rzV/GCYHI2WUuql758iCCPTbE4DLYBzyST/Eg5h1jveQetObIGpy PGMRGKv4jXg3BUQN6gxrI7SN2ZGSs8i+oxJdmu7pr1Zwnc3DxAVX9HgupfjARray MbO9RqbFKPoaWSwIJj6/SpNvVb/0b9zHPrN2UQWW31LfL4NS/3Ku5iTf3Fm5lx8l 7qLg+vJ4K35FO0iV/WIrOu+SHLPE8jiqlaaOgMC2pFfpqueLIMf5EXn0usiDgLjl IrvdxBzvMfPI4H+4UiNoMq3OD9v0jBFvaIGcFqPmVlqKr93N/GNT/sRYgxxOIXpw +4nzu5sRB2uFJa+4ABUs6RrJ8QvSzzkZW72rXk0hYNygn8IuUX8YkQMgifEQ19KZ WLgxSrO5FnWPUkYL+X7i =EbAB -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gr_pfb_clock_sync_ccf.cc question related to work function
Thanks for replying Tom. Happy Thanksgiving to you. Although I understand the idea behind this time sync method I still have a question regarding your code. You increment the count variable by samples per symbol value. The error control loop works at one sample per symbol and updates the pointer to the correct subfilter. By updating the count variable by d_sps aren't we losing information as we are dropping d_sps - 1 samples on every iteration of for-loop in work function. Thanks On Tuesday, November 23, 2010, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 22, 2010 at 6:01 AM, John Andrews gnu.f...@gmail.com wrote: I got it. The polyphase filter is implemented by having a single stage filter and choosing the right taps from the set of 'nfilts' taps rather than having nfilts filter stages. This of course is computationally more efficient. Hi John, Thanks for the question. And the answer. You had me worried for a second that I had missed something in the implementation. I was pretty sure I had this correct when fred and I were talking about all of this stuff last summer. As you've surmised, the implementation pretty much follows figure 13.21 in fred's book. Although he was looking at it being designed in an FPGA where he had to load the registers with the coefficients; instead, I just keep the bank of filter coefficients, each with their own symbol phase, and select the path into the bank based on the error estimate. So we select the appropriate filter path to go through and run that one stage. It's a neat trick as fred likes to say. And yes, literalnet, I understand that we're still actually loading the coefficients into registers. I'm only talking about how the C++ code was implemented conceptually as opposed to an FPGA design. Tom On Sat, Nov 20, 2010 at 9:47 PM, John Andrews gnu.f...@gmail.com wrote: Hi, I was trying to understand the code of the new clock sync block gr_pfb_clock_sync_ccf.cc and although I understand most of it there is one particular thing that confuses me. This is what I understood so far 1. There are two filter banks present. A) For RRC filtering B) the differential filter bank 2. These filters are implemented as polyphase filters thus, each of these filters has nfilts=32 sub-filters 3. The theory behind this block is found in section 13.3.2 of fred harris' book on multi-rate filters so I understand the concept behind this block pretty well. What confuses me is the coding. In line 265 of gr_pfb_clock_sync_ccf.cc out[i] = d_filters[d_filtnum]-filter(in[count]); the input to the block is passed only to one sub-filter of each filter bank. Why? Looking at the section in harris' book i thought it was an input to all the sub-filters and we choose one of the outputs as the sync'd sample. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] call set_output_multiple() on the fly
On Thu, Nov 25, 2010 at 11:11:27PM +1100, Kyle Zhou wrote: I am writing a module that might need dynamic change to the block length. So I want to call set_output_multiple(blk_len) when the flow graph is running. Firstly, is this allowed? Secondly, what are the effects? If I have a noutput_items%blk_len==0 checking in work(), will it fail during the transition? Thanks Kyle There is no guarantee that set_output_multiple will work if you change it on the fly. It is possible that you could specify a value for set_output_multiple that would require reallocation of the impacted buffers. We do not do that. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] call set_output_multiple() on the fly
On 26/11/2010 11:28 AM, Eric Blossom wrote: There is no guarantee that set_output_multiple will work if you change it on the fly. It is possible that you could specify a value for set_output_multiple that would require reallocation of the impacted buffers. We do not do that. Eric Thanks Eric. How about set_relative_rate()? can I call it on the fly? Another question: is it thread safe to modify the module's member variables from outside the work()? Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] call set_output_multiple() on the fly
On Fri, Nov 26, 2010 at 11:55:50AM +1100, Kyle Zhou wrote: On 26/11/2010 11:28 AM, Eric Blossom wrote: There is no guarantee that set_output_multiple will work if you change it on the fly. It is possible that you could specify a value for set_output_multiple that would require reallocation of the impacted buffers. We do not do that. Eric Thanks Eric. How about set_relative_rate()? can I call it on the fly? Small changes are OK. Large changes have the same problem as set_output_multiple. Another question: is it thread safe to modify the module's member variables from outside the work()? In general no, unless you do something to make it safe yourself. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] status of USRP2 on Mac
Hi, I'm wondering if someone can tell me the status of using a USRP2 with a Mac. I found an email on this thread from July 2010 saying that it needs UHD support (whatever that is), but version 3.3 has since been released. The wiki page for Mac install under getting started ( http://gnuradio.org/redmine/wiki/gnuradio/MacInstall) seems to be out of date and doesn't mention anything special about USPR2 at all. The macports install of version 3.3 seems to go OK, but there are no USRP2 related binaries. Any info much appreciated. Cheers, Randall. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] status of USRP2 on Mac
It should work fine with UHD and the gnuradio next branch. http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Gnuradio-UHD -Josh On 11/25/2010 10:53 PM, Randall Wayth wrote: Hi, I'm wondering if someone can tell me the status of using a USRP2 with a Mac. I found an email on this thread from July 2010 saying that it needs UHD support (whatever that is), but version 3.3 has since been released. The wiki page for Mac install under getting started ( http://gnuradio.org/redmine/wiki/gnuradio/MacInstall) seems to be out of date and doesn't mention anything special about USPR2 at all. The macports install of version 3.3 seems to go OK, but there are no USRP2 related binaries. Any info much appreciated. Cheers, Randall. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX 2400 collides with 802.11 AP?
I saw that RFX 2400 uses 2.3-2.9 GHz band In this document, however, http://www.ettus.com/downloads/ettus_ds_transceiver_dbrds_v6c.pdf an internal BPF filter out the non-ISM band frequency. Does that mean I cannot use 2.3G, 2.5G-2.9GHz? If so, I have an 802.11 AP, and these two can collide? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
