Re: [Discuss-gnuradio] The bug in gr_bytes_to_syms?
On Tue, Nov 10, 2009 at 11:14:24PM -0800, Firas Abbas wrote: Welcome back Eric! Thanks Firas! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The bug in gr_bytes_to_syms?
why are we awake so late anyways? On Wed, Nov 11, 2009 at 2:07 AM, Eric Blossom e...@comsec.com wrote: On Tue, Nov 10, 2009 at 11:14:24PM -0800, Firas Abbas wrote: Welcome back Eric! Thanks Firas! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Adam Lee email: adamryan...@gmail.com cell: 515-833-0533 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Irregular sampling of input stream
I don't want to reconfigure the graph at run time, but I want to minimize the use of CPU on my parallel path. Essentially, this extra path is 'raw' USRP samples which are really only required when packets are successfully received. Otherwise, the main path is a classic digital radio one, moving from samples to symbols to bytes. I just want to save time by not processing *all* of the raw samples all the time on the extra path. Maybe this is not possible. One idea to do this would be to use a carrier- probe (look in gnuradio-examples/python/digital/benshmark_rx.py), and look at it's state. The probe is basically a power- threshold, so if you have a state change from muted to unmuted, you may save the previous few buffers. Have a look at the gr_message_*- classes... I think you could do it with some sort of callback function, which looks at the state of the probe and depending on the state drops the message in the queue on the floor, or saves it to some other buffer, maybe puts it in a message- source, which is connected to a file- sink or similar. When I do testing I hook a file- sink to the output of every block in my flow- graph. The files get very big very fast, but they should be manageable if the measurement is short. Regarding real time/synchronization. There is a gnuradio real time library, gruel, which is kind of useful, have you had a look at that? If I remember correctly, the gruel- lib sets the priority to about 75% of maximum priority. Hi, I was beginning to write an answer to your first mail, but something distracted me, and I suppose it never got sent. I'm still not exactly sure what you are asking, but from what I can recall, I was writing something about having a look at the gr_basic_block, gr_top_block and their likings. Not much of a response to my initial question, so I'll try to be more specific with my questions. What is the best way to send a gated/non-continuous gnuradio signal stream between signal processing blocks? My main signal path is a 'standard' digital radio demodulation process, where data travels through a cascaded chain of processing blocks, being converted from samples to symbols and then to bytes. However, I want to supplement this path with an auxilliary on/off gated stream of 'raw' USRP samples from the earliest block, which handles samples, to one of the later ones in the chain, which handles bytes. My current approach is to create an extra output in the sample-processing C++ block and then hook it up (in Python) to the newly-created input of the downstream C++ byte-processing block. * Q1: Are there any scheduling/synchronization/real-time issues in gnuradio with stopping and starting a gnuradio stream (using feedback signalling between blocks or otherwise) like this? - In my application, I need to ensure that the series of 'raw' samples is the complete continuous set of samples that occured before a particular bit was detected in the main demodulation path. With the assumption that you do not suffer from under- /over- runs, the samples should be in sequential order. Have a look at the implementation of the usrp_sink_x blocks... Regarding stopping and starting flow- graphs, do you want to reconfigure the flow- graph runtime? I'm not sure how much time it takes to do this, I have always assume it's time- consuming, since it requires you to pause the entire flow- graph, reconfigure and then start it again. (As I have come to understand this, others are welcome to correct me) I think there might be something similar in the digital- example folder, for receiving packets. There is a carrier sense- probe, which _might_ do something like what you are trying to do. But since I'm not sure... * Q2: Should I avoid such signalling feedback and just throw away the samples at the downstream bit-processing block (e.g. by selectively routing to a sink or to a local data structure in the downstream processing block) or is this too expensive for CPU processing time? * Q3: Are there existing routines for timestamping samples/symbols/bits accurately enough so that they can be accurately cross-referenced with each other? Answers/ suggestions/ warnings/ advice/ approaches/ pointers_to_similar_examples would all be appreciated. / David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hello world ex. grc problem
Hi everyone, I am newbie both at gnuradio and linux environment and I am currently working on a project about usrp. First of all I've installed the gnuradio-3.2.2 and ubuntu 9.04. Then i tried to run the dial tone example. When i run dial tone example on http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html on the terminal there is nothing wrong, i mean it doesn't give any error messages but i can't hear anything from my computer's speakers. Do i have to do any extra process to execute the code? My second question is about the grc. I wanted to use this gui to try some examples. But when i write the terminal grc i got this messages; meh...@mehmet-laptop:~$ grc Generic Colouriser 1.1 grc [options] command [args] Options: -e --stderrredirect stderr. If this option is selected, do not automatically redirect stdout -s --stdoutredirect stdout, even if -e is selected -c name --config=nameuse name as configuration file for grcat --colour=word word is one of: on, off, auto Is there something wrong with it? How can i open the grc GUI ? Thanks ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: hello world ex. grc problem
About my second question: Now I noticed that I have another program with a name of generic colouriser and when i type grc on the terminal i run this program. Now i uninstall generic colouriser and then type grc again but now i got this message: File /usr/lib/python2.6/email/__init__.py, line 82, in __getattr__ return getattr(mod, name) File /usr/lib/python2.6/email/__init__.py, line 82, in __getattr__ return getattr(mod, name) RuntimeError: maximum recursion depth exceeded Original exception was: Traceback (most recent call last): File /usr/bin/grc, line 48, in module from gnuradio.grc.python.Platform import Platform File /usr/lib/python2.6/dist-packages/gnuradio/grc/python/Platform.py, line 22, in module from .. base.Platform import Platform as _Platform File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 22, in module from .. base import ParseXML, odict File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/ParseXML.py, line 20, in module from lxml import etree File lxml.etree.pyx, line 188, in lxml.etree (src/lxml/lxml.etree.c:124917) LookupError: unknown encoding: ASCII The second question in the first mail is invalid! Thanks... 2009/11/11 mehmet kabasakal 85kabasa...@gmail.com Hi everyone, I am newbie both at gnuradio and linux environment and I am currently working on a project about usrp. First of all I've installed the gnuradio-3.2.2 and ubuntu 9.04. Then i tried to run the dial tone example. When i run dial tone example on http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html on the terminal there is nothing wrong, i mean it doesn't give any error messages but i can't hear anything from my computer's speakers. Do i have to do any extra process to execute the code? My second question is about the grc. I wanted to use this gui to try some examples. But when i write the terminal grc i got this messages; meh...@mehmet-laptop:~$ grc Generic Colouriser 1.1 grc [options] command [args] Options: -e --stderrredirect stderr. If this option is selected, do not automatically redirect stdout -s --stdoutredirect stdout, even if -e is selected -c name --config=nameuse name as configuration file for grcat --colour=word word is one of: on, off, auto Is there something wrong with it? How can i open the grc GUI ? Thanks ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Zigbee MAC
Hi, I am using UCLA_Zigbee_Phy on RFX2400 boards and trying to transmit IEEE802.15.4 Zigbee packets using the board. I am also working on developing a MAC layer stack for the same. I kindly request you to let me know whether anyone is working on it and also could I use a code which is available as of now. Please share your thoughts about how to go about the same. Thanks and Regards, Sivaram ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Halfband filter coefficients help
Ilkyoung Kwoun- Thank you for your advice. Actually I am aware of basic characteristics of half band filter. It is very well explained in Rick Ryon's Understanding Digital Signal Processing (2nd Ed.) ( http://www.amazon.com/Understanding-Digital-Signal-Processing-2nd/dp/0131089897/ref=sr_1_1?ie=UTF8s=booksqid=1257900094sr=8-1 ) The thing I do not have any clue is the 'inner' and 'outer' coefficient things in FIR filter. I guess this is something related to the practical implementation issue rather than the fundamental concept. I did a simple googling yesterday and found a paper. ( http://ce.et.tudelft.nl/publicationfiles/1090_509_shahbahrami_prorisc2005.pdf) I hope I can find a way to get started. :-) Here is a Hypersignal log-magnitude plot showing the frequency response of the two halfband filters (31-tap in blue, 7-tap in red): http://www.signalogic.com/images/gnu_radio_halfband_filters.jpg In the plots I used an arbitrary sampling rate of 25 MHz -- don't know what you're using. Note that both filters have an approx -6 dB point at Fs/4 as would be expected due to halfband symmetry properties. As for inner and outer mention in the Verilog code, I might guess that refers to 2 multiplies needed when filtering a complex signal. As for why there are two (2) filters, one is used for higher rate up/down conversions and the other for lower rate. Firas' documentation has some information on this... also here is QA exchange between Firas and Matt that might help you out: http://old.nabble.com/Some-USRP2-Questions-td20729711.html -Jeff 2009/11/10 Sebastiaan Heunis sheu...@gmail.com Hi I think Brian is just referring to the fact that you can see that the HBFs are implemented as symmetric FIR filters (the coefficients). A HBF is just a special filter that is designed so that the cutoff frequency will always be at fs/2, so if you filter with it and decimate by 2 afterwards (which is why you would use an HBF), you don't get aliasing. Also, the decimation in the CIC filters can be set to a wide range of values, so the HBF will always have to cut at fs/2 regardless of the decimation in the CIC. From what I've read, Goodman and Carey came up with them so you can probably look for some papers if you're interested. Sebastiaan -- Sebastiaan Heunis Radar Remote Sensing Group, University of Cape Town, South Africa Tel: +27 72 950 9370 ___ 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] USRP2 Halfband filter coefficients help
Hi I can help a bit with the implementation of the one HBF. It has 31taps, of which every second one, apart from the center one is zero. the center one is scaled relative to one (2^18 on the FPGA). In total there is therefore (16+the center one) non-zero taps. This requires 8 multiplications (because of the symmetry, we can simply add the 1st and 31st,3rd and 29th values,etc. and then multiply by the appropriate tap value. For the center tap,we just need to bit-shift the sample at that position appropriately. Hope this helps a bit. Sebastiaan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Halfband filter coefficients help
I will explain the RX side, the TX side is basically the same. small_hb_dec is the short filter which works at the higher rate. There are 2 of them instantiated, one for I and one for Q. It has 7 taps. One of those taps is the center tap which only requires a shift and not a multiply, and 2 of those taps are zeros. That leaves 4 taps. The taps are symmetric, which leaves 2 multiplies per output. Since we have at least 2 cycles to produce each output, we can use a single multiplier. hb_dec is 2nd halfband filter and it works at the lower rate. There are 2 of them instantiated, one for I and one for Q. It has 31 taps. One of those taps is the center tap which only requires a shift and not a multiply, and half of the remainder are zeros. That leaves 16 taps. They are symmetric, so that means we need to do 8 multiplies to produce each output. There are at least 4 cycles to produce each output, so we need to do 2 multiplies at a time. One of those multipliers does the outer coefficients, meaning the ones at the very beginning and end of the impulse response, and one does the inner coefficients, meaning the ones around the center of the impulse response. This division is purely an implementation choice, and does not affect the output. I could have put the odd ones on one mult and the even ones on the other, or any other split you could imagine. It doesn't matter. Matt Jeff Brower wrote: Ilkyoung Kwoun- Thank you for your advice. Actually I am aware of basic characteristics of half band filter. It is very well explained in Rick Ryon's Understanding Digital Signal Processing (2nd Ed.) ( http://www.amazon.com/Understanding-Digital-Signal-Processing-2nd/dp/0131089897/ref=sr_1_1?ie=UTF8s=booksqid=1257900094sr=8-1 ) The thing I do not have any clue is the 'inner' and 'outer' coefficient things in FIR filter. I guess this is something related to the practical implementation issue rather than the fundamental concept. I did a simple googling yesterday and found a paper. ( http://ce.et.tudelft.nl/publicationfiles/1090_509_shahbahrami_prorisc2005.pdf) I hope I can find a way to get started. :-) Here is a Hypersignal log-magnitude plot showing the frequency response of the two halfband filters (31-tap in blue, 7-tap in red): http://www.signalogic.com/images/gnu_radio_halfband_filters.jpg In the plots I used an arbitrary sampling rate of 25 MHz -- don't know what you're using. Note that both filters have an approx -6 dB point at Fs/4 as would be expected due to halfband symmetry properties. As for inner and outer mention in the Verilog code, I might guess that refers to 2 multiplies needed when filtering a complex signal. As for why there are two (2) filters, one is used for higher rate up/down conversions and the other for lower rate. Firas' documentation has some information on this... also here is QA exchange between Firas and Matt that might help you out: http://old.nabble.com/Some-USRP2-Questions-td20729711.html -Jeff 2009/11/10 Sebastiaan Heunis sheu...@gmail.com Hi I think Brian is just referring to the fact that you can see that the HBFs are implemented as symmetric FIR filters (the coefficients). A HBF is just a special filter that is designed so that the cutoff frequency will always be at fs/2, so if you filter with it and decimate by 2 afterwards (which is why you would use an HBF), you don't get aliasing. Also, the decimation in the CIC filters can be set to a wide range of values, so the HBF will always have to cut at fs/2 regardless of the decimation in the CIC. From what I've read, Goodman and Carey came up with them so you can probably look for some papers if you're interested. Sebastiaan -- Sebastiaan Heunis Radar Remote Sensing Group, University of Cape Town, South Africa Tel: +27 72 950 9370 ___ 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] Altera Quartus II for linux free web edition finally available
With the release of Quartus II 9.1 on 2 november 2009 Altera has finally decided to make a free Linux Web edition available. https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp http://www.altera.com/corporate/news_room/releases/2009/products/nr-quartus-ii-v91.html?f=hpk=wn2 This means it is finally possible to synthesize the FPGA firmware for the USRP on Linux without having to use a windows emulator. Best Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Time of Arrival Hooks
Hello everyone, I'm doing a project with the USRP2 that where I need to know the Time of Arrival(TOA) of the waveforms. This is for a geolocation application. My understanding as of now is that the hooks to get TOA are there in the USRP2, but the firmware does not provide access to them at this point. Is this correct? If the firmware can provide TOA, how can I get that information?? Thanks, Devin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USB VID PID's
Hi Guys I’m new to the list and have a query regarding USB VID PID’s. The HPSDR community are currently prototyping a single board HF transceiver. The product is named Hermes. A list of SDR USB PID’s seem to be maintained here: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/firmware/include/usrp_ids.h We are looking for a unique VID PID combination for Hermes, who do I need to contact to gain Hermes a valid PID? Looking at the list above, it looks like the next allocation is 0x0014 or 0x0019, we are looking to use the VID of 0xFFFE. Any advice or pointers in the right direction greatly appreciated. 73’s Kevin - M0KHZ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB VID PID's
On Wed, Nov 11, 2009 at 07:38:52PM +, Kevin Wheatley wrote: Hi Guys I’m new to the list and have a query regarding USB VID PID’s. The HPSDR community are currently prototyping a single board HF transceiver. The product is named Hermes. A list of SDR USB PID’s seem to be maintained here: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/firmware/include/usrp_ids.h We are looking for a unique VID PID combination for Hermes, who do I need to contact to gain Hermes a valid PID? Looking at the list above, it looks like the next allocation is 0x0014 or 0x0019, we are looking to use the VID of 0xFFFE. Any advice or pointers in the right direction greatly appreciated. 73’s Kevin - M0KHZ 0x0014 is now allocated to you. 73, Eric K7GNU diff --git a/usrp/firmware/include/usrp_ids.h b/usrp/firmware/include/usrp_ids.h index 4f9ac4f..dd5daed 100644 --- a/usrp/firmware/include/usrp_ids.h +++ b/usrp/firmware/include/usrp_ids.h @@ -54,6 +54,7 @@ #define USB_PID_FSF_BDALE_70x0011// Bdale Garbee bd...@gag.com #define USB_PID_FSF_BDALE_80x0012// Bdale Garbee bd...@gag.com #define USB_PID_FSF_BDALE_90x0013// Bdale Garbee bd...@gag.com +#define USB_PID_FSF_HPSDR_HERMES 0x0014// HPSDR Hermes #define USB_PID_FSF_LBNL_UXO0x0018// http://recycle.lbl.gov/~ldoolitt/uxo/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] extending fftsink2 for static object
Request for comments from the plot.py guru(s) before diving in: I'd like to extent the fftsink2 (fftsink_nongl on my street) plot canvas to include static objects such as a stationary reticule line, info-text, boxes, etc. I'm guessing the entire canvas is redrawn with every fft data event so it would need some kind of data structure to merge with the fft points. I've hacked plot.py to make a black background with green fft and an orange grid for an attractive look. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB VID PID's
Wow that was quick :) Thanks Eric. 73's Kevin - M0KHZ On 11 Nov 2009, at 20:43, Eric Blossom wrote: On Wed, Nov 11, 2009 at 07:38:52PM +, Kevin Wheatley wrote: Hi Guys I’m new to the list and have a query regarding USB VID PID’s. The HPSDR community are currently prototyping a single board HF transceiver. The product is named Hermes. A list of SDR USB PID’s seem to be maintained here: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/firmware/include/usrp_ids.h We are looking for a unique VID PID combination for Hermes, who do I need to contact to gain Hermes a valid PID? Looking at the list above, it looks like the next allocation is 0x0014 or 0x0019, we are looking to use the VID of 0xFFFE. Any advice or pointers in the right direction greatly appreciated. 73’s Kevin - M0KHZ 0x0014 is now allocated to you. 73, Eric K7GNU diff --git a/usrp/firmware/include/usrp_ids.h b/usrp/firmware/ include/usrp_ids.h index 4f9ac4f..dd5daed 100644 --- a/usrp/firmware/include/usrp_ids.h +++ b/usrp/firmware/include/usrp_ids.h @@ -54,6 +54,7 @@ #define USB_PID_FSF_BDALE_70x0011// Bdale Garbee bd...@gag.com #define USB_PID_FSF_BDALE_80x0012// Bdale Garbee bd...@gag.com #define USB_PID_FSF_BDALE_90x0013// Bdale Garbee bd...@gag.com +#define USB_PID_FSF_HPSDR_HERMES 0x0014// HPSDR Hermes #define USB_PID_FSF_LBNL_UXO0x0018// http://recycle.lbl.gov/~ldoolitt/uxo/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time of Arrival Hooks
Devin, The metadata is already passed to GNURadio by the USRP2 firmware. Its the gnuradio usrp2 source block that doesn't do anything with this information (metadata has the timestamp for the first sample of each frame) You can modify the code to provide a second stream, or interleave the data with them somehow by modifying the rx**_fc_handler.h files (primarily) to get access to this timestamp data in C++ blocks or post processing in python (all I've done so far). Look for the Fixme: Do something with metadata line! I've posted a couple of questions about getting timestamps to this mailing list (I don't need absolute times in my case though so haven't thought about how to sync these timestamps to real times) which some people (Doug, Juha I think) have helped me out on and I'm just summarising their replies here! I think I've read something about the 3.3 release implementing this but that might have been about the ability to do TDMA Cheers, Tim On Wed, Nov 11, 2009 at 7:21 PM, devin kelly dwwke...@gmail.com wrote: Hello everyone, I'm doing a project with the USRP2 that where I need to know the Time of Arrival(TOA) of the waveforms. This is for a geolocation application. My understanding as of now is that the hooks to get TOA are there in the USRP2, but the firmware does not provide access to them at this point. Is this correct? If the firmware can provide TOA, how can I get that information?? Thanks, Devin ___ 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] scientific computing repository update
I hate to be partly off topic, but I wanted to give an update on the repository I shared a few days ago. I created the repository because I've been using RHEL/CentOS for GNURadio and Octave a long time and wanted to help others do so since it can be a chore on the slower distributions. Although I've been porting and packaging a long time, I admit I'm new to running a repository and may have made some beginner mistakes in that area. I made the announcement on the 6th after getting some initial RPMs up, and later found out that there may have been some RPMs I'd built locally long ago that may have been used in the build process but weren't actually in my repository which were causing failed dependencies in yum. I worked for several days to improve the packaging of the RPMs provided, and added several new packages. I went through and made sure everything was signed and included, so all dependencies should now be resolved. I apologize if anyone gave it a try and encountered problems, and I hope they'll try again. If there are other packages you'd like to work on RHEL/CentOS or are having problems with the ones posted, I'll be happy to try and remedy the situation. I'm also open to packaging suggestions or corrections such as trying to put some of these off to the side with alternate package names. I'm all ears and just want to make GNURadio more accessible. -Brett P.S. I'm still in the process of getting a mock build environment for RHEL organized so I can create the i386 repository, which should clean up some of the few remaining library issues as well as make GNURadio a little more accessible. Lastly, I hope to include SDL support sooner or later, but it's dependency heck and ultimately messes with packages like nss which is dangerous and needs to be done carefully. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time of Arrival Hooks
devin kelly wrote: Hello everyone, I'm doing a project with the USRP2 that where I need to know the Time of Arrival(TOA) of the waveforms. This is for a geolocation application. My understanding as of now is that the hooks to get TOA are there in the USRP2, but the firmware does not provide access to them at this point. Is this correct? If the firmware can provide TOA, how can I get that information?? Thanks, Devin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio The timestamp on the frame of *samples* is indeed available - and if you use the low-level interface to the USRP2 (libusrp2) you can see those timestamps. However, the gr-usrp2 interface (i.e. the default source block for working with the USRP2) does not. If you want to see the timestamps in a GNURadio flowgraph, you'll need to create a custom block based on the usrp2_source_[32fc or 16sc] block. However, that won't give you the TOA of a received signal *directly*. You'll need some scheme to decide that a signal has arrived, and then calculate the TOA based on the timestamp corresponding to that sample (the timestamps you get from libusrp2 are for the first signal in the frame of samples - so you'd need to either calculate the running timestamp for each sample, or keep track of the offset within the frame somehow). Good luck! Doug -- Douglas Geiger Code 5545 U.S. Naval Research Laboratory Washington, DC 20375 (202) 767-9048 douglas.gei...@nrl.navy.mil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Altera Quartus II for linux free web edition finally available
On Wednesday 11 November 2009 19:47:26 Martin DvH wrote: With the release of Quartus II 9.1 on 2 november 2009 Altera has finally decided to make a free Linux Web edition available. One down, one to go (Nokia Firmware Updater). Great News! Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Halfband filter coefficients help
Thank you folks, Jeff, thank you for your snapshot. I modified Firas' MATLAB m file( http://www.nabble.com/file/8506/usrpddc.m) to get similar picture. :-) Sebastiaan and Matt, thank you for your kind explanation. Now, I get it clearly. :-) Regards, ILKYOUNG. 2009/11/12 Matt Ettus m...@ettus.com I will explain the RX side, the TX side is basically the same. small_hb_dec is the short filter which works at the higher rate. There are 2 of them instantiated, one for I and one for Q. It has 7 taps. One of those taps is the center tap which only requires a shift and not a multiply, and 2 of those taps are zeros. That leaves 4 taps. The taps are symmetric, which leaves 2 multiplies per output. Since we have at least 2 cycles to produce each output, we can use a single multiplier. hb_dec is 2nd halfband filter and it works at the lower rate. There are 2 of them instantiated, one for I and one for Q. It has 31 taps. One of those taps is the center tap which only requires a shift and not a multiply, and half of the remainder are zeros. That leaves 16 taps. They are symmetric, so that means we need to do 8 multiplies to produce each output. There are at least 4 cycles to produce each output, so we need to do 2 multiplies at a time. One of those multipliers does the outer coefficients, meaning the ones at the very beginning and end of the impulse response, and one does the inner coefficients, meaning the ones around the center of the impulse response. This division is purely an implementation choice, and does not affect the output. I could have put the odd ones on one mult and the even ones on the other, or any other split you could imagine. It doesn't matter. Matt Jeff Brower wrote: Ilkyoung Kwoun- Thank you for your advice. Actually I am aware of basic characteristics of half band filter. It is very well explained in Rick Ryon's Understanding Digital Signal Processing (2nd Ed.) ( http://www.amazon.com/Understanding-Digital-Signal-Processing-2nd/dp/0131089897/ref=sr_1_1?ie=UTF8s=booksqid=1257900094sr=8-1 ) The thing I do not have any clue is the 'inner' and 'outer' coefficient things in FIR filter. I guess this is something related to the practical implementation issue rather than the fundamental concept. I did a simple googling yesterday and found a paper. ( http://ce.et.tudelft.nl/publicationfiles/1090_509_shahbahrami_prorisc2005.pdf ) I hope I can find a way to get started. :-) Here is a Hypersignal log-magnitude plot showing the frequency response of the two halfband filters (31-tap in blue, 7-tap in red): http://www.signalogic.com/images/gnu_radio_halfband_filters.jpg In the plots I used an arbitrary sampling rate of 25 MHz -- don't know what you're using. Note that both filters have an approx -6 dB point at Fs/4 as would be expected due to halfband symmetry properties. As for inner and outer mention in the Verilog code, I might guess that refers to 2 multiplies needed when filtering a complex signal. As for why there are two (2) filters, one is used for higher rate up/down conversions and the other for lower rate. Firas' documentation has some information on this... also here is QA exchange between Firas and Matt that might help you out: http://old.nabble.com/Some-USRP2-Questions-td20729711.html -Jeff 2009/11/10 Sebastiaan Heunis sheu...@gmail.com Hi I think Brian is just referring to the fact that you can see that the HBFs are implemented as symmetric FIR filters (the coefficients). A HBF is just a special filter that is designed so that the cutoff frequency will always be at fs/2, so if you filter with it and decimate by 2 afterwards (which is why you would use an HBF), you don't get aliasing. Also, the decimation in the CIC filters can be set to a wide range of values, so the HBF will always have to cut at fs/2 regardless of the decimation in the CIC. From what I've read, Goodman and Carey came up with them so you can probably look for some papers if you're interested. Sebastiaan -- Sebastiaan Heunis Radar Remote Sensing Group, University of Cape Town, South Africa Tel: +27 72 950 9370 ___ 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
Re: [Discuss-gnuradio] Re: hello world ex. grc problem
File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/ParseXML.py, line 20, in module from lxml import etree File lxml.etree.pyx, line 188, in lxml.etree (src/lxml/lxml.etree.c:124917) LookupError: unknown encoding: ASCII did you install the python-lxml package? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building complete FM receiver/transmitter with two dell laptops and two usrp radios
You will need to checkout the latest branch of the BBN code. You should checkout the usrp2_version of the code. https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version - Miklos On Tue, Nov 10, 2009 at 6:03 PM, Adam Lee adamryan...@gmail.com wrote: hello, i've gone through a few tutorials and have recently been trying to install and run the bbn 802.11b code in particular to test out the transmitter and receiver but have run into a myriad of troubles including having to change references, include standard libraries in code, and now the code cant find a block called 'blks'. Is there any code out there that is up to date that doesn't require so much tinkering? I just want to test my two pieces of equipment. Thank you for any help or references, if anyone knows how to find 'blks' i would appreciate that as well, thank you. ___ 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
