[Discuss-gnuradio] O-QPSK demodulation
Dear all, I am struggling with O-QPSK receiver that I hope I can utilize GnuRadio radio for it. However, after doing quite a lot of search, I am still stuck, making no headway. Some results I could find are: 1. The mpsk_receiver states he can do OQPSK demodulation (based on the comments in the source code and in some documents e.g., Simple GNU Radio User manual); however, I can not figure it out how he could do it 2. The second approach used in UCLA Zigbee ( https://www.cgran.org/wiki/UCLAZigBee) with the links among O-QPSK <-> MSK <->FSK then FSK Demod is used to accomplish O-QPSK demodulation. The problem here is with this direction, we can only handle the case O-QPSK with half-sine pulse shaping - then OQPSK becomes MSK, a special case while I wish could do general OQPSK. One question also strikes my mind is with this approach, where is the parameters for the root raised cosine (rrc) filter? Can anyone kindly show me the way to solve my problem: OQPSK demodulation using GnuRadio, or just tell me if I missed or misunderstood something? I would like to thank you very much in advance, Nguyen Anh Duc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacOS 10.7.3 - mmap or shm_open is not available
On 9 Apr 2012, at 01:16, Michael Dickens wrote:
>> Does anyone have any pointers as to where I should be looking?
>
>
> Hi Steven - First, the humor < http://xkcd.com/138/ >.
>
I was waiting for something like that :o)
> Do "ipcs -a" to see how many shared memory attachments are in place. You
> might see a lot, given that 'shmat' returns 'too many files open'. Here's
> the BASH script I run, very often in my work right now, to try to remove
> extraneous ones:
>
> for tf in `ipcs -m | sed -e 1d -e 2d -e 3d | awk '{print $2 }'`; do
>ipcrm -m $tf ;
> done
>
I only seem to have one entry:
$ ipcs -a
IPC status from as of Mon Apr 9 11:03:42 BST 2012
T ID KEYMODE OWNERGROUP CREATOR CGROUP CBYTES
QNUM QBYTES LSPID LRPID STIMERTIMECTIME
Message Queues:
T ID KEYMODE OWNERGROUP CREATOR CGROUP NATTCH
SEGSZ CPID LPID ATIMEDTIMECTIME
Shared Memory:
m 262157 0x --rw--- stevenstaff stevenstaff 2
393216 2302 2120 19:39:30 20:03:03 19:39:30
T ID KEYMODE OWNERGROUP CREATOR CGROUP NSEMS
OTIMECTIME
Semaphores:
$ ipcrm -m 262157
ipcrm: shmid(262157): : Invalid argument
> If all else fails, reboot and see if that doesn't take care of the issue, at
> least for now. If the issue persists, it might be a new Lion issue from
> 10.7.3; I know I've run GNU Radio in 10.7.[0-2]. I'll hopefully have a few
> spare cycles later this week to look into GNU Radio on Lion. - MLD
I've already tried that, doesn't seem to make any difference. I know of at
least one other person on 10.7.3 that is having this exact same issue.
Cheers,
Steven.
smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Screencast for Absolute Beginners
thx mate !! Cheers Piet Am 8. April 2012 01:07 schrieb sumitstop : > > Hi Community, > > I have uploaded screencast of some very basic things for the beginners in > gnuradio like installing gnuradio, finding common examples of usrp, uhd, > utilities etc. Also getting information about usrp's / daughterboards, > antennas, burning SD card etc. > > Here is the link > > http://www.youtube.com/user/2011HPS?feature=watch > http://www.youtube.com/user/2011HPS?feature=watch > > > Although these things are given in enough detail on gnuradio webpage but I > think watching on screen will be very helpful for the starters :) > > Enjoy :) > > ** Suggestions/improvements are most welcome > > - > Sumit Kr. > Research Assistant > Communication Research center > IIIT Hyderabad > India > -- > View this message in context: > http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33650161.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacOS 10.7.3 - mmap or shm_open is not available
Hmmph. Well, I bet Apple did something "clever" inside the Darwin kernel that
messed with shared memory in 10.7.3. There's probably a work-around too, but I
have no idea what it might be right now since I'm still using 10.6.8: it's
stable and works well for what I need right now. I'll look into this issue at
the end of this week unless someone else gets there first :) - MLD
On Apr 9, 2012, at 6:08 AM, Steven wrote:
>
> On 9 Apr 2012, at 01:16, Michael Dickens wrote:
>
>>> Does anyone have any pointers as to where I should be looking?
>>
>>
>> Hi Steven - First, the humor < http://xkcd.com/138/ >.
>>
>
> I was waiting for something like that :o)
>
>
>> Do "ipcs -a" to see how many shared memory attachments are in place. You
>> might see a lot, given that 'shmat' returns 'too many files open'. Here's
>> the BASH script I run, very often in my work right now, to try to remove
>> extraneous ones:
>>
>> for tf in `ipcs -m | sed -e 1d -e 2d -e 3d | awk '{print $2 }'`; do
>> ipcrm -m $tf ;
>> done
>>
>
> I only seem to have one entry:
>
> $ ipcs -a
> IPC status from as of Mon Apr 9 11:03:42 BST 2012
> T ID KEYMODE OWNERGROUP CREATOR CGROUP CBYTES
> QNUM QBYTES LSPID LRPID STIMERTIMECTIME
> Message Queues:
>
> T ID KEYMODE OWNERGROUP CREATOR CGROUP NATTCH
> SEGSZ CPID LPID ATIMEDTIMECTIME
> Shared Memory:
> m 262157 0x --rw--- stevenstaff stevenstaff 2
> 393216 2302 2120 19:39:30 20:03:03 19:39:30
>
> T ID KEYMODE OWNERGROUP CREATOR CGROUP NSEMS
> OTIMECTIME
> Semaphores:
>
> $ ipcrm -m 262157
> ipcrm: shmid(262157): : Invalid argument
>
>
>
>> If all else fails, reboot and see if that doesn't take care of the issue, at
>> least for now. If the issue persists, it might be a new Lion issue from
>> 10.7.3; I know I've run GNU Radio in 10.7.[0-2]. I'll hopefully have a few
>> spare cycles later this week to look into GNU Radio on Lion. - MLD
>
> I've already tried that, doesn't seem to make any difference. I know of at
> least one other person on 10.7.3 that is having this exact same issue.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacOS 10.7.3 - mmap or shm_open is not available
On Mon, Apr 9, 2012 at 8:13 AM, Michael Dickens wrote: > Hmmph. Well, I bet Apple did something "clever" inside the Darwin kernel > that messed with shared memory in 10.7.3. There's probably a work-around > too, but I have no idea what it might be right now since I'm still using > 10.6.8: it's stable and works well for what I need right now. I'll look into > this issue at the end of this week unless someone else gets there first :) - > MLD > > On Apr 9, 2012, at 6:08 AM, Steven wrote: > >> >> On 9 Apr 2012, at 01:16, Michael Dickens wrote: >> Does anyone have any pointers as to where I should be looking? >>> >>> >>> Hi Steven - First, the humor < http://xkcd.com/138/ >. >>> >> >> I was waiting for something like that :o) Steven, Try to rebuild GNU Radio using -DTRY_SHM_VMCIRCBUF=Off. After you rebuild it, make sure you remove "~/.gnuradio/prefs/gr_vmcircbuf_default_factory" so you don't confuse the system. We recently re-enabled this with cmake and it's the default under autotools. There's a known bug in Cygwin, which was why this is an option that can be set. As far as I know, it's always worked under OSX, but as Michael said, something might have changed and it's just been masked for a while. It'll be interesting to know if this is a new problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Benchmark_Tx Problem
Hello, Thank you for everyone’s response. Marcus - I am using a dual-boot because VM just wouldn't for me. Tom - I used the ./configure. Thank You Samuel Ibarra On Fri, Apr 6, 2012 at 5:52 PM, Tom Rondeau wrote: > On Fri, Apr 6, 2012 at 8:10 PM, Marcus D. Leech wrote: > > On 04/06/2012 07:59 PM, sibar002 wrote: > >> > >> Hello Ben, > >> > >> Thank you for your response. I tried adjusting my bitrate in order to > >> prevent this from happening, but I continue to have the same problem. I > >> forgot to mention that I am running a dual OS on my computer (Windows > and > >> Linux). Could this be causing the overflow problem? Thank you again. I > >> really appreciate any help or advice. > >> > >> Thanks > >> Sam > >> > >> > > Are you running your Linux partition as a VM, or you just dual-boot? > > > > I've found that USB support through VMWare is *horrible*. > > Sam, > > Also, are you building with autotools (./configure) or cmake? I've > been seeing more reports on this then before, so I'm trying to figure > out if there's something odd going on and where. > > Tom > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmantation fault usrp_spectrum_sense
On Sun, Apr 8, 2012 at 9:59 PM, Abdelrahman Ahmed wrote: > last week every thing was fine until today when i want to sense the > spectrum i faced this problem > >>./usrp_spectrum_sense.py 1901M 1983M > file.tr > > Warning: this is known to have issues on some machines+Python version > combinations to seg fault due to the callback in bin_statitics. If you > figure out why, we'd love to hear about it! > Traceback (most recent call last): > File "./usrp_spectrum_sense.py", line 237, in > tb = my_top_block() > File "./usrp_spectrum_sense.py", line 135, in __init__ > num_channels=1) > File "/usr/local/lib/python2.7/ > dist-packages/gnuradio/uhd/__init__.py", > line 116, in constructor_interceptor > return old_constructor(*args) > File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", > line 2885, in usrp_source > return _uhd_swig.usrp_source(*args) > RuntimeError: LookupError: KeyError: No devices found for -> > Device Address: > addr: 192.168.10.2 > although i am using usrp 1 so i added this args > >>usrp_spectrum_sense.py 1901M 1983M >file.tr --address="type=usrp1" > > linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-24-g8630807c > > Warning: this is known to have issues on some machines+Python version > combinations to seg fault due to the callback in bin_statitics. If you > figure out why, we'd love to hear about it! > -- Opening a USRP1 device... > -- Using FPGA clock rate of 64.00MHz... > Using Volk machine: ssse3_64 > gain = 25.75 > Segmentation fault Well, it does say right as you start the program: Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! So what changed for you between last week and this week? Have you changed code or any installations that we should know about? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [discuss-gnuradio]ofdm sync using only one preamble in gnuradio example benchmark_tx.py and benchmark_rx.py
On Sat, Apr 7, 2012 at 6:19 PM, Alex Zhang wrote: > Hi Tom, > > Just correct my mail. > I retest the case, it is found that my matlab code has some errors which > cause this confusion. Sorry for the incorrect result. Alex, Thanks for getting back in touch about this. I wasn't sure how to answer your last question. Good to hear you've got things worked out. Tom > On Tue, Apr 3, 2012 at 12:43 AM, Alex Zhang wrote: >> >> Hi Tom, >> >> To dig the details of the current ofdm receiver synchronization, i did >> some experiments by the benchmark_rx.py. But I see something strange >> regarding the Preamble correlation plateau width, although the data packet >> is communicated as expected. >> >> My command is as: >> >> ./benchmark_tx.py -f 1.4G --fft 256 --occ 240 --log >> ./benchmark_rx.py -f 1.4G --fft 256 --occ 240 --log >> >> Please see the attached pictures, I analyzed the data file >> "ofdm_sync_pn-theta_f.dat" which is generated by ofdm_sync_pn.py. But I >> found the plateau width is half of the cp length(128), which is shown in >> 1.jpg. >> So I continue to analyze the data file "ofdm_sync_pn-input_c.dat" >> generated in the same time, by manually doing the correlation on the input >> data of the ofdm_sync_pn.py and find that the plateau is correct as >> cp_length (128), which is shown in 2.jpg. >> So I guess, are there any operations like the decimation to decrease the >> sample number by half, when generating the normalized metric for the >> preamble correlation plateau in ofdm_sync_pn.py. >> >> I know it is long time for you to have looked this piece of code. But it >> is really appreciated if you can give a help. >> >> >> On Sat, Mar 31, 2012 at 9:36 AM, Tom Rondeau wrote: >>> >>> On Tue, Mar 27, 2012 at 10:29 PM, Alex Zhang >>> wrote: >>> > Hi Tom, >>> > >>> > Thanks for the reply. >>> > In the ofdm_sync_pn.py, I see that a matched filter is used, after the >>> > timing metric is obtained based on the correlation of the two halves of >>> > the >>> > preamble. I understand this matched filter is trying to find the end of >>> > the >>> > plateau of the metric and get the smooth peak. But I am a little >>> > confused >>> > with the length of this matched filter. >>> > In the code, the length of this matched filter is set as equal to >>> > cp_length. >>> > But in T.M.Schmidl's paper(page 1615), the plateau length is equal to >>> > the >>> > cp_length minus the channel impulse response length. I am thinking, >>> > without >>> > counting the channel response length, can we get the peak accurately, >>> > especially in multipath environment? >>> >>> It's been so long since I've looked closely at that. You could be >>> right. Test it and see and let us know the results. >>> >>> Tom >>> >>> >>> >>> > On Sun, Mar 25, 2012 at 12:40 PM, Tom Rondeau wrote: >>> >> >>> >> On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang >>> >> wrote: >>> >> > Hi Gurus, >>> >> > >>> >> > I just want to make sure how the current gnuradio ofdm exampel is >>> >> > doing synchronization. >>> >> > According to T. M. Schmidl and D. C. Cox, "Robust Frequency and >>> >> > Timing Synchonization for OFDM," IEEE Trans. Communications, vol. >>> >> > 45, no. >>> >> > 12, 1997. >>> >> > When, estimating the carrier frequency offset at the receiver, if >>> >> > the >>> >> > phase >>> >> > difference between the two halves of the 1st training symbol is >>> >> > guaranteed >>> >> > to be less than PI, then the frequency offset estimate can derived >>> >> > by >>> >> > Phi/(Pi*T). In this situation, the even PN sequencies of the second >>> >> > training >>> >> > symbol would not be needed. Otherwise, the actual frequency offset >>> >> > would >>> >> > be >>> >> > >>> >> > Phi/(Pi*T) + 2*z/T >>> >> > and the z can be estimated by some optimization algorithm, using >>> >> > both >>> >> > of >>> >> > the training symbols. Also, the paper mentioned that the odd >>> >> > frequencies >>> >> > of >>> >> > the second training symbol can be used to measure the sub-channels. >>> >> > >>> >> > However, I find that only one training symbol is generated to act as >>> >> > preamble at the ofdm transmitter. And on the receiver, it seems that >>> >> > only >>> >> > one preamble is used to estimate the timing peak and the frequency >>> >> > offset. >>> >> > Is the current implementation assuming that the frequency is less >>> >> > than >>> >> > PI? >>> >> > Or anything I missed? >>> >> > >>> >> > Looking forward to your input! >>> >> > -- >>> >> > >>> >> > Alex, >>> >> > Dreams can come true – just believe. >>> >> >>> >> >>> >> Alex, >>> >> >>> >> Take a look at the presentation we put together here: >>> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/Wireless >>> >> >>> >> It explains the synchronization process. Basically, the single >>> >> preamble is made up of two identical sections, so the correlation is >>> >> done between those two sections to get the timing and fine frequency >>> >> estimate. Since this preamble is known, we also use it to handle t
Re: [Discuss-gnuradio] digital_correlate_access_code_bb
On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech wrote:
> Just looking at this function:
>
> correlate_access_code_bb
>
> In the method set_access_code, it takes a string. Which should be ASCII '1'
> and '0' characters to represent the binary sequence being
> correlated against.
>
> Here's a little beauty of a code snippet:
>
> d_access_code = 0;
> for (unsigned i=0; i < 64; i++){
> d_access_code <<= 1;
> if (i < len)
> d_access_code |= access_code[i] & 1; // look at LSB only
> }
>
> This relies on the fact that ASCII '1' and '0' happen to have low-order bits
> of the right "flavour". This is insanely dirty and gross and I can't
> believe we let this nonsense in the code base.
>
> There's no reason not to do the right thing here.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
Want to submit a patch?
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] digital_correlate_access_code_bb
On 04/09/2012 01:38 PM, Tom Rondeau wrote:
On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech wrote:
Just looking at this function:
correlate_access_code_bb
In the method set_access_code, it takes a string. Which should be ASCII '1'
and '0' characters to represent the binary sequence being
correlated against.
Here's a little beauty of a code snippet:
d_access_code = 0;
for (unsigned i=0; i< 64; i++){
d_access_code<<= 1;
if (i< len)
d_access_code |= access_code[i]& 1;// look at LSB only
}
This relies on the fact that ASCII '1' and '0' happen to have low-order bits
of the right "flavour". This is insanely dirty and gross and I can't
believe we let this nonsense in the code base.
There's no reason not to do the right thing here.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
Want to submit a patch?
Tom
Attached.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
diff --git a/gr-digital/lib/digital_correlate_access_code_bb.cc b/gr-digital/lib/digital_correlate_access_code_bb.cc
index f21b57d..79c7639 100644
--- a/gr-digital/lib/digital_correlate_access_code_bb.cc
+++ b/gr-digital/lib/digital_correlate_access_code_bb.cc
@@ -78,7 +78,20 @@ digital_correlate_access_code_bb::set_access_code(
for (unsigned i=0; i < 64; i++){
d_access_code <<= 1;
if (i < len)
- d_access_code |= access_code[i] & 1; // look at LSB only
+{
+ if (access_code[i] == '1')
+ {
+ d_access_code |= 1;
+ }
+ else if (access_code[i] == '0')
+ {
+ d_access_code |= 0;
+ }
+ else
+ {
+ return false;
+ }
+}
}
return true;
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] digital_correlate_access_code_bb
On Mon, Apr 9, 2012 at 10:48 AM, Marcus D. Leech wrote:
> On 04/09/2012 01:38 PM, Tom Rondeau wrote:
>
>> On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech
>> wrote:
>>
>>> Just looking at this function:
>>>
>>> correlate_access_code_bb
>>>
>>> In the method set_access_code, it takes a string. Which should be ASCII
>>> '1'
>>> and '0' characters to represent the binary sequence being
>>> correlated against.
>>>
>>> Here's a little beauty of a code snippet:
>>>
>>> d_access_code = 0;
>>> for (unsigned i=0; i< 64; i++){
>>>d_access_code<<= 1;
>>>if (i< len)
>>> d_access_code |= access_code[i]& 1;// look at LSB only
>>> }
>>>
>>> This relies on the fact that ASCII '1' and '0' happen to have low-order
>>> bits
>>> of the right "flavour". This is insanely dirty and gross and I can't
>>> believe we let this nonsense in the code base.
>>>
>>> There's no reason not to do the right thing here.
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>
>> Want to submit a patch?
>>
>> Tom
>>
>>
>> Attached.
While you're patching correlate_access_code_bb, please patch
correlate_access_code_tag_bb with the attached patch.
--n
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
correlate_access_code_tag_bb.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacOS 10.7.3 - mmap or shm_open is not available
On 9 Apr 2012, at 17:41, Tom Rondeau wrote: > > Steven, > > Try to rebuild GNU Radio using -DTRY_SHM_VMCIRCBUF=Off. > > After you rebuild it, make sure you remove > "~/.gnuradio/prefs/gr_vmcircbuf_default_factory" so you don't confuse > the system. > > We recently re-enabled this with cmake and it's the default under > autotools. There's a known bug in Cygwin, which was why this is an > option that can be set. As far as I know, it's always worked under > OSX, but as Michael said, something might have changed and it's just > been masked for a while. It'll be interesting to know if this is a new > problem. Thanks, that seems to have done the trick. For the record here's how I built it: # Install the dependencies sudo port install apple-gcc42 atk autoconf automake bison boost bzip2 cairo cmake cppunit db46 dbus docbook-xml docbook-xml-4.1.2 docbook-xml-4.2 docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl doxygen expat fftw-3 fftw-3-single flac fontconfig freetype gawk gcc_select gd2 gdbm gdk-pixbuf2 getopt gettext ghostscript glib2 gmp gnome-common gnome-doc-utils gperf gputils graphviz groff gsed gsl gtk-doc gtk2 gts guile help2man hicolor-icon-theme icu intltool iso-codes jack jasper jbig2dec jbigkit jpeg lcms lcms2 libedit libffi libglade2 libiconv libidn libLASi libmikmod libmng libogg libpaper libpixman libpng libsamplerate libsdl libsdl_mixer libsndfile libtool libusb libusb-legacy libvorbis libxml2 libxslt m4 makedepend mesa ncurses ncursesw netpbm nosetests_select openssl orc p5.12-getopt-long p5.12-locale-gettext p5.12-pathtools p5.12-scalar-list-utils p5.12-xml-parser pango pcre perl5 perl5.12 pkgconfig portaudio psutils py27-cairo py27-cheetah py27-distribute py27-gobject py27-gtk py27-libxml2 py27-lxml py27-nose py27-numpy py27-opengl py27-opengl-accelerate py27-pil py27-py py27-pyqt4 py27-pyqwt py27-sip py27-tkinter py27-wxpython-devel python26 python27 python_select qt4-mac qwt52 qwtplot3d rarian readline sdcc29 shared-mime-info smpeg sqlite3 swig swig-python tcl texinfo tiff tk urw-fonts usrp wxWidgets-devel Xft2 xmlcatmgr xorg-bigreqsproto xorg-compositeproto xorg-damageproto xorg-dri2proto xorg-fixesproto xorg-glproto xorg-inputproto xorg-kbproto xorg-libice xorg-libpthread-stubs xorg-libsm xorg-libX11 xorg-libXau xorg-libXaw xorg-libxcb xorg-libXcomposite xorg-libXcursor xorg-libXdamage xorg-libXdmcp xorg-libXext xorg-libXfixes xorg-libXi xorg-libXinerama xorg-libXmu xorg-libXrandr xorg-libXScrnSaver xorg-libXt xorg-randrproto xorg-renderproto xorg-scrnsaverproto xorg-util-macros xorg-xcb-proto xorg-xcb-util xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xineramaproto xorg-xproto xorg-xtrans xpm xrender xz zlib # Set your PYTHONPATH PYTHONPATH=/usr/local/lib/python2.7/site-packages/ # grab the latest source cd /usr/local git clone git://gnuradio.org/gnuradio # Not sure if this step is necessary now but haven't tested without it sudo port select gcc apple-gcc42 export CC=gcc export CXX=g++ # Build it mkdir build cd build cmake ../gnuradio/ -DPYTHON_LIBRARY=/opt/local/lib/libpython2.7.dylib -DENABLE_GR_WAVELET=OFF -DTRY_SHM_VMCIRCBUF=OFF # Test it make test # Install it :o) make install smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Screencast for Absolute Beginners
Hi Community, Just uploaded 11 more screen casts in GNURADIO for absolute beginners. They are mostly related to using benchmark files of digital transmission and ofdm transmission. Some playing with the spectrum sensing code is also there. I have increased the font size as well as bright back ground for better visibility. http://www.youtube.com/user/2011HPS?feature=watch A lot more will be coming. Cheers :working: heckpiet wrote: > > thx mate !! > > Cheers > > Piet > > Am 8. April 2012 01:07 schrieb sumitstop > : >> >> Hi Community, >> >> I have uploaded screencast of some very basic things for the beginners in >> gnuradio like installing gnuradio, finding common examples of usrp, uhd, >> utilities etc. Also getting information about usrp's / daughterboards, >> antennas, burning SD card etc. >> >> Here is the link >> >> http://www.youtube.com/user/2011HPS?feature=watch >> http://www.youtube.com/user/2011HPS?feature=watch >> >> >> Although these things are given in enough detail on gnuradio webpage but >> I >> think watching on screen will be very helpful for the starters :) >> >> Enjoy :) >> >> ** Suggestions/improvements are most welcome >> >> - >> Sumit Kr. >> Research Assistant >> Communication Research center >> IIIT Hyderabad >> India >> -- >> View this message in context: >> http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33650161.html >> Sent from the GnuRadio mailing list archive at Nabble.com. >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33657814.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacOS 10.7.3 - mmap or shm_open is not available
On Mon, Apr 9, 2012 at 2:58 PM, Steven wrote: > > On 9 Apr 2012, at 17:41, Tom Rondeau wrote: > > > Steven, > > Try to rebuild GNU Radio using -DTRY_SHM_VMCIRCBUF=Off. > > After you rebuild it, make sure you remove > "~/.gnuradio/prefs/gr_vmcircbuf_default_factory" so you don't confuse > the system. > > We recently re-enabled this with cmake and it's the default under > autotools. There's a known bug in Cygwin, which was why this is an > option that can be set. As far as I know, it's always worked under > OSX, but as Michael said, something might have changed and it's just > been masked for a while. It'll be interesting to know if this is a new > problem. > > > Thanks, that seems to have done the trick. > > For the record here's how I built it: > > # Install the dependencies > sudo port install apple-gcc42 atk autoconf automake bison boost bzip2 cairo > cmake cppunit db46 dbus docbook-xml docbook-xml-4.1.2 docbook-xml-4.2 > docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl > doxygen expat fftw-3 fftw-3-single flac fontconfig freetype gawk gcc_select > gd2 gdbm gdk-pixbuf2 getopt gettext ghostscript glib2 gmp gnome-common > gnome-doc-utils gperf gputils graphviz groff gsed gsl gtk-doc gtk2 gts guile > help2man hicolor-icon-theme icu intltool iso-codes jack jasper jbig2dec > jbigkit jpeg lcms lcms2 libedit libffi libglade2 libiconv libidn libLASi > libmikmod libmng libogg libpaper libpixman libpng libsamplerate libsdl > libsdl_mixer libsndfile libtool libusb libusb-legacy libvorbis libxml2 > libxslt m4 makedepend mesa ncurses ncursesw netpbm nosetests_select openssl > orc p5.12-getopt-long p5.12-locale-gettext p5.12-pathtools > p5.12-scalar-list-utils p5.12-xml-parser pango pcre perl5 perl5.12 pkgconfig > portaudio psutils py27-cairo py27-cheetah py27-distribute py27-gobject > py27-gtk py27-libxml2 py27-lxml py27-nose py27-numpy py27-opengl > py27-opengl-accelerate py27-pil py27-py py27-pyqt4 py27-pyqwt py27-sip > py27-tkinter py27-wxpython-devel python26 python27 python_select qt4-mac > qwt52 qwtplot3d rarian readline sdcc29 shared-mime-info smpeg sqlite3 swig > swig-python tcl texinfo tiff tk urw-fonts usrp wxWidgets-devel Xft2 > xmlcatmgr xorg-bigreqsproto xorg-compositeproto xorg-damageproto > xorg-dri2proto xorg-fixesproto xorg-glproto xorg-inputproto xorg-kbproto > xorg-libice xorg-libpthread-stubs xorg-libsm xorg-libX11 xorg-libXau > xorg-libXaw xorg-libxcb xorg-libXcomposite xorg-libXcursor xorg-libXdamage > xorg-libXdmcp xorg-libXext xorg-libXfixes xorg-libXi xorg-libXinerama > xorg-libXmu xorg-libXrandr xorg-libXScrnSaver xorg-libXt xorg-randrproto > xorg-renderproto xorg-scrnsaverproto xorg-util-macros xorg-xcb-proto > xorg-xcb-util xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto > xorg-xineramaproto xorg-xproto xorg-xtrans xpm xrender xz zlib > > # Set your PYTHONPATH > PYTHONPATH=/usr/local/lib/python2.7/site-packages/ > > # grab the latest source > cd /usr/local > git clone git://gnuradio.org/gnuradio > > # Not sure if this step is necessary now but haven't tested without it > sudo port select gcc apple-gcc42 > export CC=gcc > export CXX=g++ > > # Build it > mkdir build > cd build > cmake ../gnuradio/ -DPYTHON_LIBRARY=/opt/local/lib/libpython2.7.dylib > -DENABLE_GR_WAVELET=OFF -DTRY_SHM_VMCIRCBUF=OFF > > # Test it > make test > > # Install it :o) > make install Thanks for the info. It'd be great to figure out where/why this is going wrong. As I said, it used to be the default case under autotools, and I don't think we had a problem with it. If it's a new feature in OSX version x.y.z, then we'll have to live with it until we can figure out a workaround. If no one can figure out how to get shared memory mapping to work, we'll add another check to disable it for both Windows and OSX. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] digital_correlate_access_code_bb
On Mon, Apr 9, 2012 at 2:02 PM, Nick Foster wrote:
> On Mon, Apr 9, 2012 at 10:48 AM, Marcus D. Leech wrote:
>>
>> On 04/09/2012 01:38 PM, Tom Rondeau wrote:
>>>
>>> On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech
>>> wrote:
Just looking at this function:
correlate_access_code_bb
In the method set_access_code, it takes a string. Which should be ASCII
'1'
and '0' characters to represent the binary sequence being
correlated against.
Here's a little beauty of a code snippet:
d_access_code = 0;
for (unsigned i=0; i< 64; i++){
d_access_code<<= 1;
if (i< len)
d_access_code |= access_code[i]& 1; // look at LSB only
}
This relies on the fact that ASCII '1' and '0' happen to have low-order
bits
of the right "flavour". This is insanely dirty and gross and I can't
believe we let this nonsense in the code base.
There's no reason not to do the right thing here.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
>>>
>>>
>>> Want to submit a patch?
>>>
>>> Tom
>>>
>>>
>> Attached.
>
>
> While you're patching correlate_access_code_bb, please patch
> correlate_access_code_tag_bb with the attached patch.
>
> --n
So my guess is that the use of the binary & operator is to avoid the
need for an if/if else/else branching check. It was most likely done
for efficiency. So while this patch might be the "right" way to do it
from a code perspective, it could result in slower code (on certain
machines that don't handle branch prediction well). It does make
assumptions about the correctness of the access code, though.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failures on master branch
> Absolutely. I'm also concerned I have some underlying platform issue. Thanks for working with me, Josh. Today I gave up and went to RHEL 6. The build went fine. Hopefully the rest of what I indend to do will work well on this "new" OS. Should have probable started here...too many out of date dependencies on RHEL 5. $ cat /proc/version Linux version 2.6.32-220.el6.x86_64 (mockbu...@x86-004.build.bos.redhat.com) (gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC) ) #1 SMP Wed Nov 9 08:03:13 EST 2011 $ cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.2 (Santiago) $ git show commit 779d8c67ae520ab76198019e656c86c88281719d Merge: 3de14a2 c7139a7 Author: Johnathan Corgan Date: Mon Apr 9 14:10:26 2012 -0700 $ make test ... 100% tests passed, 0 tests failed out of 101 In case it helps someone, these packages from RHEL and EPEL will cover the dependencies for UHD and GR (listed by yum package name): boost* cmake cppunit* fftw fftw-devel fftw-static git-all gsl* guile* libusb* orc* pcre* python-docutils pygtk* PyQt4* PyQwt* pyxdg qt* qwt* sdcc* wxPython* xdg-utils With those in place, both the UHD and GR latest master git branches built today. Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GSOC: slot request
Just a gentle reminder if any mentor has missed this one. http://lists.gnu.org/archive/html/summer-of-code/2012-04/msg00079.htm Sreeraj R IIT Bombay http://home.iitb.ac.in/~rsreeraj ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmantation fault usrp_spectrum_sense
No thing happened all other examples are working . When i added "file.tr" to the command it gave me this error and when i wrote the command without "file.tr" it worked without any problems and usrp start to sense. But i need to save this data > > On Monday, April 9, 2012, Tom Rondeau wrote: > >> On Sun, Apr 8, 2012 at 9:59 PM, Abdelrahman Ahmed >> wrote: >> > last week every thing was fine until today when i want to sense the >> >spectrum i faced this problem >> >>>./usrp_spectrum_sense.py 1901M 1983M > file.tr >> > >> > Warning: this is known to have issues on some machines+Python version >> >combinations to seg fault due to the callback in bin_statitics. If >> you >> >figure out why, we'd love to hear about it! >> >Traceback (most recent call last): >> > File "./usrp_spectrum_sense.py", line 237, in >> >tb = my_top_block() >> > File "./usrp_spectrum_sense.py", line 135, in __init__ >> >num_channels=1) >> > File "/usr/local/lib/python2.7/ >> > dist-packages/gnuradio/uhd/__init__.py", >> >line 116, in constructor_interceptor >> >return old_constructor(*args) >> > File >> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", >> >line 2885, in usrp_source >> >return _uhd_swig.usrp_source(*args) >> >RuntimeError: LookupError: KeyError: No devices found for -> >> >Device Address: >> >addr: 192.168.10.2 >> >although i am using usrp 1 so i added this args >> >>>usrp_spectrum_sense.py 1901M 1983M >file.tr --address="type=usrp1" >> > >> >linux; GNU C++ version 4.6.1; Boost_104601; >> UHD_003.004.000-24-g8630807c >> > >> >Warning: this is known to have issues on some machines+Python version >> >combinations to seg fault due to the callback in bin_statitics. If >> you >> >figure out why, we'd love to hear about it! >> >-- Opening a USRP1 device... >> >-- Using FPGA clock rate of 64.00MHz... >> >Using Volk machine: ssse3_64 >> >gain = 25.75 >> >Segmentation fault >> >> Well, it does say right as you start the program: >> >> Warning: this is known to have issues on some machines+Python version >> combinations to seg fault due to the callback in bin_statitics. If you >> figure out why, we'd love to hear about it! >> >> So what changed for you between last week and this week? Have you >> changed code or any installations that we should know about? >> >> Tom >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
