Re: [Discuss-gnuradio] GNU Radio in Fedora repo
2008/5/4 Steve Totaro <[EMAIL PROTECTED]>: > > On Sun, May 4, 2008 at 11:15 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: > > On Sun, May 04, 2008 at 04:19:16PM +0200, Trond Danielsen wrote: > > > > > > GNU Radio and related tools are now available from the Fedora > > > repository which should get you up and running in no time :-) > > > > > > Regard, > > > -- > > > Trond Danielsen > > > > That's great news Trond! > > > > Thanks! > > Eric > > > > Very NICE! I am yumming it right now on FC8 (28M). Thanks Trond. As mentioned in another email, Marek Mahut [1] is the one who deserves the credit. [1] [EMAIL PROTECTED] -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio on PCI-104 (i.e., Fedora on USB Flash Drive)
2008/5/1 Bahn, William L Civ USAFA/DFCS <[EMAIL PROTECTED]>: > Is there a fairly straightforward way to get Fedora to run from a USB key? Just boot the install media with the USB key plugged into the board and you should be able to select the USB key as the target for the install. > An alternative would be: Does anyone know of a Linux distro that can be made > to run from a USB key that we can get GnuRadio up and running on without too > much heartache. We've tried installing it on DSL (Damn Small Linux) but can't > get the fftw libraries to compile. GNU Radio and related tools are now available from the Fedora repository which should get you up and running in no time :-) Regard, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: frequency offset of USRP
2008/3/30, Sl Peng <[EMAIL PROTECTED]>: > Thanks Trond! > I think this thread just tell me there should be a frequency offset, but > I did not find any answer about how do deal with this problem in this > thread. There are several ways to deal with this issue, but a simple solution that I have used my self is to just increase the Doppler frequency search range of your acquisition procedure. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] frequency offset of USRP
2008/3/30, Sl Peng <[EMAIL PROTECTED]>: > Hi all: > My task is to use the USRP to down convert the GPS L1 channel to > baseband signal. > I have some problems with the carrier offset of the DBS_RX > daughterboard. > When I set f_l0 of the DBS_RX daughterboard to be 1575.42e6 which is the > center frequency of GPS L1 signal, I found the real frequency in the > tune(double _freq) function was 1575.5e6. So there is 8 hz offset. I > want to know what the output of DBSRX daughterboard is. What is the > effect of this offset to my input signal? > > Next, I need to down convert the output signal of the daughterboard. Fox > example, I want to down convert it to 1.5M hz. Then, what should I do? > I think I should use this function: > usrp_standard_rx: set_rx_freq (int channel, double freq). > > What is the input value of freq? > > Any suggestions? Thanks a lot! Hi, I think you might find this thread from the mailing list archive useful: http://lists.gnu.org/archive/html/discuss-gnuradio/2007-04/msg00105.html -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Best GR-friendly Linux distro ... Ubuntu won !
2008/3/27, Trond Danielsen <[EMAIL PROTECTED]>: > 2008/3/26, mohamed adm <[EMAIL PROTECTED]>: > > > Ubuntu 7.10 Gusty seems to be more GR-friendly than > > others, I tried it well and everything works fine, but > > can't find USB info from "lsusb" or "/proc/bus/usb"! > > any ideas? > > > I would just like to point out that GNU Radio and related tools will > be available for Fedora 9 when it is released at the end of april. > Hopefully these packages will be backported to F8, which makes Fedora > a GR-friendly distribution. Yay! Small correction: GNU Radio is also available for F-8, but is currently only available in the testing repository. Depending in the amount of feedback it receives it will be moved to the stable repository within the next week (faster if positive feedback is received). You can easily submit feedback here: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2771 -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Best GR-friendly Linux distro ... Ubuntu won !
2008/3/26, mohamed adm <[EMAIL PROTECTED]>: > Ubuntu 7.10 Gusty seems to be more GR-friendly than > others, I tried it well and everything works fine, but > can't find USB info from "lsusb" or "/proc/bus/usb"! > any ideas? I would just like to point out that GNU Radio and related tools will be available for Fedora 9 when it is released at the end of april. Hopefully these packages will be backported to F8, which makes Fedora a GR-friendly distribution. Regard, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.1.1 available - upgrade recommended
2007/11/8, Johnathan Corgan <[EMAIL PROTECTED]>: > On Thu, 2007-11-08 at 14:21 +1030, Berndt Josef Wulf wrote: > > > On NetBSD the following error occurs with: > > > > checking boost/shared_ptr.hpp usability... yes > > checking boost/shared_ptr.hpp presence... yes > > checking for boost/shared_ptr.hpp... yes > > checking for svn... /usr/pkg/bin/svn > > Shared object "libaprutil-0.so.0" not found > > Shared object "libaprutil-0.so.0" not found > > Component omnithread passed configuration checks, but not building. > > Component gnuradio-core requires omnithread, which is not being built. > > configure: error: Component gnuradio-core has errors, stopping. > > *** Error code 1 > > > > Can someone tell me more about libaprutil? Is this a new dependency? I > > didn't > > see it on previous versions. > > This is not part of GNU Radio and is not a GNU Radio dependency. > 'libapr' is the Apache Portable Runtime Utility library. Something > that ./configure runs is trying to dynamically load this and your system > either doesn't have it installed or it can't otherwise be found. I notice that on the line before the failed check ./configure looks for subversion. ldd /usr/bin/svn tells me that the svn binary is linked with libarputil-1.so.0 on my Fedora 8 box. This might not be a solution to your problem, but might help locating it. Regards. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulated Doppler Shift
2007/10/26, Ryan Rutherford <[EMAIL PROTECTED]>: > Hello everyone, > > I am trying to figure out the best way to approach simulating doppler > shift on my BPSK transmitter. Does anyone know of how I may be able to > approach this? > > Thank you in advance for any information. Hi, You can just multiply the BPSK signal with the signal from a gr.sig_source_c block. This should be sufficient if you do no take the effect of the Doppler frequency shift of the BPSK signal into account. This assumption might be valid for your application, but that depends on the rate of the BPSK modulation. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upgrade to Fedora 7?
2007/8/8, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > I've been using Ubuntu with much better results. You'll spend less time > fixing the OS and more time on doing GNU radio stuff. > > > > On Tue, 7 Aug 2007, Marcus Leech wrote: > > > I'm considering upgrading my receiver 'puter (a Dual-core Pentium > > system) from FC6 to Fedora7. > > > > Anything I need to know for Gnu Radio? I've been using both FC6 and F7 with GNU Radio, and have never had any problems. > > I've already noticed that Firefox 2.0.0.5 is *very* flakey on Fedora > > 7--crashes without provocation every few > > minutes. [If anyone here happens to know the fix for that, that would > > be cool, but I'm mostly interested > > in Gnu Radio "gotchas"]. I am using FF 2.0.0.5, and cannot find any problems with it. I leave it running for days on my workstation, and it does not crash here. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-buffer usage
2007/7/24, Eric Blossom <[EMAIL PROTECTED]>:
> On Tue, Jul 24, 2007 at 12:36:10PM +0200, Vincenzo Pellegrini wrote:
> > thanks Trond,
> > I went your way, and actually my stream gets loaded right into the ram
> > as I wanted..:)
> > my problem is now that.. doing:
> >
> > data = fromfile("/root/Desktop/ofdm_encode_1H.dump",
> > dtype="complex64")
> > vector_source = gr.vector_source_c(data,True)
> >
> > self.connect(vector_source,gain)
> > self.connect (gain, self.u)
> >
> > I get an error relating to the number of arguments I pass to
> > gr.vector_source_c
> >
> > vector_source = gr.vector_source_c(data,True)
> > File
> > "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_gengen.py",
> > line 6695, in vector_source_c
> > return _gnuradio_swig_py_gengen.vector_source_c(*args)
> > NotImplementedError: Wrong number of arguments for overloaded function
> > 'vector_source_c'.
> > Possible C/C++ prototypes are:
> >
> > gr_make_vector_source_c(std::vector > > > const &,bool)
> >
> > gr_make_vector_source_c(std::vector > > > const &)
> >
> >
> > what am I doing wrong?
> >
> > sorry for bothering..
> > and thanks for help
> >
> > vincenzo
>
> What is the type of the "data" result?
The type of data is a numpy array. It can be converted to an ordinary
python list:
a_list = data.tolist()
However, whenever a list is expected, a numpy array can always be used.
> vector_source_c expects a Python list or tuple of complex.
--
Trond Danielsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-buffer usage
2007/7/25, Vincenzo Pellegrini <[EMAIL PROTECTED]>: > i think my problem is that numpy's fromfile() provides this as an output > > [ -1.38586906e+38 +1.12948992e+32j 1.43605805e+30 -4.40817649e-09j >8.78218944e+08 -1.98631123e-14j ..., 4.88822397e+23 +2.90330289e > +13j >5.91237359e-02 +4.88047634e+23j -5.31466166e+33 -3.25484218e-18j] > > which gets refused from gr.vector_source > > instead of this > > [ -1.38586906e+38 +1.12948992e+32j , 1.43605805e+30 -4.40817649e-09j >8.78218944e+08 -1.98631123e-14j , 4.88822397e+23 +2.90330289e+13j >5.91237359e-02 +4.88047634e+23j , -5.31466166e+33 -3.25484218e-18j] > > which works fine. > > I haven't been able to find much documentation about numpy so I don't > know how to convert between these data types.. > > does anyone know where to look? http://www.scipy.org -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-buffer usage
2007/7/19, Vincenzo Pellegrini <[EMAIL PROTECTED]>:
thanks Trond,
doesn't
gr.file_source--->usrp_sink
constrain me at the maximum speed of my hard drive?
and what whould be the right flow graph setup for buffering via
gr.vector_source,
anything like:
gr.file_source--->data=gr.vector_sink
gr.vector_source(data, repeat=true)--->usrp_sink
would be correct?
No, if you use vector_source, you should not use the gr.file_source to
load the data. How you read the data from the file depends on the
format is is stored in, but if it data recorded with GNU Radio, I
personally use numpy/scipy. Python example:
from numpy import *
# Use complex64 for gr.gr_complex and float32 for gr.float
data = fromfile("filename.dat", dtype="complex64")
src = gr.vector_source(data, repeat=True)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-buffer usage
2007/7/19, Vincenzo Pellegrini <[EMAIL PROTECTED]>: hi, can anyone point me towards some example code using gr-buffer? I need to read a sample stream from HD (not very fast..) and afterwards re send it towards the usrp significantly faster (8complex Msps). is gr-buffer a good candidate to do this? You could either use gr.file_source_x or gr.vector_source_x. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Plotting question
I find it convenient to sink the data to a vector_sink and then use matplotlib to plot the signal. 2007/7/14, Justin Shaw <[EMAIL PROTECTED]>: A quick and dirty fix is to dump the data to a file, then plot the data offline with python. Teun wrote: > Hi guys, > > I have a question. I have made a python script with some c++ modules. > Everything is working fine, so I'm pretty happy so far. Occasionally > something happens within a .cc file, it doesn't really matter what happens. > Whenever this happens I want to make a plot of the event and if it happens > again I want the plot to be refreshed so that we can keep track of the event > changing over time. Hope you guys understand what I'm talking about ^^. > > So now my question. Is there any way to do this? Should I dive into the .cc > code and do some sort of plot, not using python? Any other ideas are very > welcome. > > Thanks, > tvb > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA Gain?
2007/7/10, Eric Cottrell <[EMAIL PROTECTED]>: Hello, The LFRX daughterboard on the USRP has 20 dB of gain. I seem to remember that 10 dB of that gain is from the FPGA. I assume that this gain is after the ADC? If so, is it really useful? I relate digital gain to zoom on a digital camera. The analog gain is the optical zoom and the digital gain is the digital zoom. Digital cameras have 10x or more digital zoom but it is not really useful. At high digital zooms you get lower resolution and the picture is blocky. Optical zoom is more useful as it comes before the digitizer. So if I have noise values of 35 and signal values of 40 then I get values of 350 and 400 after the 10 dB digital amplifier. I may see a higher amplitude signal but how do I gain anything? Am I missing something? 73 Eric Hi Eric, The ADC has a programmable gain stage prior to sampling. Could it be that one you are thinking of? Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFT Spectral smoothing]
2007/6/29, Aadil Volkwin <[EMAIL PROTECTED]>: Hi, My apologies for the lengthy silence. I have been out of town and unable to respond to mail. I'm not entirely clear on what you mean when you ask if the smoothing is over time or frequency. In essence, I would like to reproduce an output comparable to that of a spectrum analyser. That is, the GNU FFT show the frequencies and their related power in dB respectively, instantaneously. I would like to average the values of the Power spectrum and obtain an output showing the "smoothed/average" frequency values over a certain period. for instance say 100 samples of each frequency. Such that the values outputted are more stable and accurate and less eratic. As I am new to GNU_RADIO, I am not aware if the functionality for smoothing is built in and If I would need to write code to do this averaging of values, i'm not quite clear on where to begin. My apologies again for the lengthy delay and look forward and appreciate your assistance regarding this matter. regards, Aadil Volkwin You can use the single pole iir filter to smooth the signal. The single pole filter is also known as a exponential moving average filter. You can find the GNU Radio documentation for it here: http://gnuradio.org/doc/doxygen/classgr__single__pole__iir__filter__cc.html If you want to know more, I can recommend this: http://www.dspguide.com/ch19/2.htm -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency resolution of CORDIC algorithm
2007/6/28, Johnathan Corgan <[EMAIL PROTECTED]>: > Thus, for DC, the phase increment value is zero, for 0.0149 Hz, it is 1, for 0.0298 Hz, it is 2, all the way up to 32 MHz, where it is pow(2, 31). You can also tune negative frequencies, where -1 creates -0.0149 Hz, etc. There is one more thing that I just can not figure out. The largest angular rotation that can be performed by the CORDIC is +/- pi/2, which means that is takes four cycles to rotate the vector all the way around. How come the largest frequency that can be generated be 32 MHz. Thanks in advance Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency resolution of CORDIC algorithm
2007/6/28, Brian Padalino <[EMAIL PROTECTED]>: On 6/28/07, Trond Danielsen <[EMAIL PROTECTED]> wrote: > Hi, > > after having read several papers on the subject, I am still not able > to find the answer I am looking for. I wonder how to calculate the > frequency resolution of the CORDIC algorithm. In an earlier post to > this mailing list it was stated that the resolution is approximately > 0.01 Hz. Could anyone point me to where I can find a deviation of this > result? This paper is really good for understanding the CORDIC: http://web.njit.edu/~hkj2/CORDIC.pdf It is specifically written to look at FPGA implementations, which is nice. As I understand it, the USRP uses the CORDIC as described in section 3.1 of that paper. A phase accumulator is used to spin the angle around, and the modulated sin/cos or xi is the output on xo and yo after 12 iterations of the algorithm. The value of zo should be zero, and any error leftover should be represented on that output. The resolution should really be how slowly you can spin the zi component while maintaining accuracy out of the CORDIC. It may be that with 12 iterations and 16-bit inputs 0.01 Hz is possible, whereas more iterations or larger inputs might get better resolution, but I suspect you're really past the point of diminishing returns at that point. Is that helpful? Thank you a lot for your reply. I have already read the mentioned paper, and found it useful. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency resolution of CORDIC algorithm
2007/6/28, Johnathan Corgan <[EMAIL PROTECTED]>: Trond Danielsen wrote: > after having read several papers on the subject, I am still not able > to find the answer I am looking for. I wonder how to calculate the > frequency resolution of the CORDIC algorithm. In an earlier post to > this mailing list it was stated that the resolution is approximately > 0.01 Hz. Could anyone point me to where I can find a deviation of > this result? The "phase generator" part of the CORDIC block works by incrementing a 32-bit phase register by a fixed amount per clock cycle. The full size of the register represents 2*PI() of phase, or one cycle of the waveform. The user programmed phase increment per clock cycle then represents frequency. In the receive chain of the FPGA, the phase generator is clocked at 64 MHz. Thus, the minimum delta-frequency (a one bit change in the phase increment register) is 64 MHz / pow(2, 32) = 0.0149 Hz. Thus, for DC, the phase increment value is zero, for 0.0149 Hz, it is 1, for 0.0298 Hz, it is 2, all the way up to 32 MHz, where it is pow(2, 31). You can also tune negative frequencies, where -1 creates -0.0149 Hz, etc. The CORDIC block then uses the resulting "sawtooth" phase value to rotate the incoming signal by that amount, resulting in complex frequency conversion. Did this help, or confuse? Thanks a lot! This was indeed the last missing piece in my CORDIC puzzle, which by no means covers the entire picture, but a sufficient subset for my humble needs :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Frequency resolution of CORDIC algorithm
Hi, after having read several papers on the subject, I am still not able to find the answer I am looking for. I wonder how to calculate the frequency resolution of the CORDIC algorithm. In an earlier post to this mailing list it was stated that the resolution is approximately 0.01 Hz. Could anyone point me to where I can find a deviation of this result? Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question regarding the DBSRX frequency range and bandwidth
2007/6/27, Matt Ettus <[EMAIL PROTECTED]>: Trond Danielsen wrote: > Hi, > > I have a small question regarding the frequency range and bandwidth of > the DBSRX daughterboard from www.ettus.com. According to the > daughterboard datasheet [1] the frequency range is from 800 to 2400 > MHz, and the adjustable bandwidth is from 1 to 60 MHz. However, the > datasheet for the MAX2118 [2] states a frequency range from 925 to > 2175 MHz, and the adjustable LP filter BW is 4 to 33 MHz. > > If someone could provide some information that would enlighten me on > these matters I would be most grateful. Frequency Range: The MAX2118 datasheet says that it covers 925 to 2175 MHz. They spec that because it is the range that their typical customer needs (for small satellite dish IFs). However, I have never found one which doesn't work to the larger 800 MHz to 2400 MHz range. Maxim guarantees 925 to 2175, I guarantee the larger range. Bandwidth: When Maxim states that their maximum LPF bandwidth is 33 MHz, they mean one-sided bandwidth (i.e. 0 to 33 MHz). Since it is used in a direct conversion IQ system, that actually gives a 66 MHz bandwidth (-33 MHz to +33 MHz). Since that is beyond nyquist for our ADC, I spec to 60 MHz (+/- 30 MHz). On the low end, they specify 4 MHz, which is really 8 MHz (+/-4 MHz) of RF bandwidth. The filter is actually capable of going to a much narrow frequency, but it is outside of Maxim's specs, since nobody in the small satellite dish market cares about less than 8 MHz of BW. So I spec that it goes down to 1 MHz wide. It should be noted that when you go below 4 MHz wide (2 MHz in Maxim-speak) that your noise floor will rise a bit and phase noise may also rise. Matt Hi, Thank you very much for the clarification! I will add this information to the wiki, just in case anyone else wonders about the same. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question regarding the DBSRX frequency range and bandwidth
Hi, I have a small question regarding the frequency range and bandwidth of the DBSRX daughterboard from www.ettus.com. According to the daughterboard datasheet [1] the frequency range is from 800 to 2400 MHz, and the adjustable bandwidth is from 1 to 60 MHz. However, the datasheet for the MAX2118 [2] states a frequency range from 925 to 2175 MHz, and the adjustable LP filter BW is 4 to 33 MHz. If someone could provide some information that would enlighten me on these matters I would be most grateful. Regards, -- Trond Danielsen [1] http://www.ettus.com/downloads/miscdboards_v3b.pdf [2] http://datasheets.maxim-ic.com/en/ds/MAX2116-MAX2118.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Website down?
2007/6/22, Teun van Berkel <[EMAIL PROTECTED]>: gnuradio.org down? :( It works just fine in my little corner of the world. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFT Spectral smoothing
2007/6/21, Aadil Volkwin <[EMAIL PROTECTED]>: Hi, i'd like to do spectral smoothing on an FFT in real time through GNU_RADIO. Is there a function that will allow me to do this in the GNU_RADIO modules? If not has anyone attempted it before, or have any suggestions as to how I should go about implementing it myself. Perhaps any ideas of cascading blocks that do exit. Thanks, Aadil From what I can find, "spectral smoothing" is not an unambiguous term. Could you please elaborate the problem, preferably the mathematical definition of what you are trying to accomplish. Best regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Parameters for USRP (motherboard only) FM receiver
2007/6/19, Shane Clark <[EMAIL PROTECTED]>: I am using the DBSRX board. I have actually gotten the receiver working more or less through trial and error, but I have yet to do the FM demodulation in Python. Did you read the specifications for the DBSRX board? The frequency range of this daughter board is approx. 900 to 2400 MHz, which is outside the signal you are trying to receive. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA in USRP
2007/6/15, Achilleas Anastasopoulos <[EMAIL PROTECTED]>: Dear Mande here is an application that requires significant FPGA functionality: try to design the first stages of a spread-spectrum receiver, ie, the part of the receiver that does pn code acquisition (and tracking). This is a demanding task that needs to be performed on hardware. Once code acquisition/tracking is performed, the input data can be despread (this is also done in hardware) and then only the symbol-spaced samples are passed to the Gnu-radio software for further processing (ie, decoding, etc). I do not know the rate of the spreading codes used in the IS-95 standard, but several people have made complete or parts of GPS receivers for GNU Radio, where all of the processing is done in real-time. The lack of hardware multipliers in the Cyclone I is the biggest limiting factor for creating the these correlators in the FPGA. Some receivers require 2 or 3 such blocks (fingers) running in parallel. Check out how IS-95 mobile standard works for more info. In a GPS receiver, it is desirable to be able to run at least 4 channels in parallel. This highly specialized functionality is better suited for software. With modern CPUs, SIMD instructions and advanced algorithms, I do not think the performance here is that much different. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Power PC running Linux
2007/6/13, Robert McGwier <[EMAIL PROTECTED]>: If anyone has gnuradio running on a Power PC under Linux (FC6 in particular), could you drop me a private email with any details you might care to provide on getting it to run? It compiles just fine but blows up in make check and other areas. Search the archive for a thread regarding EFIKA. EFIKA is an embedded PowerPC that runs Linux. Others have successfully been running GNU Radio on that platform, but I cannot verify the performance or if they had other problems. Once my thesis is finished I will pull mine out from the drawer and see if I can get Fedora running on it. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] spectrum analyzer
2007/6/13, Abram Young <[EMAIL PROTECTED]>: Hi, I'm a recent gnuradio/python user (newbie) and have played with the python pieces and USRP as far as time will allow for now. I can write my own program to record A/D streams to disk, but that's about it. I'm using Octave to read in and plot the streams then. I'd like to either modify the usrp_fft.py code, or add the fft_sink call to my own .py (preferred) and output to stdout. Specifically, I need to access the data from fft_sink to find the maximum, and output it's frequency/value. How do I do this? You can either use the gr.max_xx or gr.argmax_xi blocks that are available in trunk to get the maximum value or the argument of the maximum value from the FFT. Or you can just sink the signal to a vector sink, and process the recorded signal with numpy/scipy or octave/matlab if that is your cup of tea. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Several basic questions
2007/6/11, Teun <[EMAIL PROTECTED]>: Hi Guys, I tried searching the forum, but I still got some problems which I don't fully understand. To my knowledge, the receiving ADC Rate is 64 MSamples/second, at a granuality of 14 bits/sample. This would make it possible to have a total system bandwith of 32 Mhz (Nyquist), which is enough for example 802.11 standards. However, samples are transfered to the PC, using the USB bus. The usual I/O handling of the USB bus is 16 bits I and 16 bits Q signals, which means that you require 4 bytes per complex sample. The raw data rate for the USB is 480Mbit/s, but due to overhead it is possible to get only about 320Mbit/s, which is about 40Mbyte/s. Summing everything up, it is possible to transfer 40M/4 = 10Msamples/second over the USB bus, which means that you can only check a system with a bandwith of approximately 10Mhz. Am I right about this? If this is true, the limiting factor is the USB bus, not the ADC's on the USRP. Is it possible to use some sort of 1Gbit ethernet connection for the USRP? I know this wouldn't help that much, but It would make it possible to achieve the 802.11 standards (Channels of 20Mhz). Is this possible or are other things like CPU speed/PC memory becoming an issue? Correct me if I am wrong, but in the usrp_rx_cfile.py script there is an option to transfer 8-bit samples across the USB. With this option enable, it should be possible to increase the BW at the expense of the resolution. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make error [svn revision 5708]
2007/6/6, Tarun Tiwari <[EMAIL PROTECTED]>:
Hi,
Today I update the gnuradio from svn, and received following error in make:
make[5]: Entering directory
`/home/tarun/gnuradio/gnuradio-core/src/lib/swig'
make[5]: *** No rule to make target
`../../../../gnuradio-core/src/lib/general/gr_dpll_ff.i',
needed by `gnuradio_swig_py_general.cc'. Stop.
Then, I edited the Makefile.am in
../../../../gnuradio-core/src/lib/general/ and added
gr_dpll_ff.{cc,h,i} but I got following error :
make[6]: Entering directory
`/home/tarun/gnuradio/gnuradio-core/src/lib/general'
make[6]: *** No rule to make target `gr_dpll_ff.cc', needed by
`gr_dpll_ff.lo'. Stop.
Can somebody check the Makefile as I am not able to identify the problem?
Thanks in advance.
Regards,
Tarun
UT Dallas
I just pulled a fresh copy from svn (rev.5708), ran ./bootstrap;
./configure; make. No problems so far. I recommend that you run
./bootstrap and ./configure again after pulling from svn. This ensures
that the generated Makefiles are updated according to the svn changes.
--
Trond Danielsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how do I disable this buffer warning?
2007/6/4, Eric Blossom <[EMAIL PROTECTED]>: On Mon, Jun 04, 2007 at 12:19:21PM +0200, Vincenzo Pellegrini wrote: > Hi List, > the warning is ok, but once I have realized I've got no problem with it > how do I prevent it from spoiling the continuity of my status > messages? :D > > can anyone suggest how to disable it > > many thanks > best regards > > vincenzo > > - > > Connecting Outer Interleaver, Bit Extractor, Inner Encoder > > Done > > - > > Connecting Inner Interleaver > > gr_buffer::allocate_buffer: warning: tried to allocate > >5 items of size 6048. Due to alignment requirements > >128 were allocated. If this isn't OK, consider padding > >your structure to a power-of-two bytes. > >On this platform, our allocation granularity is 4096 bytes. It's printed out on line 126 of gr_buffer.cc. Hack away ;) Eric I also get a lot of messages like this, and I suspect it is the curse for doing vector processing on vectors of length other than powers of two. Am I correct? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Conversion from Python Numeric to numpy on trunk
2007/5/28, Johnathan Corgan <[EMAIL PROTECTED]>: Because of the variety of platforms GNU Radio is used on, there may be some problems with specific systems that we'll need to go back and look at. The GNU Radio wiki pages that deal with installation on different platforms still need to be updated to reflect the change. numpy is part of the "Engineering and Scientific" group, so the instructions for Fedora is up to date: http://gnuradio.org/trac/wiki/FedoraInstall -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS on DBSRX
2007/5/24, Chris Stankevitz <[EMAIL PROTECTED]>: Ben Loftin wrote: > Chris, > > I have successfully done coarse acquisition using the correlator developed > here, Ben, Thanks for the reply. I now have a GPS acquisition routine and tracker running. I am using the DBSRX with about 60dB of gain on a "puck" style antenna. My trackers are producing the nav bits, but I still need to decode them (I plan to use GPStk for this). It is all implemented as a single gnuradio block. I will release the source when I get smart on the subject and get a final thumbs up from my company (which paid for it). Chris I am very excited to see the result once it is released! I just wanted to mention some of the differences between this and my approach. I am trying to keep as much as possible at GNU Radio level, and thereby exposing as much of the internals as possible at Python level. This has proven to be harder that initially assumed due to the lack of message passing functionality[1] and the possibility to reconfigure a running graph. My main target is research and development, so to have access to all parts of the receiver in a high level language is a great advantage. Since it is also a goal to be able to experiment with sensor integration such as INS, a modular system is also an advantage. If anyone wants to get together and discuss GNU Radio and GNSS, I will be at ION GNSS 2007 in September; hopefully the OpenGNSS will have gained more functionality by then :) [1]. I have looked into message queues, but it is not what I am looking for. Mblocks might be the answer, but they were not available in March. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS on DBSRX
2007/5/24, Ben Loftin <[EMAIL PROTECTED]>: Trond, > If anyone is interested, I have a complete coarse acquisition module > written for GNU Radio. The source code is available from > http://code.google.com/p/opengnss/. Some cleaning of the code is still > required. You can find images of the current results here: > http://trondd.blogspot.com/2007/05/opengnss-status.html Awesome, I would like to try it out, what is the best way to get the needed blocks assuming they are not in a patch already? Any thoughts on the next step of tracking? I want to try both the BASS tracking described by James Bao-Yen Tsui in Fundamentals of Global Positioning System Receivers: A Software Approach and a conventional PLL based tracking module. But before I can get down to tracking, I have to implement the fine frequency estimation. Also, if I want to test it from my captured files would I change line 85 of acquisition.py to pull from a file or is this done somewhere else. Thanks. Take a look at the gr_gnss-acquistion-test.py script in the scripts folder. Basically this is all you need: file_src = gr.file_source(gr.sizeof_gr_complex, "../data/L1-4MHz-svn1-nav.dat") self.acquisition = acquisition(fs=fs, svn=1, alpha=alpha) self.ca_sink = gr.vector_sink_f() self.fd_sink = gr.vector_sink_f() self.rmax_sink = gr.vector_sink_f() self.connect( self.src, self.acquisition) self.connect( (self.acquisition, 0), self.ca_sink ) self.connect( (self.acquisition, 1), self.fd_sink ) self.connect( (self.acquisition, 2), self.rmax_sink ) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS on DBSRX
2007/5/23, Trond Danielsen <[EMAIL PROTECTED]>: 2007/5/23, Ben Loftin <[EMAIL PROTECTED]>: > Chris, > > I have successfully done coarse acquisition using the correlator developed > here, > > https://projects.cecs.pdx.edu/~icarroll/SoftwareGPSCorrelator/index.cgi/wiki > > A plot of the 'acquisition' is here > > http://64.6.242.226/grblog/uploaded_images/sat_18-714418.png > > for satellite PRN 18 with a code offset of 1988 as shown by the 'spike'. The > gain for the dbsrx was 86 dB while using an active external antenna to get 28 > dB more of gain. More details on my blog, > > http://64.6.242.226/grblog/grblog.html > > Not sure if I will have a link to the sample data because it is almost 2 GB > compressed, yikes! If you know how to break up the data let me know and I will > upload just the begininning of the file, since it is just over a minute of > data. If anyone is interested, I have a complete coarse acquisition module written for GNU Radio. The source code is available from http://code.google.com/p/opengnss/. I forgot to mention that you need some additional block for GNU Radio that is not available in the stock distribution. Patches have been sent to Eric Blossom, but do not think they have been included yet. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS on DBSRX
2007/5/23, Ben Loftin <[EMAIL PROTECTED]>: Chris, I have successfully done coarse acquisition using the correlator developed here, https://projects.cecs.pdx.edu/~icarroll/SoftwareGPSCorrelator/index.cgi/wiki A plot of the 'acquisition' is here http://64.6.242.226/grblog/uploaded_images/sat_18-714418.png for satellite PRN 18 with a code offset of 1988 as shown by the 'spike'. The gain for the dbsrx was 86 dB while using an active external antenna to get 28 dB more of gain. More details on my blog, http://64.6.242.226/grblog/grblog.html Not sure if I will have a link to the sample data because it is almost 2 GB compressed, yikes! If you know how to break up the data let me know and I will upload just the begininning of the file, since it is just over a minute of data. If anyone is interested, I have a complete coarse acquisition module written for GNU Radio. The source code is available from http://code.google.com/p/opengnss/. Some cleaning of the code is still required. You can find images of the current results here: http://trondd.blogspot.com/2007/05/opengnss-status.html The current version has been tested against signals generated by a Spirent GPS simulator. The recorded data files are available from ftp://open-gnss.org/pub/opengnss/raw_gps_data. Please let me know if you have any feedback. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real sampling with DBSRX (& more!)
2007/5/14, Davide Anastasia <[EMAIL PROTECTED]>: Il giorno lun, 14/05/2007 alle 11.23 +0200, Trond Danielsen ha scritto: > > Il giorno lun, 14/05/2007 alle 11.09 +0200, Trond Danielsen ha > scritto: > > > > Hi List, > > > > is it possible to use only real sampling coming from the DBSRX? > > > > > > I am not sure if I understood your question correctly, but Is > there a > > > reason why gr.complex_to_real() does not work? > > > > Why not simply usrp.source_s()? > > http://lists.gnu.org/archive/html/discuss-gnuradio/2007-03/msg00406.html > > Besides, floats are more convenient :) I'm not really sure I've understood what you want to tell me. Infact you give me a link to a reply on a thread I open some times ago. I only refered to Eric Blossoms statement that usrp.source_s is broken, but I have not found anything regarding why it is broken. As I said earlier, if you are just interested in the positive part of the spectrum, then gr.complex_to_real should give you everything you need. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real sampling with DBSRX (& more!)
2007/5/14, Davide Anastasia <[EMAIL PROTECTED]>: Il giorno lun, 14/05/2007 alle 11.09 +0200, Trond Danielsen ha scritto: > > Hi List, > > is it possible to use only real sampling coming from the DBSRX? > > I am not sure if I understood your question correctly, but Is there a > reason why gr.complex_to_real() does not work? Why not simply usrp.source_s()? http://lists.gnu.org/archive/html/discuss-gnuradio/2007-03/msg00406.html Besides, floats are more convenient :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real sampling with DBSRX (& more!)
2007/5/14, Davide Anastasia <[EMAIL PROTECTED]>: Hi List, is it possible to use only real sampling coming from the DBSRX? I am not sure if I understood your question correctly, but Is there a reason why gr.complex_to_real() does not work? As long as you signal is an appropriate IF, the real part of the complex signal should contain all of the information. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dictionary basic blocks
2007/5/14, Teun van Berkel <[EMAIL PROTECTED]>: Hi guys, I'm a bit new to the GNU radio. I've got it working right now, but I was just wondering if there is some sort of dictionary (library) for every block that is available in GNU radio, explain the syntax and how to use the block. I've looked everywhere on the web, but can't seem to find anything. Any help is much appreciated. This should cover most of the available blocks: http://gnuradio.org/doc/doxygen/hierarchy.html You can find additional information under the documentation section on the GNU Radio website: http://gnuradio.org/trac/wiki -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updating trac?
2007/5/13, Johnathan Corgan <[EMAIL PROTECTED]>: Brett L. Trotter wrote: > The gnuradio build guide for fedora should be updated since the latest > trunk requires guile-devel to be installed as well. Actually, only the interpreter is needed, you don't need the full devel environment, so if Fedora has these split up (like Debian derivatives do) then you only need to install the former. http://gnuradio.org/trac/wiki/FedoraInstall should now be correct. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updating trac?
2007/5/13, Brett L. Trotter <[EMAIL PROTECTED]>: The gnuradio build guide for fedora should be updated since the latest trunk requires guile-devel to be installed as well. http://gnuradio.org/trac/wiki/FedoraInstall is now up2date. Is there a way for average joes to update the trac wiki? You can use the guest account with password gnuradio. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Single pole filter, difference equation and documentation.
Hi, I notice from the documentation that all of the different single_pole_* filters have the same difference equation. Is this correct? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with messages and msg_queue
2007/5/10, Eric Blossom <[EMAIL PROTECTED]>: On Thu, May 10, 2007 at 05:02:21PM +0200, Trond Danielsen wrote: > 2007/5/10, Eric Blossom <[EMAIL PROTECTED]>: > >On Thu, May 10, 2007 at 10:24:04AM +0200, Trond Danielsen wrote: > >> > >> Ok, I read from pkt.py that to finish a packet, I just append > >> gr.message(1) at the tail of the message queue, but is there a simple > >> way to do this if I just want to send packet of fixed size, where the > >> payload comes from a flow graph? > > > >Hi Trond, > > > >The gr.message(1) isn't to end a packet, it's to tell the scheduler > >that there's no more data coming. > > > >I'm not exactly sure I'm following what you are trying to do. > >However, I think that if you follow through the logic in > >gnuradio-examples/python/digital/tunnel.py you'll see a way to send > >and receive packets (fixed or variable length) between python and the > >flow graph. > > > >Eric > > > > Okay, I will try to describe my problem a little better. I have a > block that estimates some properties on a received signal: Frequency > and phase. Lets call the block acquisition. The acquisition block > outputs the estimates at 1kHz. Now what I want to do is grab these > estimates and use them to update the center frequency and code delay > in another block, lets call it tracking :). > > I have tried to use probe_signal_f, but this does not work because the > acquisition and tracking block must be synchronized. First of all, thank you for you patience with all the questions from a simple user like me! I wouldn't have got very far without the support from this mailing list. The easy way is to put them in the same block (Yes, I know that wasn't the answer you were looking for.) Or you could try using a message queue and messages between them. You don't have to use gr_message_sink. You could have your estimator block create mesages (of whatever format it likes) and insert them into a message queue that was handed to it, say in the constructor. Indeed it would easier if everything was in one block, but I should mention that the acquisition block is defined at python level, and is currently not written in C++. I would really like to keep it at this level, both because of simplicity and for the flexibility it adds. I do believe that the problem that I address is a fairly general one, and something that might be easier with the new mblock. But from what I could see, mblocks are currently only available from C++, or am I missing something? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with messages and msg_queue
2007/5/10, Eric Blossom <[EMAIL PROTECTED]>: On Thu, May 10, 2007 at 10:24:04AM +0200, Trond Danielsen wrote: > > Ok, I read from pkt.py that to finish a packet, I just append > gr.message(1) at the tail of the message queue, but is there a simple > way to do this if I just want to send packet of fixed size, where the > payload comes from a flow graph? Hi Trond, The gr.message(1) isn't to end a packet, it's to tell the scheduler that there's no more data coming. I'm not exactly sure I'm following what you are trying to do. However, I think that if you follow through the logic in gnuradio-examples/python/digital/tunnel.py you'll see a way to send and receive packets (fixed or variable length) between python and the flow graph. Eric Okay, I will try to describe my problem a little better. I have a block that estimates some properties on a received signal: Frequency and phase. Lets call the block acquisition. The acquisition block outputs the estimates at 1kHz. Now what I want to do is grab these estimates and use them to update the center frequency and code delay in another block, lets call it tracking :). I have tried to use probe_signal_f, but this does not work because the acquisition and tracking block must be synchronized. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with messages and msg_queue
2007/5/10, Eric Blossom <[EMAIL PROTECTED]>: On Wed, May 09, 2007 at 11:14:43PM +0200, Trond Danielsen wrote: > 2007/5/9, Eric Blossom <[EMAIL PROTECTED]>: > >On Wed, May 09, 2007 at 08:12:05PM +0200, Trond Danielsen wrote: > >> Hi everyone, > >> > >> I've got a problem with messages and message queues. The problem is > >> simply that I just cannot figure out how to use them. I tried the > >> simple program that is attached to this email (test.py), and the > >> result is in test.log. If anybody has the time to take a quick look at > >> the code and point me in the right direction, I would be very > >> thankful! > >> > >> Regards, > >> > >> -- > >> Trond Danielsen > > > > > >This looks correct, and in fact you are receiving a payload that's 800 > >bytes long (== 200 * sizeof(float)), so everything looks good. > > > >In reality, you'd want to do something with the payload: > > > > payload = msg.to_string() # return payload as an python string > > > > foo = struct.unpack(format, payload) > > > >See gnuradio-core/src/python/gnuradio/blksimpl/pkt.py for a real-life > >example. > > > >Eric > > Ok, I guess I misunderstood one thing: I assumed that gr.message_sink( > gr.sizeof_float, ...) would set the payload size for each packet to 4 > bytes. No, that would kill our performance. Eric Ok, I read from pkt.py that to finish a packet, I just append gr.message(1) at the tail of the message queue, but is there a simple way to do this if I just want to send packet of fixed size, where the payload comes from a flow graph? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with messages and msg_queue
2007/5/9, Eric Blossom <[EMAIL PROTECTED]>: On Wed, May 09, 2007 at 08:12:05PM +0200, Trond Danielsen wrote: > Hi everyone, > > I've got a problem with messages and message queues. The problem is > simply that I just cannot figure out how to use them. I tried the > simple program that is attached to this email (test.py), and the > result is in test.log. If anybody has the time to take a quick look at > the code and point me in the right direction, I would be very > thankful! > > Regards, > > -- > Trond Danielsen This looks correct, and in fact you are receiving a payload that's 800 bytes long (== 200 * sizeof(float)), so everything looks good. In reality, you'd want to do something with the payload: payload = msg.to_string() # return payload as an python string foo = struct.unpack(format, payload) See gnuradio-core/src/python/gnuradio/blksimpl/pkt.py for a real-life example. Eric Ok, I guess I misunderstood one thing: I assumed that gr.message_sink( gr.sizeof_float, ...) would set the payload size for each packet to 4 bytes. > #!/usr/bin/env python > > from gnuradio import gr > > class testing(gr.top_block): > def __init__(self): > gr.top_block.__init__(self, "testing") > > self.src = gr.vector_source_f( range(200), False ) > > self.mq = gr.msg_queue() > self.sink = gr.message_sink(gr.sizeof_float, self.mq, False) > self.connect( self.src, self.sink ) > > def main(): > top_block = testing() > runtime = gr.runtime(top_block) > > try: > runtime.start() > > print "queue" > print top_block.mq.count() > > msg = top_block.mq.delete_head() > print "msg" > print msg.type() > print msg.arg1() > print msg.arg2() > print msg.length() > > runtime.wait() > except KeyboardInterrupt: > pass > > if __name__ == "__main__": > main() > > # vim: ai ts=4 sts=4 et sw=4 > > connecting: vector_source_f(1):0 -> message_sink(2):0 > Setting runtime on 0x6923a0 to 0x6918c0 > start: entered > flattening testing > Flattening edge vector_source_f(1):0->message_sink(2):0 > Validating block: message_sink(2) > Validating block: vector_source_f(1) > Creating block detail for message_sink(2) > Creating block detail for vector_source_f(1) > Allocating new buffer for output 0 > Setting input 0 from edge vector_source_f(1):0->message_sink(2):0 > start_threads: entered > start_threads: starting 0x6d26f0 > queue > 0 > msg > 0 > 4.0 > 200.0 > 800 > wait: entered > wait: joining thread 0x6d26f0 > wait: join returned -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with messages and msg_queue
Hi everyone, I've got a problem with messages and message queues. The problem is simply that I just cannot figure out how to use them. I tried the simple program that is attached to this email (test.py), and the result is in test.log. If anybody has the time to take a quick look at the code and point me in the right direction, I would be very thankful! Regards, -- Trond Danielsen #!/usr/bin/env python from gnuradio import gr class testing(gr.top_block): def __init__(self): gr.top_block.__init__(self, "testing") self.src = gr.vector_source_f( range(200), False ) self.mq = gr.msg_queue() self.sink = gr.message_sink(gr.sizeof_float, self.mq, False) self.connect( self.src, self.sink ) def main(): top_block = testing() runtime = gr.runtime(top_block) try: runtime.start() print "queue" print top_block.mq.count() msg = top_block.mq.delete_head() print "msg" print msg.type() print msg.arg1() print msg.arg2() print msg.length() runtime.wait() except KeyboardInterrupt: pass if __name__ == "__main__": main() # vim: ai ts=4 sts=4 et sw=4 connecting: vector_source_f(1):0 -> message_sink(2):0 Setting runtime on 0x6923a0 to 0x6918c0 start: entered flattening testing Flattening edge vector_source_f(1):0->message_sink(2):0 Validating block: message_sink(2) Validating block: vector_source_f(1) Creating block detail for message_sink(2) Creating block detail for vector_source_f(1) Allocating new buffer for output 0 Setting input 0 from edge vector_source_f(1):0->message_sink(2):0 start_threads: entered start_threads: starting 0x6d26f0 queue 0 msg 0 4.0 200.0 800 wait: entered wait: joining thread 0x6d26f0 wait: join returned ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Modulation
2007/5/9, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Hi at all, during the work on my diploma thesis I have to deal with Gnu Radio to set up a baseband modem. Now I've got a question: Is there a good place to find available modules for modulation or coding ? If there ist a place, maybe anyone can give me a hint where to find. Thanks for your help! Benedikt The best source for information is the GNU Radio source tree. There you are guaranteed to find the most up-to-date information. You can start by taking a look in the $GNURADIO_SVN_TRUNK/gnuradio-core/src/python/gnuradio/blksimpl folder I can also recommend the doxygen documentation, which is available online: http://gnuradio.org/doc/doxygen/hierarchy.html. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Buffer allocation warning.
Hi, Is there anything I can do to resolve warnings like this: - - - Creating block detail for vector_source_c(161) Allocating new buffer for output 0 Creating block detail for single_pole_iir_filter_ff(158) Allocating new buffer for output 0 gr_buffer::allocate_buffer: warning: tried to allocate 4 items of size 16000. Due to alignment requirements 32 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. Creating block detail for fft_vcc(156) Allocating new buffer for output 0 gr_buffer::allocate_buffer: warning: tried to allocate 4 items of size 32000. Due to alignment requirements 16 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. - - - -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building mblock fails when building in a separate tree
Hi, I create a separate folder when building gnuradio (mkdir -p build && pushd build && ../configure ). This however fails when it comes to mblock: [EMAIL PROTECTED] mblock]$ pwd /home/trondd/src/gnuradio/trunk/build/mblock [EMAIL PROTECTED] mblock]$ make Making all in src make[1]: Entering directory `/home/trondd/src/gnuradio/trunk/build/mblock/src' Making all in lib make[2]: Entering directory `/home/trondd/src/gnuradio/trunk/build/mblock/src/lib' GUILE_LOAD_PATH="/home/trondd/src/gnuradio/trunk/build/mblock/src/lib/../../../../pmt/src/scheme:/home/trondd/src/gnuradio/trunk/build/mblock/src/lib/../../../../mblock/src/scheme" /usr/bin/guile -e main -s ../../../../mblock/src/scheme/gnuradio/compile-mbh.scm qa_bitset.mbh qa_bitset_mbh.cc ERROR: In procedure open-file: ERROR: No such file or directory: "qa_bitset.mbh" make[2]: *** [qa_bitset_mbh.cc] Error 1 make[2]: Leaving directory `/home/trondd/src/gnuradio/trunk/build/mblock/src/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/trondd/src/gnuradio/trunk/build/mblock/src' make: *** [all-recursive] Error 1 -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mean value block
2007/5/3, konvak <[EMAIL PROTECTED]>:
hi all,
I would be interested in getting and displaying some
statistical information (mean, variance...) about received signal (let's
say for educational purposes to try to determine what kind of modulation
I am receiving). Is there any way to get let's say the mean value of the
signal without writing a new block. The only thing I came across is
gr.probe_signal_f() to get the value of the signal. Is it possible to
get _every_ sample with this, somehow I don't think it would work. So do
I really need a new block?
thanks for any suggestions and help,
tomas
I have attached a patch that adds a gr_mean_XX block to gnuradio-core.
The block calculates the arithmetic mean of a single vector. The
variance block should be quite easy to create using this one as a
template. I have not added the various bits and pieces to Makefile.am
etc, but that should (in theory... :) ) not be too hard.
Cheers,
--
Trond Danielsen
Index: gr_mean_XX.cc.t
===
--- gr_mean_XX.cc.t (revisjon 0)
+++ gr_mean_XX.cc.t (revisjon 0)
@@ -0,0 +1,64 @@
+/* -*- c++ -*- */
+/*
+ * Copyright 2004 Free Software Foundation, Inc.
+ *
+ * This file is part of GNU Radio
+ *
+ * GNU Radio is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * GNU Radio is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GNU Radio; see the file COPYING. If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street,
+ * Boston, MA 02110-1301, USA.
+ */
+
+// @WARNING@
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include <@[EMAIL PROTECTED]>
+#include
+
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@ ( size_t vlen )
+{
+ return @SPTR_NAME@ ( new @NAME@(vlen));
+}
+
[EMAIL PROTECTED]@::@NAME@( size_t vlen)
+ : gr_sync_block ( "@BASE_NAME@",
+ gr_make_io_signature (1, 1, vlen*sizeof (@I_TYPE@)),
+ gr_make_io_signature (1, 1, sizeof (@O_TYPE@))),
+ d_vlen(vlen)
+{
+}
+
+int
[EMAIL PROTECTED]@::work( int noutput_items,
+ gr_vector_const_void_star &input_items,
+ gr_vector_void_star &output_items)
+{
+ const @I_TYPE@ *in;
+ @O_TYPE@ *optr = (@O_TYPE@ *) output_items[0];
+
+ for (int i=0; i
+
+class @NAME@;
+typedef boost::shared_ptr<@NAME@> @SPTR_NAME@;
+
[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ (size_t vlen);
+
+
+class @NAME@ : public gr_sync_block
+{
+ friend @SPTR_NAME@ [EMAIL PROTECTED]@ (size_t vlen);
+
+ @NAME@ (size_t vlen);
+ size_t d_vlen;
+
+ public:
+
+ int work (int noutput_items,
+gr_vector_const_void_star &input_items,
+gr_vector_void_star &output_items);
+};
+
+
+#endif
Index: gr_mean_XX.i.t
===
--- gr_mean_XX.i.t (revisjon 0)
+++ gr_mean_XX.i.t (revisjon 0)
@@ -0,0 +1,34 @@
+/* -*- c++ -*- */
+/*
+ * Copyright 2004 Free Software Foundation, Inc.
+ *
+ * This file is part of GNU Radio
+ *
+ * GNU Radio is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * GNU Radio is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GNU Radio; see the file COPYING. If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street,
+ * Boston, MA 02110-1301, USA.
+ */
+
+// @WARNING@
+
+GR_SWIG_BLOCK_MAGIC(gr,@BASE_NAME@)
+
[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ (size_t vlen);
+
+class @NAME@ : public gr_sync_block
+{
+ private:
+ @NAME@ (size_t vlen);
+ size_t d_vlen;
+};
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sdcc now available in Fedora.
2007/5/2, Achilleas Anastasopoulos <[EMAIL PROTECTED]>: Trond, I was not able to locate sdcc in the FC5 repos. Could you please verufy what the status of this project is. Ah, I never added it to FC5, and the CVS are closed atm because of the merge between Fedora Core and Fedora Extras, so I cannot commit it now. I will however request a build once it is open again. In the meantime you should be able to download the src.rpm for devel or FC6 (they are identical) and build it your self. Sorry for the inconvenience. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Alternative to gr_read_binary.py
Hi, I noticed when updating my gnuradio svn tree that gr_read_binary.py had been added to the tree. I just wanted to say that for those who already have scipy installed, the function fromfile(file, dtype=...) also works. Just remembed to add dtype=complex64 for gr_complex data, and dtype=float32 for gr_float. cheers, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] max and argmax blocks with SIMD instructions
2007/4/23, Pascal Charest <[EMAIL PROTECTED]>: If you don't want to use assembly, you can use MMX and SSE intrisics compiler support. These are C functions/macros to allow the use of SSE instructions directly from C/C++. Thanks a lot, I will definitely look into that, as i would pref ere to stay out of assembly land a little longer. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] max and argmax blocks with SIMD instructions
2007/4/23, Eric Blossom <[EMAIL PROTECTED]>: On Mon, Apr 23, 2007 at 10:48:58AM +0200, Trond Danielsen wrote: > Hi everyone, > > I've written a couple of blocks for GNU Radio, but am not satisfied > with the performance. I am therefore thinking of using SIMD > instructions. However, I am not that familiar with x86 assembly > instructions, and finding the reference manual on Intel's website was > not easy. I know that DSPs such as the Blackfin has special vector > instructions that would make this very simple, but I am not sure about > x86. > > I am also going to write a general purpose multiply and accumulate > block that would benefit much from SIMD instructions. > > Any comments are appreciated. Hi Trond, Can you point us at your code? Before diving into SIMD, it would be good to confirm that there isn't an easier change to make. Have you run oprofile on your code? Thanks a lot for your answer, very enlightening! The max and argmax blocks can be found here: ftp://open-gnss.org/pub/opengnss. If you find it useful I do not mind including them in GNU Radio. I haven't profiled the code, so really cannot verify that it is the main problem atm. I was just curious because I know that such instructions exist for other processors. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] max and argmax blocks with SIMD instructions
Hi everyone, I've written a couple of blocks for GNU Radio, but am not satisfied with the performance. I am therefore thinking of using SIMD instructions. However, I am not that familiar with x86 assembly instructions, and finding the reference manual on Intel's website was not easy. I know that DSPs such as the Blackfin has special vector instructions that would make this very simple, but I am not sure about x86. I am also going to write a general purpose multiply and accumulate block that would benefit much from SIMD instructions. Any comments are appreciated. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MATLAB/Windows and the USRP
2007/4/19, Kevin Rudd (Contractor) <[EMAIL PROTECTED]>: Hello all, I just received my USRP and I have successfully installed GNURadio on my Linux box. I am just starting to dabble with the code a bit. I am very much a Windows/MATLAB developer, so I think I could be far more productive if I could just stream the baseband waveforms to and from the USRP from MATLAB. I see on Ettus's site that some are working on a MATLAB interface. I would like to contribute to this effort. Does anyone have a good starting point? Are there any windows drivers (dll's or source)? Hi, If you want to do off-line analysis in matlab, python or octave, a solution that works for me is to just record a suitable amount of data with usrp_rx_cfile.py, and thereafter do whatever I like in my high-level language of choice. It might not be the best solution if you want to tweak USRP parameters from Matlab, but it works. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on argmax block
2007/4/16, Eric Blossom <[EMAIL PROTECTED]>: On Mon, Apr 16, 2007 at 10:20:59AM +0200, Trond Danielsen wrote: > Hi, > > I've written a block that return the index of the largest element in a > vector; in other words, it implements the argmax function. Now I have > a small issue, I would relay like to get both the value and the index > of the largest element in the vector. What would be the easiest way to > do this? I am thinking of just sequencially outputing the index and > the value after each other and de-interleaving them to get each result > in a separate stream. You could either implement two separate outputs, or declare a structure containing the two values and use that as the output type. I suspect that interleaving is going to be confusing and bug prone. I decided that the most flexible and simplest solution was just to create two separate block; one that returns max, and one that returns argmax. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on argmax block
2007/4/16, Johnathan Corgan <[EMAIL PROTECTED]>: Trond Danielsen wrote: > I've written a block that return the index of the largest element in a > vector; in other words, it implements the argmax function. Now I have > a small issue, I would relay like to get both the value and the index > of the largest element in the vector. What would be the easiest way to > do this? I am thinking of just sequencially outputing the index and > the value after each other and de-interleaving them to get each result > in a separate stream. Since you are generating exactly one of each (value, index) per input vector, why not just assign your block two output streams and stuff the value into one and the index into the other? Of cause... Silly me! -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rearranging a running flow graph
2007/3/17, Josh Blum <[EMAIL PROTECTED]>: I think gnuradio needs a mux and a demux block. A mux has N inputs and a set_n method. The mux will only feed the output with the nth input stream (throw out/ignore the other inputs). A demux has N outputs and a set_n method. The demux will only feed the nth output with the input stream. Has anybody written something like this allready? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help on argmax block
Hi, I've written a block that return the index of the largest element in a vector; in other words, it implements the argmax function. Now I have a small issue, I would relay like to get both the value and the index of the largest element in the vector. What would be the easiest way to do this? I am thinking of just sequencially outputing the index and the value after each other and de-interleaving them to get each result in a separate stream. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Shared Memory Problem
2007/4/12, Eric Blossom <[EMAIL PROTECTED]>: On Thu, Apr 12, 2007 at 02:50:17PM +0200, Trond Danielsen wrote: > Hi, > > I have a problem with insufficent shared memory. I'm running GNU Radio > from SVN, and keep getting these messages: > > gr_vmcircbuf_sysv_shm: shmget (1): No space left on device > gr_buffer::allocate_buffer: failed to allocate buffer of size 32 KB > terminate called after throwing an instance of 'std::bad_alloc' > what(): St9bad_alloc > Avbrutt (SIGABRT) > > I've tried increasing the maximum size of shared mem blocks with this > command: > sysctl -w kernel.shmmax=2147483648 > > I've attached the block that causes these problems (it will not work > if you try it, because some additional modules are missing). Any hints > on how to solve this? As Greg mentioned, this error is from shmget, and indicates that there are not enough shared memory segments available. Looks like kernel.shmmni may be the parameter that needs tweaking. It's 4096 on my machines. Thanks for the answers! kernel.shmmni is the same as on my machines, so I doubt that it is the problem . But I have already solved the problem; Johnathan pointed me to the single pole IIR filter that solved my problem in a much better way than the solution that I came up with. Apparently GNU Radio does not like 2000 simultaneous branches in a single block... BTW, I like your use of lambda expressions below: Saves a lot of typing :) > gr.hier_block2.__init__(self, > "acquisition", > gr.io_signature(1,1,gr.sizeof_gr_complex), > gr.io_signature(1,1, int(self.fft_size * gr.sizeof_float))) > > # aliases: > c = lambda i, o, i_p=0, o_p=0: self.connect(i,i_p,o,o_p) > d = lambda n, f: self.define_component( n, f) > > # Input signal; get Fourier transform of signal. > d( "s2v_input", > gr.stream_to_vector(gr.sizeof_gr_complex, self.fft_size)) > d( "fft_input", > gr.fft_vcc(self.fft_size, True, self.window)) Eric -- Trond Danielsen ___ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to integrate a vector signal?
2007/4/12, Johnathan Corgan <[EMAIL PROTECTED]>: Trond Danielsen wrote: > I wonder if anybody has any suggestion on how to integrate a vector > signal? I have a block that generates a vector signal, but I want to > integrate the output over 3-10 vectors to improve the SNR. Now if > this was a regular stream signal I would have just used a FIR filter > with N taps to implement this ( y(n) = x(n) + x(n-1) + ... + x(n-N-1) > ) , but I am not sure how to accomplish the same thing on a vector > signal. You can use the gr.single_pole_iir_filter_xx block, but set the vlen parameter (second constructor argument, defaults to 1) to the length of your vector. The block will create a single pole IIR filter for each position in the vector, then as the vectors come in, the filters will act in parallel so the output vectors are the result of treating each vector element as its own stream of data values. The constructor parameter 'alpha' determines the amount of smoothing; 1.0 is no smoothing (out = in), and with 0.0 the output would never change from zero. Mathematically, its the same as resistor-capacitor low pass filter. Google "exponential average filter" for a more detailed discussion on how to determine the alpha parameter to have the filter response you want. There is a good example of using this in the fftsink.py code, where the vector output of the FFT goes through an averaging filter before it gets sent to the display window. See line 116. Thanks a lot! Don't know how I missed that one. -- Trond Danielsen ___ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Shared Memory Problem
2007/4/12, Greg Troxel <[EMAIL PROTECTED]>: I have a problem with insufficent shared memory. I'm running GNU Radio from SVN, and keep getting these messages: You didn't mention what operating system you are running, but it could well be that you are hitting a limit on the number of segments rather than the total size. See the end of this page for setting shm limits to get the tests to pass: http://gnuradio.org/trac/wiki/NetBSDInstall Ah, forgot to mention that :). I've tested on both Fedora Rawhide (development) on my i386 laptop with 512 MB ram, and on Fedora Core 6 x86_64 that runs on an AMD 64 with 1 GB ram. -- Trond Danielsen ___ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Shared Memory Problem
Hi,
I have a problem with insufficent shared memory. I'm running GNU Radio
from SVN, and keep getting these messages:
gr_vmcircbuf_sysv_shm: shmget (1): No space left on device
gr_buffer::allocate_buffer: failed to allocate buffer of size 32 KB
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Avbrutt (SIGABRT)
I've tried increasing the maximum size of shared mem blocks with this command:
sysctl -w kernel.shmmax=2147483648
I've attached the block that causes these problems (it will not work
if you try it, because some additional modules are missing). Any hints
on how to solve this?
--
Trond Danielsen
from gnuradio import gr,window
from local_code import local_code
class acquisition(gr.hier_block2):
def __init__(self, fs, fd):
self.fft_size = int( 1e-3*fs)
self.window = window.blackmanharris(self.fft_size)
gr.hier_block2.__init__(self,
"acquisition",
gr.io_signature(1,1,gr.sizeof_gr_complex),
gr.io_signature(1,1, int(self.fft_size * gr.sizeof_float)))
# aliases:
c = lambda i, o, i_p=0, o_p=0: self.connect(i,i_p,o,o_p)
d = lambda n, f: self.define_component( n, f)
# Input signal; get Fourier transform of signal.
d( "s2v_input",
gr.stream_to_vector(gr.sizeof_gr_complex, self.fft_size))
d( "fft_input",
gr.fft_vcc(self.fft_size, True, self.window))
# Local code.
d( "local_code", local_code(svn=1, fs=fs, fd=fd))
# Multiply local code with recv. signal.
d( "mult", gr.multiply_vcc(self.fft_size))
# Invers transform result.
d( "ifft", gr.fft_vcc(self.fft_size, False, self.window))
# Get signal magnitude.
d( "mag", gr.complex_to_mag(self.fft_size) )
d( "v2s", gr.vector_to_stream(gr.sizeof_float, self.fft_size))
# Split vector into N branches for filtering.
d( "one2N", gr.deinterleave(gr.sizeof_float))
# Integrate signal: y(n) = x(n) + x(n-1) + x(n-2)
for i in range(self.fft_size):
d( ( "fir_%d" % i ), gr.fir_filter_fff( 1, [1.0, 1.0, 1.0] ))
# Combine signal again.
d( "N2one", gr.interleave(gr.sizeof_float))
d( "s2v", gr.stream_to_vector(gr.sizeof_float, self.fft_size))
# Connect everything.
c( "self", "s2v_input")
c( "s2v_input", "fft_input")
c( "local_code", "mult")
c( "fft_input", "mult", o_p=1)
c( "mult", "ifft")
c( "ifft", "mag" )
c( "mag", "v2s" )
c( "v2s", "one2N" )
for i in range(self.fft_size):
fir = ("fir_%d" % i )
c( "one2N", fir, i_p=i )
c( fir, "N2one", o_p=i)
c( "N2one", "s2v" )
c( "s2v", "self" )
___
Discuss-gnuradio mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to integrate a vector signal?
Hi, I wonder if anybody has any suggestion on how to integrate a vector signal? I have a block that generates a vector signal, but I want to integrate the output over 3-10 vectors to improve the SNR. Now if this was a regular stream signal I would have just used a FIR filter with N taps to implement this ( y(n) = x(n) + x(n-1) + ... + x(n-N-1) ) , but I am not sure how to accomplish the same thing on a vector signal. Any comments are welcome! -- Trond Danielsen ___ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New Wiki Front Page
Thank you for the feedback! I did not have access to a Windows machine
to test it in IE, so I could not test it.
2007/4/6, Bart Mermuys <[EMAIL PROTECTED]>:
Hi,
> - Original Message -
> From: "Johnathan Corgan" <[EMAIL PROTECTED]>
> To: "gnuradio mailing list"
> Cc: "Eric Blossom" <[EMAIL PROTECTED]>
> Sent: Friday, April 06, 2007 3:38 AM
> Subject: [Discuss-gnuradio] New Wiki Front Page
>
> The front page to the GNU Radio wiki has been updated to a simpler and
> hopefully more easily navigable format. Thanks go to Trond Danielsen
> for creating the new look and linked pages.
>
> http://gnuradio.org/trac
>
Thanks, but there seems to be a render problem, at least with ie6sp2 & ie7.
The words "Content" and "News" do not show correctly. The first letter
isn't visible and the second letter is half-visible looking cutoff.
I had a look at the page source, css and noticed the following:
The html page has a table with two td's, like so:
And the trac css file has this:
.wikipage { padding-left: 18px }
.wikipage h1, .wikipage h2, .wikipage h3 { margin-left: -18px}
The wikipage class is inherited by all elements under the div, but according
to css rules padding and margin styles aren't inherited. So the td has no
padding-left, but the h2 inside it does has margin-left because the style is
targetted directly at the h2. Since now h2 has a negative margin and td
does not have padding, i assume that's why the first letter isn't shown
correctly.
Not sure about the fix, you could :
- apply the wikipage class explicitly to the td's, making them use the
padding-left (it's not inherited anymore),
- change the css:
.wikipage, .wikipage td { padding-left: 18px }
- not use h1, h2, h3 inside td
...
Thanks and hope this helps,
Greetings
> --
> Johnathan Corgan
> Corgan Enterprises LLC
> http://corganenterprises.com
>
>
> ___
> 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
--
Trond Danielsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas Loop
2007/4/2, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Hi, I'm an italian student. I'm studying about GnuRadio and Usrp. I would like to know informations about Costas loop's coefficients. Alpha and Beta. Where can I find some inform Taken from the header file: * All settings max_freq and min_freq are in terms of radians per sample, * NOT HERTZ. Alpha is the phase gain (first order, units of radians per radian) * and beta is the frequency gain (second order, units of radians per sample per radian) For a good theoretical and practical description of the parameters look here: http://archive.chipcenter.com/dsp/DSP010531F1.html -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Carrier offset on DBSRX.
2007/3/27, Trond Danielsen <[EMAIL PROTECTED]>: 2007/3/27, Eric Blossom <[EMAIL PROTECTED]>: > > Okay, I think I understand. But still, when inspecting the signal with > > ursp_fft.py, the signal is not at baseband, but offset by approx. > > 500kHz > > 500 kHz seems excessive. Can you post a link to a screen shot? I am not at the lab atm, but I'll post a screenshot tomorrow when I get back to the university (which is in about 10h). Thank you all for your replies. I this case I think that the user is the one to blame for the problem... Something must have been very wrong yesterday, because today I get within 20kHz of the desired frequency, which is good enough atm. (http://trondd.blogspot.com/2007/03/gps-l1.html) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Carrier offset on DBSRX.
2007/3/27, Eric Blossom <[EMAIL PROTECTED]>: > Okay, I think I understand. But still, when inspecting the signal with > ursp_fft.py, the signal is not at baseband, but offset by approx. > 500kHz 500 kHz seems excessive. Can you post a link to a screen shot? I am not at the lab atm, but I'll post a screenshot tomorrow when I get back to the university (which is in about 10h). -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Carrier offset on DBSRX.
2007/3/27, Eric Blossom <[EMAIL PROTECTED]>: On Tue, Mar 27, 2007 at 10:36:05AM +0200, Trond Danielsen wrote: > Hi, > > I have a problem with my DBSRX daughterboard. I tried to send in a > single carrier on 1.57542 GHz and watch it with usrp_fft.py, and I > observe that the received signal is offset by many KHz. This really > does not come as a big surprise, since ack. to the usrp_fft.py GUI the > actual BB frequency is 1.5755 GHz. Is it not possible to tune the > DBSRX to 1.57542 GHz? BTW: How is the C++ version of the dbsrx driver > coming along? Does it contain any improvements over the python > version? > > -- > Trond Danielsen Trond, I would venture that the offset of a many KHz is not because of anything having to do with the reported BB frequency, but rather because of the offset between the Tx and Rx clocks. They are spec'd at 50 ppm. At 1.5 GHz each clock could be off by 75kHz and they'd still be within spec. The input signal is generated by a Spirent GPS simulator, not by the USRP, so the carrier should be _very_ stable. Also, I think you may be worrying about the wrong thing, when you see the baseband frequency reported. On both the Tx and Rx paths, tuning is a two step processes. Part of it is handled on the daughterboard, and part of it is handled with a DDC or DUC. The value reported in usrp_fft.py is the frequency that the front end is tuned to. The DDC is programmed such that the frequency you asked for is actually at DC in the complex baseband signal (post DDC). Okay, I think I understand. But still, when inspecting the signal with ursp_fft.py, the signal is not at baseband, but offset by approx. 500kHz -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Carrier offset on DBSRX.
2007/3/27, Gregory W Heckler <[EMAIL PROTECTED]>: Trond: Tuning the down-converter on the DBS-RX card consists of programming the values of 2 dividers. The R divider divides down the reference clock frequency (4 MHz, which derives from the 64 MHz board clock). The N divider divides down the LO frequency. The R divider has a range from 2 to 256, the N divider from 256 to 32768. The Max2118 phase locks the divide LO frequency to the divided reference clock frequency, or: LO = N*(Refclk_Freq/R) However, the PLL in the Max2118 is unstable if you divide down the reference clock frequency to below 250 kHz, this effectively limits the frequency resolution at which you can command the LO frequency. Additionally, the error in the board clock at 64 MHz will produce a frequency error in the LO frequency of tens of kHz at L1. I would suggest passing a sine wave at 1.57542 GHz through the DBS-RX and USRP (set the digital down-convert frequency to 0), and observing where the frequency appears in the PSD of your samples. You can then use the resulting frequency to command the digital down-convert stage of the USRP to mix L1 precisely to baseband. I will formally submit the C++ driver after I get it commented out, if you want the version I have working now I can forward it to you. Greg Heckler Thank you very much for your explanation! Unfortunately the appnote that describes how to set the frequency of the dbsrx is only available on demand from Maxim, and the python driver contains only magic number for someone who does not have access to this. Would it be possible to add this information to the wiki? I would very much like to test you C++ driver. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi-machine sweeper
2007/3/26, Brett L. Trotter <[EMAIL PROTECTED]>:
In the long run- perhaps a python app that sits on a socket and changes the
frequency at the command of the other side of the link, which is doing a loop
through the daughtercard frequencies and then keeps track of the SNR or the db
above baseline or something. The quick and dirty way would be to have the RX
hop to the frequency, listen to baseline with transmitter not going, record
level, ask TX side to go to same frequency, measure again- record the result
and then move to the next frequency.
It should be possible to run a SOAP server as a thread in a GNU Radio
application. The simplest possible soap server looks like this:
- - -
import SOAPpy
def hello():
return "Hello World"
server = SOAP.SOAPServer(("localhost", 8080))
server.registerFunction(hello)
server.serve_forever()
- - -
and can be called with the following client code:
- - -
import SOAPpy
server = SOAPpy.SOAPProxy("http://localhost:8080/";)
print server.hello()
- - -
Of cause you have to replace localhost with the host name of the
server and the hello()-method with something more meaningful, but
otherwise the code should be very similar.
SOAPpy is availble here: http://pywebsvcs.sourceforge.net/
--
Trond Danielsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Carrier offset on DBSRX.
Hi, I have a problem with my DBSRX daughterboard. I tried to send in a single carrier on 1.57542 GHz and watch it with usrp_fft.py, and I observe that the received signal is offset by many KHz. This really does not come as a big surprise, since ack. to the usrp_fft.py GUI the actual BB frequency is 1.5755 GHz. Is it not possible to tune the DBSRX to 1.57542 GHz? BTW: How is the C++ version of the dbsrx driver coming along? Does it contain any improvements over the python version? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Block processing and printing results in python
2007/3/25, Eric Blossom <[EMAIL PROTECTED]>: On Sat, Mar 24, 2007 at 08:42:40AM -0700, Robert Miller wrote: > > Hello, > > I would like to repeatedly compute signal characteristics for consecutive > blocks of data from the USRP, while echoing the results to the screen (e.g. > mean,etc.). I would prefer to do this within python without writing my own > signal processing block. Is this possible without writing my own block? > > Thanks, > Rob Depending on what you're trying to measure, this is possible. See for example gnuradio-core/src/lib/general/ gr_probe_signal_f.h gr_probe_signal_c.h gr_probe_signal_avg_mag_sqrd_f.h gr_probe_signal_avg_mag_sqrd_c.h I was looking for something like this too, but from what I can see, gr_probe_signal_c.* is not available in trunk (rev. 4796). Am I missing something? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More on the Qwt package for Fedora
2007/3/26, Robert McGwier <[EMAIL PROTECTED]>: It will build against EITHER and with qt4 you get more capabilities added automatically. It determines this by search in your QTDIR environment variable, which must be set for Qt things to work correctly. I will build qwt for both qt3 and 4, so everyone can chose what they want :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Polymorphic Computer:
2007/3/24, Martin Dvh <[EMAIL PROTECTED]>: http://investor.raytheon.com/phoenix.zhtml?c=84193&p=irol-newsArticle&ID=975694&highlight= The URL contains "investor", which makes me to think: "Don't belive the hype" -- Public Enemy :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't Compile
2007/3/23, Kerry Miller <[EMAIL PROTECTED]>: I recently became aware of gnuradio. I run Fedora Core 5 Linux. I downloaded the gnuradio software and got this message: checking for fftw3f >= 3.0... Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing `fftw3f.pc' to the PKG_CONFIG_PATH environment variable No package 'fftw3f' found configure: error: Library requirements (fftw3f >= 3.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. My assumption is this is a library needed by the gnuradio software. I have done some searching of my system and the file does not appear to be on my system. Not just where your configure can't find it. Where do I find it? And how do I install it? You need to add the devel files by running "yum install fftw-devel". Everything is described on the wiki: http://gnuradio.org/trac/wiki/FC5Install If you want to use the USRP, you also need sdcc, which unfortunately is not available for FC5 (my fault :( ). But it is very simple to rebuild the src.rpm for fc5; if you need help with this, just contact me off the list, and I will send you the instructions. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] More on the Qwt package for Fedora
Hi, I've been in contact with the developer of qwt, and he seemed interested in adding a pkg-config file to qwt, so hopefully it will be included in future released. I haven't submitted it for inclusion in Fedora yet, but I think the package is pretty much ready. One last thing: Are you building agains qt-3 or qt4? Cheers, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rearranging a running flow graph
2007/3/17, Patrick Strasser <[EMAIL PROTECTED]>: The third possibility would be contruct a swtich block that takes n inputs and has a method to select the input by a number. Would this be possible an a way so that the not-to be consumed path temporarily discontinues processing? On continuation, the interrupted path would work with old data. Any way to flush this or are the buffers small enough to neglect this effect? I guess this would also be true for connect/disconnect. A mute block already exist: http://gnuradio.org/doc/doxygen/classgr__mute__cc.html. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Qwt packages for Fedora
2007/3/16, Johnathan Corgan <[EMAIL PROTECTED]>: Jason Coy wrote: > Yeah, I agree that the .pc file is the best way to handle providing this > info. In the qwt tar file on the n4hy.org web site there is a version of > the qwt library that has the .pc file in it. It is similar to the qt-mt.pc > file that is installed by qt. I will send an email to the upstream developer regarding the pkg-config file. Well, I've since reverted a portion of the gr_qwt.m4 file to remove the need for the qwt subdirectory. The reason--the canonical tarball from [...] It's really up to the distribution packagers to standardize these according to the LSB, so Trond, you could create a .pc file with the right info for where you're putting them with your RPM. But my configuration script needs to work whether there is a .pc file or not, so I can't take advantage of it until even the canonical upstream source has one. When packaging stuff I try to remain compatible with upstream, but the qwt package contains _alot_ of header files, and I think it would be better to store them in a separate subfolder. I'll discuss this with the upstream devs too. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Qwt packages for Fedora
2007/3/15, Trond Danielsen <[EMAIL PROTECTED]>: Hi, qwt-5.0.1 packages for Fedora are now available here: ftp://open-gnss.org/pub/fedora/qwt/ A small error reported by Johnathan Corgan has now been corrected: New package here: ftp://open-gnss.org/pub/fedora/qwt/qwt-5.0.1-2.x86_64.rpm and ftp://open-gnss.org/pub/fedora/qwt/qwt-5.0.1-2.src.rpm (only x86_64 this time, I just turned of my laptop...) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Qwt packages for Fedora
Hi, qwt-5.0.1 packages for Fedora are now available here: ftp://open-gnss.org/pub/fedora/qwt/ The package builds on both i386 and x86_64, is built for QT-3.3. But I have not tested it, so please try it out and give me feedback, so I can get it ready for review for inclusion in Fedora. Cheers, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio spec file for Fedora
Hi everyone, I know I promised a spec file for GNU Radio, but I have been busy lately. Here is however the inital version. I still have to split it into several sub-packages, but it works ftp://open-gnss.org/pub/gnuradio/gnuradio.spec Give it a try, and send me feedback if you want to. The spec file has been created for gnuradio-3.0.3. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem compiling sdcc package
2007/3/12, xrin oscar <[EMAIL PROTECTED]>: Hi, the package is sdcc-2.5.0.tar.gz. The latest version of sdcc is 2.6.0, I suggest you try that before trying to debug the older version. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem compiling sdcc package
2007/3/9, xrin oscar <[EMAIL PROTECTED]>: Hi, I try to compile sdcc package and i met with the following problem. Help needed. Thanks. Hi, I have not seen that error before, but may I ask which distribution and version of sdcc you are using? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PlayStation 3 Installation Instructions
2007/3/8, Tom Rondeau <[EMAIL PROTECTED]>: I just put a link under BuildGuide for how to install FC6 and GNU Radio on a PlayStation 3. Following these steps, the example script mentioned at the bottom of the page should work to start sending signal from the USRP. I just read your instructions read the instructions regarding sdcc on FC6, and just want to mention why the binaries from sdcc are installed into /usr/libexec/sdcc instead of /usr/bin. Some of the executables have very generic names, and it was therefore decided during the package review to move them to /usr/libexec/sdcc, and create symlinks. The easiest way is to just add /usr/libexec/sdcc to path before ./configure && make. This is the way it is done in the upcoming spec file. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] top-posting considered harmful
2007/3/7, Eric Blossom <[EMAIL PROTECTED]>: Folks, please trim your posts. Do not top post like I just did (to illustrate what I'm talking about). For that matter, don't blindly bottom post either. Note the 5 copied messages. I've added some notes regarding this to the wiki: http://gnuradio.org/trac/wiki/MailingLists -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding fft-ifft processing
2007/3/7, Kuntal Majumdar <[EMAIL PROTECTED]>: Recently, Brian told me that the FFT-IFFT processing is handled by the host side. Can I know how this is done exactly? Is there any relevant documentation for this on the Wiki? Did you read this: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html? The document is a bit old, but still give a very good introduction to the basics of GNU Radio. I read in an earlier thread that you want to do the (I)FFT processing in the FPGA. This is not how it is intended to be used. GNU Radio is a software radio framework, and the goal is to move as much of the signal processing as possible onto the host computer. Moving the FFT back to the FPGA would therefore be a step backward in the software approach. This is just my personal opinion, so feel free to spank me with a 10 foot monopole if your view is different :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS with DBSRX, Almost There
2007/3/6, Gregory W Heckler <[EMAIL PROTECTED]>: > If anyone would like any GPS IF data I would be happy to email it to your personal email address (indicate how many seconds of data you would like). Thanks! I am very interested to here more about your experience with GNU Radio and GPS! I am creating a similar application, and wonder what your goals are? Are you creating a complete receiver in GNU Radio, or a you using an existing software receiver? Feel free to contact me off list if you want to discuss more. Cheers, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio website.
2007/3/6, Martin Dvh <[EMAIL PROTECTED]>: I would add a heading "Full Documentation Index" or "Wiki Index" with a link to http://gnuradio.org/trac/wiki/TitleIndex under Documentation. Good idea! I had that in mind earlier, but somehow it must have slipped. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SiGe GN3S Sampler (GPS)
2007/3/6, Eric Blossom <[EMAIL PROTECTED]>: On Tue, Mar 06, 2007 at 01:21:17PM -0500, Brian Padalino wrote: > Has anyone seen this? > > http://www.sparkfun.com/commerce/product_info.php?products_id=8238 > > It uses an FX2 and actually some USRP files are in with the source - > but provides no processing, just a book reference to get some MATLAB > scripts. > > Maybe this would be good to support within GNU Radio for those who > like doing GPS things? > > Brian Thanks for the pointer! I saw the prototype when I was at Univ of Colorado a few months ago. Glad to see they got it into production. Eric Wow! Looks cool, but I'm glad it was not available 6 month ago, or I might never have gotten into GNU Radio... :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to generate control signals between block?
2007/3/5, Greg Troxel <[EMAIL PROTECTED]>: Once such a packet is found then the flowgraph has a message sink and puts this half-baked packet in this queue, together with possibly another message of a different TYPE (control message) with some parameters required in the second flow (such as initial phase estimate, etc). Have you looked at the m-block design (discussion in list archives) and work in progress? I realize it's not ready yet, and that you might want to do something before it is, but it seems like this is an ad hoc version of the more general scheme. I read about the m-block architecture, and I must say that is seems very nice, but a bit too complicated for my simple needs. I just need to estimate some parameters at a low rate, and update another graph dynamically. BTW: Has anybody else done any work on CDMA? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packaging GNU Radio for Fedora
2007/3/6, Eric Blossom <[EMAIL PROTECTED]>: On Tue, Mar 06, 2007 at 01:38:51PM +0100, Trond Danielsen wrote: > Hi, > > I creating a spec file for GNU Radio, and I discovered some minor issues: > > 1. Standard library paths are hardcoded into some of the libraries. I > use this command in the spec file to fix libtool before building: > sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' > libtool > sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool Just out of curiosity, how does _everybody_ else handle this problem? I suspect that they're not editing libtool source. Please take a look at the .spec files for other applications built with autotools. I am aware of that this solution looks a bit dirty, but it is actually taken from the packaging guidelines on the fedoraproject wiki: http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544 The message reported by rpmbuild is not an error; it is possible to ignore it, but I wanted to do the right thing. Thats why I am asking. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Packaging GNU Radio for Fedora
Hi, I creating a spec file for GNU Radio, and I discovered some minor issues: 1. Standard library paths are hardcoded into some of the libraries. I use this command in the spec file to fix libtool before building: sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool 2. Install path for some of the python modules are problematic: /usr/lib64/python2.4/site-packages/__init__.py /usr/lib64/python2.4/site-packages/_usrp_prims.la /usr/lib64/python2.4/site-packages/_usrp_prims.so /usr/lib64/python2.4/site-packages/usrp_dbid.py /usr/lib64/python2.4/site-packages/usrp_fpga_regs.py /usr/lib64/python2.4/site-packages/usrp_prims.py Would it be possible to move these to a separate subfolder? Cheers, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio website.
lør, 03.03.2007 kl. 10.16 -0800, skrev Eric Blossom: > OK. Why don't you create the page as WikiStart2, and then we can > iterate the design there. When we're all happy, we'll move it to > WikiStart I have created http://gnuradio.org/trac/wiki/WikiStart2. Let me know what you think. I have tried to give an overview of what information is available on the wiki, while keeping the size of the front page to a reasonable size to avoid scrolling. I haven't had the time yet to look at the gnu.org website, but I've got it on my TODO list. -- Trond Danielsen <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to generate control signals between block?
Hi, I think I have a fairly good understanding of how the basics of GNU Radio work, but there is one thing that I just can't figure out: How can I generate control signals between block and between blocks and the world outside. I understand how to set up flow graph, but I can't find any good examples or tutorials on how to interact with the graph once its running. I'll give you an example: I am creating a receiver, and the signal is divided into several flow graphs. One graph performs acquistion on the incoming signal, and then passes two parameters to the tracking loop. Now what would be the correct way to signal the other graph? In GUI programming the equivalent would be for one block to emit a certain signal, which triggers a callback in another block, but I am not sure if this is the way it is done in GNU Radio. My application has fairly relaxed requirements: There are no hard real-time requirements, as the demodulated data is not intended to be displayed in real time. I have read about the new mblock, but it seemed overkill for my application. Hope I managed to present my question clearly. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio website.
2007/3/3, Eric Blossom <[EMAIL PROTECTED]>: On Sat, Mar 03, 2007 at 10:42:49AM -0800, Johnathan Corgan wrote: > Eric Blossom wrote: > > > Another thing to think about is what do we want at > > http://gnuradio.org? Maybe that's where the "marketing page" goes. Of > > course we can config apache to redirect it into the wiki somewhere. > > I think this is the right approach. Trac is sort of a minimalist Wiki > implementation tacked on to a better repository browser and issue > tracking system. It's not meant to host "fluff" type stuff, or rather, > it doesn't really provide a great deal of assistance in doing so. > > > Once that's sorted out, perhaps we ought to replicate it at > > http://gnuradio.org [Violating my own rule, I know. I'm not sure I > > can get a redirect installed at http://www.gnu.org/software/gnuradio, > > and JavaScript is out.] > > Personally, I'd rather install Wikimedia on gnuradio.org and just use > Trac for repository browsing and tickets. There are far more effective > spam control modules for Wikimedia than Trac, as well as more > sophisticated math rendering, attachment/inline controls, revision > control, user accounts, etc. Seems like a lot of work, possible confusion, and we lose all the trac integration with the wiki. I agree! A full blown mediawiki installation for a simple site as the gnu.org site, would be overkill IMO. It looks like there's a desire for two things: - A nice looking "marketing page" (which could be static) I have checked out the sources for the gnu.org site, and will look into it tomorrow, and hopefully come up with some ideas and a proposal in a couple of days. - And the place where we're really getting all the work done (Trac) Exactly! This is sort of how I picture things: gnu.org: - Welcome/introduction/what is gnuradio and SDR? - Use cases/glossy examples ( think marketing :) ). - How do I get this? -> Point to wiki at gnuradio.org gnuradio.org * Getting started: - download - requirements -install: Distro specific and generic * Getting help - commercial support and training. * Get in touch - mailing lists - irc (yes, you can actually find some of us on #gnuradio on freenode.net ) * Documentation - API - Examples (practical, not the shiny ones on gnu.org) - Suggested readings. - List of talks, presentations and videos. * Contribute (already on gnu.org) Puh, thats about it (concider this a note-to-self(r) and others :) ) At last, thank you for all the feedback. I hope that you find this useful and that it will help bring GNU Radio to a larger group of people! -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio website.
2007/3/3, Don Ward <[EMAIL PROTECTED]>: From: "Trond Danielsen" <[EMAIL PROTECTED]> >> I agree that the current WikiStart page isn't beautiful, however it >> does handle what I assume are the first 95% of the questions: where's >> the code, how do I build it, and what about the USRP stuff? > > As a user who is just getting started I disagree with you on that > point. I have been exploring GNU Radio for half a year, and I think > there are three major questions that has to be anwered on the front > page: > > 1. How do I get this stuff? > 2. How do I use it? > 3. How can I get in touch with the people who created this stuff? Don't forget: 0. What is it? No one who subscribes to the mailing list needs this, but anyone else who happens to stumble across the website (e.g., via Google) might want to know. All it takes is a prominent link to an appropriate page. Of cause! I missed that one. But that is exactly what I think the page at gnu.org should be. I'll get back to that later. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
