Re: [Discuss-gnuradio] Bug #419: gr_vmcircbuf_sysv_shm
On 07/02/2011 09:38 PM, Vincent W wrote: > Thank you for your advice. Unfortunately, this causes make tests to fail, with > the following error: > I dont see an error. Did you try it out? > Testing gr_vmcircbuf_createfilemapping_factory... > gr_vmcircbuf_createfilemapping: createfilemapping is not available > ... gr_vmcircbuf_createfilemapping_factory: Doesn't work createfilemapping is for windows OS only :-) -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG related problem with new filter function
Hi Tom, > Are you doing this in your own top-level block (dsss from the looks of it) > or under a current GNU Radio directory like gnuradio-core where the > gr_firdes currently is? > Yes, I am doing this in my own top-level directory named 'dsss' (abbreviation for direct sequence spread spectrum) > > You haven't mentioned adding anything to the Makefile so that it is built > properly. If you are working under gnuradio-core/src/lib/general, you'll > also want to add your .h and .i files to general.i so that it get's > compiled. > I added the names to Makefile.am like I added the remaining names of files. The Makefile.am has been adapted from howto-write-a-block. The C++ part gets compiled without any problem but when importing in python it throws an undefined_variable_dsss_firdes_Z*** type of error, which according to my previous experience occurs with wrong SWIG interface problem. I am pretty sure I am having a SWIG related issue here. > > Also, just curious, what application are you interested in that requires a > raised cosine filter? And couldn't you just create a root raised cosine > filter and convolve the the taps against themselves to make the raised > cosine taps? > I am developing a BPSK based Direct sequence spread spectrum Tx/Rx and at the transmitter i wanted to use a raised cosine filter when interpolating from symbol to N samples before sending it to the USRP. I am not sure if this is the preferred method but I haven't found any documentation related to DSSS that mentions pulse-shaping. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug #419: gr_vmcircbuf_sysv_shm
On 07/02/2011 02:27 PM, Vincent W wrote: > Hi, > > I just pulled the latest git sources, and wanted to confirm the behaviour > noted > in Bug #419; > > Bug #419: Programs using WxWidgets graphical sinks fail with the error: > > gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument > gr_buffer::allocate_buffer: failed to allocate buffer of size 20840 KB > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted > Please try my gr_kludge_one_in_n branch: http://gnuradio.org/cgit/jblum.git/commit/?id=e147a813faaf89141af06bbf1d782d1ff3d97536 -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Import Error:no module called _audio_swig found
Hello everyone I have recently updated my Gnuradio.When I try to import audio block and uhd block I get errors saying Import Error:no module called _audio_swig and _uhd_swig found.I tried reinstall the whole gnuradio and its packets but with no success. I would like to what could be the reason for this -- View this message in context: http://old.nabble.com/Import-Error%3Ano-module-called-_audio_swig-found-tp31982670p31982670.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief
>> >> I wonder if that assertion is generally true, or only in some cases? >> Increment and test shouldn't be *that* expensive. >> > > I'm sure the benefit varies depending on the situation, including some where > there is no benefit. But modulo increments add a conditional operation for > every pointer increment, which can cause a processor pipeline stall, and > takes up register file space to hold the array boundaries for every input > and output stream. It also forces the author of the work() function to know > about how GNU Radio handles circular buffers. The double-mapped circular > buffer lets the work() function treat all its inputs and outputs as linear > arrays in memory, no matter the actual case. > Suppose that we didn't have a specially mapped memory. I believe the scheduler could easily ensure that contiguous chunks of memory are always passed into the work function with little overhead for both read and for write. Now, I bet there will be a slight problem when you have a block with "history" like FIR filter that needs ntaps worth of samples repeated into the next work function. So, when the scheduler has to actually wrap back around to the beginning of the buffer, it will have to memcpy nsamps to the begging of the buffer. Which shouldnt be bad when buffer size >>> history size. Its sounds possible (so stop me if I missed something big here). Basically, it would be nice to support a linear memory/buffer mode for the block executor for two reasons. 1) switch to a linear memory when allocation of mapping fails, and 2) swap out the buffer with something like a memory hole for a dsp for direct-copy. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using fftw for neon with gnuradio
On 06/29/2011 08:51 PM, Morgan Redfield wrote: I don't think you have to change the parameters you're giving to ./configure for gnuradio. You actually want to change the parameters used by ./configure for fftw. This worked for me: ./configure --enable-single --enable-neon --enable-shared CFLAGS='-fPIC -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2' And then I built gnuradio as normal. Make sure you remove the installed fftw libraries and headers. Something like: opkg list-installed | grep fftw opkg remove fftwf fftwf-dev (where the package names match the result from the first command) You will need to add the appropriate fore removal option to opkg, Philip Morgan On Wed, Jun 29, 2011 at 2:46 AM, Phelps Williams wrote: Could somebody post the whole configure call once the vesperix fftw lib was installed? I'm giving this a try here myself but want to make sure I'm on the right track. ./configure --disable-volk --disable-usrp2 --disable-usrp1 --disable-gr-video-sdl --enable-shared CFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC" CXXFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC" -with-qwt-incdir=/usr/include On Wed, Jun 22, 2011 at 5:26 PM, Thomas Tsou wrote: On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister wrote: Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to build as a shared library. That worked for me. Thomas ___ 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] Import Error:no module called _audio_swig found
On 07/03/2011 01:03 AM, uday_gnu wrote: > > Hello everyone > I have recently updated my Gnuradio.When I try to import audio block and uhd > block I get errors saying Import Error:no module called _audio_swig and > _uhd_swig found.I tried reinstall the whole gnuradio and its packets but > with no success. > I would like to what could be the reason for this I have seen this caused on windows when the dll was not in the %PATH%. Its really a stupid error because python can find _audio_swig just fine. Is gnuradio-audio.dll and gnuradio-uhd.dll in your %PATH%? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Max temperature for usrp2
I have the same problem -- I'm going to be using a USRP2 outdoors in the shade (not direct sunlight) for around six hours in Yuma, Arizona, where the daytime temperatures are 100-110 degrees F now in July. Will the USRP2 be able to operate under these high temperatures? Check it out: http://www.wund.com/US/AZ/Yuma.html --- On Thu, 6/30/11, Feng Andrew Ge wrote: > From: Feng Andrew Ge > Subject: Re: [Discuss-gnuradio] Max temperature for usrp2 > To: emat...@nd.edu, discuss-gnuradio@gnu.org > Date: Thursday, June 30, 2011, 4:52 PM > > Eric, in your 2009 experiment > indicated below, did the USRP2 sustain the high temperature > of 150 F? > > Is there anybody else who has tried to use USRP2 > continuously at a temperature above 105 F? Your > feedback is highly appreciated. > > > Andrew > > > On Mon, Jul 13, 2009 at 1:13 PM, Eric Matlis > wrote: > > > Hi all- > > > > I'm about to conduct some measurements on a > running GE aircraft jet engine > > with the USRP2. The test cell temps could > reach 150 F. Is that going to > > fry my USRP? > > > > Thanks, > > eric > > > > > ___ > 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 code walkthrough
On Mon, Jun 27, 2011 at 8:43 AM, adib_sairi wrote: > > Dear GNU Radio community, > > I and my group had this tutorial/code walkthrough to share. we found out > that it is quite hard for beginner to start with GNU Radio, hopefully this > walkthrough explanation can help a bit. > > this is the 1st version. please help us to improve by giving comment on any > mistake that we made. any comment is highly appreciated. > > the slide can be downloaded from this site > http://trg.fke.utm.my/members/adib/ under tutorials section. > > thanks and have a nice day. > > Adib > > - > Mohd Adib Sarijari > Universiti Teknologi Malaysia > > my website: http://trg.fke.utm.my/members/adib/ > my faculty: http://www.fke.utm.my/ > my university: http://www.utm.my/ Hi Abid, This looks good. Feel free to add a link to the gnuradio.org Wiki (maybe under "presentations" or make a new page under "Documentation" for tutorial material). The guest login is guest:gnuradio, unless you have already registered your own account. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DPSK2 Demodulator
On Wed, Jun 29, 2011 at 10:30 AM, Ralf wrote: > Hi, > > we are trying to use DPSK2 modulator and demodulator during our first > trials. > As far as we can see there is hardly any documentation available on this. > > We would appreciate a few explaining words from somebody who knows how to > configure the demodulator so that data is correctly received. > What synchronization method(s) is/are included? > Raised-cosine-filter for matched filtering seems to be included? > > We tried like this with no success: > Modulator: > Type: DQPSK > Sample/Symbol: 2 > Excess BW: 0.35 > GrayCode: YES > Verbose: OFF > Logging: OFF > > Demodulator: > Sample/Symbol: 2 > Excess BW: 0.35 > FLL Alpha: 0.01 > Phase Alpha: 0.1 > Timing Max Dev: 1.5 > Omega Relative Limit: 0.005 > GrayCode: YES > Verbose: OFF > Logging: OFF > Sync Out: ON > > Thanks in advance! > Ralf > The DPSK2 blocks use a frequency locked loop (FLL), a polyphase timing recovery loop, and a Costas loop for phase and residual frequency locking. Unfortunately, there are no magic numbers to use for these, but the defaults have worked well for me in the past. I'll point out that the FLL in particular still needs work. It can get into oscillations pretty easily, and if that happens, the rest of your receiver chain won't work at all. You can also turn on logging with --log to benchmark_rx.py, which dumps most pieces of the receiver chain to a file. You can then analyze the various parts of the receive path to see where things start to go wrong. An common problem with the digital modulation code is if the frequency offset of the USRPs is too large between the TX and RX. It can be outside of the locking range and so never converge. To start with, it's a good idea to transmit with one radio and look at the spectrum with your receiver radio. Figure out the frequency delta between the two and compensate for it. It doesn't have to be exact, but just enough to get you close. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] throttle for very low data rates
On Sat, Jul 2, 2011 at 2:27 PM, Brett L. Trotter wrote: > I have a loop block that I wanted to run very slow (1Hz), and put a > throttle block set to rate 1. Unfortunately, it seems to tear through > the first 8-9k samples in a blink before it slows down. Is there an > alternative implementation of the throttle block that would work at very > slow speeds? Perhaps rather than memcopying the entire batch of samples > passed into the work function, it would loop copy and deal with rate and > sleeps during the loop? Obviously this wouldn't be optimal for fast rate > blocks, but what about creating a separate throttle optimized for slow > data rates? > Yes, I think you could make something like that work, but you're right that it would have to be done for only small data rates. If you come up with a general solution to this, we can work on getting it into the code. This comes back to the general issues others have had with the fact that the schedule optimizes for throughput and doesn't really care about issues like what you are seeing. It pops up more in the case where people want to minimize latency. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM preamble
On Fri, Jul 1, 2011 at 2:36 AM, John Waugh wrote: > Hi. > I wanted to know about the preambles that are inserted in the ofdm packet. > I know they are inserted for the synchronization and frequency offset > purposes. > But I want to know where in the OFDM packet they are inserted. I have > following questions. > > 1. How can I vary the length of preambles? Can I do that ? > > 2. On which parameters length of preamble depends? > > 3. What is the length of preamble sequence if I am using fft-length=512, > occupied carriers=200 cp-length=128, size of ofdm packet=400 bytes, > modulation='bpsk'. > > 4. Where are they inserted in the OFDM packet? I mean before Payload? > > > preamble| payload| > > 5. Both the preambles are inserted at the start ? > > 6. Which modulation is used for preambles? > > Need your help > > Regards > John, Look in gnuradio-core/src/python/gnuradio/blks2impl/ofdm.py at the ofdm_mod class. This is where we construct and insert the preamble, using gr_ofdm_insert_preamble. The preamble we use is based on the Schmidl and Cox model, where we take one OFDM symbol and, in time, repeat the same info twice. The length of the symbol is based on the occupied tones, it is then padded to fft-length to fill the entire OFDM symbol. The repetition is created in the frequency domain by setting every other subcarrier to 0, which is the same as repeating the pattern in time. Likewise, if we set two subcarriers to 0, that is X00X00X00..., you would get a triple redundancy in time. The receiver can then correlate against the repetition in time to recovery the frequency and timing offset. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer questions
On Thu, Jun 30, 2011 at 9:16 PM, Morgan Redfield wrote: > Hi, > > I've been working on building a CSMA/CA MAC for the past couple of > weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's > working now, but I don't think it's very efficient. I ended up having > to relax a lot of timing parameters to get it working, so my > throughput is pretty bad. I also get a lot of dropped packets. I think > this is also because my timing isn't very accurate, and I end up with > more collisions than I would expect. > > I was wondering if anyone else had had any luck building a CSMA/CA > MAC. I saw a few posts on the mailing list from several years ago > about people who were working on it, but I don't see any example code > anywhere. I also checked out CMUmacs on CGRAN, but that relies on a > deprecated version of GNURadio. > > Is my best bet to rewrite the MAC as a block in C++? Can anyone tell > me what kind of speedup that's likely to get me? > > Thanks, > Morgan Redfield > Morgan, Yes, this is an issue with MACs in software radio when you have a bus like USB or Ethernet between the processing and the air interface. These buses have fairly large and jittery latency, so by the time you have received samples, measured the power to determine that the channel is clear, and then sent a payload to be transmitted, but the time the payload actually goes out of the air interface, you decision is so far in the past that it's pretty meaningless to the current state of the channel. We have a rudimentary CSMA MAC in tunnel.py in the digital examples, but it suffers from the same problems you are seeing. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG related problem with new filter function
On Sun, Jul 3, 2011 at 3:25 AM, John Andrews wrote: > Hi Tom, > > > >> Are you doing this in your own top-level block (dsss from the looks of it) >> or under a current GNU Radio directory like gnuradio-core where the >> gr_firdes currently is? >> > Yes, I am doing this in my own top-level directory named 'dsss' > (abbreviation for direct sequence spread spectrum) > >> >> You haven't mentioned adding anything to the Makefile so that it is built >> properly. If you are working under gnuradio-core/src/lib/general, you'll >> also want to add your .h and .i files to general.i so that it get's >> compiled. >> > > I added the names to Makefile.am like I added the remaining names of files. > The Makefile.am has been adapted from howto-write-a-block. The C++ part gets > compiled without any problem but when importing in python it throws an > undefined_variable_dsss_firdes_Z*** type of error, which according to my > previous experience occurs with wrong SWIG interface problem. I am pretty > sure I am having a SWIG related issue here. > Ok, it _sounds_ like you are doing everything correctly. In my experience with this stuff, it usually comes down to a small typo somewhere. You can post your files here (.i, .h, and Makefile) so others to maybe have a look to see if there's anything incorrect in them. > Also, just curious, what application are you interested in that requires a >> raised cosine filter? And couldn't you just create a root raised cosine >> filter and convolve the the taps against themselves to make the raised >> cosine taps? >> > > I am developing a BPSK based Direct sequence spread spectrum Tx/Rx and at > the transmitter i wanted to use a raised cosine filter when interpolating > from symbol to N samples before sending it to the USRP. I am not sure if > this is the preferred method but I haven't found any documentation related > to DSSS that mentions pulse-shaping. > >> >> Tom >> > There is definitely some work on pulse shaping of DSSS systems. I believe, though, that they all use root raised cosine filters. This is done at both the transmitter and receiver so that the received signal has gone through two root raised cosine filters to make the raised cosine filter, which is a Nyquist filter. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sending Patches
On Sat, Jul 2, 2011 at 11:38 PM, Vincent W wrote: > Hi, > > I was wondering whether the email address for patches ( > patch-gnura...@gnu.org ) > was still valid. The wiki says it's for SVN, but seeing as the project is > in git... > > Alternatively, what is the preferred form of submitting patches? May I post > a > patch file? Or would it be easier to set up a gitorious repo and have the > maintainers pull/merge from that? > > Warm Regards, > > vvv > It depends on how many lines you change, really. A few simple lines of code can be easily captured in a patch. If you are working on multiple files and large numbers of changes, then a project on some git site is probably better. Where the lines cross is up to you. The SVN line in the description of the GNU Radio patch list was only because we had no updated it, yet. I just fixed it :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New post about server update
Hi everyone, I just wrote a new post about our recent server upgrade http://gnuradio.squarespace.com/?SSScrollPosition=711. There isn't too much that we haven't gone over in emails to the list, but I wanted to point out one new feature that might benefit everyone. I now have Jenkins running a make distcheck against our git master branch weekly. If the distcheck passes, Jenkins publishes the tarball and it's SHA1 sum on the gnuradio.org Download page. So now everyone can access at most a week-old build of GNU Radio if, for whatever reason, you have issues with using git. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer questions
On Sun, Jul 3, 2011 at 8:16 AM, Tom Rondeau wrote: > On Thu, Jun 30, 2011 at 9:16 PM, Morgan Redfield wrote: > >> Hi, >> >> I've been working on building a CSMA/CA MAC for the past couple of >> weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's >> working now, but I don't think it's very efficient. I ended up having >> to relax a lot of timing parameters to get it working, so my >> throughput is pretty bad. I also get a lot of dropped packets. I think >> this is also because my timing isn't very accurate, and I end up with >> more collisions than I would expect. >> >> I was wondering if anyone else had had any luck building a CSMA/CA >> MAC. I saw a few posts on the mailing list from several years ago >> about people who were working on it, but I don't see any example code >> anywhere. I also checked out CMUmacs on CGRAN, but that relies on a >> deprecated version of GNURadio. >> >> Is my best bet to rewrite the MAC as a block in C++? Can anyone tell >> me what kind of speedup that's likely to get me? >> >> Thanks, >> Morgan Redfield >> > > > Morgan, > Yes, this is an issue with MACs in software radio when you have a bus like > USB or Ethernet between the processing and the air interface. These buses > have fairly large and jittery latency, so by the time you have received > samples, measured the power to determine that the channel is clear, and then > sent a payload to be transmitted, but the time the payload actually goes out > of the air interface, you decision is so far in the past that it's pretty > meaningless to the current state of the channel. > > We have a rudimentary CSMA MAC in tunnel.py in the digital examples, but it > suffers from the same problems you are seeing. > > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > Perhaps this could be a new feature for the UHD driver interface. There is already a start streaming at clock value X feature. The idea is to augment that and have a start streaming at clock value X if channel is clear; if not clear return an error code. A channel sense block should not be too complicated to put into hardware. A side note, it would be great if Ettus and company could develop a USRP with a PCI-express interface (the new Thunderbolt interface?). This could possible solve a lot of the timing issues (can the more HW oriented folks comment on this). Also it would a great excuse to sell a more expensive USRP board (with higher margin! $$). :P --Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in installing GnuRadio by script.
Hey Marcus..a nice thing... I did some manipulation in your script and it worked. first I omitted the function "firmware" .. saved it and then ran the script. then I downloaded the images from http://www.ettus.com/downloads/uhd_releases/master_images/ (the .tar file) then I extracted it and copied the image folder into /usr/local/share/uhd/ then I did chmod 644 thing there (as was written in the script) i.e. chmod 644 /usr/local/share/uhd/images/* and everything was great.. now i have a gnuradio in my system without any error :) so finally done hhhh :) thanks a lot for the script. Marcus D. Leech wrote: > >> Yes indeed our institute has transparent web cache to decrease the load >> on >> network.I can't say whether its flushing properly or not.I will try >> installing it tomorrow with a separate connection. >> But how is this related to the errors I am getting .. > Sometimes "transparent web caches" aren't so transparent. Updates to > the downstream actual website aren't >always tracked correctly. > > So when the "firmware" paragraph trys to fetch stuff, the web cache > delivers an incomplete version of the target >website--the firmware is fetched using "wget" to an http:// URL, so > your webcache will definitely be involved. > > >> > > > -- > 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 > > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Problem-in-installing-GnuRadio-by-script.-tp31929580p31985316.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in installing GnuRadio by script.
Let me know if some further settings I need to do . sumitstop wrote: > > Hey Marcus..a nice thing... > > I did some manipulation in your script and it worked. > > first I omitted the function "firmware" .. saved it and then ran the > script. > then I downloaded the images from > http://www.ettus.com/downloads/uhd_releases/master_images/ (the .tar file) > then I extracted it and copied the image folder into /usr/local/share/uhd/ > then I did chmod 644 thing there (as was written in the script) i.e. chmod > 644 /usr/local/share/uhd/images/* > > and everything was great.. now i have a gnuradio in my system without any > error :) > > so finally done hhhh :) > thanks a lot for the script. > > > > Marcus D. Leech wrote: >> >>> Yes indeed our institute has transparent web cache to decrease the load >>> on >>> network.I can't say whether its flushing properly or not.I will try >>> installing it tomorrow with a separate connection. >>> But how is this related to the errors I am getting .. >> Sometimes "transparent web caches" aren't so transparent. Updates to >> the downstream actual website aren't >>always tracked correctly. >> >> So when the "firmware" paragraph trys to fetch stuff, the web cache >> delivers an incomplete version of the target >>website--the firmware is fetched using "wget" to an http:// URL, so >> your webcache will definitely be involved. >> >> >>> >> >> >> -- >> 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 >> >> > > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Problem-in-installing-GnuRadio-by-script.-tp31929580p31985341.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AGC on the RFX900 board
Hi,
I have a few questions about the (analog) AGC on the AD8347 mixer chip on
the Flex900 daughterboard.
1. Given a signal received with some known power, is it possible to read the
programmed AGC gains (and thereby find the mixer's noise figure)?
2. Is it possible to lock these gain settings? If not, can the AGC
functionality be disabled?
3. How fast does the AGC track changes in signal power?
4. If (1), (2) are not possible, is it still possible to know the RX noise
figure?
I'd appreciate some inputs :) If I understand correctly, to calibrate the
receive SNR, we need to know the RX noise floor (seen in software). For this
we need to know the RX noise figure...
To provide some context, the following is our immediate application: we have
a coded 16QAM system implemented on GNURadio. We want to measure the Frame
Error Rate vs. Es/No ("per-symbol SNR") for this system. The TX and RX have
separate USRP boards, each with a RFX900 daughterboard. A coaxial cable
connects the TX and RX antenna ports. With this setup, we vary the transmit
power and measure the frame error rate. To compare these results with a
Matlab model, we need to know the received Es/No: for that we need the RX
noise figure...and hence my question above.
I'd appreciate your help.
Thanks in advance,
Regards
Sundar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AGC on the RFX900 board
On 07/03/2011 08:05 PM, Sundaram Vanka wrote:
> Hi,
>
> I have a few questions about the (analog) AGC on the AD8347 mixer chip
> on the Flex900 daughterboard.
>
> 1. Given a signal received with some known power, is it possible to
> read the programmed AGC gains (and thereby find the mixer's noise
> figure)?
> 2. Is it possible to lock these gain settings? If not, can the AGC
> functionality be disabled?
> 3. How fast does the AGC track changes in signal power?
> 4. If (1), (2) are not possible, is it still possible to know the RX
> noise figure?
>
> I'd appreciate some inputs :) If I understand correctly, to calibrate
> the receive SNR, we need to know the RX noise floor (seen in
> software). For this we need to know the RX noise figure...
>
> To provide some context, the following is our immediate application:
> we have a coded 16QAM system implemented on GNURadio. We want to
> measure the Frame Error Rate vs. Es/No ("per-symbol SNR") for this
> system. The TX and RX have separate USRP boards, each with a RFX900
> daughterboard. A coaxial cable connects the TX and RX antenna ports.
> With this setup, we vary the transmit power and measure the frame
> error rate. To compare these results with a Matlab model, we need to
> know the received Es/No: for that we need the RX noise figure...and
> hence my question above.
>
> I'd appreciate your help.
>
> Thanks in advance,
> Regards
> Sundar
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
The gain control on the RFX900 is all purely manual, unless you modify
the hardware for AGC.
Figure 19 on the AD8347 datasheet shows noise figure vs gain settings
for the mixer, but on the
RFX900, there's an LNA in front of it, which at least for higher mixer
gain settings very much
offsets the conversion noise. The very best noise figure on the mixer
is at highest gain, giving roughly
5dB for the mixer. Dividing this by the 13.2dB LNA gain and adding
the noise of the MGA82563 LNA
(2.2dB) gives a best-case noise figure of something on the order of
3dB. In reality, you're likely
looking at closer to 3.8dB noise figure, due to connector and trace
losses in front of the LNA, etc.
The gain setting in UHD/Gnu Radio should correspond fairly-precisely to
the gain setting on the
RFX900 mixer, which provides something like 69dB of total gain range.
In most cases in RF systems
like this, gain-control is implemented using variable attenuators in
front of the gain element, so
effective noise figure becomes worse as you lower the gain. I believe
that UHD attempts to optimize
its gain distribution for noise figure, but you can also manually set
the individual gains that
are available. On the USRP, there's a PGA in front of/part-of the RX
ADC, in addition to the gain control
on the AD8347 mixer chip, and UHD will distribute gain settings over
these elements.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief
Suppose that we didn't have a specially mapped memory. I believe the scheduler could easily ensure that contiguous chunks of memory are always passed into the work function with little overhead for both read and for write. Now, I bet there will be a slight problem when you have a block with "history" like FIR filter that needs ntaps worth of samples repeated into the next work function. So, when the scheduler has to actually wrap back around to the beginning of the buffer, it will have to memcpy nsamps to the begging of the buffer. Which shouldnt be bad when buffer size>>> history size. Its sounds possible (so stop me if I missed something big here). Basically, it would be nice to support a linear memory/buffer mode for the block executor for two reasons. 1) switch to a linear memory when allocation of mapping fails, and 2) swap out the buffer with something like a memory hole for a dsp for direct-copy. -Josh I am intrigued by your ideas, and wish to subscribe to your newsletter :-) -- 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
Re: [Discuss-gnuradio] Sending Patches
Tom Rondeau wrote: > Vincent W Alternatively, what is the preferred form of submitting patches? May I > post a > patch file? Or would it be easier to set up a gitorious repo and have the > maintainers pull/merge from that? > > It depends on how many lines you change, really. A few simple lines of code > can > be easily captured in a patch. If you are working on multiple files and large > numbers of changes, then a project on some git site is probably better. Where > the lines cross is up to you. At least initially, I wanted to make a couple of gnuradio-companion example scripts and programs. I figured the best way to do this would be to include a datafile, along with some scripts and sample programs. Afterwards (hopefully within a week), I wanted to see what I could do with the sdl video stuff. I think, for the time being, I'll create a gitorious repo for this. > The SVN line in the description of the GNU Radio patch list was only because > we > had no updated it, yet. I just fixed it :) Didn't mean to nit-pick; I didn't know if the alias was used by SVN or something. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug #419: gr_vmcircbuf_sysv_shm
Josh Blum wrote: > On 07/02/2011 09:38 PM, Vincent W wrote: >> Thank you for your advice. Unfortunately, this causes make tests to fail, >> with >> the following error: >> > > I dont see an error. Did you try it out? Sorry - I closed the terminal I had everything running. I'm building on arch linux using a buildscript. Checking our that filed caused the build to fail - I guess I didn't copy enough of the error. vvv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG related problem with new filter function
Here are all the related files.
C++ header
***
* dsss_firdes.h *
***
#ifndef _DSSS_FIRDES_H_
#define _DSSS_FIRDES_H_
#include
#include
class dsss_firdes {
public:
dsss_firdes();
static std::vector raised_cosine (double gain, double sampling_freq,
double symbol_rate, double alpha, int ntaps);
};
#endif
C++ Source file -
*
* dsss_firdes.cc *
*
#include "dsss_firdes.h"
#include
using std::vector;
// Raised Cosine Filter
vector
dsss_firdes::raised_cosine (double gain, double sampling_freq, double
symbol_rate, double alpha, int ntaps)
{
ntaps |= 1; // ensure that ntaps is odd
double spb = sampling_freq/symbol_rate; // samples per bit/symbol
vector taps(ntaps);
double scale = 0;
for(int i=0;i raised_cosine(double gain, double sampling_freq,
double symbol_rate, double alpha, int ntaps);
};
***
* Makefile.am *
***
include $(top_srcdir)/Makefile.common
# C/C++ headers get installed in ${prefix}/include/gnuradio
grinclude_HEADERS = dsss_firdes.h
###
# SWIG Python interface and library
TOP_SWIG_IFILES = dsss.i
# Install so that they end up available as:
# import gnuradio.dsss
# This ends up at:
# ${prefix}/lib/python${python_version}/site-packages/gnuradio
dsss_pythondir_category = gnuradio
# additional sources for the SWIG-generated library
dsss_la_swig_sources = dsss_firdes.cc
include $(top_srcdir)/Makefile.swig
# add some of the variables generated inside the Makefile.swig.gen
BUILT_SOURCES = $(swig_built_sources)
# Do not distribute the output of SWIG
no_dist_files = $(swig_built_sources)
On Sun, Jul 3, 2011 at 10:33 AM, Tom Rondeau wrote:
> On Sun, Jul 3, 2011 at 3:25 AM, John Andrews wrote:
>
>> Hi Tom,
>>
>>
>>
>>> Are you doing this in your own top-level block (dsss from the looks of
>>> it) or under a current GNU Radio directory like gnuradio-core where the
>>> gr_firdes currently is?
>>>
>> Yes, I am doing this in my own top-level directory named 'dsss'
>> (abbreviation for direct sequence spread spectrum)
>>
>>>
>>> You haven't mentioned adding anything to the Makefile so that it is built
>>> properly. If you are working under gnuradio-core/src/lib/general, you'll
>>> also want to add your .h and .i files to general.i so that it get's
>>> compiled.
>>>
>>
>> I added the names to Makefile.am like I added the remaining names of
>> files. The Makefile.am has been adapted from howto-write-a-block. The C++
>> part gets compiled without any problem but when importing in python it
>> throws an undefined_variable_dsss_firdes_Z*** type of error, which according
>> to my previous experience occurs with wrong SWIG interface problem. I am
>> pretty sure I am having a SWIG related issue here.
>>
>
> Ok, it _sounds_ like you are doing everything correctly. In my experience
> with this stuff, it usually comes down to a small typo somewhere. You can
> post your files here (.i, .h, and Makefile) so others to maybe have a look
> to see if there's anything incorrect in them.
>
>
>> Also, just curious, what application are you interested in that requires a
>>> raised cosine filter? And couldn't you just create a root raised cosine
>>> filter and convolve the the taps against themselves to make the raised
>>> cosine taps?
>>>
>>
>> I am developing a BPSK based Direct sequence spread spectrum Tx/Rx and at
>> the transmitter i wanted to use a raised cosine filter when interpolating
>> from symbol to N samples before sending it to the USRP. I am not sure if
>> this is the preferred method but I haven't found any documentation related
>> to DSSS that mentions pulse-shaping.
>>
>>>
>>> Tom
>>>
>>
> There is definitely some work on pulse shaping of DSSS systems. I believe,
> though, that they all use root raised cosine filters. This is done at both
> the transmitter and receiver so that the received signal has gone through
> two root raised cosine filters to make the raised cosine filter, which is a
> Nyquist filter.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug #419: gr_vmcircbuf_sysv_shm
Josh Blum wrote:
> On 07/02/2011 02:27 PM, Vincent W wrote:
>> Hi,
>>
>> I just pulled the latest git sources, and wanted to confirm the behaviour
>> noted
>> Bug #419: Programs using WxWidgets graphical sinks fail with the error:
>
> Please try my gr_kludge_one_in_n branch:
> http://gnuradio.org/cgit/jblum.git/commit/?id=e147a813faaf89141af06bbf1d782d1ff3d97536
Your branch compiles cleanly and seems to work: Applications that previously
failed to run are now working. Below, please find the configuration options I
used (after pulling from gnuradio master):
msg "Starting build."
git clean -x -f -d
./bootstrap
export PKG_CONFIG_PATH=/usr/lib64/pkgconfig
git pull http://gnuradio.org/cgit/jblum.git gr_kludge_one_in_n
./configure --enable-usrp2 --enable-gr-usrp2 --enable-gr-wxgui --enable-grc
--enable-docs --enable-doxygen \
--enable-gr-audio-alsa --enable-gnuradio-examples --enable-gnuradio-core
--enable-gr-audio-oss \
--enable-gr-video-sdl --with-md-cpu=x86_64 --with-boost=/usr
--with-boost-libdir=/usr/lib \
--enable-qtgui --prefix=/usr
msg "Starting make..."
make -j8 || return 1
make check || return 1
make DESTDIR=${pkgdir} install || return 1
vvv
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AGC on the RFX900 board
Thanks, Marcus, for your prompt and detailed response. If I understand you
correctly:
1. The best case noise figure of the RFX900 daughterboard is about 3-3.8 dB.
This occurs when the mixer amplifiers are set to their highest gain setting.
2. These gain settings can be fixed via software (via UHD).
3. UHD distributes the single programmed gain value over the mixer and the
PGA to optimize for the noise figure.
I looked up the UHD app. notes. For RFX boards (as you probably already know
:)) there is a single gain setting: PGA0. I found this at:
http://www.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series
So if I want the best case noise figure, would it be sufficient to set PGA0
to 70 dB?
As a side note, we found that for a given USRP motherboard (and hardware
settings), the received power as seen in software changes from one RFX900
board to another by as much as 10 dB. Is this expected?
Thanks again,
Regards
Sundar
On Sun, Jul 3, 2011 at 8:42 PM, Marcus D. Leech wrote:
> On 07/03/2011 08:05 PM, Sundaram Vanka wrote:
>
> Hi,
>
> I have a few questions about the (analog) AGC on the AD8347 mixer chip on
> the Flex900 daughterboard.
>
> 1. Given a signal received with some known power, is it possible to read
> the programmed AGC gains (and thereby find the mixer's noise figure)?
> 2. Is it possible to lock these gain settings? If not, can the AGC
> functionality be disabled?
> 3. How fast does the AGC track changes in signal power?
> 4. If (1), (2) are not possible, is it still possible to know the RX noise
> figure?
>
> I'd appreciate some inputs :) If I understand correctly, to calibrate the
> receive SNR, we need to know the RX noise floor (seen in software). For this
> we need to know the RX noise figure...
>
> To provide some context, the following is our immediate application: we
> have a coded 16QAM system implemented on GNURadio. We want to measure the
> Frame Error Rate vs. Es/No ("per-symbol SNR") for this system. The TX and RX
> have separate USRP boards, each with a RFX900 daughterboard. A coaxial cable
> connects the TX and RX antenna ports. With this setup, we vary the transmit
> power and measure the frame error rate. To compare these results with a
> Matlab model, we need to know the received Es/No: for that we need the RX
> noise figure...and hence my question above.
>
> I'd appreciate your help.
>
> Thanks in advance,
> Regards
> Sundar
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> The gain control on the RFX900 is all purely manual, unless you modify the
> hardware for AGC.
>
> Figure 19 on the AD8347 datasheet shows noise figure vs gain settings for
> the mixer, but on the
> RFX900, there's an LNA in front of it, which at least for higher mixer
> gain settings very much
> offsets the conversion noise. The very best noise figure on the mixer is
> at highest gain, giving roughly
> 5dB for the mixer. Dividing this by the 13.2dB LNA gain and adding the
> noise of the MGA82563 LNA
> (2.2dB) gives a best-case noise figure of something on the order of 3dB.
> In reality, you're likely
> looking at closer to 3.8dB noise figure, due to connector and trace
> losses in front of the LNA, etc.
>
> The gain setting in UHD/Gnu Radio should correspond fairly-precisely to the
> gain setting on the
> RFX900 mixer, which provides something like 69dB of total gain range. In
> most cases in RF systems
> like this, gain-control is implemented using variable attenuators in
> front of the gain element, so
> effective noise figure becomes worse as you lower the gain. I believe
> that UHD attempts to optimize
> its gain distribution for noise figure, but you can also manually set the
> individual gains that
> are available. On the USRP, there's a PGA in front of/part-of the RX
> ADC, in addition to the gain control
> on the AD8347 mixer chip, and UHD will distribute gain settings over
> these elements.
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://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
