Re: [Discuss-gnuradio] DVSI USB-3000 P25
On Tue, Aug 28, 2012 at 3:52 PM, Eric Cottrell wrote: > Hello, > > This looked interesting since the voice codec will do P25, DMR, and D*. So I > bought one and should have it in a couple of days. > > http://www.dvsinc.com/products/usb_3k.htm > > 73 Eric Neat. Let us know what you find. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA time
Sorry for the confusion. We are trying to synchronize 3 usrps for collect. The devices seem to be time aligned in that the samples are timestamped with the same metadata, so we believed that synchronization had been achieved. However, when the data collected from the usrps was correlated, samples that should have had 0 time difference of arrival were off by as many as 5 samples, at a sample rate of 6.25MS/S. So even though the timestamps are time aligned, the data does not seem to be. The devices have been synchronized PPS times, not uspr.get_time_now(). Thank you, Anisha On Tue, Aug 28, 2012 at 5:40 PM, Josh Blum wrote: > > > On 08/28/2012 01:39 PM, Anisha Gorur wrote: > > Thats actually what we are using, however, when printing out the tick > > count, we randomly, and only sometimes, see a jump of about 30 ticks, and > > if each tick is 10ns, that is a huge 300ns jump. Do you know why this > could > > be happening? > > > > I'm very lost. Where are you getting the time_spec from? A receive > packet? usrp.get_time_now()? Or is this a time difference between devices? > > get_time_now is completely asynchronous to the device, if thats what you > are calling in a loop, I would expect to see a lot of variation in time > deltas. > > -josh > > > We are using gpsdo's as both a time and clock reference, though this > > problem seems to occur even if we set the clock and time reference to > > external. However, setting them to gpsdo seems to make it more stable, as > > we have seen the ~30 tick jump fewer times with those references. Another > > question is why would there be a big difference in what the reference is > > set as when either way, supposedly the internal GPSDO is being used. > > > > Thanks, > > > > On Tue, Aug 28, 2012 at 4:13 PM, Josh Blum wrote: > > > >> > >> > >> On 08/28/2012 12:03 PM, Anisha Gorur wrote: > >>> Hello, > >>> We've been having some trouble with the synchronizing aspects of our > >>> project. What we want is the exact same time as the FPGA tick counter, > >> not > >>> a time_spec_t representation of time. Where can we get access to that? > >>> Thanks! > >>> -Anisha > >>> > >>> > >> > >> call to_ticks with the clock rate of the device: > >> > >> > http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#ad75960ba4c788cd30a5d0c8904888da3 > >> > >> -josh > >> > >>> > >>> ___ > >>> 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 > >> > > > > > > > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stream Tags
> I have not yet used stream tags, and have a number of > questions: > > 1. Is it possible to get timetags for every sample? My >readings on time tags seemed to imply that only one >is created at the beginning of a stream. > Your block will need to grab a hold of the last time tag that was produced. If you know the sample count of this tag, and the sample count of the sample you are interested in, its a simple interpolation. > 2. What is the accuracy/precision of the time tags? Jitter >is going to be the make-or-break factor on this project. > The fractional seconds are stored as double precision floating point. This gives the fractional seconds enough precision to unambiguously specify a clock-tick/sample-count up to rates of several petahertz. :-) > 3. It looks like the Start-Of-Burst (SOB) tag is the only >way to control the time of transmission. Is there any >limitation on the length of a burst? In my case, I would >want to start the transmitter in response to receiving >the uplink, and not stop it until the uplink ceases, >about 4 minutes later. > The tx_time tag is the way to control the time of transmission. Bursts can be any length. Its important to end a burst or an underflow is produced if you stop producing TX samples. > 4. Is there any good tutorial or example information on >the use of stream tags? (I'm using GR 3.6.1) Yes: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/tags_demo.cc > > 5. Does all this sound like I'm headed in the right direction, >or is there something fundamental that I'm missing? > I think you have got it! http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-with-GNU-Radio -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA time
On 08/28/2012 01:39 PM, Anisha Gorur wrote: > Thats actually what we are using, however, when printing out the tick > count, we randomly, and only sometimes, see a jump of about 30 ticks, and > if each tick is 10ns, that is a huge 300ns jump. Do you know why this could > be happening? > I'm very lost. Where are you getting the time_spec from? A receive packet? usrp.get_time_now()? Or is this a time difference between devices? get_time_now is completely asynchronous to the device, if thats what you are calling in a loop, I would expect to see a lot of variation in time deltas. -josh > We are using gpsdo's as both a time and clock reference, though this > problem seems to occur even if we set the clock and time reference to > external. However, setting them to gpsdo seems to make it more stable, as > we have seen the ~30 tick jump fewer times with those references. Another > question is why would there be a big difference in what the reference is > set as when either way, supposedly the internal GPSDO is being used. > > Thanks, > > On Tue, Aug 28, 2012 at 4:13 PM, Josh Blum wrote: > >> >> >> On 08/28/2012 12:03 PM, Anisha Gorur wrote: >>> Hello, >>> We've been having some trouble with the synchronizing aspects of our >>> project. What we want is the exact same time as the FPGA tick counter, >> not >>> a time_spec_t representation of time. Where can we get access to that? >>> Thanks! >>> -Anisha >>> >>> >> >> call to_ticks with the clock rate of the device: >> >> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#ad75960ba4c788cd30a5d0c8904888da3 >> >> -josh >> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Stream Tags
I'm starting up on another R&D project using GnuRadio. The project is a transponder, used by NASA for ranging. It uses DSSS on both the uplink and the downlink. The transponder has to be coherent, and it synchronizes the PN epochs of the received uplink and the transmitted downlink. This allows the groundstation to compute the round-trip time, (and hence the range), by comparing the offset of the received epoch to that of the one originally transmitted to the transponder. My plan is to use stream tags to accomplish the synchronization. This will require getting a time tag for each received sample, identifying the time of the first sample associated with the epoch of the received uplink, and using that time to start the transmission of the first sample of the downlink epoch a small integer number of epochs later (to allow for GnuRadio latency). I have not yet used stream tags, and have a number of questions: 1. Is it possible to get timetags for every sample? My readings on time tags seemed to imply that only one is created at the beginning of a stream. 2. What is the accuracy/precision of the time tags? Jitter is going to be the make-or-break factor on this project. 3. It looks like the Start-Of-Burst (SOB) tag is the only way to control the time of transmission. Is there any limitation on the length of a burst? In my case, I would want to start the transmitter in response to receiving the uplink, and not stop it until the uplink ceases, about 4 minutes later. 4. Is there any good tutorial or example information on the use of stream tags? (I'm using GR 3.6.1) 5. Does all this sound like I'm headed in the right direction, or is there something fundamental that I'm missing? Thanks in advance for any help! @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] IT++ Convolutional encoder
I have the next code working, in the firsts seconds I have erroneous
bits, after 10 seconds I don't have any error... another thing if I put
Max Number of Output = 0 always have a ber of 40%...
Umbrella_encodconv_vff::Umbrella_encodconv_vff (const std::vector
&val1, int val2, int val3)
: gr_sync_block ("encodconv_vff",
gr_make_io_signature (1, 1, sizeof (float) * val3),
gr_make_io_signature (1, 1, sizeof (float) * val3 * val1.size()))
{
polsize = val1.size();
cl = val2;
pz = val3;
for (int i = 0; i < 0x100; i++){
polynom[i] = i;
}
unsigned int size = std::min((size_t) 0x100, val1.size());
for (unsigned int i = 0; i < size; i++){
polynom[i] = val1[i];
}
// -- Channel code parameters --
itpp::ivec generator(polsize);
for (int i = 0; i < polsize; i++){
generator[i] = polynom[i];
}
code.set_generator_polynomials(generator, cl);
}
int
Umbrella_encodconv_vff::work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
itpp::bvec tempin(pz * sizeof(float));
itpp::bvec tempout(pz * polsize * sizeof(float));
for (int j = 0; j < (pz * sizeof(float)); j++){
tempin[j] = in[j];
}
code.encode_tailbite(tempin, tempout);
for (int k = 0; k < (pz * polsize * sizeof(float)); k++){
out[k] = tempout[k];
}
// Tell runtime system how many output items we produced.
return noutput_items;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA time
Thats actually what we are using, however, when printing out the tick count, we randomly, and only sometimes, see a jump of about 30 ticks, and if each tick is 10ns, that is a huge 300ns jump. Do you know why this could be happening? We are using gpsdo's as both a time and clock reference, though this problem seems to occur even if we set the clock and time reference to external. However, setting them to gpsdo seems to make it more stable, as we have seen the ~30 tick jump fewer times with those references. Another question is why would there be a big difference in what the reference is set as when either way, supposedly the internal GPSDO is being used. Thanks, On Tue, Aug 28, 2012 at 4:13 PM, Josh Blum wrote: > > > On 08/28/2012 12:03 PM, Anisha Gorur wrote: > > Hello, > > We've been having some trouble with the synchronizing aspects of our > > project. What we want is the exact same time as the FPGA tick counter, > not > > a time_spec_t representation of time. Where can we get access to that? > > Thanks! > > -Anisha > > > > > > call to_ticks with the clock rate of the device: > > http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#ad75960ba4c788cd30a5d0c8904888da3 > > -josh > > > > > ___ > > 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 > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA time
On 08/28/2012 12:03 PM, Anisha Gorur wrote: > Hello, > We've been having some trouble with the synchronizing aspects of our > project. What we want is the exact same time as the FPGA tick counter, not > a time_spec_t representation of time. Where can we get access to that? > Thanks! > -Anisha > > call to_ticks with the clock rate of the device: http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#ad75960ba4c788cd30a5d0c8904888da3 -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DVSI USB-3000 P25
Hello, This looked interesting since the voice codec will do P25, DMR, and D*. So I bought one and should have it in a couple of days. http://www.dvsinc.com/products/usb_3k.htm 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FPGA time
Hello, We've been having some trouble with the synchronizing aspects of our project. What we want is the exact same time as the FPGA tick counter, not a time_spec_t representation of time. Where can we get access to that? Thanks! -Anisha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MIMO Error on USRP2 2X
On 08/28/2012 07:02 AM, Muhammad JUNAID wrote: > i want to make MIMO on 2X USRP2 GRC is attached, i got this error... > > linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-34-stable > > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > Using Volk machine: sse4_2_32 > Floating point exception (core dumped) > I am unsure, but I have 2 suggestions. 1) You dont need the throttle block. The USRP sink throttles the stream. 2) You should individually address the USRPs to avoid confusion over which "block" is which device: http://files.ettus.com/uhd_docs/manual/html/identification.html Try making those fixes. If there error is still present, I recommend sending a gdb traceback so we can know where the issue occurred. -josh > > Regards > Muhammad Junaid > m_junaid0...@yahoo.com > http://junaidmuhammad.webs.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] USRP2 MIMO system implementation
On 08/28/2012 12:19 AM, Pan, Luyuan wrote: > Hello, > I want to implement a MIMO system using USRP2, I just have USRP2s and > MIMO cable. > 1. Do I have to use an external clock source ? No. With the mimo cable, you can share a clock reference between a pair of devices > 2. I searched the maillist and found: Each USRP2 can handle 1 antenna > with most daughterboards, or 2 if you > have your own external RF sections connected to the USRP2 at IF. > Does it mean I should buy "external RF sections" to use 2 antennas on 1 > USRP2? Or where can I get them? You should select a daughterboard based on the desired frequency coverage. Typically transceiver boards have 1 tx frontend and 1 rx frontend. The TVRX2, which is RX only, has 2 rx frontends. > 3. If I want to build a 2X2 MIMO system,-- 2 USRP2s, 1 MIMO cable, the > "external RF sections" said above, -- Is that enough? > Correct. You may also find these notes helpful: http://files.ettus.com/uhd_docs/manual/html/sync.html -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MIMO Error on USRP2 2X
i want to make MIMO on 2X USRP2 GRC is attached, i got this error... linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-34-stable -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes Using Volk machine: sse4_2_32 Floating point exception (core dumped) Regards Muhammad Junaid m_junaid0...@yahoo.com http://junaidmuhammad.webs.com/ test.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to utilize multi-thread processor
On Mon, Aug 27, 2012 at 7:07 AM, Qing Yang wrote: > Hi there, > > I am currently doing a OFDM transceiver project based on RawOFDM. We want to > implement 20MHz bandwidth transmit/receive, but the RawOFDM code seems to > support only narrow band (<1MHz). Once I set the sample-rate larger than > 1MHz, my program will block with overrun messages (more details here > http://lists.gnu.org/archive/html/discuss-gnuradio/2012-08/msg00069.html). I > think the reason is that at 20MHz sample-rate, USRP produces too much data > for the PC to process and drain PC's computation power. > > To boost the speed, I have two questions > > 1) My cpu have 8 threads(4 cores), can I manually dedicate one thread to > each gr block, and make it a pipe-line system? Tom mentioned that gnuradio > use a "thread-per-block" scheduler > (http://lists.gnu.org/archive/html/discuss-gnuradio/2010-09/msg00274.html) > but in my case only two threads are 100% occupied when I run the program. > > 2) Inside some blocks, we extensively use vector multiplications (e.g., > precoding, CFO compensation). I've heard about the use of SSE to boost the > speed of vector multiplication. How can I utilize this technology in my > program? > > > Best regards, > -- > Yang, Qing > Information Engineering, CUHK Qing, Yes, the default scheduler is the thread-per-block, so each block operates in its own thread, and the OS will distribute those across the CPU's. What you are seeing is probably that two blocks in particular are taking a long time to process and starving the others. So CPU affinity won't help you. From your other posts, it looks like you are trying to profile the code. That's the better way to go; figure out which blocks are taking the most time and try to optimize them. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Profile gr python code using Oprofile and Kcachegrind
On Tue, Aug 28, 2012 at 4:21 AM, Qing Yang wrote: > Hi everyone, > > Where can I find a concrete example on how to profile the gnuradio code in > Python? > > My PC is Linux 2.6.35-32-generic-pae #67-Ubuntu SMP Mon Mar 5 21:23:19 UTC > 2012 i686 GNU/Linux. I use Ubuntu 10.10 and Xeon W3530. > > I can use Kcachegrind to profile code written in C++. But when I profile > python code(e.g., dial_tone.py), there is no profile data output. > > address@hidden:~/Public$ valgrind --tool=callgrind ./dial_tone.py Qing, Try this: address@hidden:~/Public$ valgrind --tool=callgrind python ./dial_tone.py I've used callgrind with Python before, but you need to explicitly call it through the interpreter for callgrind to catch on. I _think_ this works, but it's just from memory. If it doesn't, Google callgrind and Python; I know the answer is out there. Tom > ==30385== Callgrind, a call-graph generating cache profiler > ==30385== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et > al. > ==30385== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for > copyright info > ==30385== Command: ./dial_tone.py > ==30385== > ==30385== For interactive control, run 'callgrind_control -h'. > address@hidden:~/Public$ ls -l > total 12 > -rw--- 1 yangqing yangqing0 2012-08-27 16:29 callgrind.out.30385 > ** the size of profile data is 0? ** > -rwxr-xr-x 1 yangqing yangqing 2006 2012-07-05 16:37 dial_tone.py > -rwxr-xr-x 1 yangqing yangqing 249 2012-08-27 16:22 mainloop.py > drwxr-xr-x 25 yangqing yangqing 4096 2012-08-27 00:23 oprofile > > Then I try Oprofile, but also failed :( > > address@hidden:~/Public$ sudo opcontrol --init > address@hidden:~/Public$ sudo opcontrol --setup --no-vmlinux > address@hidden:~/Public$ sudo opcontrol --start > ATTENTION: Use of opcontrol is discouraged. Please see the man page for > operf. > Using default event: CPU_CLK_UNHALTED:10:0:1:1 > Using 2.6+ OProfile kernel interface. > Using log file /var/lib/oprofile/samples/oprofiled.log > Daemon started. > Profiler running. > address@hidden:~/Public$ sudo opcontrol --reset > Signalling daemon... done > address@hidden:~/Public$ ./dial_tone.py > address@hidden:~/Public$ sudo opcontrol --dump > address@hidden:~/Public$ sudo opcontrol --shutdown > Stopping profiling. > Killing daemon. > address@hidden:~/Public$ opreport -l dial_tone.py > Using /var/lib/oprofile/samples/ for samples directory. > error: no sample files found: profile specification too strict ? ** can't > find the profile data? ** > > and I try > address@hidden:~/Public$ opreport -l|less > CPU: Intel Core/i7, speed 2.794e+06 MHz (estimated) > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit > mask of 0x00 (No unit mask) count 10 > samples %image name app name symbol > name > 9729344.4076 no-vmlinux no-vmlinux > /no-vmlinux > 4332419.7744 nvidia_drv.sonvidia_drv.so > /usr/lib/nvidia-173/xorg/nvidia_drv.so > 2318910.5842 chromium-browser chromium-browser > /usr/lib/chromium-browser/chromium-browser > 8264 3.7719 libpixman-1.so.0.18.4libpixman-1.so.0.18.4 > /usr/lib/libpixman-1.so.0.18.4 > 5975 2.7272 libglib-2.0.so.0.2600.1 libglib-2.0.so.0.2600.1 > /lib/libglib-2.0.so.0.2600.1 > 4409 2.0124 libgobject-2.0.so.0.2600.1 libgobject-2.0.so.0.2600.1 > /usr/lib/libgobject-2.0.so.0.2600.1 > 3811 1.7395 libcairo.so.2.11000.0libcairo.so.2.11000.0 > /usr/lib/libcairo.so.2.11000.0 > 3001 1.3698 libpangoft2-1.0.so.0.2800.2 libpangoft2-1.0.so.0.2800.2 > /usr/lib/libpangoft2-1.0.so.0.2800.2 > 2714 1.2388 python2.6python2.6 > /usr/bin/python2.6 > 2083 0.9507 libdbus-1.so.3.5.2 libdbus-1.so.3.5.2 > /lib/libdbus-1.so.3.5.2 > 2003 0.9142 libwfb.solibwfb.so > /usr/lib/xorg/modules/libwfb.so > 1969 0.8987 Xorg Xorg > /usr/bin/Xorg > 1894 0.8645 libgtk-x11-2.0.so.0.2200.0 libgtk-x11-2.0.so.0.2200.0 > /usr/lib/libgtk-x11-2.0.so.0.2200.0 > 1732 0.7905 libgnuradio-core-3.5.2git.so.0.0.0 > libgnuradio-core-3.5.2git.so.0.0.0 gr_sig_source_f::work(int, > std::vector or >&, std::vector >&) > 1578 0.7202 libgdk-x11-2.0.so.0.2200.0 libgdk-x11-2.0.so.0.2200.0 > /usr/lib/libgdk-x11-2.0.so.0.2200.0 > 1378 0.6290 libpango-1.0.so.0.2800.2 libpango-1.0.so.0.2800.2 > /usr/lib/libpango-1.0.so.0.2800.2 > 962 0.4391 [vdso] (tgid:1237 range:0xb77ec000-0xb77ed000) Xorg > [vdso] (tgid:1237 range:0xb77ec000-0xb77ed000) > 802 0.3661 libpthread-2.12.1.so libpthread-2.12.1.so > pthread_mutex_lock > 690 0.3149 libc-2.12.1.so libc-2.12.1.so > __memcpy_ssse3_rep > 640 0.2921 libpthread-2.12.1.so libpthread-2.12.1.so > __pthread_mutex_unlock_usercnt > 459 0.2095 libX11.so.6.3.0 libX11.so.6.3.0 > /usr/lib/libX11.so.6.3.0 > 444 0.2027 libQtGui.so.4.7.0libQtGui.so.4.7.0 > /usr/l
Re: [Discuss-gnuradio] Setting the XCVR2450 Bandwidth
Awesome, thanks Josh - I'll give this a try tomorrow! On Thu, Aug 23, 2012 at 9:55 AM, Josh Blum wrote: > > > On 08/22/2012 06:11 AM, Michael Hill wrote: > > Thanks Josh, > > > > I've still been toying with this though.. and aren't really having any > > success. > > E.g. if I pick a Tx bandwidth of 24MHz.. and transmit > > > > and use 8bit I&Q samples transmitted at 50MHz.. then shouldn't I see some > > signs of the filter? > > What should I be looking for on my spec amp? > > Just transmit some wideband noise and zoom out on the spectrum analyzer. > You should easily see the filter profile. > > (Flow graph attached). > > > > > I assume by baseband filter, that you mean this is a digital filter that > > applies what I send from the CPU to the USRP.. > > > > This is an analog baseband filter on the XCVR 2450. > > -Josh > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Profile gr python code using Oprofile and Kcachegrind
Hi everyone, Where can I find a concrete example on how to profile the gnuradio code in Python? My PC is Linux 2.6.35-32-generic-pae #67-Ubuntu SMP Mon Mar 5 21:23:19 UTC 2012 i686 GNU/Linux. I use Ubuntu 10.10 and Xeon W3530. I can use Kcachegrind to profile code written in C++. But when I profile python code(e.g., dial_tone.py), there is no profile data output. address@hidden:~/Public$ valgrind --tool=callgrind ./dial_tone.py ==30385== Callgrind, a call-graph generating cache profiler ==30385== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et al. ==30385== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==30385== Command: ./dial_tone.py ==30385== ==30385== For interactive control, run 'callgrind_control -h'. address@hidden:~/Public$ ls -l total 12 -rw--- 1 yangqing yangqing0 2012-08-27 16:29 callgrind.out.30385 ** the size of profile data is 0? ** -rwxr-xr-x 1 yangqing yangqing 2006 2012-07-05 16:37 dial_tone.py -rwxr-xr-x 1 yangqing yangqing 249 2012-08-27 16:22 mainloop.py drwxr-xr-x 25 yangqing yangqing 4096 2012-08-27 00:23 oprofile Then I try Oprofile, but also failed :( address@hidden:~/Public$ sudo opcontrol --init address@hidden:~/Public$ sudo opcontrol --setup --no-vmlinux address@hidden:~/Public$ sudo opcontrol --start ATTENTION: Use of opcontrol is discouraged. Please see the man page for operf. Using default event: CPU_CLK_UNHALTED:10:0:1:1 Using 2.6+ OProfile kernel interface. Using log file /var/lib/oprofile/samples/oprofiled.log Daemon started. Profiler running. address@hidden:~/Public$ sudo opcontrol --reset Signalling daemon... done address@hidden:~/Public$ ./dial_tone.py address@hidden:~/Public$ sudo opcontrol --dump address@hidden:~/Public$ sudo opcontrol --shutdown Stopping profiling. Killing daemon. address@hidden:~/Public$ opreport -l dial_tone.py Using /var/lib/oprofile/samples/ for samples directory. error: no sample files found: profile specification too strict ? ** can't find the profile data? ** and I try address@hidden:~/Public$ opreport -l|less CPU: Intel Core/i7, speed 2.794e+06 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 10 samples %image name app name symbol name 9729344.4076 no-vmlinux no-vmlinux /no-vmlinux 4332419.7744 nvidia_drv.sonvidia_drv.so /usr/lib/nvidia-173/xorg/nvidia_drv.so 2318910.5842 chromium-browser chromium-browser /usr/lib/chromium-browser/chromium-browser 8264 3.7719 libpixman-1.so.0.18.4libpixman-1.so.0.18.4 /usr/lib/libpixman-1.so.0.18.4 5975 2.7272 libglib-2.0.so.0.2600.1 libglib-2.0.so.0.2600.1 /lib/libglib-2.0.so.0.2600.1 4409 2.0124 libgobject-2.0.so.0.2600.1 libgobject-2.0.so.0.2600.1 /usr/lib/libgobject-2.0.so.0.2600.1 3811 1.7395 libcairo.so.2.11000.0libcairo.so.2.11000.0 /usr/lib/libcairo.so.2.11000.0 3001 1.3698 libpangoft2-1.0.so.0.2800.2 libpangoft2-1.0.so.0.2800.2 /usr/lib/libpangoft2-1.0.so.0.2800.2 2714 1.2388 python2.6python2.6 /usr/bin/python2.6 2083 0.9507 libdbus-1.so.3.5.2 libdbus-1.so.3.5.2 /lib/libdbus-1.so.3.5.2 2003 0.9142 libwfb.solibwfb.so /usr/lib/xorg/modules/libwfb.so 1969 0.8987 Xorg Xorg /usr/bin/Xorg 1894 0.8645 libgtk-x11-2.0.so.0.2200.0 libgtk-x11-2.0.so.0.2200.0 /usr/lib/libgtk-x11-2.0.so.0.2200.0 1732 0.7905 libgnuradio-core-3.5.2git.so.0.0.0 libgnuradio-core-3.5.2git.so.0.0.0 gr_sig_source_f::work(int, std::vector >&, std::vector >&) 1578 0.7202 libgdk-x11-2.0.so.0.2200.0 libgdk-x11-2.0.so.0.2200.0 /usr/lib/libgdk-x11-2.0.so.0.2200.0 1378 0.6290 libpango-1.0.so.0.2800.2 libpango-1.0.so.0.2800.2 /usr/lib/libpango-1.0.so.0.2800.2 962 0.4391 [vdso] (tgid:1237 range:0xb77ec000-0xb77ed000) Xorg [vdso] (tgid:1237 range:0xb77ec000-0xb77ed000) 802 0.3661 libpthread-2.12.1.so libpthread-2.12.1.so pthread_mutex_lock 690 0.3149 libc-2.12.1.so libc-2.12.1.so __memcpy_ssse3_rep 640 0.2921 libpthread-2.12.1.so libpthread-2.12.1.so __pthread_mutex_unlock_usercnt 459 0.2095 libX11.so.6.3.0 libX11.so.6.3.0 /usr/lib/libX11.so.6.3.0 444 0.2027 libQtGui.so.4.7.0libQtGui.so.4.7.0 /usr/lib/libQtGui.so.4.7.0 409 0.1867 libc-2.12.1.so libc-2.12.1.so _int_malloc 354 0.1616 librt-2.12.1.so librt-2.12.1.so clock_gettime 341 0.1556 libc-2.12.1.so libc-2.12.1.so __memset_sse2_rep 337 0.1538 libgnuradio-audio-3.5.2git.so.0.0.0 libgnuradio-audio-3.5.2git.so.0.0.0 audio_alsa_sink::work_s32(int, std::vector >&, std::vector >&) 332 0.1515 anon (tgid:25090 range:0x4fc0a000-0x4fcff000) chromium-browser anon (tgid:25090 range:0x4fc0a000-0x4fcff000) 322 0.1470 libc-2.12.1.so libc-2.12.1
[Discuss-gnuradio] USRP2 MIMO system implementation
Hello, I want to implement a MIMO system using USRP2, I just have USRP2s and MIMO cable. 1. Do I have to use an external clock source ? 2. I searched the maillist and found: Each USRP2 can handle 1 antenna with most daughterboards, or 2 if you have your own external RF sections connected to the USRP2 at IF. Does it mean I should buy "external RF sections" to use 2 antennas on 1 USRP2? Or where can I get them? 3. If I want to build a 2X2 MIMO system,-- 2 USRP2s, 1 MIMO cable, the "external RF sections" said above, -- Is that enough? Any suggestion is appreciated. Thank you.. -- Best regards, Luyuan Pan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
