Re: [Discuss-gnuradio] PDUs in GNU Radio for UHD USRP Sink
> I noticed the comment about blocking, and wondered if a dedicated message handler would be a better option than overloading "calculate_output_stream_ length". Yes I think that would be a cleaner way that follows the GR message passing paradigm. > I was wondering if I should use the PDU to Tagged Stream block before going into the USRP, and it seems a common option to take. Using the Tag Debug block after the PDU to Tagged Stream block, I see that tx_sob, tx_time, and tx_eob pass through. Using a pdu_to_tagged_stream block would handle the conversion of PDU length to a tag that you could tell the USRP to look for using tsb_tag_name. However if you already have a block that correctly sets tx_sob/tx_eob tags, you wouldn't need this. If the USRP sink has tsb_tag_name="" (i.e., empty string), it will look for tx_sob/tx_eob tags by default. A nonempty tsb_tag_name will indeed ignore tx_sob/tx_eob tags. Sean On Wed, Nov 16, 2016 at 2:01 PM, Collins, Richard < richard.coll...@axenterprize.com> wrote: > Hey Sean, > > Thanks for the heads up. I was just looking through the > pdu_to_tagged_stream block for debugging. I noticed the comment about > blocking, and wondered if a dedicated message handler would be a better > option than overloading "calculate_output_stream_length". > > Thanks for the info about the tsb_tag_name... I was wondering if I should > use the PDU to Tagged Stream block before going into the USRP, and it seems > a common option to take. Using the Tag Debug block after the PDU to Tagged > Stream block, I see that tx_sob, tx_time, and tx_eob pass through. I'll > test ASAP to see if the USRP Sink listens to these tags (now that it should > see them). If not, I'll try setting the tsb_tag_name to packet_len (which I > guess causes the usrp sink to ignore tx_sob, tx_eob, etc.). > > Thanks again, > > - Rich > > On Wed, Nov 16, 2016 at 11:23 AM, Sean Nowlan <nowl...@ieee.org> wrote: > >> I think you will have to write a custom block that is similar to the >> pdu_to_tagged_stream block, but doesn't inherit from tagged_stream_block to >> avoid the limitation on the number of samples that can be handled. Here's >> how I'd do it, but keep in mind I haven't tried this and you may get into >> trouble doing blocking waits within the work method. >> * Copy pdu_to_tagged_stream in an OOT project. >> * Inherit from source_block instead of tagged_stream_block. >> * Move the stuff that's in "calculate_output_stream_length" into the top >> of the work method body. It looks like this will do a blocking wait with a >> timeout to see if there is a PDU available on the queue. If not, it should >> return 0 items. Once a PDU is found, it stashes the PDU's metadata, data >> vector, and length. >> * At the seciton of the work method that copies tags, I suggest keeping >> that code since it will copy your PDU length. The downstream USRP sink >> should be configured with a tsb_tag_name argument matching the 'packet_len' >> field in your PDU's metadata. >> * At the bottom of the work method, write as many items of the data >> vector to the output as noutput_items allows, and then decrement the number >> of remaining items to write. Keep an index or pointer into your current >> buffer and increment that too. After one or more work calls you should have >> written the entire buffer to the output and you can go back to looking for >> PDU packets on the input port. >> >> Hope this helps. >> >> Sean >> >> You'd have to add a message handler that stashes >> >> work >> >> On Thu, Nov 10, 2016 at 9:07 PM, Collins, Richard < >> richard.coll...@axenterprize.com> wrote: >> >>> Hello, >>> >>> I'm having trouble figuring out how to correctly send PDUs to the UHD >>> USRP Sink. It's my understanding (mostly from [1] and [2]) that you can >>> send a PDU with >>> >>>- a dictionary car containing "tx_sob" set to PMT_T, (and maybe >>>"tx_time" formatted according to notes in [2] or in the source code), and >>>- a uniform vector cdr containing complex32 samples to send. >>> >>> What I've done is make a block that accepts a stream of samples tagged >>> by a previous block (using stream tags), and saves them off to a >>> std::vector between the start and end tags. This part works as expected. >>> Once this vector (or "pkt_buffer") is full, other samples are ignored and >>> the transmission half of the code in this custom block is able to run. It >>> uses usrp->get_time_now() to check to see if some time has elapsed, and if &
Re: [Discuss-gnuradio] PDUs in GNU Radio for UHD USRP Sink
I think you will have to write a custom block that is similar to the pdu_to_tagged_stream block, but doesn't inherit from tagged_stream_block to avoid the limitation on the number of samples that can be handled. Here's how I'd do it, but keep in mind I haven't tried this and you may get into trouble doing blocking waits within the work method. * Copy pdu_to_tagged_stream in an OOT project. * Inherit from source_block instead of tagged_stream_block. * Move the stuff that's in "calculate_output_stream_length" into the top of the work method body. It looks like this will do a blocking wait with a timeout to see if there is a PDU available on the queue. If not, it should return 0 items. Once a PDU is found, it stashes the PDU's metadata, data vector, and length. * At the seciton of the work method that copies tags, I suggest keeping that code since it will copy your PDU length. The downstream USRP sink should be configured with a tsb_tag_name argument matching the 'packet_len' field in your PDU's metadata. * At the bottom of the work method, write as many items of the data vector to the output as noutput_items allows, and then decrement the number of remaining items to write. Keep an index or pointer into your current buffer and increment that too. After one or more work calls you should have written the entire buffer to the output and you can go back to looking for PDU packets on the input port. Hope this helps. Sean You'd have to add a message handler that stashes work On Thu, Nov 10, 2016 at 9:07 PM, Collins, Richard < richard.coll...@axenterprize.com> wrote: > Hello, > > I'm having trouble figuring out how to correctly send PDUs to the UHD USRP > Sink. It's my understanding (mostly from [1] and [2]) that you can send a > PDU with > >- a dictionary car containing "tx_sob" set to PMT_T, (and maybe >"tx_time" formatted according to notes in [2] or in the source code), and >- a uniform vector cdr containing complex32 samples to send. > > What I've done is make a block that accepts a stream of samples tagged by > a previous block (using stream tags), and saves them off to a std::vector > between the start and end tags. This part works as expected. Once this > vector (or "pkt_buffer") is full, other samples are ignored and the > transmission half of the code in this custom block is able to run. It uses > usrp->get_time_now() to check to see if some time has elapsed, and if so, > carves up the internal "pkt_buffer" vector into PDUs of the desired size > (e.g. a max of 512 samples long), and sends them out of the registered > message port. Externally, this port is connected to the "command" port of > the UHD USRP Sink block. > > I know these messages have a max size (I think of 4k samples), and it > seems to work best (e.g. without the flowgraph freezing freezing, or > uhd_usrp_source block taking up too much CPU of one core) when the size is > smaller (e.g. 512 samples). > > What happens though, as seen through captured samples from another SDR, is > the USRP will output nothing for a while (a little longer than the expected > length in time of my whole "packet" or set of PDUs). Then the USRP will > output what looks just like a carrier signal for the rest of the time > before the next burst of PDUs (I'm assuming from the Null Source feeding > into the UHD USRP Sink block's streaming "in" port, which must be connected > to something in GNU Radio). > > As a small side note, I don't get an error output except for a single U > per packet... it seems if I send too many PDUs (i.e. more than the first, > second to last, and the last), I'll get a "U" after a whole set of PDUs is > sent. I don't think that's a problem though. > > I've checked the output of this block with the message debug block, and it > seems that the correct samples are sent in the expected order. > > An example of what I'm trying to do (in C++) can be found here: > http://pastebin.com/uyNTkFmU > Documentation Used: > [1] - http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html > [2] - http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_ > command_syntax_cmds > [3] - http://gnuradio.org/doc/doxygen/page_pmt.html > [4] - http://gnuradio.org/doc/doxygen/page_msg_passing.html > Examples found: > [5] - https://github.com/bastibl/gr-foo/blob/master/lib/packet_ > pad_impl.cc helped, but he's using stream tags, not Asynchronous Message > passing > [6] - some examples in uhd/host/examples/ and > gnuradio/gr-uhd/examples/c++/ but mostly for testing uhd function calls to > get/set gps time. > > It's been suggested a couple times to use asynchronous message passing > instead of tagged streams when I've asked over the past year or so, and I > see why from an old post from Tim O'Shea's blog that shows the differences > in performance. I just don't know how to use his eventstream or other > underlying gr-vt blocks, and would like to rely on as few OOT modules as > possible. I've found a few examples where tagged streams are
Re: [Discuss-gnuradio] Fun with history
Great! I like not reinventing wheels (and other circular things like GR buffers). Thanks for the pointer about shared memory. Sean On Thu, Oct 6, 2016 at 4:46 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Sean, > > 2) sounds fine :) > > you might need to tell your OS that you need a lot of shared memory (or > else you'll run into the very BOFH-esque error "No space left on device" > when GNU Radio allocates buffers). > > Greetings, > > Marcus > > On 06.10.2016 20:20, Sean Nowlan wrote: > > Hi list - > > For a particular application, I need to make a block that can save a ton > of history in some type of circular buffer - think 10M+ samples - and the > entire buffer needs to be available inside of a call to work. It seems like > I have two choices: > > 1) Implement my own internal buffer, and create a state machine that > copies a batch of samples into the large buffer during each call to work. > After doing that, run the logic that needs access to huge history. > 2) Tell the scheduler to make the already-existing upstream buffer large > enough that I can declare an enormous history in my block. > > I understand that things like page size, architecture, available memory, > etc. come into play, but realistically will I be able to accomplish what I > want with setting a large output buffer on the upstream block (using > set_min_output_buffer) and using a set_history call on my block with a > large number? > > Thanks, > Sean > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://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
[Discuss-gnuradio] Fun with history
Hi list - For a particular application, I need to make a block that can save a ton of history in some type of circular buffer - think 10M+ samples - and the entire buffer needs to be available inside of a call to work. It seems like I have two choices: 1) Implement my own internal buffer, and create a state machine that copies a batch of samples into the large buffer during each call to work. After doing that, run the logic that needs access to huge history. 2) Tell the scheduler to make the already-existing upstream buffer large enough that I can declare an enormous history in my block. I understand that things like page size, architecture, available memory, etc. come into play, but realistically will I be able to accomplish what I want with setting a large output buffer on the upstream block (using set_min_output_buffer) and using a set_history call on my block with a large number? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Scale ESN0 on BER Curve Gen when using codes of different rates?
I'd like to use BER Curve Gen and QT BER Sink to simulate some FEC schemes that have different code rates. I'm wondering about the right way to do this so that the plots are w.r.t. EBN0 as opposed to ESN0. For example, in gr-fec/examples/ber_curve_gen.grc, plots are w.r.t ESN0. In order to make them plot w.r.t. EBN0, I imagine I'd want to scale the "esno_0" vector by the code rate for each FEC scheme and feed each to its BER Curve Gen block. This would be something like: esno_0 - 10.0*numpy.log10(.rate()) Then I would pass esno_0 unmodified to QT GUI Bercurve Sink. Does this sound reasonable? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Corrupted SDK installer
Thanks, this is a false alarm. It must have been an issue with downloading on Chrome for Windows on the machine I was using. I just verified that the file's SHA256 checksum matches the expected checksum on a Ubuntu system: $ wget http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh [...] $ sha256sum oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh Sean On Tue, May 3, 2016 at 1:22 PM, Tom Rondeau <t...@trondeau.com> wrote: > On Tue, May 3, 2016 at 10:51 AM, Sean Nowlan <nowl...@ieee.org> wrote: > >> I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here >> [1] is corrupted, or at least the download keeps failing in the same way. >> >> The SHA256 checksums do not match: >> Posted >> [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a >> Actual: d99df0557e8766d02036f583cca6fb95d066d7e7c7614f271c0b84efe711e81b >> >> This error occurs when the script is self-extracting: [3]. Note that the >> GUI version downloads properly and has a correct SHA256 checksum. >> >> Thanks, >> Sean >> >> [1] >> http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh >> [2] http://gnuradio.org/data/sdk/ >> [3] https://gist.github.com/nowls/f25cbfd314c47e9ecabd2a33d3e3399c >> > > > Sean, > > I'm not getting the same results. I checked both the local file on the > server and downloaded it myself onto another computer, and all SHA256 sums > match what's in that table for me. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK
Sorry, email confusion with IEEE email forwarding. Resending to hit discuss-gnuradio list. Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded Jethro. This version incorporated the bugfix, so it could theoretically be enabled in meta-sdr's gnuradio build. On Tue, May 3, 2016 at 11:51 AM, Sean Nowlan <nowl...@gmail.com> wrote: > Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded > Jethro. This version incorporated the bugfix, so it could theoretically be > enabled in meta-sdr's gnuradio build. > > Sean > > On Tue, May 3, 2016 at 11:39 AM, West, Nathan <n...@ostatemail.okstate.edu > > wrote: > >> ORC is still in VOLK, but it doesn't give you much. >> >> On Tue, May 3, 2016 at 11:32 AM, Philip Balister <phi...@balister.org> >> wrote: >> >>> On 05/03/2016 10:47 AM, Sean Nowlan wrote: >>> > According to the wiki [1], ORC support was disabled on armhf due to a >>> bug, >>> > which has apparently since been resolved [2]. Was ORC support added >>> back >>> > for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the >>> wiki >>> > page just out of date? >>> > >>> > Thanks, >>> > Sean >>> > >>> > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded >>> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464 >>> > [3] http://gnuradio.org/data/sdk/ >>> >>> I feel like we've replaced all the places we used orc, so we >>> (uhd/gnuradio/volk) are not really using it anymore. >>> >>> It tends to show up in images, just that it may not be used by gnuradio >>> and friends. >>> >>> Philip >>> >>> > >>> > >>> > >>> > ___ >>> > 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
[Discuss-gnuradio] Corrupted SDK installer
I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here [1] is corrupted, or at least the download keeps failing in the same way. The SHA256 checksums do not match: Posted [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a Actual: d99df0557e8766d02036f583cca6fb95d066d7e7c7614f271c0b84efe711e81b This error occurs when the script is self-extracting: [3]. Note that the GUI version downloads properly and has a correct SHA256 checksum. Thanks, Sean [1] http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh [2] http://gnuradio.org/data/sdk/ [3] https://gist.github.com/nowls/f25cbfd314c47e9ecabd2a33d3e3399c ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ORC support on armhf w/ embedded SDK
According to the wiki [1], ORC support was disabled on armhf due to a bug, which has apparently since been resolved [2]. Was ORC support added back for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki page just out of date? Thanks, Sean [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464 [3] http://gnuradio.org/data/sdk/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC Fails to Display QT/WX Elements
On 06/21/2013 09:56 AM, Tom Rondeau wrote:
The only thing that comes to mind is a problem we had with something
else that seems to be a result of using GCC 4.7. I always just use 4.6
to that I can build and use ControlPort. If someone who is having
these problems can tell me if they are using 4.7 or not, that'd be
great. Also, if you are using 4.7, could you move back to using 4.6
and rebuild GNU Radio with that and see if that fixes things? You can
apt-get install {gcc-4.6, g++-4.6} and then symlink /usr/bin/gcc-4.6
to /usr/local/bin/{gcc,cc} and /usr/bin/g++ /usr/local/bin/{g++,c++}.
Tom ___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On a Ubuntu system I find it easier to pass cmake the following to use
GCC 4.6 instead of messing around with symlinks:
cd ~/gnuradio/build
cmake -DCMAKE_CXX_COMPILER=g++-4.6 -DCMAKE_C_COMPILER=gcc-4.6
-DENABLE_GR_CTRLPORT=ON ../
--sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rrc_filter in generic_mod_demod
On 06/12/2013 12:42 PM, Dan CaJacob wrote: I think the range across which you have acceptable linearity may be somewhat related to the type of signal you are using. The general recommendation in the past has been to stick below 0.2 The graphs show that you only lose about 7 dBm of total possible power by backing off the digital amplitude to 0.2 max and you get a linear 1 dBm power output increase for every 1 dB gain increase across the entire gain range of the WBX. By they, it is a bit unrelated, but I also measured -119 dBm for 12 dB SINAD on the RX side with an 8920A specan. Very Respectfully, Dan CaJacob HiDan, Did you perform any measurements of amplitude and/or gain across the freq range of the board? I'd expect it to vary somewhat since it's such a wideband board, but it'd be interesting to learn the relationship. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Run time FIFO error
On 06/12/2013 08:09 PM, Marcus D. Leech wrote: On 06/12/2013 08:00 PM, Jay Prakash wrote: Sry, It's switch but not a dedicated one. Sample rate 1M. But error came even at 32k. Jay Prakash Well, 32K isn't a valid sample rate, Jay. Sample rates have to be a proper integer fraction of the master clock rate on the USRP device. For the N210, the minimum reasonable sample rate is 250ksps. The minimum reasonable sample rate I've used is 2e5 (100e6/2e5 = 500). I think 100e6/512 = 195312.5 is the smallest supported rate. Some switches are very poor at maintaining bulk traffic without dropping packets. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Run time FIFO error
On 06/12/2013 08:49 PM, Marcus D. Leech wrote: On 06/12/2013 08:29 PM, Sean Nowlan wrote: The minimum reasonable sample rate I've used is 2e5 (100e6/2e5 = 500). I think 100e6/512 = 195312.5 is the smallest supported rate. Yup, sorry, you're right. I tend to pick values that are valid for both 64Msps and 100Msps master clock rates, since I write apps that need to be reasonably agnostic with respect to hardware. Ah, makes sense. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Run time FIFO error
I think 512 is the max value for N on N200/N210 hence 195kSps is minimum sample rate. Karan Talasila karan@gmail.com wrote: @sean can you please tell me how you got minimum sampling rate for usrp N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N where N is an integer. So N can be any integer even greater than 512 right. In that way, what is the minimum that the USRP accepts. what is maximum N that can be used. On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan sean.now...@gtri.gatech.edu wrote: On 06/12/2013 08:49 PM, Marcus D. Leech wrote: On 06/12/2013 08:29 PM, Sean Nowlan wrote: The minimum reasonable sample rate I've used is 2e5 (100e6/2e5 = 500). I think 100e6/512 = 195312.5 is the smallest supported rate. Yup, sorry, you're right. I tend to pick values that are valid for both 64Msps and 100Msps master clock rates, since I write apps that need to be reasonably agnostic with respect to hardware. Ah, makes sense. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Regards Karan Talasila ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink
Do late packets always get dropped by the USRP? What happens if its buffers get filled up with samples, all of which are late? Marcus D. Leech mle...@ripnet.com wrote: L = late packet, there was a time on the packet which was time on device when There are two different cases for late packets happening. The first is that you haven't sent your packet far enough in advance to account for latency variations on the host. Unfortunately, on a general-purpose OS like Windows or Linux, latency variability can be extreme, and for long-running flow-graphs you might need to develop a good model to determine what the worst-case is and account for that. The second is that the clock on the USRP and the clock on the host will tend to drift apart over time, particularly if both of them are free running. So when you schedule timed bursts far enough in advance during the start of a session, it's entirely possible that after quite some time, the two clocks have drifted apart unfavourably in terms of allowing you to schedule things far enough in advance, relative to the USRP clock. PC clocks are *terrible* by themselves. They'll drift significant fractions of a second on a daily basis without any outside steering. The USRP clock, even free-running, is typically much, much better. -- 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] Detecting underflows with uhd_usrp_sink
On 06/10/2013 01:17 PM, Josh Blum wrote: On 06/10/2013 09:43 AM, Sean Nowlan wrote: Do late packets always get dropped by the USRP? What happens if its buffers get filled up with samples, all of which are late? The stream args have a policy parameter. Also, these args can be set from a parameter in the USRP GRC blocks, as well as the constructor for the gr-uhd blocks themselves. This should be helpful: http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second period with 50/50 duty cycle) and I started the flowgraph 10 minutes late. With the next_burst policy, could I rely on the USRP to dutifully drop all late bursts? Are the packets dropped in the Ethernet buffer or does the TX sample buffer fill up first? If it's the latter case, my scenario implies that the TX buffer will have to be filled and emptied multiple times until there are no more late packets, and normal transmissions begin. This would happen at the sample rate times the number of samples sent. I suppose I'd also want to implement a message handler to drop the flood of L symbols before they get piped to STDERR/STDOUT. Do I have the right understanding of this process? Thanks! --sean P.S. -- Copying to USRP list since this could be relevant to people there. -josh Marcus D. Leech mle...@ripnet.com wrote: L = late packet, there was a time on the packet which was time on device when There are two different cases for late packets happening. The first is that you haven't sent your packet far enough in advance to account for latency variations on the host. Unfortunately, on a general-purpose OS like Windows or Linux, latency variability can be extreme, and for long-running flow-graphs you might need to develop a good model to determine what the worst-case is and account for that. The second is that the clock on the USRP and the clock on the host will tend to drift apart over time, particularly if both of them are free running. So when you schedule timed bursts far enough in advance during the start of a session, it's entirely possible that after quite some time, the two clocks have drifted apart unfavourably in terms of allowing you to schedule things far enough in advance, relative to the USRP clock. PC clocks are *terrible* by themselves. They'll drift significant fractions of a second on a daily basis without any outside steering. The USRP clock, even free-running, is typically much, much better. -- 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 ___ 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] How to repeatedly continously transmit a signal from a file ?
On 06/04/2013 01:09 PM, Monahan-Mitchell, Tim wrote: - How is it possible to transmit a file (as a signal source) repeatedly and continously without interrupts (with gnuradio uhd) ?? Even without the USRP (i.e. just simulating with throttle graphical sinks and a file source) interrupts occurs (time-periods of no samples) for each time the file repeats (i.e. starts over from the beginning). Same thing with transmitting with USRP as uhd-source (then without throttling of course), however no underruns are reported. I want to continuously send a prepared signal from a file over and over again but can't accept the interrupts each time the file ends starts over. This happens even at slow sample rates and I want to transmit really fast! I might have found a solution to this about year ago but now I can't remember what I did... something simple... Somehow read in the whole file into cached memory so it doesn't need to be re-read from disk for each repetition (in Linux)... but how? Maybe create a small ram-disk outside of GNU Radio, then copy your file to it, then use the new path for the file source block? Depending how big this file is and how much memory you're willing to consume, you can read your file into a vector (from Python, this is pretty easy with numpy.fromfile() or a simple for loop ) and use it to initialize a vector source (with repeat=True). - Tim ___ 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] GnuradioConfig.cmake on master
GnuradioConfig.cmake was recently added to master. It broke finding
gnuradio-digital include directories. The reason for the failure was the
following line:
112GR_MODULE(DIGITAL gnuradio-digital digital/lfsr.h gnuradio-digital)
The LFSR and most other gr-digital components haven't been ported to 3.7
API on master branch, so digital/lfsr.h was not found. This change is a
band-aid:
112GR_MODULE(DIGITAL gnuradio-digital
digital/ofdm_frame_equalizer_vcvc.h gnuradio-digital)
There may be other packages that aren't found for similar reasons
(missing new-style/3.7 header format). I haven't tried them all.
For everybody's information, I got this to work in my out-of-tree
project by modifying my CMakeLists.txt file in the top-level project
directory:
# Find gnuradio build dependencies
...
# take a look at GnuradioConfig.cmake for the component names
set(GR_REQUIRED_COMPONENTS CORE ANALOG DIGITAL BLOCKS FFT FILTER)
# this is installed on a system path; there's no need to copy
GnuradioConfig.cmake
# to your gr-module/cmake/Modules directory
find_package(Gnuradio)
...
# Setup the include and linker paths
include_directories(
...
#{GNURADIO_ALL_INCLUDE_DIRS}
...
)
link_directories(
...
#{GNURADIO_ALL_LIBRARIES}
...
)
I hope this new config method finds its way into gr-modtool!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuradioConfig.cmake on master
On 05/09/2013 09:48 AM, Tom Rondeau wrote:
Good catch, Sean, and thanks for the patch as well! Seems I can't make
any changes without messing up between the master/next changes these
days... I'm making sure all of the components are searching for the
right headers in master and next.
Actually, I'm having trouble with the CORE component. Perhaps it's
conflicting with the FindGnuradioCore.cmake module.
This works:
find_package(GnuradioCore)
set(GR_REQUIRED_COMPONENTS ANALOG DIGITAL BLOCKS FFT FILTER)
find_package(Gnuradio)
This doesn't:
set(GR_REQUIRED_COMPONENTS CORE DIGITAL BLOCKS FFT FILTER)
find_package(Gnuradio)
cmake ../ succeeds and finds both libgnuradio-core.so and includes in
/usr/local/include/gnuradio. However, when I run make, I get:
fatal error: gr_io_signature.h: No such file or directory
Somehow the include statements aren't getting set correctly. I suppose I
need to keep find_package(GnuradioCore). If so, what's the purpose of
setting CORE (or RUNTIME) in GR_REQUIRED_COMPONENTS?
See the bottom of the main page in the Doxygen manual (you'll have to
build it yourself). It explains it a bit more. Since
GnuradioConfig.cmake is installed by GNU Radio, there's no need to put
it into modtool; you just have to use it in modtool if you want it's
functionality. Right now, by default, projects built with modtool only
look for libgnuradio-runtime, just to make sure it's there. If you
need the more complicated functionality the GnuradioConfig provides,
you can easily add that line to the CmakeLists file yourself to search
for the necessary components as well as the API compatible version you
need for your OOT project. So it doesn't really need to be part of
modtool. Thanks! Tom
Ok. Although, I don't think placing a couple of commented-out lines in
CMakeLists.txt would hurt, with a comment like, to use GR components,
uncomment the following and set GR_REQUIRED_COMPONENTS to libraries you
want to link.
Finally, it looks like it's not necessary to set include_directories
to ${GNURADIO_ALL_INCLUDE_DIRS} and link_directories to
${GNURADIO_ALL_LIBRARIES}. Cmake is a colossal mystery to me...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuradioConfig.cmake on master
On 05/09/2013 12:28 PM, Tom Rondeau wrote:
On Thu, May 9, 2013 at 11:56 AM, Sean Nowlan
sean.now...@gtri.gatech.edu wrote:
On 05/09/2013 09:48 AM, Tom Rondeau wrote:
Good catch, Sean, and thanks for the patch as well! Seems I can't make any
changes without messing up between the master/next changes these days... I'm
making sure all of the components are searching for the right headers in
master and next.
Actually, I'm having trouble with the CORE component. Perhaps it's
conflicting with the FindGnuradioCore.cmake module.
This works:
find_package(GnuradioCore)
set(GR_REQUIRED_COMPONENTS ANALOG DIGITAL BLOCKS FFT FILTER)
find_package(Gnuradio)
This doesn't:
set(GR_REQUIRED_COMPONENTS CORE DIGITAL BLOCKS FFT FILTER)
find_package(Gnuradio)
cmake ../ succeeds and finds both libgnuradio-core.so and includes in
/usr/local/include/gnuradio. However, when I run make, I get:
fatal error: gr_io_signature.h: No such file or directory
Try it from a clean build directory. I just did and it worked fine.
gr_io_signature.h is in $prefix/include/gnuradio, so if that's in your
include directories like you mentioned above, there should be no
reason for it not to find it.
Somehow the include statements aren't getting set correctly. I suppose I
need to keep find_package(GnuradioCore). If so, what's the purpose of
setting CORE (or RUNTIME) in GR_REQUIRED_COMPONENTS?
You should not need to use find_package(GnuradioCore) (or
GnuradioRuntime) if you are using the GnuradioConfig script. They are
duplications; the latter, if used, should replace any need for the
former in your cmake files.
Try it again. Like I said, I just tried it, and it worked fine for me.
I probably had some cached Cmake stuff that was getting in the way. When
purged the build directory it worked.
See the bottom of the main page in the Doxygen manual (you'll have to
build it yourself). It explains it a bit more. Since GnuradioConfig.cmake is
installed by GNU Radio, there's no need to put it into modtool; you just
have to use it in modtool if you want it's functionality. Right now, by
default, projects built with modtool only look for libgnuradio-runtime, just
to make sure it's there. If you need the more complicated functionality the
GnuradioConfig provides, you can easily add that line to the CmakeLists file
yourself to search for the necessary components as well as the API
compatible version you need for your OOT project. So it doesn't really need
to be part of modtool. Thanks! Tom
Ok. Although, I don't think placing a couple of commented-out lines in
CMakeLists.txt would hurt, with a comment like, to use GR components,
uncomment the following and set GR_REQUIRED_COMPONENTS to libraries you want
to link.
Sure, adding a comment is certainly appropriate here.
Finally, it looks like it's not necessary to set include_directories to
${GNURADIO_ALL_INCLUDE_DIRS} and link_directories to
${GNURADIO_ALL_LIBRARIES}. Cmake is a colossal mystery to me...
Eh, probably not. But they could be easy convenience variables to use.
And it doesn't hurt anything being there, even if unused.
Tom
Last thing: I have a couple C++ hier blocks that use components from
gr-analog and gr-digital. I needed to add GNURADIO_ANALOG_LIBRARIES and
GNURADIO_DIGITAL_LIBRARIES to lib/CMakeLists.txt:
target_link_libraries(${Boost_LIBRARIES} ${GRUEL_LIBRARIES}
${GNURADIO_CORE_LIBRARIES} ${GNURADIO_DIGITAL_LIBRARIES}
${GNURADIO_ANALOG_LIBRARIES})
Without this step I would get undefined symbol errors when trying to
run swigged blocks from Python. I don't quite understand why I didn't
need to include GNURADIO_BLOCKS_LIBRARIES or GNURADIO_FILTER_LIBRARIES,
which these modules also use. It may be something specific to my
code/configuration; it's hard to tell.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 13.04
On 05/03/2013 08:59 AM, Sean Nowlan wrote: On 05/02/2013 10:37 PM, Marcus D. Leech wrote: Has anyone experienced any build failures in UHD on Ubuntu 13.04 using build-gnuradio? I haven't upgraded my Ubuntu system yet, and I have had one report of a UHD build failure on Ubuntu 13.04 due to libboost1.49, but a manual upgrade to libboost1.53 cured it. I didn't try to build with Boost 1.49. I went straight to Boost 1.53 and haven't had any issues yet (knock on wood!). (Sorry - forgot to copy to list) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble posting messages to block's message port
On 05/03/2013 01:26 PM, Marcus Müller wrote: Hi Sean, have you tried using tb.msg_connect(src, out_port_id, dst, in_port_id) instead of tb.connect? Cheers Marcus I'm trying to post a message to a port from top_block as opposed to connecting the output port of one block to the input of dst. The documentation indicates this can be done using dst.to_basic_block()._post(port, msg).Unfortunately this is not working for me. http://gnuradio.org/doc/doxygen/page_msg_passing.html --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble posting messages to block's message port
On 05/03/2013 01:41 PM, Sean Nowlan wrote: On 05/03/2013 01:26 PM, Marcus Müller wrote: Hi Sean, have you tried using tb.msg_connect(src, out_port_id, dst, in_port_id) instead of tb.connect? Cheers Marcus I'm trying to post a message to a port from top_block as opposed to connecting the output port of one block to the input of dst. The documentation indicates this can be done using dst.to_basic_block()._post(port, msg).Unfortunately this is not working for me. http://gnuradio.org/doc/doxygen/page_msg_passing.html More precisely, posting the message doesn't fail, so I *guess* it worked. However the handler function is not called. I used the boost::bind call to bind the message handler function following the lead of the example code. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trouble posting messages to block's message port
I'm trying to create a block that accepts messages and prints them out. I created a block that extends gr_block and it has no stream ports: I'm using gr_io_signature(0,0,0) for input and output. I am following the guidance of this page: http://gnuradio.org/doc/doxygen/page_msg_passing.html From a test Python script I instantiate a top_block /tb/ and then connect my stream-port-less block with tb.connect(block_instance). I follow the lead of the page above to post a message, but the bound handler function never gets called (I inserted a line to print I'm here!! to stdout when the function gets called). Am I having issues because my block doesn't have any stream inputs or outputs? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New OFDM blocks
If I'm reading ofdm_carrier_allocator_cvc_impl.cc right, it appears that the user must make sure that the occupied carrier indexes and pilot tones don't refer to the same positions with OFDM symbols, otherwise the occupied data carriers will get blown array. Is this correct? --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 control GPIOs on SBX boards
On 04/23/2013 02:06 PM, Nelson Pina wrote:
Hi everyone,
I have been trying to make a gnuradio out-of-the-tree block that is
able to control the four GPIOs, currently attached to LED's, of the
SBX daughter-boards working with an USRP motherboard.
I wonder if anyone can help me on this, making a functional draft code
of such a block:
1 integer input - that will define the state of the GPIOs
1 parameter - to define the motherboard serial number
I believe that for people with knowledge of C++, and Python this is a
very simple module, unfortunately that is not my area since I'm a
hardware engineer and I only work with C.
I tried some approaches, using the gr_modtool to create the module,
but it always fails with GRC running errors like:
**
Traceback (most recent call last):
File
/home/to-nelsonpina/Desktop/locus_gnuradio/GRC_files/top_block.py,
line 16, in module
import gpio
File /usr/local/lib/python2.7/dist-packages/gpio/__init__.py, line
45, in module
from gpio_swig import *
File /usr/local/lib/python2.7/dist-packages/gpio/gpio_swig.py,
line 26, in module
_gpio_swig = swig_import_helper()
File /usr/local/lib/python2.7/dist-packages/gpio/gpio_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_gpio_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-gpio.so: undefined symbol:
_ZN3uhd4usrp10multi_usrp4makeERKNS_13device_addr_tE
*
This is most likely a failure to define the SWIG header file
appropriately, or possibly you've _declared_ a class that SWIG found but
you haven't _defined_ it. Finally because I just found this out the hard
way, if you're using the new code structure with block.h, block_impl.h,
and block_impl.cc, be aware that block.h needs to declare an abstract
class and its method declarations need to be pure virtual. block_impl.h
declares the concrete class and block_impl.cc provides concrete method
definitions.
If you want to unmangle that symbol, type this:
c++filt _ZN3uhd4usrp10multi_usrp4makeERKNS_13device_addr_tE
I will appreciate all the help I can get from you guys.
Best regards,
__
*Nelson Pina*
Product Developer
Hardware
*n.p...@tomorrow-options.com mailto:n.p...@tomorrow-options.com*
*T* +351 220 301 596 (PT)
*T* +44 114 213 2712 (UK)
*www.tomorrow-options.com http://www.tomorrow-options.com/
*Porto // Portugal
Sheffield // United Kingdom
http://www.tomorrow-options.com/http://www.linkedin.com/company/tomorrow-optionshttp://www.facebook.com/pages/Porto-Portugal/Tomorrow-Options/214846405104http://twitter.com/TomorrowOptionshttp://www.youtube.com/user/TomorrowOptionsTube
___
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] accessing gr-blocks, gr-filter, gr-digital, etc. in out-of-tree module
On 04/22/2013 11:59 AM, Sean Nowlan wrote: On 04/18/2013 12:28 PM, Tom Rondeau wrote: On Thu, Apr 18, 2013 at 12:15 PM, Sean Nowlan sean.now...@gtri.gatech.edu wrote: How does one setup cmake to find gr-blocks, gr-filter, etc. in out-of-tree modules? Is there already a cmake routine for this, or should I copy gr-newmod/cmake/Modules/FindGnuradioCore.cmake and plug in the right names? --sean There's a new FindGnuradio.cmake script, and I'm working on improving it to make it more usable by out of tree projects exactly for this purpose. You set(GR_REQUIRED_MODULES ...) and list, in all caps, which components you want (RUNTIME, BLOCKS, FILTER, etc). It will find them, setup some variables, and fail if they aren't installed on your system. If you don't set this variable, it defaults to searching for everything. So this sets up both include and linker paths? I've been trying to update some code to the new namespace-based API. I can compile OK but I'm getting symbol not found errors when importing from swig. It's possible the swig files aren't right, but I modeled them after the output of gr_modtool. I suspect there's a linking issue. That should read: I'm getting ImportError: [...] undefined symbol errors whenever I import the package. Everything compiles including SWIG wrapper file. As I said, though, I'm working on it to make it more easily usable, so some things about it might change. Also, can't remember if this is in master or just on next off the top of my head... I found it in 'next'. Tom --sean ___ 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] accessing gr-blocks, gr-filter, gr-digital, etc. in out-of-tree module
How does one setup cmake to find gr-blocks, gr-filter, etc. in out-of-tree modules? Is there already a cmake routine for this, or should I copy gr-newmod/cmake/Modules/FindGnuradioCore.cmake and plug in the right names? --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wiki/issue tracker access
Hi GR admins - When one of you gets a chance, could you please approve my wiki/tracker account if it isn't already? Thanks! Sean Nowlan sean.nowlan -at- gtri.gatech.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Long PDUs
I want to see whether very long PDUs would break the new tagged stream model implementation in recent GR versions. Let's say I want to use tagged streams with length tags to transmit streams that would require many more samples than a single call to work() could handle. From diving into the source code, streamed tag blocks look like they explicitly ask the scheduler for the exact number of samples needed to process an entire PDU. So it looks like I'll get into trouble here. I can see how this methodology is smart for many packet-based protocols, but I basically want to control gated streaming with precise timing control (using USRP). Many times I'll need to stream for seconds or minutes, which implies multiple calls to work() to generate samples. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Long PDUs
On 04/17/2013 11:34 AM, Martin Braun (CEL) wrote: On Wed, Apr 17, 2013 at 10:12:31AM -0400, Sean Nowlan wrote: I want to see whether very long PDUs would break the new tagged stream model implementation in recent GR versions. Let's say I want to use tagged streams with length tags to transmit streams that would require many more samples than a single call to work() could handle. From diving into the source code, streamed tag blocks look like they explicitly ask the scheduler for the exact number of samples needed to process an entire PDU. So it looks like I'll get into trouble here. I can see how this methodology is smart for many packet-based protocols, but I basically want to control gated streaming with precise timing control (using USRP). Many times I'll need to stream for seconds or minutes, which implies multiple calls to work() to generate samples. Hi Sean, thanks for trying the tagged stream blocks, they are still new and probably have some unexposed bugs. The actual derivation from gr_tagged_stream_block works on the paradigm that the processing is done frame-wise. This has signal processing advantages (e.g. if you're equalizing a frame with a 2D-equalizer, this is how you'd like your data to be available), and it also does not require the blocks to save state (i.e., where in the frame we are). So yes, you're right: Massive PDUs will cause them to break. However, this only a convenience. If you have special requirements, you can always use gr_blocks as before. Then, you must save state, but you don't have to wait for all the samples to be available before the block is called in the first place (because that's what gr_tagged_stream_block's are there for). So are you then bounded by max_noutput_items inherited from top_block (or set explicitly)? I didn't see any bounds checking on length tags to prevent massive PDUs in gr_tagged_stream_block. Also I see PDU length tags as solving another problem - letting intermediate blocks and sinks know how many items they will have to process in a row. As we've already discussed, packet-based flows are a good example. Another is the case I mentioned (though, yes, I can introduce a length tag to something that inherits gr_block). Another might be making a PPS signal with a large duty cycle, though there may be easier ways to do that. Finally, letting UHD know what to do with PDU length tags even when a burst is expected to be larger than one buffer passed one work() call. I can see you're tracking this last one already. :c) http://gnuradio.org/redmine/issues/530 As you also point out, they work well for packetized data transmission. When I was working on the new OFDM blocks, I had packets in mind on the same order as 802.11a packets, so buffer size was never a problem. MB ___ 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] Long PDUs
On 04/17/2013 01:52 PM, Johnathan Corgan wrote: On Wed, Apr 17, 2013 at 8:34 AM, Martin Braun (CEL) martin.br...@kit.edu mailto:martin.br...@kit.edu wrote: As you also point out, they work well for packetized data transmission. When I was working on the new OFDM blocks, I had packets in mind on the same order as 802.11a packets, so buffer size was never a problem. For robustness, we should probably have a way to retrieve what the MTU is for a tagged stream block. Just thinking out loud: could this be worked into the tagged_stream_block class? If mtu is left as a default, behavior will be identical to the way it's defined now and work() will always get called with the exact number of items a derived block wants. If a length tag comes along that is greater than the mtu, it should shout its disapproval and/or truncate the packet and/or fragment (though this introduces even more nightmares... what's next, fragment offset tags?? actually, maybe...). However if mtu is defined to be bigger than max_noutput_items/relative_rate, we should handle that case somehow. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ 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] Tiny, trivial change on master
I wasn't sure it was worth filing a bug report because it's a 1-char
documentation bug, but as you can see it's critical to the context:
diff --git a/gr-blocks/include/blocks/repack_bits_bb.h
b/gr-blocks/include/blocks/repack_bits_bb.h
index 268e4ee..f33d4bd 100644
--- a/gr-blocks/include/blocks/repack_bits_bb.h
+++ b/gr-blocks/include/blocks/repack_bits_bb.h
@@ -30,7 +30,7 @@ namespace gr {
namespace blocks {
/*!
- * \brief Pack \p k bits from the input stream onto \p k bits of
the output stream.
+ * \brief Pack \p k bits from the input stream onto \p l bits of
the output stream.
* \ingroup byte_operators_blk
*
* \details
--sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Extending UHD USRP Sink in out-of-tree module
On 04/14/2013 05:53 AM, Josh Blum wrote: On 04/12/2013 07:45 PM, Sean Nowlan wrote: I mean to set those controls dynamically based on incoming stream tags, similar to the way burst tags work. For instance I designed a tx_gain tag that gets read by uhd_usrp_sink and sets the gain using set_command_time. I just wanted to know the easiest way to move this modified sink to an OIT of tree module, even though I'll be duplicating most of the gr-uhd code to do it. I see. Sounds like it doesn't fit well. I wouldn't recommend tags or for that matter modifying the source/sink block. Since 1) the control is async to the data anyway, 2) the control would get delayed by the data pipeline, 3) it wouldn't make sense in the case of the source block. Rather I would create another block which opens a usrp session and accepts control messages to act on. I happen to have one in the works, but its not ready yet. So that is to say I'd use the standard gr_uhd_usrp_sink block for the data pipe and I'd create a separate USRP session from my own custom block to handle just the control logic (timed gain and DUC retuning commands, etc.)? It looks like you're working on exactly the types of things I'd like to do: https://github.com/guruofquality/grextras/blob/next/lib/uhd_control_port.cpp I was thinking, since there's a limited command buffer in the USRP, would it make sense to add a message queue and encode timestamps and commands into the message? Is there a way to test the FPGA command buffer for fullness or some other way to prevent overflow? Also, if it fit well, you would FWIW, open the usrp device session in your control block/IP, whatever that may be, and talk directly to it. That may be convenient. A lot less to maintain out of tree in either case anyway. -josh Josh Blum j...@ettus.com wrote: On 04/12/2013 07:00 PM, Sean Nowlan wrote: I want to add some functionality to gr_uhd_usrp_sink to change frontend gain and tune the DDC. I've achieved part of this in the past by Hooks are already exposed to set individual gain element, or individual parts of the tuning chain. The later is even available in GRC. What specifically is missing? modifying the files directly in gnuradio/gr-uhd, but that's an imprecise way to do it. Would you recommend I: 1) copy the code from the gnuradio tree to my out-of-tree module, change namespaces, etc. and add my functionality? 2) create my own private uhd_usrp_sink_impl that extends gnuradio's uhd_usrp_sink and add my functionality there? 3) something else? If its using stock FPGA images and all, branch off of the gnuradio maint, contribute the changes back. I remember reading something on this list from somebody who rolled their own usrp wrapper. Any hints? That turned out to be an attempt to set gain from the work function based off of some older USRP1 app that did the same. In any case, it actually wasnt needed. -josh Thanks, Sean ___ 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
Re: [Discuss-gnuradio] GNU Radio enabled Bluetooth transeiver other then USRP
I'm not sure of its status, but there's a researcher building a cheap SDR for doing Bluetooth security research (among other uses): http://greatscottgadgets.com/hackrf/ --sean karimkhan khan_karim2...@yahoo.com wrote: ___ 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] Extending UHD USRP Sink in out-of-tree module
I want to add some functionality to gr_uhd_usrp_sink to change frontend gain and tune the DDC. I've achieved part of this in the past by modifying the files directly in gnuradio/gr-uhd, but that's an imprecise way to do it. Would you recommend I: 1) copy the code from the gnuradio tree to my out-of-tree module, change namespaces, etc. and add my functionality? 2) create my own private uhd_usrp_sink_impl that extends gnuradio's uhd_usrp_sink and add my functionality there? 3) something else? I remember reading something on this list from somebody who rolled their own usrp wrapper. Any hints? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Async Messages for Tx Timestamps
On 04/08/2013 04:45 PM, Jordan Otomo wrote: Hi, I have a packet-based application where it would be useful to know exactly when each packet has been successfully radiated by the USRP (N200). It seems that UHD and gr-uhd already provide similar functionality for receiving asynchronous messages when a burst has been successfully transmitted (EVENT_CODE_BURST_ACK). However, in my application, I'm transmitting continuously and don't use end_of_burst tags. Would it be possible for the USRP to post messages to the event queue when it has transmitted a sample with a generic tag attached? If not, will I experience an interruption of my signal or any latency if I insert end_of_burst tags into my continuous stream of samples? Your advice is greatly appreciated. I'm a bit confused by what you mean when you say you're transmitting continuously in a packet-based application. Are the packets back-to-back in your sample stream? Or are you stuffing a bunch of zero samples in between packets? That isn't the cleanest way to do it. It would be better to use start-of-burst (tx_sob) and end-of-burst (tx_eob) tags if you're using gnuradio. Gnuradio end-of-burst tags will signal UHD firmware to bring down the TX chain. The tag gets converted into a flag in a metadata struct. This struct is sent with an 1-sample buffer of samples when send(...) is called in gr_uhd_usrp_sink. (See line 376 and thereabouts here: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_sink.cc). Thanks! Jordan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hope this helps! --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wireshark Help
Perhaps you mean the TCP or UDP sink block? Matt D md...@nycap.rr.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Nick, I was under the impression that gnu radio had a sink that would send packets to an ip address on the local machine. the guys at osmomcom did it somehow but their site is down (sad). Thanks, Matt - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRTE++AAoJEIC13XTKWhPPeaUIALuV14X3QrSJ/0blbQUnae7g KLvyHLRy52MTVDDUZIEKoT5hUM4UA5fkOefUjM3AcsZsvblEAsqlYww8+jP3UMgw dbaUgBlj8xfsVPneJS8YntljvIM9GXtAz0cC5Y7+bRjGKCXNlfervwhGJ/cI2S53 GvkYP15aRhYj1sqVRGD2jBQnYuig9eUqQBjalCxG/63Fzw/+AwdfUEW6Tcp4dkb2 Bk7iWnsPFc/pLNcxtdrUT2ea5FHQmeC0sNBbcQKgn4WD0Ar2W7a+IC8BTMvnbZkv igWUBIYMjHPurei11yMhL7HH8kxoEmjVBuTCcZcvE+GhlkpPvR6rSQzo7OYhhFo= =XR7H -END PGP SIGNATURE- ___ 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] Wireshark Help
On 03/22/2013 11:06 AM, Matt D wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/22/2013 09:58 AM, Sean Nowlan wrote: Perhaps you mean the TCP or UDP sink block? Matt D md...@nycap.rr.com wrote: Thanks Nick, I was under the impression that gnu radio had a sink that would send packets to an ip address on the local machine. the guys at osmomcom did it somehow but their site is down (sad). Thanks, Matt --- Sounds right but I am stuck trying to find out how to send the packets to the wireshark interface. Thanks (Replying to list) You should be able to point the TCP/UDP sink to localhost on some high-numbered port that you choose. Then in Wireshark, capture on the local interface, usually lo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRTHOAAAoJEIC13XTKWhPP5IAIAI7tc7DhiJP56RdDbvVnUDGy ryrFiMeitCz59mz5SfylB6wtXsAXgmUCOBUOuQJdbs/7sHmGuLBmnarZmq5mgFQs yMh2n/v7X1yQbvb4/rh+gT24CvuWHw9jsZMM8mf/Ko5yoZ+FCP1EqolUEx7QccqW R4nAyujLbYoHzQ6Xh0gXoaqgxn3cnBafiCeQtQSAVXXSVDDUMYU95KBccgM2CEA9 AYVEkvblr+WezGiKJTHpRxz1kfsEkWIz/Ng3ToKW+NRRia6JGZBrppEGOIyGifGK 8zzRym9MFaHY6ktFVmNwSdN/xU6Xj9+31I3EOPITieSIq5iTpuFKstW6Kj3JWHU= =Wq7d -END PGP SIGNATURE- -- *Sean M. Nowlan* Research Engineer I ICL/CNSD Georgia Tech Research Institute 250 14th St NW, Suite 470 Atlanta, GA 30318 404.407.7952 sean.now...@gtri.gatech.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [BULK] Fading channel in GNURadio
On 03/21/2013 03:45 PM, Manu T S wrote: I'm trying to make a block for fading channel model using hierarchical block. class channel(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, channel, gr.io_signature(1, 1, gr.sizeof_float), gr.io_signature(1, 1, gr.sizeof_gr_complex)) self.taps = generate_taps() self.filt = filter.fir_filter_ccc(1, self.taps) self.connect(self, self.filt, self) def generate_taps(): n_taps = random.randint(1, 10) r_taps = random.rand(n_taps) i_taps = random.rand(n_taps) return r_taps + 1j*i_taps I want the block to be able to update the channel filter taps in run time. Can I do that? Can I define a function in the class so that the filter taps are updated for every 5 seconds? The set_taps function gives you access to this from the top_block level. In that case, your main thread would be updating the block's taps using a while loop with sleep(5). You could also make a block class that inherits from fir_filter_ccc or channel_model and change the taps within the work function every N seconds: every time (ninput_items / samp_rate) % N == 0. I hope that's enough info to point you in the right direction. Thank you. -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *Sean M. Nowlan* Research Engineer I ICL/CNSD Georgia Tech Research Institute 250 14th St NW, Suite 470 Atlanta, GA 30318 404.407.7952 sean.now...@gtri.gatech.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [BULK] Rx/Tx gain
On 03/14/2013 07:41 AM, Nada ABDELKADER wrote: Hi, Would you plz tell me the best way to set the gain values for Rx/Tx USRP with benchmark_tx and benchmark_rx at command line. How to adjust these values? Thanks. This message was sent using IMP, the Internet Messaging Program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The process is trial-and-error and involves a lot of things, including but not limited to: 1) free space loss between the transmitter and receiver 2) whether the transmitter and receiver are so close that you're coupling signals on the front-end unintentionally 3) noise My recommendations: - Open up an FFT plot using uhd_fft on the receiver and set the gain slider somewhere in the middle (tune it to Rx freq, obviously) - Run benchmark_tx.py on the transmitter with default gain and tx-amplitude settings - See how strong the signal looks on uhd_fft. I've found you need 25 or 30+ dB SNR to make it work (I don't remember the exact numbers) - If you have a board with no front-end gain, such as RFX2400, increase the tx-amplitude parameter in small steps and see if you get better results. If you see clipping/compression - you'll see a big, wide, ugly signal on uhd_fft - you've gone too far. Keep in mind that the gain is specified in the range [0, 1.0] inclusive, but the lower and upper regions don't produce a clean, linear signal. You should stay in the 0.1-0.2 range but your mileage may vary. - If your board does have front-end gain, leave the tx-amplitude at its default value and change the gain only. - You may have to adjust the uhd_fft Rx gain, but again, beware of clipping on the Rx side. - Once you think you have the numbers right, try running benchmark_rx.py with the same Rx gain setting you found with uhd_fft.py and the same Tx gain settings you found for benchmark_tx.py. HTH. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 124, Issue 13
On 03/13/2013 01:24 PM, Elvin Mollinedo Mencia wrote: Estimados señores ettus Quisiera q me ayuden con mi usrp 2 con quien puedo contactarse para hacerme acesorar como puedo hacer una central telefónica con el proyecto OPEn bts, agradeciendo su ayuda. Saludos Elvin Mollinedo Santa Cruz - Bolivia Enviado desde mi iPhone I would ask for help on the OpenBTS mailing list: openbts-disc...@lists.sourceforge.net If you're having trouble with USRP 2 hardware, ask on the USRP list: usrp-us...@lists.ettus.com --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Copyrights using gr-modtool
I've noticed that gr-modtool keeps FSF's copyright assignment for a lot of boilerplate (CMakeLists.txt, QA code, etc.) but puts a hook for the end user's copyright statement in block source files. Is this a pretty standard way of doing things? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Copyrights using gr-modtool
On 03/12/2013 11:24 AM, Tom Rondeau wrote: On Tue, Mar 12, 2013 at 11:22 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Mar 12, 2013 at 11:04:20AM -0400, Tom Rondeau wrote: On Tue, Mar 12, 2013 at 10:29 AM, Sean Nowlan sean.now...@gtri.gatech.edu wrote: I've noticed that gr-modtool keeps FSF's copyright assignment for a lot of boilerplate (CMakeLists.txt, QA code, etc.) but puts a hook for the end user's copyright statement in block source files. Is this a pretty standard way of doing things? Yes, pretty much. Of course, this is just my understanding of how copyright of works is handled, and obviously IAMAL. I assume you meant 'IANAL'. It kind of reads the opposite way :) MB Yeah, typo Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio With the understanding that I will *not* take any answers as *actual* legal advice, is it generally reasonable to say: 1) If I copy a gnuradio block (copyright FSF), tweak a few things, and redistribute, FSF retains copyright and I have no copyright to the changes 2) If I build a block from the ground up, it's still GPLv3 since it depends on gnuradio, but I may either maintain copyright or assign it to FSF --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reg:Tags_demo.cc example
On 03/12/2013 02:14 PM, Josh Blum wrote: On 03/11/2013 09:52 PM, john jade wrote: Hi, 1. What is get_full_seconds and get_frac_seconds printing? Its probably the receive timestamp, its the time stamp from this object: http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html 2.Can we get upto precision of nano seconds using the above methods and please tell me how to do it. The fractional seconds are stored as double precision floating point. This gives the fractional seconds enough precision to unambiguously specify a clock-tick/sample-count up to rates of several petahertz. Although time can be *represented* with petahertz+ resolution, doesn't the hardware clock constrain the *realizable* resolution? For example on a USRP with a 100 MHz FPGA clock, would actual transmit precision be limited to 10 ns? -josh In the frac seconds i am getting 0.xx(only 6 digits after point-micro seconds) 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Copyrights using gr-modtool
1) If I copy a gnuradio block (copyright FSF), tweak a few things, and redistribute, FSF retains copyright and I have no copyright to the changes No, that's not what I said (or at least meant). The code generated from gr-modtool is copyrighted by the FSF. If you add any modifications to the file, that new code will be your copyright. You would then add a copyright notice into the file to say that this is copyright you, 2013. Ok, thanks. I didn't mean to imply that's what you said; just getting further clarification. :) Basically I'll retain FSF copyright notice (it would be a violation to remove it) and add mine. --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
