Re: [Discuss-gnuradio] A silly question
On Mon, 27 Aug 2012 09:46:56 -0700, Josh Blum wrote: > >> >> How can we do that in a C++/Python hybrid flowgraph? Is there a Python >> interface out there? >> > > So to register a python callback into C++ is tricky. The answer is SWIG > directors. However, I nearly killed myself yesterday trying to get that > madness to work. > Oh, this let me recall that I spent lots of time to make SWIG interfaces between C++ vector of vector to Python tuple of typle... C++ reference to vector of vector won't work. I finally use vector of vector, which mighe be more expensive because of copy construction. I find SWIG can be tricky indeed. > So until I figure that out... If it helps anybody, this is a hook to > register an empty handler for the messages: http://pastebin.com/aeSVSjVC > > from gnuradio import uhd > uhd.disable_msgs() > > -josh > Thanks for the effort! I really appreciate it. -- alick Fedora 16 (Verne) user https://fedoraproject.org/wiki/User:Alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio RTL-SDR: self._grid_compiled_list_id error under Mac OS X 10.7.4
I am trying to get GNU Radio working on a Mac OS X 10.7.4 Air laptop. I installed most of the required packages via MacPorts, and then pulled GNU Radio from git. It installed O.K., but dies like this: Using Volk machine: sse4_1_64 gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Elonics E4000 tuner Exact sample rate is: 100.026491 Hz >>> gr_fir_ccc: using SSE >>> gr_fir_fff: using SSE Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/usr/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: : wrong type O This part of the code is returning None for self._grid_compiled_list_id If I add in some if statements to proceed further, I then ran into a problem with some padding variables not being initialized in grid_plotter_base.py. To get aroun these, I add # Added self.padding_left, self.padding_right = (0, 0) self.padding_top, self.padding_bottom = (0, 0) But the graphs won't show up. The radio part works under the multimode receiver, but the visual graphs parts do not work. Any ideas? I can successfully listen to the NOAA Weather Station and to some local FM stations using the multimode.py Multimode Radio Receiver, and can load the grc file and start it up within the GNU Radio Companion, so most of GNU Radio is working O.K., just not the graphics parts. Thank you, Dan Weeks GNU Radio Companion 3.6.2git-149-g9305abf4 Python 2.7.3 Darwin Kernel Version 11.4.2: Wed May 30 20:13:51 PDT 2012; root:xnu-1699.31.2~1/RELEASE_X86_64 x86_64___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Queue Source not being processed by DPSK Demod Block
Im having an issue with the my dpsk demodulator block not processing any data provided by a message source block. This is how I'm passing it to the queue: msg = gr.message_from_string(processed.tostring(), gr.sizeof_gr_complex) tb.source_queue.insert_tail(msg) The "processed" data is a numpy array. Is there is an issue with this data type? -Travis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] re ad_gpio() help
Hello,
I am working on a program that continuously reads pins io_rx[0-15] on the
basic_rx board (I am using USRP N210). I am able to read the pins using the
read_gpio() function, but after a couple seconds I get the following error.
RuntimeError: RuntimeError: fifo ctrl timed out looking for acks
My program looks like this:
#!/usr/bin/env python
from gnuradio import uhd # addded uhd
import struct
import sys
#
/
# main
#
/
def main():
global flag, p, v
flag = True
v = uhd.usrp_source(' ' , uhd.stream_args('fc32'))
while flag:
p = v.get_dboard_iface().read_gpio(114)
print(p)
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
pass
I would greatly appreciate any advise that anyone can give me. Thank you for
your time and help.
Sam
--
View this message in context:
http://old.nabble.com/read_gpio%28%29-help-tp34348253p34348253.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] change to daily batch
Hi kindly change my subscription to a daily batch. Mayowa Aregbesola | aregbes...@gmail.com ___ 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 03:24 PM, Anisha Gorur wrote: > 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 Can you tell me more about the correlation? Are you sending a impulse split to all 3 devices and determining the pulse arrival. Is the error in time of arrival consistent between runs or does it seem to be random? If you ask all N USRPs to stream at time X, the time reported in the metadata will still be X, even if the internal tick count in each device is not marching in lock step. I have a few suggestions: 1) I think you have 1 GPSDO per USRP providing each a different reference. I would first try the experiment with a shared 10 MHz reference and PPS to all devices to confirm the algorithm. You will need to move the 10 MHz reference jumper back so you can provide an external ref via SMA. 2) When you use the GPSDO, make sure that each one reports locked. The gps_locked is available through the python interface as well: http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application 3) Its good to make sure that you are correctly setting the time. A quick check would be to read get_time_now() on all devices after setting the time on the next pps. You should be able to see that the time from each device is about the same, within an RTT. -josh > 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 >>> >>> >>> >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FPGA time
On 29 Aug 2012 15:13, Josh Blum wrote: > On 08/28/2012 03:24 PM, Anisha Gorur wrote: > >> 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 > > Can you tell me more about the correlation? Are you sending a impulse > split to all 3 devices and determining the pulse arrival. Is the error > in time of arrival consistent between runs or does it seem to be random? > > If you ask all N USRPs to stream at time X, the time reported in the > metadata will still be X, even if the internal tick count in each device > is not marching in lock step. > > I have a few suggestions: > > 1) I think you have 1 GPSDO per USRP providing each a different > reference. I would first try the experiment with a shared 10 MHz > reference and PPS to all devices to confirm the algorithm. You will need > to move the 10 MHz reference jumper back so you can provide an external > ref via SMA. I've observed, in a previous life, phase-hits between two GPSDOs connected to the same antenna, watching the same cluster of satellites. Never figured out why, which is why for phase-sensitive work, it makes sense to use a common reference, (like an external GPSDO), rather than a GPSDO-per-unit. ___ 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
Hi Tom, Thanks for your suggestion, my Kcachegrind works well now. But this method (explicitly call through python interpreter) doesn't work for Oprofile, I still can't find the session name "dial_tone" in the profiled data. BTW, if Kcachegrind works well with python application, why do you guys recommend Oprofile? Sincerely, -- Yang, Qing Information Engineering, CUHK 2012/8/28 Tom Rondeau > 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 l
