Re: [Discuss-gnuradio] Has anyone implemented your own module into real hardware?
I have no practical experience in this area but you may want to check out this approach (or similar): http://www.ettus.com/sdr-software/detail/rf-network-on-chip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Distinguish Data from Voice
I have been having problems reliably distinguishing an audio file containing human voice and on containing sound of data. Most of my attempts have been with looking for values produced by "sox stats" and "sox stat". For example, keying off Crest factor misses in some cases. As files are produced from a gnuradio based application that I can modify source code of so I would be interested in ways to do this with gnuradio as well.Any input would be appreciated. Thanks, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU RADIO on Ubuntu Server
I have run a python based gnuradio application on Odroid C2 and recently XU4. It will come done to what you are trying to do (amount of sample rate you require and what kind of processing you are doing). Also, I just recently heard about and used volk_profile. This helped me with performance. On 3/4/19 6:20 AM, mehtap özkan wrote: Dera All, I have an embedded arm board with limited storage (4 GB eMMC). I suspect Ubuntu+ GNU RADIO+Phyton will not fit on it. Does anybody have used GNU RADIO on Ubuntu Server or alternatively on a small footprint Linux Distor? I have created a .py file from an .grc file and it has no visual output. I want to run the .py file. ___ 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] 802.11b bbn error in gnuradio 3.6.2
bbn 802.11b is designed for gnuradio 3.1.1 but i am trying it run it in
gnuradio 3.6.2
i am getting the following error while running
bbn_80211b_tx.py/bbn_80211b_rx.py
Traceback (most recent call last): File "bbn_80211b_transmit_path.py", line
29, in from bbn_80211b_pkt import * File
"/home/snigdha/bbn_80211/src/examples/bbn_80211b_pkt.py", line 31, in from
gnuradio import bbn File
"/usr/local/lib/python2.7/dist-packages/gnuradio/bbn.py", line 24, in _bbn =
swig_import_helper() File
"/usr/local/lib/python2.7/dist-packages/gnuradio/bbn.py", line 20, in
swig_import_helper _mod = imp.load_module('_bbn', fp, pathname, description)
ImportError: /usr/local/lib/python2.7/dist-packages/gnuradio/_bbn.so:
undefined symbol: _ZN11omni_thread6init_tD1Ev
--
View this message in context:
http://gnuradio.4.n7.nabble.com/802-11b-bbn-error-in-gnuradio-3-6-2-tp39975.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] error while running the .cc files in gr-bluetooth
when i try running a .cc file of gr-bluetooth , i get certain errors that some .h files are not there and it results in fatal error... snigdha@ubuntu:~/gr-bluetooth/src/lib$ gcc bluetooth.cc bluetooth.cc:149:20: fatal error: Python.h: No such file or directory compilation terminated. when i run bluetooth.py, swig import error occurs and an import error occurs... snigdha@ubuntu:~/gr-bluetooth/src/lib$ python bluetooth python: can't open file 'bluetooth': [Errno 2] No such file or directory snigdha@ubuntu:~/gr-bluetooth/src/lib$ python bluetooth.py Traceback (most recent call last): File "bluetooth.py", line 24, in _bluetooth = swig_import_helper() File "bluetooth.py", line 16, in swig_import_helper import _bluetooth ImportError: No module named _bluetooth How do i resolve this error -- View this message in context: http://gnuradio.4.n7.nabble.com/error-while-running-the-cc-files-in-gr-bluetooth-tp40133.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] Porting Kalibrate tool
Just wondering if there is anyone here who would be willing to have a go at porting the kalibrate tool for use with the hackrf, I think this would be a great tool to have but my programming skills are not good enough to complete this myself. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error Compiling Multimon
I am running gnuradio 3.7.0 and been using grc with good results. When I try to make Multimon (recent trunk) I get the following errors: trunk # make /usr/local/bin/grcc -d . multimode.grc >>> Error: Block key "gr_complex_to_real" not found in Platform - grc(GNU Radio Companion) Traceback (most recent call last): File "/usr/local/bin/grcc", line 25, in from grc.python.Platform import Platform ImportError: No module named grc.python.Platform >>> Error: Block key "gr_keep_one_in_n" not found in Platform - grc(GNU Radio Companion) Traceback (most recent call last): File "/usr/local/bin/grcc", line 25, in from grc.python.Platform import Platform ImportError: No module named grc.python.Platform >>> Error: Block key "gr_feedforward_agc_cc" not found in Platform - grc(GNU Radio Companion) Traceback (most recent call last): File "/usr/local/bin/grcc", line 25, in from grc.python.Platform import Platform ImportError: No module named grc.python.Platform >>> Error: Block key "gr_keep_one_in_n" not found in Platform - grc(GNU Radio Companion) Traceback (most recent call last): File "/usr/local/bin/grcc", line 25, in from grc.python.Platform import Platform ImportError: No module named grc.python.Platform >>> Error: Block key "gr_keep_one_in_n" not found in Platform - grc(GNU Radio Companion) Traceback (most recent call last): File "/usr/local/bin/grcc", line 25, in from grc.python.Platform import Platform ImportError: No module named grc.python.Platform >>> Error: Block key "gr_fft_filter_xxx" not found in Platform - grc(GNU Radio Companion) Traceback (most recent call last): File "/usr/local/bin/grcc", line 25, in from grc.python.Platform import Platform ImportError: No module named grc.python.Platform [continuation of errors snipped] Any ideas as to how to address? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
On 09/11/13 20:02, Marcus D. Leech wrote: Multimode hasn't been converted to 3.7 yet. Thanks! I have heard good things about how it handles nbfm and wanted to compare it to what I have hacked together. I have been reviewing examples of nbfm demodulation and would appreciate any pointers to "ideal" approach in this area. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
On 09/11/13 20:14, Marcus D. Leech wrote: You can pull the .grc into gnuradio-companion, although that might not work out that well, since the block-names changed across 3.7. When I do this a large percentage of blocks/connectors do mot render. In a separate thread I can present what I have so far to get some input. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
On 09/12/13 08:41, Tom Rondeau wrote: [snip] There are a few ways you can go about fixing it. The easiest would be to have a version of 3.6.5.1 installed on your system. When you open up your .grc file, look for any block with "(old)" in the name. Those are blocks that will disappear in 3.7. You can just find the new version of that block (same name without the "(old)") and replace it. When you then open the newly saved grc file in 3.7, those blocks will still be there. [snip] I have gone down this path and see the references to those with "(old)" in the name. However, I also see some errors that need to be addressed (search has not yielded anything yet). A typical one manifests itself in something as simple as definition of samp_rate variable: Param - Value(value): Value "int(mh.get_good_rate(devinfo,srate))" cannot be evaluated: name 'mh' is not defined I cannot see where "mh" should be brought into the flow graph. There may be other errors bu this one appears pretty common on initial look. Thanks, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
On 09/13/13 22:21, John wrote: I have gone down this path and see the references to those with "(old)" in the name. However, I also see some errors that need to be addressed (search has not yielded anything yet). A typical one manifests itself in something as simple as definition of samp_rate variable: Param - Value(value): Value "int(mh.get_good_rate(devinfo,srate))" cannot be evaluated: name 'mh' is not defined I cannot see where "mh" should be brought into the flow graph. There may be other errors bu this one appears pretty common on initial look. This issue can be ignored. I was so focused on editing the file I ignored the part where I needed to set PYTHONPATH. After I followed the instructions in make install it worked. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
On 09/12/13 09:16, Marcus Leech wrote: And I`ll comment that if you *do* undertake that work, successfully, I`d be happy to fold the results into the SVN code for multimode. I am moving down the path but do not yet have something that is working. What I have done: - Reverted back to 3.6.5.1 and loaded flow graph. - Took screen shots of overall flow graph including details of blocks I knew were a problem. - Changed blocks with (old) in name to new block. - Loaded low graph into 3.7.0 - Had to set default for sc_list_str to 300 as there was error when default was block - Took a long break from working on this and came back to it probably forgetting important things. - The following blocks did not load into 3.7.0: osmocom source block and FM deemphasis. I had to add these back. - In 3.7 disabled the import firdes block as it threw and error and help file indicates it may not be needed. I have a temp repository on github for my changes: https://github.com/john-/multimode-tmp I will keep working through the errors I receive when executing the flow graph. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
Also note that I could not get Multimon to work in 3.6.5.1 prior to making changes in 3.7 (although it didn't work differently). On the premise that was issue with my install of that version I did not work through resolving those issues. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error Compiling Multimon
On 10/05/13 12:22, Marcus D. Leech wrote: You should work with asokna...@gmail.com who has also made an attempt to get it working under 3.7. I will do that. His attempt comes up, but "stalls" after a few seconds, and then just gets continuous "O". This is how it behaved for me under 3.6.5.1. Curiously enough, Andrew's port of simple_fm_rcv to 3.7 went swimmingly well. Not sure what's going on. Indeed that "import firdes" in the "helper" .py hasn't been necessary for a long time, and was just a bit of detritus. Thanks for confirmation. The osmocom sources changed across 3.6->3.7 boundary, so you have to re-instantiate in 3.7, and hopefully replicate what was in 3.6 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question over the Silder in GRC
It sounds like when you say "in between" you mean the period of time from when the user stop dragging the slider and the next time they stop dragging the slider. In general, when people ask this question the area of focus is the period of time when they are dragging the slider. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD on USRP1 (Karmic Ubuntu)
Dear All, I have downloaded the latest 3.3 version source and have
built/check/installed and it appears fine (yeah!) in that I created
gr-uhd and libuhd is created and I can run gnuradio-companion on my
USRP(1) and LFRX daughterboard.
A while ago I purchased a DBSRX2 so I am trying to shift my system to
UHD. I don't mind having the default UHD behaviour of 2 up/ 2 down which
I believe is the default FPGA etc.
I have gone into Gnuradio-comp and converted the USRP source to a UHD
one but it needs an IP address so I don't think that is how I convert
the USRP from being GNU to UHD.
I am positing to this hybrid board in the hope that someone can help me
navigate this change.
Kind Regards,
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD on USRP1 (Karmic Ubuntu)
On 12/25/2010 05:01 PM, john wrote: >> A while ago I purchased a DBSRX2 so I am trying to shift my system to >> UHD. I don't mind having the default UHD behaviour of 2 up/ 2 down which >> I believe is the default FPGA etc. >> >> I have gone into Gnuradio-comp and converted the USRP source to a UHD >> one but it needs an IP address so I don't think that is how I convert >> the USRP from being GNU to UHD. >> >USB based devices do not have IP addresses. See the docs in the block > properties. Also see > > http://www.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps >Also make sure that uhd_find_devices can find your device. >Peace Thanks very much Josh. Yes the device is found : Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done -- -- UHD Device 0 -- Device Address: type: usrp1 name: serial: 4c745353 Just to be crystal clear, A UHD implementation of a GNURadio-Companion file is the same as GNURadio i.e. source is USRP not UHD for USRP1? Also, when I populate with the DBSRX2 in addition to LFRX, can I run both? I saw a post from August saying something about only 1 i/o path at the moment. Hopefully, I will be smarter in 2011. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD on USRP1 (Karmic Ubuntu)
On Sun, 2010-12-26 at 01:02 -0800, Josh Blum wrote: > > Thanks very much Josh. Yes the device is found : > > > > Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done > > -- > > -- UHD Device 0 > > -- > > Device Address: > > type: usrp1 > > name: > > serial: 4c745353 > > > > Just to be crystal clear, A UHD implementation of a GNURadio-Companion file > > is the same as GNURadio i.e. source is USRP not UHD for USRP1? > > > > Use the blocks in the UHD category (not USRP). Also, the floating point > samples are between -1.0 and 1.0 which is different than the old driver, > so that could change things depending upon your app. Its best to run it > and see what happens. :-) > > > Also, when I populate with the DBSRX2 in addition to LFRX, can I run both? > > I saw a post from August saying something about only 1 i/o path at the > > moment. > > > > Both channels should work. Configure the single usrp block for two > channels and setup the subdevice specification string (should be docs > for this in the block properties dialog box). > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks very much Josh - now I understand, Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNURadio -> UHD transition LFRX (Ubuntu, Karmic) RESOLVED
On Tue, 2010-12-28 at 12:33 +1300, john wrote: > I have migrated to UHD and leaving the rest of the plumbing as is, I > have the attached USRP block which works but when I put the UHD block > attached, it does not without any error diagnostics. > > Sometimes the FFT scope works showing the peaks of local radio stations, > but I never get any audio. > > Anything obvious? I wonder if it is the type of the signal on UHD but > have no more than that hunch. > >Kind Regards, > > John > > p.s. I know that switching back and forth between UHD and USRP > sourced-GRC will likely cause f/w issues particularly for the latter (in > that UHD seems to load on the fly). After looking at the output level on the FFT on the UHD, I realised it was way too low compared to the USRP implementation. The final solution was to complex multiply the output of the UHD block by 75,000. Josh had mentioned the output level of UHD but it didn't twig that I would need a multiplier. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio -> UHD transition LFRX (Ubuntu, Karmic)
On Tue, 2010-12-28 at 00:56 +0100, Alexandru Csete wrote: > On Tue, Dec 28, 2010 at 12:33 AM, john wrote: > > I have migrated to UHD and leaving the rest of the plumbing as is, I > > have the attached USRP block which works but when I put the UHD block > > attached, it does not without any error diagnostics. > > > > Sometimes the FFT scope works showing the peaks of local radio stations, > > but I never get any audio. > > > > Anything obvious? I wonder if it is the type of the signal on UHD but > > have no more than that hunch. > > > > John, > > I suspect the signal strength is too low - I mean the magnitude of the > samples. > One significant difference between UHD and the old driver is the > numerical range of the samples. The old driver used signed integer > range with samples between +/- 16000 or so, while UHD uses +/- 1.0. In > practice I often see samples far below 0.1. For FM and PM it is no big > deal but for AM-type radio this is just too low because the dynamic > range of the soundcard is also +/- 1.0. You can use a scope sink > connected to the UHD source to see the range of the samples you are > getting and put in a "multiply with constant" block to increase the > signal to sufficient level. > > Alex > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks Alex, You are correct. I needed to put in a complex multiply constant of ~75,000 to get similar levels on FFT under UHD compared to USRP. Thanks again, Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LPDA orientation when receiving GPS signals on USRP2
On Thu, 2011-01-13 at 22:08 -0500, Nick Othieno wrote: > Hi everyone, > > Does anyone know what the orientation of an LPDA (log periodic dipole > antenna) should be when receiving GPS signals? > > Should the up-most element be the longest one, or should it be the > shortest one? In other words > > > > ___ > ___- > __ > > OR ___ >__ > > > > > > Nick > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >From ARRL Antenna Handbook (1988) the 'forward' direction is towards the smaller elements on an LPDA. Don't think that JCM equations have changed since '88. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd.tune_request_t & DBRSX[2]
I wonder if someone can help me? I have been trying to understand 'tuning' and I note that UHD has a couple of options for setting the centre frequency. The two methods: tune_request_t( target_freq ) method1 and tune_request_t( target freq, lo_off) when I try the former in GNURadio Companion for a source of UHD things work as I expect but when I decide to put in a lo_off I get strange results. uhd.tune_request_t(804.75*e6, 40*e6) and I have enabled the dbsrx2_debug flag to true to see how things are being driven and can see the following when I execute the GRC, it says: Target 844.75 and actual 844.75 which seems correct (i.e. what I think I asked for) but then I get: setting of regs x00 through x07 and then Warning: The hardware does not support the requested RX frequency Target 804.75 Actual: 868.75 but it receives the 804.75 signal (or thereabouts - tv audio so wideish bandwidth)! The s/w is calculating the correct integer and fractional values in N (ext_div of 4 (HMC426), scaler 4 (since freq < 1125Mhz ) etc. Some questions: 1) why is 844.75 not valid ? From the MAX2112 spec there are VASA/VASE signals which allow the chip to search/select VCOs but cannot see where these are set and assume that is the reason that 2) why is the utility talking about 868.75? 3) why, when it says actual is 868.75, is the system receiving signals on 804.75? 4) if you can direct the tuner to a specific frequency with method1 , why would you consider having the option to specify an lo_offset? would it allow an IF to be generated (e.g. 10.7 MHz)? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Run problems with latest UHD build
Ubuntu 10.4 I (intended) to pull over the latest GIT and did the usual procedure which has worked before i.e. cmake ../ make make test sudo make install however, when I run the GNURadio Companion as before, I now get: Traceback (most recent call last): File "/home/john/lsb_tx_bpf.py", line 14, in from gnuradio import uhd File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line 27, in from uhd_swig import * File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 6, in import _uhd_swig ImportError: /usr/local/lib/python2.6/dist-packages/gnuradio/uhd/_uhd_swig.so: undefined symbol: _ZNK3uhd12meta_range_tIfE4clipERKfb I am sure that the error is all mine but would appreciate someone pointing out where I am going wrong? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Run problems with latest UHD build
On Sun, 2011-01-23 at 11:43 +0100, Alexandru Csete wrote: > On Sun, Jan 23, 2011 at 8:11 AM, john wrote: > > Ubuntu 10.4 > > > > > > I (intended) to pull over the latest GIT and did the usual procedure > > which has worked before i.e. > > > > cmake ../ > > make > > make test > > sudo make install > > > > however, when I run the GNURadio Companion as before, I now get: > > > > Traceback (most recent call last): > > File "/home/john/lsb_tx_bpf.py", line 14, in > >from gnuradio import uhd > > File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line > > 27, in > >from uhd_swig import * > > File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line > > 6, in > >import _uhd_swig > > ImportError: > > /usr/local/lib/python2.6/dist-packages/gnuradio/uhd/_uhd_swig.so: undefined > > symbol: _ZNK3uhd12meta_range_tIfE4clipERKfb > > > > I am sure that the error is all mine but would appreciate someone > > pointing out where I am going wrong? > > > > Hi John, > > There have been some API changes in the latest UHD announcement so you > have to rebuild GNU Radio with the new UHD libs (make clean, make, > sudo make install). > > Alex Thanks Alex for the pointer. I have recreated UHD and find_devices works. When I try GNURadio rebuild, after a lot of (seemingly) successful operations, I get: make[4]: Entering directory `/home/john/gnuradio/gr-uhd/swig' /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I/home/john/gnuradio/gnuradio-core/src/lib/runtime -I/home/john/gnuradio/gnuradio-core/src/lib/general -I/home/john/gnuradio/gnuradio-core/src/lib/general -I/home/john/gnuradio/gnuradio-core/src/lib/gengen -I/home/john/gnuradio/gnuradio-core/src/lib/gengen -I/home/john/gnuradio/gnuradio-core/src/lib/filter -I/home/john/gnuradio/gnuradio-core/src/lib/filter -I/home/john/gnuradio/gnuradio-core/src/lib/missing -I/home/john/gnuradio/gnuradio-core/src/lib/reed-solomon -I/home/john/gnuradio/gnuradio-core/src/lib/viterbi -I/home/john/gnuradio/gnuradio-core/src/lib/io -I/home/john/gnuradio/gnuradio-core/src/lib/g72x -I/home/john/gnuradio/gnuradio-core/src/lib/swig -I/home/john/gnuradio/gnuradio-core/src/lib/hier -I/home/john/gnuradio/gnuradio-core/src/lib/swig -I/home/john/gnuradio/gruel/src/include -I/home/john/gnuradio/gruel/src/include -I/home/john/gnuradio/volk/include -I/usr/include -I/usr/include/python2.6 -I/usr/local/include -I/home/john/gnuradio/gr-uhd/lib -g -O1 -Wno-strict-aliasing -Wno-parentheses -pthread -MT _uhd_swig_la-uhd_swig.lo -MD -MP -MF .deps/_uhd_swig_la-uhd_swig.Tpo -c -o _uhd_swig_la-uhd_swig.lo `test -f 'uhd_swig.cc' || echo './'`uhd_swig.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I/home/john/gnuradio/gnuradio-core/src/lib/runtime -I/home/john/gnuradio/gnuradio-core/src/lib/general -I/home/john/gnuradio/gnuradio-core/src/lib/general -I/home/john/gnuradio/gnuradio-core/src/lib/gengen -I/home/john/gnuradio/gnuradio-core/src/lib/gengen -I/home/john/gnuradio/gnuradio-core/src/lib/filter -I/home/john/gnuradio/gnuradio-core/src/lib/filter -I/home/john/gnuradio/gnuradio-core/src/lib/missing -I/home/john/gnuradio/gnuradio-core/src/lib/reed-solomon -I/home/john/gnuradio/gnuradio-core/src/lib/viterbi -I/home/john/gnuradio/gnuradio-core/src/lib/io -I/home/john/gnuradio/gnuradio-core/src/lib/g72x -I/home/john/gnuradio/gnuradio-core/src/lib/swig -I/home/john/gnuradio/gnuradio-core/src/lib/hier -I/home/john/gnuradio/gnuradio-core/src/lib/swig -I/home/john/gnuradio/gruel/src/include -I/home/john/gnuradio/gruel/src/include -I/home/john/gnuradio/volk/include -I/usr/include -I/usr/include/python2.6 -I/usr/local/include -I/home/john/gnuradio/gr-uhd/lib -g -O1 -Wno-strict-aliasing -Wno-parentheses -pthread -MT _uhd_swig_la-uhd_swig.lo -MD -MP -MF .deps/_uhd_swig_la-uhd_swig.Tpo -c uhd_swig.cc -fPIC -DPIC -o .libs/_uhd_swig_la-uhd_swig.o uhd_swig.cc:4278: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4286: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4286: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4294: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4297: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4300: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4300: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4303: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4303: error: ‘uhd::range_t’ is not a template uhd_swig.cc: In function ‘uhd::range_t std_vector_Sl_uhd_range_t_Sl_float_Sg__Sg__pop(std::vector >*)’: uhd_swig.cc:4306: error: ‘uhd::range_t’ is not a template uhd_swig.cc:4306: error: ‘uhd::range_t’ is not a template uhd_swig.cc: At global scope: uhd_swig.cc:4310: error: ‘uhd::range_t’ is
Re: [Discuss-gnuradio] Run problems with latest UHD build
On Sun, 2011-01-23 at 14:54 -0800, Josh Blum wrote: > > uhd_swig.cc:4333: error: ‘uhd::range_t’ is not a template > > thats true, its not, but it was... so something is out of date > > > uhd_swig.cc:4333: error: redefinition of ‘struct > > swig::traits’ > > uhd_swig.cc:4278: error: previous definition of ‘struct > > swig::traits’ > > > > Do you have any further advice, Alex? > > > > Does your uhd_swig.i look like this one: > http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/swig/uhd_swig.i?h=next > > I think you may not have the most recent next branch? > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Yes, Josh, you are correct. Will pull the next branch from gnuradio and give it a try. Thanks for your assistance, Slainte, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Recent Changes to UHD causing issue for USRP1?
Dear All, I am running Ubuntu 10.04 LTS on two systems using Marcus' script to load/install UHD nad the latest GNURadio. On the first system on Sat 16th of April, I ran his script and it worked well in the GR_Companion works etc. and using UHD_find_devices as a diagnostic tool, I get the following: john@john-laptop:~$ uhd_find_devices linux; GNU C++ version 4.4.3; Boost_104000;UHD_003.000.001-98a05d8 Loading firmware image: /usr/local/share/uhd/images/usrp1_fw.ihx... done -- -- UHD Device 0 -- Device Address: type: usrp1 name: serial: 4c745353 john@john-laptop:~$ uhd_usrp_probe linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-98a05d8 Loading FPGA image: /usr/local/share/uhd/images/usrp1_fpga.rbf... done _ / | Device: usrp1 device | _ |/ | | Mboard: usrp1 mboard - 4c745353 | | serial: 4c745353 | | _ | |/ | | | RX DSP: usrp1 ddc0 + hb | | | Codec Rate: 64.00 Msps | | _ | |/ | | | RX DSP: usrp1 ddc1 + hb | | | Codec Rate: 64.00 Msps | | _ | |/ | | | TX DSP: usrp1 duc0 | | | Codec Rate: 128.00 Msps | | _ | |/ | | | TX DSP: usrp1 duc1 | | | Codec Rate: 128.00 Msps | | _ | |/ | | | RX Dboard: usrp1 dboard (rx unit) - A | | | _ | | |/ | | | | RX Subdev: DBSRX2 (0x0012) | | | | Antennas: J3 | | | | Freq range: 800.000 to 2400.000 Mhz | | | | Gain range GC1: 0.0 to 73.0 step 0.1 dB | | | | Gain range BBG: 0.0 to 15.0 step 1.0 dB | | | | Connection Type: c | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: usrp1 adc - ad9862 - slot A | | | | Gain range PGA: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | RX Dboard: usrp1 dboard (rx unit) - B | | | _ | | |/ | | | | RX Subdev: Unknown - Unknown (0x) | | | | Antennas: | | | | Freq range: 0.000 to 0.000 Mhz | | | | Gain Elements: None | | | | Connection Type: C | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: usrp1 adc - ad9862 - slot B | | | | Gain range PGA: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | TX Dboard: usrp1 dboard (tx unit) - A | | | _ | | |/ | | | | TX Subdev: Unknown - Unknown (0x) | | | | Antennas: | | | | Freq range: 0.000 to 0.000 Mhz | | | | Gain Elements: None | | | | Connection Type: C | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: usrp1 dac - ad9862 - slot A | | | | Gain range PGA: -20.0 to 0.0 step 0.1 dB | | _ | |/ | | | TX Dboard: usrp1 dboard (tx unit) - B | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - AB | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: C | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - BA | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: c | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - A | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: R | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - B | | | | Antennas: | | | | Freq range: -32.000 to 32.00
Re: [Discuss-gnuradio] Recent Changes to UHD causing issue for USRP1?
On Sun, 2011-04-24 at 08:36 -0400, Marcus D. Leech wrote: > On 04/24/2011 02:47 AM, john wrote: > > wget -nd -r -np > > http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/ > > > >> /dev/null 2>&1 > >> > > does not work. I just navigated to the image files in binaries for > > release 003.000.001 - 2011/04/01 > > > > i.e UHD-images-003.000.001.tar.gz so I think that is not necessarily > > the issue. > > > > Since find_devices is such a primitive command, I suspect it might be a > > f/w incompatability but don't know how to progress. > > > Well, it looks like Josh re-organized the directory tree of where UHD > fpga/firmware images are > kept, so my script can no longer find the relevant files. Arrrg. > > You should confirm that you have a /usr/local/share/uhd/images > directory, and it looks roughly like so: > > -rw-r--r--. 1 root root 183046 2011-04-05 00:02 usrp1_fpga_4rx.rbf > -rw-r--r--. 1 root root 181588 2011-04-05 00:02 usrp1_fpga.rbf > -rw-r--r--. 1 root root 18552 2011-04-05 00:02 usrp1_fw.ihx > -rw-r--r--. 1 root root 862544 2011-04-05 00:02 usrp2_fpga.bin > -rw-r--r--. 1 root root 16383 2011-04-05 00:02 usrp2_fw.bin > -rw-r--r--. 1 root root 873980 2011-04-05 00:02 usrp_e100_fpga.bin > -rw-r--r--. 1 root root 75056 2011-04-05 00:02 usrp_e100_pt_fpga.bin > -rw-r--r--. 1 root root 1268576 2011-04-05 00:02 usrp_n210_fpga.bin > -rw-r--r--. 1 root root 16383 2011-04-05 00:02 usrp_n2xx_fw.bin > > > > > Thanks Marcus, I have: john@johnsdesktop:/usr/local/share/uhd/images$ ls -l total 4336 -rw-r--r-- 1 root root 17396 2011-04-22 18:53 22_april_usrp1_fw.ihx -rw-r--r-- 1 root root 183046 2011-04-22 20:07 usrp1_fpga_4rx.rbf -rw-r--r-- 1 root root 181588 2011-04-22 20:07 usrp1_fpga.rbf -rw-r--r-- 1 root root 17396 2011-04-22 20:07 usrp1_fw.ihx -rw-r--r-- 1 root root 862544 2011-04-22 20:07 usrp2_fpga.bin -rw-r--r-- 1 root root 16383 2011-04-22 20:07 usrp2_fw.bin -rw-r--r-- 1 root root 873980 2011-04-22 20:07 usrp_e100_fpga.bin -rw-r--r-- 1 root root 75056 2011-04-22 20:07 usrp_e100_pt_fpga.bin -rw-r--r-- 1 root root 892820 2011-04-22 20:07 usrp_n200_fpga.bin -rw-r--r-- 1 root root 16383 2011-04-22 20:07 usrp_n200_fw.bin -rw-r--r-- 1 root root 1268576 2011-04-22 20:07 usrp_n210_fpga.bin -rw-r--r-- 1 root root 16383 2011-04-22 20:07 usrp_n210_fw.bin I will look into Josh's suggestion that I did not build with USB and USRP1 support. Thanks, Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent Changes to UHD causing issue for USRP1?
On Sun, 2011-04-24 at 09:28 -0700, Josh Blum wrote: > > > > john@johnsdesktop:~$ uhd_find_devices > > linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-8212f22 > > > > No UHD Devices Found > > john@johnsdesktop:~$ > > > > Looks like you didnt build w/ USB and USRP1 support? > > -Josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks for your response Josh. I have rebuilt with Marcus' latest script and get the following: john@johnsdesktop:~$ uhd_find_devices linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-627075e -- -- UHD Device 0 -- Device Address: type: usrp1 name: serial: ( as an aside, I think I would have gotten this the last time if I had allowed the USRP unit a bit of time to load itself after powering on). It finds/defaults to usrp1 (which IS the unit) but does not return the serial number (4c745353) so perhaps it is not really detecting anything? when I check if USRP is 'being recognised' I get: john@johnsdesktop:~$ ls -lR /dev/bus/usb | grep usrp crw-rw 1 root usrp 189, 138 2011-04-25 15:23 011 A bit of a head-scratcher, Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent Changes to UHD causing issue for USRP1?
On Sun, 2011-04-24 at 20:57 -0700, Josh Blum wrote: > > john@johnsdesktop:~$ uhd_find_devices > > linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-627075e > > > > -- > > -- UHD Device 0 > > -- > > Device Address: > > type: usrp1 > > name: > > serial: > > > > > > ( as an aside, I think I would have gotten this the last time if I had > > allowed the USRP unit a bit of time to load itself after powering on). > > > > It finds/defaults to usrp1 (which IS the unit) but does not return the > > serial number (4c745353) so perhaps it is not really detecting anything? > > > > Its reading the serial directly from eeprom as an ascii string. If the > first character wasnt valid ASCII, then it would just return with a > blank string. I wouldnt worry about it, your USRP seems to be working > just fine. > > -josh Thanks Josh but the issue is that on one UBUNTU 10.04 system I get the serial number returned by uhd_find_devices and GnuRadioCompanion works and on the other, I don't get a serial number on uhd_find_devices and GRC complains with: linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-627075e >>> gr_fir_ccc: using 3DNow!Ext Loading firmware image: /home/john/usrp1_fw.ihx... done Traceback (most recent call last): File "/home/john/fm_rx.py", line 502, in tb = fm_rx() File "/home/john/fm_rx.py", line 269, in __init__ num_channels=1, File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py", line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 1656, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs) RuntimeError: LookupError: KeyError: No devices found for -> Device Address: serial: 4c745353 I am 'feeding' in the serial number on the UHD: USRP source block. I was trying to use uhd_find_devices as the diagnostic tool. I should repeat that on the 'good' environment, the probe indentifies USRP DBs correctly. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recent Changes to UHD causing issue for USRP1?
On Mon, 2011-04-25 at 18:18 -0700, Josh Blum wrote: > > Device Address: > > serial: 4c745353 > > > > I am 'feeding' in the serial number on the UHD: USRP source block. > > > > I was trying to use uhd_find_devices as the diagnostic tool. > > > > I should repeat that on the 'good' environment, the probe indentifies > > USRP DBs correctly. > > > > So to recap: > > * The UHD cannot read the eeprom on USRP1 on your older machine: No > dboard IDs no mboard serial number. > > * But same USRP1 works perfectly fine on another computer. > > * However, the libgnuradio-usrp driver can read the eeprom perfectly > fine on both computers. > > So, the firmware is actually doing the I2C transactions. The reads from > a host perspective are just libusb control transactions. One thing that > comes to mind, what libusb are you running? libgnuradio-usrp uses > libusb0.1, but UHD is exclusively libusb1.0. Perhaps you have old buggy > libusb1.0 implementation on your older machine? Something along those > lines... > > My best guess, > -Josh Great diagnosis, Josh! Synaptic tells me that I have libusb-0.1-4, libusb-1.0-0 and their dev components. I have been here before, I think, and when I try to uninstall the 0.1 variant, it removes 'the world'. The last time I didn't check on what was being removed so had to reinstall OS and everything from the ground up. Is there a smarter way to remove the pesky 0.1 s? Thanks again for solving the mystery, Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_multi moved?
Ubuntu 10.04 LTS. GNURadio and UHD built current within 1 week. Used
Marcus' script.
Trying to run the multi_usrp_oscope.py and after changing
from import stdgui, fftsink etc. => import stdgui2, fftsink2,
and changing to std_top_block
I get the following:
john@john-laptop:~$ python multi_usrp_oscope.py
Traceback (most recent call last):
File "multi_usrp_oscope.py", line 35, in
from gnuradio import usrp_multi
ImportError: cannot import name usrp_multi
Can anyone help me track it down?
Kind Regards,
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi_usrp
Have USRP1 on Ububtu 10.04 and have latest UHD (003.002.000) and latest GNURadio ( v3.4.0-113). While some of the daughterboards are supported on GNURadio, the later ones I have need UHD and Marcus has been championing the move to UHD. >From the doxygen I see that: uhd::usrp::multi_usrp is quite a useful class (and I think one of the gurus has touted it's benefits) and can be used for single as well as multiple USRPs but am struggling to find UHD USRP1 examples which use this class from Python. There is multi_usrp_oscope and it's cfile twin but they don't (need to) do much with tx and rx daughter-cards which have more agility in USRP1. Is anyone aware of such examples? I am making the bold assumption that the plumbing (SWIG) is in place for this class? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_usrp
On Sat, 2011-07-30 at 09:29 -0400, Marcus D. Leech wrote: > On 07/30/2011 02:53 AM, john wrote: > > Have USRP1 on Ububtu 10.04 and have latest UHD (003.002.000) and latest > > GNURadio ( v3.4.0-113). > > > > While some of the daughterboards are supported on GNURadio, the later > > ones I have need UHD and Marcus has been championing the move to UHD. > > > > > From the doxygen I see that: uhd::usrp::multi_usrp > > is quite a useful class (and I think one of the gurus has touted it's > > benefits) and can be used for single as well as multiple USRPs but am > > struggling to find UHD USRP1 examples which use this class from Python. > > There is multi_usrp_oscope and it's cfile twin but they don't (need to) > > do much with tx and rx daughter-cards which have more agility in USRP1. > > > > Is anyone aware of such examples? > > > > I am making the bold assumption that the plumbing (SWIG) is in place for > > this class? > > > > Kind Regards, > > > > John > > > > > > ___ > > > The best way I've found is to use GRC to lay out a prototypical > flow-graph, and then look at the Python generated. > > There just aren't a lot of UHD examples out there, unfortunately. There > may be some stuff up on CGRAN, but using >GRC as an "example generator" I've found to be quite instructive and > useful. > > > > Thanks Marcus. Yes, that technique is quite useful - particularly in setting up channels, addressing etc. however, in terms of giving the board ID of the RX/TX on either 'side' of a USRP1 it is not so great. Yes, you can readily get frequency range/antenna/gain but I need a bit more. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_usrp
On Sun, 2011-07-31 at 18:30 -0400, Marcus D. Leech wrote: > On 07/31/2011 11:14 AM, john wrote: > > O > > Thanks Marcus. Yes, that technique is quite useful - particularly in > > setting up channels, addressing etc. however, in terms of giving the > > board ID of the RX/TX on either 'side' of a USRP1 it is not so great. > > Yes, you can readily get frequency range/antenna/gain but I need a bit > > more. > > > > Kind Regards, > > > > John > > > > > I'm not fully understanding what it is you need. You need to *fetch* > the board ID from the >interface, rather than setting the subdev specifications? > You are correct Marcus in terms of what I want to do. From reading the comments in the code, I thought that I was to use set_subdev for the channel(s) and then could both set/get relevant parameters ( freq range, gain etc. ) i.e. attributes which use channelid as parameter. ( I think that is how it was described). I wish to get mboard type and rx and tx dboard types for USRP1 but using UHD as the dboards are only supported under that paradigm when they were announced. Sorry if I am passing on my confusion, Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_usrp
On Mon, 2011-08-01 at 13:20 -0400, Marcus D. Leech wrote: > On 08/01/2011 03:30 AM, john wrote: > > On Sun, 2011-07-31 at 18:30 -0400, Marcus D. Leech wrote: > >> On 07/31/2011 11:14 AM, john wrote: > >>> O > >>> Thanks Marcus. Yes, that technique is quite useful - particularly in > >>> setting up channels, addressing etc. however, in terms of giving the > >>> board ID of the RX/TX on either 'side' of a USRP1 it is not so great. > >>> Yes, you can readily get frequency range/antenna/gain but I need a bit > >>> more. > >>> > >>>Kind Regards, > >>> > >>>John > >>> > >>> > >> I'm not fully understanding what it is you need. You need to *fetch* > >> the board ID from the > >> interface, rather than setting the subdev specifications? > >> > > You are correct Marcus in terms of what I want to do. From reading the > > comments in the code, I thought that I was to use set_subdev for the > > channel(s) and then could both set/get relevant parameters ( freq range, > > gain etc. ) i.e. attributes which use channelid as parameter. ( I think > > that is how it was described). > > > > I wish to get mboard type and rx and tx dboard types for USRP1 but using > > UHD as the dboards are only supported under that paradigm when they were > > announced. > > > > Sorry if I am passing on my confusion, > > > > Kind Regards, > > > > John > > > > > > > > > > > I think that if you look at the current UHD Doxygen, you'll find that > there are functions to do what you want. Starting with a "usrp" object, >you need to indirect a couple of times, but you can get the board ids > with UHD functions. > > Thanks, again, Marcus. I had looked at the usrp_ra_receiver in gr-radio-astronomy and saw getting DB_ID but in my ignorance, when I was told that SBX or DBSRX2 were only supported under UHD, I thought that I could/should not use USRP methods; I had assumed that the two personalities used their own firmware and I would need to tell the system to use USRP personality and go out and query boards etc. (maybe even non-UHD only boards) and then delete that instance and create one in UHD which do the real work under UHD. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Booting a new USRP
I have a USRP that seems to be working, though I haven't been able to really make it do any work yet. I've created a wiki page, http://comsec.com/wiki?UsrpInstall . I'm trying to integrate the suggestions that have floated past on the mailing list, for how to unpack and check out and use a USRP when it arrives. You said: > usrp_siggen.py is a siggen with no gui. > usrp_fft.py plots the FFT of whatever's connected to the input. > > $ usrp_siggen.py --help > $ usrp_fft.py --help ./usrp_fft.py --help doesn't produce help. It produces: usrp: found usrp rev2 Traceback (most recent call last): File "./usrp_fft.py", line 27, in ? from gnuradio.wxgui import stdgui, fftsink File "/usr/local/lib/python2.3/site-packages/gnuradio/wxgui/fftsink.py", line 89, in ? EVT_DATA_EVENT = wx.PyEventBinder (myDATA_EVENT, 0) AttributeError: 'module' object has no attribute 'PyEventBinder' So, there's a bug in that it doesn't diagnose arguments that it doesn't recognize. (Nor have a help message.) I don't understand why it failed, either. Did I fail to install some Python events package in the system? The wxpython doc for PyEventBinder is totally useless, just like all object-oriented class documentation (including gnuradio's). It says things like "Bind (self, target, ...). Bind this set of event types to target", without explaining what an event type is, what a target is, or why or when you might want to do that. But it does mention some random stuff about "backward compatability with the old EVT_* functions". Is our code perhaps using an obsolete interface that maybe doesn't work in my version of wxPython? http://www.wxpython.org/docs/api/wx.PyEventBinder-class.html (I think wxPython is not really a package name, it's really called libwxgtk2* or something like that. If so, I have version 2.4.2.6 and version 2.5.3.2 installed here. I think it picks among those with the setting in /usr/lib/python2.3/site-packages/wx.pth which is currently set to: "wx-2.5.3-gtk2-unicode". There's a whole mess of stuff under that directory, including both "wx" and "wxPython" subdirs.) John PS: I wasn't able to run the super automated install, for various reasons. I don't like sudo or root installs, so I added myself to the staff group, which can write to /usr/local. But every attempted sudo in the script failed, so I ended up going into the directories and running ../buildit by hand, then running "make install". AND -- I couldn't build mc4020 since I don't have matching kernel source until I figure out how to generate it in Debian. So it was a bit more manual than it's supposed to be, and maybe I didn't do something, which may have caused the error above. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio interface cleanup
The gnuradio packages have funny ideas about what users will need to specify and how they need to specify them. These ideas probably came from implementing the guts of GNU Radio and the USRP, but they don't really make sense to people who haven't implemented the guts. For example, the programs we've been told to run to check out our USRPs don't take any arguments in samples per second, or megasamples per second, or bytes per second, or megabytes per second. No, that would be too easy! Instead they take an argument which is the "interpolation rate", i.e. the reciprocal of the fraction of 128 megasamples per second that we want to send. Except when it's the reciprocal of the fraction of 64 megasamples per second that we want to receive. Clear as mud, and oh so portable to other hardware, too! The very first thing I'd want to specify to a signal generator (or to any other processing chain that has an output signal, like a transmitter) is what output port or device the signal should be fed to. There doesn't seem to be any way to specify that, in the programs I've encountered so far. E.g. in gnuradio-examples/usrp/siggen.py. Oh, and which connector on which "Basic TX" board (on which USRP, if I have more than one) does it output to "by default", even if I can't change the default? It's not documented and it's not obvious. The programs also seem tied to particular input or output devices. E.g. you can't use that signal generator to output to a sound card. Why not? There's a "dial tone" signal generator that's perfectly capable of making output to the sound card -- but I bet it can't output to the USRP. I also suspect that if I was able to tell it "continuously produce a 500Hz sine wave on the TX_A port of the TXA board", and left that running in the background, or in one window, that the software would be totally unable to simultaneously let me run another command like "produce a 75 kHz square wave on the TX_A port of the TXB board for three seconds". Unless I wrote my own custom program for doing both simultaneously in the same process. This will make it hard to access more than one radio at once: even though the USRP has eight high speed ports, you probably can't use more than one input port and one output port simultaneously, without doing custom programming. The library routines called by high level code aren't silent -- they spit things out to stdout or stderr, like "usrp: found usrp rev2", or "uU". Libraries should generally be seen and not heard. The high level Python code generally runs its "main loop" while also awaiting keyboard input with a prompt "Press Enter to quit". It might have been more fun if it said, "Press Enter to Exit". But it would be even better if it obeyed the standard interfaces, i.e. if it's a GUI program, it quits when you close its window; if it's a terminal-based program that isn't reading its input from the keyboard, it stops when you interrupt it with the INTR character, generally Ctrl-C. (When I've tried that, it currently spits out lines of ugly debugging information about where in the Python code I've interrupted it -- and probably doesn't clean up on its way out.) I hope we can knock some of these rough edges off the programming interfaces quickly -- before too much code has these assumptions embedded in it, and before too many users have to learn how to code around these assumptions. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Booting a new USRP
> There's a second problem caused by > > from gnuradio import usrp > > in the python code. This import probes the USB trying to figure out > what kind of a usrp is out there. If there's no USRP it fails. > I should probably just back out the check for the old usrp0's. The > 1's and 2's have the same high level interface. In general I wonder -- is it the practice in Python to have "includes" run off and do things that could cause errors? I'm used to more static languages where if you import a library, it just lays there until you call it. :-) That way, you can parse your arguments and produce your error messages, and maybe never even call that included package, depending on the options you were passed. If Python libraries tend to make trouble when they get imported, maybe we should be importing them in mid-run, only when we need to, rather than before doing anything else in the program. If it was my code, I'd have it run around and look at USB buses the first time somebody tried to open a USRP -- not before. But I'm a newbie to Python. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cognitive Radio on agenda for FCC's meeting in March
This msg is about "Cognitive" radios, not just software-defined radios. Cognitive radios make major adjustments in their transmission and reception behavior, based on observing the local radio environment. Cornell makes some good points. There are small areas of the spectrum where NOBODY can transmit, so that passive receivers such as radiotelescopes can receive. I've been advocating for defining a simple scheme for "posting" frequency bands with machine-readable signs (like the "No Hunting" signs found on trees and fences). It would have to be simple enough that every cognitive radio transmitter could implement it, listening to learn the rules of the neighborhood before transmitting. The radio astronomers could "fence off" their frequencies and physical locations by occasionally transmitting these "No Trespassing" signs on a nearby coordinating frequency. Anyone interested? John Date: Tue, 22 Feb 2005 08:03:02 -0800 From: Seth David Schoen <[EMAIL PROTECTED]> To: John Gilmore <[EMAIL PROTECTED]> John Gilmore writes: > [Have we talked recently to folks at FCC about this? Let's check in and > see what we can learn. ... This is presumably going to be a rule in ET Docket 03-108. There's some continuing ex parte activity there. Here's a reply comment critical of us and PK from the radio astronomers at Cornell. http://gullfoss2.fcc.gov/prod/ecfs/retrieve.cgi?native_or_pdf=pdf&id_document=6516210510 -- Seth Schoen Staff Technologist[EMAIL PROTECTED] Electronic Frontier Foundationhttp://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Need Help w/ install on FC3
Hello All, I need your help. I'm a nube to Linux and have been trying for two weeks to get the radio core installed. FC3 installs Python in /usr/lib/... instead of /usr/local/lib. I've tried installing a version in /usr/local/.. but the RPM manager didn't like that so I removed the default version and that wrecked the system. Anyway, I've recovered from that, but still can't get the core installed. I've set PYTHONPATH=/usr/lib/python2.3/site-packages. Now the build can't find python include. See attached file. My interests are to use GNURadio to eliminate/reduce interference to SSB narrowband signals from DSB AM. I'd also like to correlate adjacent channel signals with in-channel interference and eliminate it. I purchased David Carr's hardware(SSRP) to do this and I'm anxious to get started. Another application suited for the USRP is to connected three receive channels to three orthangonal HF dipoles to calculate/display realtime polarization on the Poincare Sphere. Looking forward to contributing. Please help. John Mark set Loading view...done [EMAIL PROTECTED] gr-build]$ sudo -v [EMAIL PROTECTED] gr-build]$ ./for-all-dirs ../buildit 2>&1 | tee make.log >>> /home/john/gr-build/gnuradio-core configure.ac: installing `./install-sh' configure.ac: installing `./missing' src/gen_interpolator_taps/Makefile.am: installing `./depcomp' src/lib/swig/Makefile.am:50: installing `./py-compile' configure.ac:24: required file `config.h.in' not found checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for AIX... no checking for library containing strerror... none required checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking whether C++ has bool... yes checking whether C++ has buggy scoping in for-loops... no checking whether user wants assertions... yes checking whether C++ has std::isnan... no checking whether user wants warnings... yes checking whether gcc accepts -Wall... yes checking whether g++ accepts -Wall... yes checking whether g++ accepts -Woverloaded-virtual... yes checking whether user wants gprof... no checking whether user wants prof... no checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking for a sed that does not truncate output... /bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes chec
Re: [Discuss-gnuradio] signals/atsc question
> I've been mulling over thinking about considering trying to rewrite the > old atsc stuff over to the new architecture; it doesn't actually look > that hard... maybe a day's work or so. Hey, great! I was thinking of doing it too, but it would take me awhile to get to it. > However before doing that, I > wanted to see that code work, since I don't want to port non-working > code... so I've been capturing signals with a USRP board. > The old code expects the signals to be in either 20MS/s shorts or in > 21.52MS/s shorts ... The old code re-samples the signals pretty early in the pipeline, once it figures out where each symbol is. It should be possible to adapt the old code to handle input at various rates, without much trouble. That's easier than resampling in the new code. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] signals/atsc question
problems with the
> signal (maybe an occasional glitch).
The pcHDTV card uses a chip that's specialized and engineered to do
this job very well in a variety of environments. By contrast, you are
only about the fourth person to ever run the ATSC input code. It's a
"dancing bear", which took more than a year of solid engineering just
to get it dancing at all. It hasn't been optimized, either for CPU
usage or for non-perfect signal reception.
When I reproduced HDTV reception, I had a little script called
"point", which loops digitizing 8M samples (less than 1/2 sec) to
disk, and then running the receiver on them. On my 2002 Athlon MP,
the loop ran every 20 seconds or so (we'd use fewer samples, which
would make it faster, but I think you need that many for the
equalizer). If the receiver doesn't like the signal, then you change
something -- the AGC, the antenna direction, the HDTV station you're
tuning into, the phase of the moon, etc. The receiver code was quite
finicky -- and my antenna looks at SF's Sutro Tower thru less than a
mile of clear air, where at least a dozen HDTV stations transmit.
Lather, rinse, and repeat until you are capturing signals that the
code likes to decode. THEN stop the script and capture a longer
period of time to disk. Then, run the decoder on that longer signal.
I'll attach my favorite point script below. I thought it was in the
source trees, but now I can't find it except on my hard drive.
Note that your disk will need to be able to keep up with your sample
rate. At 20 Msamples x 2 bytes/sample we used Linux's "LVM" (logical
volume manager) support to stripe a pair of partitions (on different
IDE buses) to handle writing at 40 Mbytes/sec. If you can't do that,
you'll need to buffer it all in RAM and write it out at the end. RAM is
cheap, and a gigabyte will store 25 seconds of samples.
Also note that our southbridge had a bug in which pushing a lot of
disk traffic would starve the PCI bus for cycles, disrupting the
signal capture's DMA. We ended up moving the disks onto a PCI IDE
disk controller, rather than using the motherboard IDE controller. YMMV.
John
#!/usr/bin/env python
# -*- python -*-
#
# Copyright 2002 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., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#
import os, os.path, math, sys, getopt, string
# set srcdir to the directory that contains Makefile.am
try:
srcdir = os.environ['srcdir']
except KeyError, e:
srcdir = "."
srcdir = srcdir + '/'
def system_chk (cmd):
r = os.system (cmd)
if (r != 0):
print "FAILED (%d): %s" % (r >> 8, cmd)
if ((r & 0xff) == 127) : # killed by signal (i.e. interrupt)
sys.exit (127)
return 0
if ((r & 0xff) != 0) : # killed by signal
sys.exit (127)
else :
sys.exit (r >> 8)
return 0
dir="/mnt/acquire/d"
use_eq = 1
i = 0+int(sys.argv[1])
while 1:
i=i+1
if use_eq:
print "S!",
sys.stdout.flush()
system_chk ("mc4020-read-adc -b -c 800 --ch3 --1v >%s/test%d.dat" %
(dir,i))
print "->D ",
sys.stdout.flush()
os.system("sync")
print "\r%d: " % i,
sys.stdout.flush()
system_chk ("./run_rx -v -L -S 1252 -s 20 -f %s/test%d.dat -o
%s/test%d.ts " % (dir,i,dir,i))
else:
system_chk ("mc4020-read-adc -b -c 400 --ch3 --1v >%s/test.dat" %
dir)
system_chk ("./run_rx -S 47 -s 20 -f %s/test.dat -o %s/test.ts
2>/dev/null" % (dir,dir))
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NCSA GnuRadio Effort
The sensor + radio fusion stuff looks interesting. I see why the Navy's interested. In the future, you should be able to talk to both radio and i2c devices using the USRP. Your current tuner board could be converted to a USRP daughterboard with minimal trouble (or you could wait for Matt's similar board). You could make a custom daughterboard that has nothing but plugs for i2c (or maybe you could use the basic rx or tx board for that -- I don't know if the i2c pins come out to the rows of headers or not). The USRP software provides a way to read and write to i2c devices (and there are a few on the USRP, including the ID EEPROMs). John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] wfm_rcv.py works, but with half-second delay in audio!
I finally got a SMA cable to hook the USRP to my old 4937 tuner.
wfm_rcv.py worked like a charm on the first try, tuning a strong local
FM radio station. I cabled the computer's audio output into my main
amplifier, which also has a traditional FM tuner. When I switched
between the tuner and the computer audio output, I noticed that the
computer output was about half a second delayed from the FM radio
signal available thru an ordinary tuner.
Any explanations?
John
PS: I'm using the tarball release from the Debian packages, not the CVS.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CVS check out and then failed to build...
I just checked out the most recent CVS sources, using the procedure: got gr-build then using the 'checkout' found in gr-build, got the rest. From there I used './for-all-dirs ../build' in the gr-build directory. I got this set of messages: ./for-all-dirs ../buildit >>> /home/GNURadio/gr-build/gnuradio-core configure.ac:24: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst aclocal.m4:66: AM_CONFIG_HEADER is expanded from... configure.ac:24: the top level configure.ac:195: warning: do not use m4_regexp: use regexp or m4_bregexp aclocal.m4:79: _AM_DIRNAME is expanded from... configure.ac:195: the top level configure.ac:24: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst aclocal.m4:66: AM_CONFIG_HEADER is expanded from... configure.ac:24: the top level configure.ac:195: warning: do not use m4_regexp: use regexp or m4_bregexp aclocal.m4:79: _AM_DIRNAME is expanded from... configure.ac:195: the top level automake-1.5: configure.ac: installing `./install-sh' automake-1.5: configure.ac: installing `./mkinstalldirs' automake-1.5: configure.ac: installing `./missing' automake-1.5: configure.ac: installing `./py-compile' automake-1.5: configure.ac: installing `./depcomp' automake-1.5: src/lib/filter/Makefile.am: warning: automake does not support libfilter_la_SOURCES being defined conditionally automake-1.5: src/lib/filter/Makefile.am: warning: automake does not support libfilter_la_SOURCES being defined conditionally automake-1.5: src/lib/filter/Makefile.am: Assembler source seen but `ASFLAGS' not defined in `configure.ac' src/lib/filter/Makefile.am:152: invalid unused variable name: `libfilter_la_common_SOURCES' automake-1.5: src/lib/omnithread/Makefile.am: warning: automake does not support libomnithread_la_SOURCES being defined conditionally automake-1.5: src/lib/omnithread/Makefile.am: warning: automake does not support libomnithread_la_SOURCES being defined conditionally >>> build FAILED in /home/GNURadio/gr-build/gnuradio-core ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CVS check out and then failed to build... (Further failures...)
John Clark wrote: I just checked out the most recent CVS sources, using the procedure: I then updated my version of 'autoconfig', and 'automake' to be the most recent on ftp.gnu.org, and got the following: (truncated for brevity sake...), but ultimately ending with a message to the effect of needing define AC_PROG_LIBTOOL and re-run. ./for-all-dirs ../buildit >>> /home/GNURadio/gr-build/gnuradio-core configure.ac:61: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.ac:61: AC_PROG_LIBTOOL is required by... config/gr_scripting.m4:30: GR_SCRIPTING is expanded from... configure.ac:61: the top level configure.ac:61: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.ac:61: AC_PROG_LIBTOOL is required by... config/gr_scripting.m4:30: GR_SCRIPTING is expanded from... configure.ac:61: the top level configure.ac:55: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:57: error: possibly undefined macro: AC_ENABLE_SHARED ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on the usrp_fft and usrp_oscope
Sachi wrote: Hi, guys I met some confusions when I tried the usrp_fft and usrp_oscope. I generate a 2MHz, peak to peak 1V, sin wave using the Agilent signal generator, and connect it to usrp. However, the result of usrp_fft always shows a very strong component at DC, besides the 2MHz. Why is that? As I recall the FT transforms a 'constant' function into a single point at the origin, suggesting that your 2Mhz signal is offset from 'zero', either by an error in the signal generator setup, or in the analog portion of the A/D. (I don't have things setup to test with a known data set... ) John Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CVS check out and then failed to build... (Further failures...)
Eric Blossom wrote: On Mon, Apr 04, 2005 at 05:39:35PM -0700, John Clark wrote: John Clark wrote: I just checked out the most recent CVS sources, using the procedure: I then updated my version of 'autoconfig', and 'automake' to be the most recent on ftp.gnu.org, and got the following: (truncated for brevity sake...), but ultimately ending with a message to the effect of needing define AC_PROG_LIBTOOL and re-run. Reinstall libtool also. Actually there seems to be a problem there as well. From another post: LRK wrote: On Mon, Apr 04, 2005 at 05:39:35PM -0700, John Clark wrote: I just checked out the most recent CVS sources, using the procedure: I then updated my version of 'autoconfig', and 'automake' to be the most recent on ftp.gnu.org, and got the following: (truncated for brevity sake...), but ultimately ending with a message to the effect of needing define AC_PROG_LIBTOOL and re-run. I have been trying to get the CVS compile working on FreeBSD and ran into that one. Aclocal19 looks into /usr/local/share/aclocal19/ for libtool.m4 and libtool puts it in /usr/local/share/aclocal/libtool15.m4. So I put a link in there where aclocal can find the file. After some set of upgrades and not-obvious-links I got the 'for-all-dirs' to get to the point of the CPPUNIT testing phase, and got this (python version is 2.3.3 ). >>> gr_fir_fff: using SSE . -- Ran 1 test in 0.065s OK .E == ERROR: test_gru_import (__main__.test_head) -- Traceback (most recent call last): File "./qa_kludged_imports.py", line 39, in test_gru_import from gnuradio import gru File "/home/GNURadio/gnuradio-core/src/python/gnuradio/gru/__init__.py", line 37, in ? exec "from gnuradio.gruimpl.%s import *" % (f,) File "", line 1, in ? File "/home/GNURadio/gnuradio-core/src/python/gnuradio/gruimpl/freqz.py", line 57, in ? import Numeric ImportError: No module named Numeric -- Ran 2 tests in 0.111s FAILED (errors=1) . -- Ran 5 tests in 0.009s OK ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Broadcast flag: FCC and MPAA Response Briefs
The American Library Association, EFF, and others challenged the FCC's authority to regulate equipment beyond the receive tuner, in its broadcast flag ruling. (The "flag" order requires that the tuner not provide its signal to equipment that would let consumers simply record the signal.) The court issued a letter questioning ALA's and EFF's standing to challenge the order. Standing is a legal doctrine that controls who is permitted to file suits; you have to be affected and not just be a bystander. EFF and ALA submitted a brief and declarations that detail how we and our members are affected and have standing. FCC's and MPAA's responses just came in; here they are, courtesy of EFF attorney and DTV Liberation Front organizer Wendy Seltzer: http://wendy.seltzer.org/media/fcc-flag-supp.pdf http://wendy.seltzer.org/media/mpaa-flag-supp.pdf Some of the earlier documents are here: http://www.publicknowledge.org/issues/bfcase More background is here: http://www.eff.org/IP/Video/HDTV/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No module named wx
LRK wrote: On Thu, Apr 14, 2005 at 12:01:11PM -0500, Suvda Myagmar wrote: I also got USRP hardware recently and installed the latest baseline and gnuradio packages to test the HW. When I ran an example this is what I got: $ ./usrp_oscope.py Traceback (most recent call last): File "usrp_oscope.py", line 26, in ? from gnuradio.wxgui import stdgui, fftsink, scopesink File "/home/myagmar/gr/lib/python2.3/site-packages/gnuradio/wxgui/stdgui.py", line 24, in ? import wx ImportError: No module named wx Another thing that might give a clue to my trouble is while building cvs gnuradio-core make check failed: $ make check == ERROR: test_gru_import (__main__.test_head) -- Traceback (most recent call last): File "./qa_kludged_imports.py", line 39, in test_gru_import from gnuradio import gru File "/home/myagmar/gnuradio/gnuradio-core/src/python/gnuradio/gru/__init__.py", line 37, in ? exec "from gnuradio.gruimpl.%s import *" % (f,) File "", line 1, in ? File "/home/myagmar/gnuradio/gnuradio-core/src/python/gnuradio/gruimpl/freqz.py", line 57, in ? import Numeric ImportError: No module named Numeric Setting PYTHONPATH to /home/myagmar/gr/lib/python2.3/site-packages is supposed to fix that. Doesn't for me either. Still working on why. There should be another "site-packages" where python is installed, in my case /usr/local/lib/python2.4/site-packages. Last resort is to put files Numeric.pth and wx.pth in that directory which contain the whole path to the packages. I'll chime in on the 'easy to intuit' requirements to get any of gr-* up, especially the gr-wxgui. Unfortunately other projects press and I have not been able to get a working 'graphical' user environment up, when most of the antecedent 'packages' don't seem to just build, and when they do the install seems not to place things in the 'right' places for building or using the gr-* codes sets. When I have time, I'll continue on. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No module named wx
Eric Blossom wrote: On Thu, Apr 14, 2005 at 01:23:08PM -0700, John Clark wrote: I'll chime in on the 'easy to intuit' requirements to get any of gr-* up, especially the gr-wxgui. Unfortunately other projects press and I have not been able to get a working 'graphical' user environment up, when most of the antecedent 'packages' don't seem to just build, and when they do the install seems not to place things in the 'right' places for building or using the gr-* codes sets. When I have time, I'll continue on. Have you tried just installing one of the RPMs that can be found at http://www.wxpython.org/download.php#binaries One of the points of why I was setting this up, was to get it on to my NetBSD based laptop which is what I have available to me most of the time. Hence using a binary package, would set it up on my linux box at work, but would cause problems in the NetBSD environment. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No module named wx
Angilberto Muniz Sb wrote: Similar situation down here in Brazil, but after adding the softlink it complains with "file not found..." or something similar... Any tips on where to put some break code to help debug the issue? Rgrds, Angilberto. While I don't have any further specific information, I have pursued a 'problem' on some of the 'upstream' packages from GNURadio. While this package may or may not be directly used by GNURadio, or the wxPython package, I was lead up stream by the site were the wxPython package is located. I was compiling PyOpenGL, and ran across what is to me an astonishing 'feature' of the modern GCC preprocessor. First note, I did not build up the linux system I'm currently working on. The system was build by someone else, based on the 'Gentoo' distribution. I don't know why this was done, but I tended to leave the set up as is. On to GCC. Apparently in the intervening 26 years that I've been C programming someone has decided that if a 'system include' appears as an argument to an explicit '-I', that it should be eliminated, so as to prevent someone from overriding the compiled 'search order'. (According to 'man gcc'...) Well, I thought that's exactly why the '-I' was created, to override the 'default search order'. Anyway, in compiling PyOpenGL, I placed an explicit '-I/usr/local/include' in my configuration file, thinking that because I had placed a different version of 'OpenGL', actually 'Mesa' there the compiler and all the make files would search '/usr/local/include' FIRST before anything else and move on if the include file was not found. As it so happens the system that I'm working on had an older/different version of OpenGL installed and has 'GL/*.h' in the 'standard places'. Hence, when the fancy compiler feature eliminated my explicit search path, the older/different include files where brought in and eventually caused a break in a typedef that needed to exist. What I did to 'correct' this was to create a new directory, '/usr/local/include_n', copy the heirarchy from /usr/local/include to the new place, fix the configure file to point to the new directory, and lo and behold, PyOpenGL compiles and installs without further trouble. What I'm going to do is recompile my standard 'compiler' setup to eliminate all but 'real' system includes in the search list, so that in the future at least this problem will not occur again. The object lesson here is that these 'packages' have incredibly sensitive setup conditions which are not 'obvious' in the least. Further, the 'configure' program does not seem to really catch a lot of this. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Built most of gr-*
I don't have any hardware for the highspeed conversions, and have not set up to use 'sound cards' etc. for low speed testing. However, I have been able to get gnuradio-core, as well as several other gr-* packages to compile. The most problem seemed to be centered on having 1) a somewhat large set of additional packages that don't seem to have much to do with signal processing, such as various cpp pre-preprocessing tools, or the like. If the intent was to have a package that was 'portable', then having a large number of ancillary packages, which have not only interdependencies, but also mutual exlucusions for an existing system configuration, seems to go counter to that goal. Since I don't have much (like absolutely none) of anything based on an existing installed python environment, the fact that a number of libraries and packages where 'installed' to get things for gnuradio to compile correctly, it is of no real great difficulty, other than just which ones, and what upstream package requirements are needed. Moving on... Since I don't have hardware at the moment, are there some examples of using simulated signal generators or the like in the existing cvs packages, or out on the net. Also, the gnuradio web site has some pictures of oscope, or fft output, are those buried some where in the gr-* set of code. Perhaps next week I'll have the time to see if I can set this up on a NetBSD machine, but in the mean time I'd like test things on the linux box I have at the moment. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Video software 'scopes'...
Now that I've scratched and clawed my way to a working set up for GNURadio, I was wondering if anyone has implemented video signal specific tools, such as a 'waveform' monitor, or a 'vectorscope'? If not, does any one have any references as to exactly how these devices 'work', and given time and, well time, I may be able to do so. Thanks John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP from multiple applications simultaneously
The current software was designed to let you run one transmit application and one receive application at the same time. If that doesn't work, please report exactly what happens when you try. Yes, that's not optimal in a 4-daughterboard, 8-antenna system, but it's what we have right now. The problem is that because of the USB interface chip, they all have to share a single USB endpoint back to the host. Our hardware isn't smart about how to share the bandwidth among various applications. The FPGA's "mux" lets us move one or more channels in each direction, but due to FPGA programming and buffering limitations, they all have to be using the same data rate over the USB bus. Whatever more-complicated muxing we may come up with to allow arbitrary settings on different daughterboards will almost certainly blow the "zero copying" model you guys are prematurely optimizing. SOMEBODY in the library or kernel will have to tease those data streams apart so the separate applications can access them without interfering with each other. So glad you brought both topics up together... :-) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mirror for USRP-KNOPPIX
Thanks for the tracker and torrent file, Mike! I've seeded many torrents, but didn't have a tracker handy. The toad.com site is now offering up the Knoppix image on BitTorrent as well as on HTTP. So: if you are one of the fourteen people currently trying to download it over my T1 line with a browser or wget, switching to BitTorrent will not slow down your download, but will speed it up. (You'll get pieces from everyone else, as well as from me. BitTorrent will not re-download the part you already got with wget.) Here's the torrent file again: http://m0mik.org/gnuradio/torrents/knop-usrp-20050504.iso.torrent You can get BitTorrent for any platform from http://bittorrent.com . As I type this, only two people are downloading from BT, and there are three complete seeds available. The tracker gives current status: http://m0mik.org:6969/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FCC's broadcast flag struck down in federal court
> good news on the legality of GNUradio software and the USRP board. let's > hope this isn't overturned on appeal. The ruling was made by the DC Circuit Court of Appeals. The only place it could go from here is the Supreme Court -- and they're unlikely to take it (because the issue of FCC's lack of authority to regulate computers that happen to hook up to tuners isn't a burning constitutional issue). Congress is likely to be Hollywood's next step. Indeed, they went to Congress before going to the FCC, but we stopped them last time. http://news.com.com/2100-1023-945691.html?tag=politech John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP based SDR
Have you considered putting a USRP-compatible daughterboard connector on your DSP-based board? That would let you mostly ignore radio front ends. You and anyone else could piggyback on the work done to make each radio front end receiver board made for the USRP. You'd just use the cheap connector/transformer board for direct connection to external radios. It seems like building the radio front ends is a significant pain (they're coming out more slowly than expected), so you can save yourself that pain. Matt and Eric claimed during the USRP development that it wasn't possible to build a USB-powered board that didn't (1) draw too much power, and (2) couple too much noise into the sensitive analog circuitry. Of course, their board has four hungry chips on it; yours will have only two. You might try building your first prototype boards with jumpers or solder bridges that will let you test with USB power and with wallwart power -- and see if the radio performs differently. In the USRP I had proposed that the clocks to the ADC's be programmable, so the whole processing chain could run more slowly than the maximum rate. Matt was unable to find clock generator parts that meet his jitter specs (which are critical for oversampling). That's why the USRP runs the ADC at top speed and downconverts using math in the FPGA. If your Blackfin can't accept data at top speed, you'll have to improve on the USRP's clocking. You prefer USB2 over firewire or gigabit Ethernet? It would be nice to have a radio spectrum interface that didn't have USB2's bandwidth as its bottleneck. Gig E is always full duplex (no collisions between transmit and receive), and offers higher bandwidth. GigE switches are now in the $100 range and dropping fast (or you can plug the board directly into a computer's GigE port, if it isn't on the Internet at the same time, e.g. for mobile laptop use). John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] need help getting simple exercise to work
> > ValueError: source and destination data sizes are different > > The 4020 returns 16 bit signed integers (shorts). The scopesink is > expecting floats. You need to put a gr.short_to_float () block in > between them. Should we make, document and recommend the use of a standard 4020 source that produces the same data type as the USRP (complex float)? That way, when we fix the rest of the I/O modularity, any input source can be used with any application. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VGA-based DVB-T modulator
> Does anyone here know if the VGA cards prevent you from controlling > the DAC durinng the blanking intervals? Are the blanking intervals > implemented in hardware or in software? Generally, video cards stop squirting bits during the blanking intervals, which are implemented in software. This lets the adjacent rows of the frame buffer be next to each other in the memory that the video hardware is scanning its way through. However, the timing of the blanking intervals can be controlled with a fair bit of detail. These are those terrible X config "modeline" values that can blow up your monitor if you set them wrongly. There will be *some* blanking interval, but it can perhaps be very short and can perhaps occur at an interval that won't often affect your signal. It would be great if video hardware had a mode that turned off this foolishness and just kept scanning out a section of RAM, raw. This would even improve refresh rates on things like LCDs that don't have to move an electron beam back across the screen during the "horizontal retrace" time. But few video chips probably do. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Tempest" for LCD displays?
> I'm actually interested in detecting LCD and CRT leakage, and decoding > the picture display from both LCDs and CRTs with a remote USRP, as a > useful hack for determining what TV channels people are watching nearby > (I know you can also listen for the local oscillator in the tuner, but > the tube probably leaks more energy, and gives you more information. Ross Anderson and Markus Kuhn did some work on this. In fact, they designed a font that makes it hard to see the text on a computer screen when monitoring via Tempest emissions. And they have a great way of optical eavesdropping, based on watching a CRT's phosphor light vary over small increments of time (e.g. watching a wall that the CRT is illuminating). The USRP may be fast enough to capture such light from slow monitors, though the USB bottleneck gets in the way. See: http://www.cl.cam.ac.uk/Research/Security/tamper/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
I'm picking up the Gigabit Ethernet conversation from a few weeks ago. Harald Welte said: > I'm actually not referring to the Ethernet hardware side, but to the > software stack. Unless you want to write a special 'ursp network stack' > that sits directly on top of the hardware driver (like PF_RING, but > that's read only), you will go through the whole 'normal' Linux network > stack. > > For every packet you process, there's an enormous amount of overhead > you're going through, even if you choose to not use IP and play some > tricks with raw sockets. Due to the sockets-based interface, you will > have additional copying of the data. > > I'm by no means arguing that the linux network stack is slow. It's just > not intended for an application which just wants to get big data streams > with low latency and little overhead into userspace. I'm surprised to hear you suggest this (though I note you didn't give numbers, just generalizations like "enormous"). The first time I looked seriously at a network stack was in a Van Jacobson/Mike Karels class about how they made BSD TCP on Sun-3/50s run at 1 MByte/sec, within a few % of the theoretical maximum thruput of 10Mbit/s Ethernet. The last time I looked at the Linux network stack was when Dave Miller was cutting his teeth on the SPARC Linux port and making 100MB/s Ethernet run within a few % of theoretical maximum (he quit when he exceeded 10MBytes/sec over TCP from user process to user process). I had of course expected that somebody would do the same thing for Gigabit Ethernet. This appears to have been done; GigE cards seem to be able to push large amounts of data under Linux. What thruput do YOU see using a good GigE card under Linux? Can you move 100 Mbytes/sec from user process to user process with TCP, across two GigE interfaces and a GigE switch? If so, it's doing much better than USB2 ever will, and much better than any version of FireWire. Here's a msg that says Linux was getting 100MBps (presumably MBytes/s) on 2.6.0-test2 in 2003: http://www.uwsg.iu.edu/hypermail/linux/net/0308.1/0037.html Here's one that says 930 Mbps using 2.4.21 on a BiXeon in 2004: http://oss.sgi.com/projects/netdev/archive/2004-04/msg00474.html Here's one that shows 870 Mbits/s in 2002 on 2.4.18 (long haul from Sunnyvale to Chicago): http://www-iepm.slac.stanford.edu/monitoring/bulk/fast/ This msg says that with a 10GB/s Ethernet card (note: 10x as fast as GigE) they can send UDP at 1.9GBps, and send TCP at 2.2Gbps from Chicago to Switzerland. Clearly the Linux kernel overhead isn't keeping thruput below a gigabit: http://www-iepm.slac.stanford.edu/monitoring/bulk/10ge/ There is a lot of research about how to make TCP run at gigabit speeds over *long distances*, particularly in recovering from dropped packets. Nobody seems to need to do research on how to make TCP run at gigabit speeds across the room; it already works. As does UDP. Harald, in what way is your experience different? John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gig-E alternatives & dual USB2
> The other thought is that if you are considering putting the peripheral > remotely close to an outdoor antenna, perhaps an optical fiber solution > would be better - why risk frying your CPU or your body? Copper GigE is sufficiently cheap and ubiquitous that a DAC/ADC board should use it. But for the people who want to mount the whole thing on a tower and run a nonconducting fiber back to their processing shack, a converter from copper GigE to fiber GigE is small, low power, and only costs a few hundred dollars. > Though GigE sounds like a good idea to pursue, has anyone thought about > using 2 or more USB 2 interfaces as an alternative? A good hack! I don't know if common multi-USB2 host interfaces can run all the ports at top speed simultaneously. Some look to software like a single interface connected to a hub. I wonder if we could make a "Second USB2" daughtercard that would use some of the FPGA's digital I/O pins to drive another USB2 chip? (The protocol over the USB would need to change to add packet numbers, or to otherwise provide for a way to synchronize the two streams; but this is probably a simpler change than making a GigE interface.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: GigE (was Re: [Discuss-gnuradio] DSP based SDR)
> involve an application layer connection control scheme. For TX, each > packet has a number and the device NACKs a packet if it is received when > the buffer is full. The host then retries NACKed packets at a given > interval and gives up if not successful after N tries. This is still a > lot lighter than a TCP stack (and could be done in an FPGA). You've just reinvented the first ten instructions of TCP packet processing. The kernel code already does (roughly) that. What is also there in TCP is code to handle the case when that "fast path" fails (e.g. when a packet was garbled on the wire and you instead receive the next packet, and you buffer it and keep looking for that first packet to be retransmitted, but meanwhile more later packets are coming in, but you aren't out of buffer space yet, or maybe you are, and the radio transmitter is getting close to needing that missing data, or maybe it isn't, etc). I've been designing protocols like this since 1979 (PCNet). It's real work. TCP was designed on the back of an envelope, but it was designed by guys who had lived under NCP (its predecessor) for a decade, and had watched it go into catastrophic network-wide failure under overload. They threw it away, discarded its most basic assumption (guaranteed delivery of data by the network), and started over with the assumption that the network could throw away your data at any time (the endpoints need to be responsible for guaranteed delivery). Their second effort, TCP, has scaled up to billions of users and trillions of bits per second. But it took them many months to get TCP working, and many years of research and tuning to make it deliver reasonable bandwidth in the face of bandwidth limits (congestion). Bandwidth limits are why we are even considering replacing our current simple USB2 protocol. Our next interface and protocol WILL be sampling signals that are at the hairy edge of what the hardware and software can handle -- just like today. Our appetites grow over time. Our flow control protocol will work better if it's been modeled and implemented and studied and deployed and fixed by thousands of other people, in real world use. Maybe we should table this discussion until someone actually proposes to build a fast AtoD with an ethernet interface. I reopened it so the last word wouldn't be "Don't ever do that". When someone eventually does it, I think we'll learn a lot from the experience. Maybe what we'll learn is "Don't do that", but I think it will be a much more subtle and interesting answer (which will then help us scale to the next level of bandwidth, 10-gigabit Ethernet, "InfernoWire", USB17, or whatever). John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gigabit Design Proposal
A critical parameter will be the response time (latency) required on the host. This is largely controlled by the amount of bufferring on the GITD. Pushing in the opposite design direction is the desire to minimize latency and cost on the GITD itself. A memory-mapped interface is great for software but adds to the complexity and bus bandwidth requirements when designing for hardware. The memory bus has to handle simultaneous packet reads & writes, etc. It would be a very much simpler design if it had only a single packet buffer for xmit (and another for rcv). Everything would be serial (FIFO) rather than random access, and the data would just flow thru. The catch is that when the last sample of a packet was sent to the DAC, the host would have a very short time in which to send the next packet containing the next sample. Adding a simple FIFO on the DAC side barely increases the complexity but lowers the required latency (adding sampleperiod x fifosize nanoseconds of latency). This is the approach taken on the USRP, as I understand it. If the Ethernet core can steer each received packet into an appropriate fifo (based on its UDP port number, for example) then multiple DACs, ADCs, up- or down-converters can be accommodated. (Even if this set of FIFOs ends up implemented with an external RAM, it maybe best to conceptualize it as FIFOs rather than random access memory. A better FPGA or tighter latency spec could result in sucking that function entirely into the FPGA.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Passive RADAR
Krzysztof Kamieniecki wrote: Eric, Do you have a presentation you could share with us? The question is, can you detect a police car's radio from a far enough distance away so that you could slow down before they check your speed with a Laser? From what I have read, people seem to think the radio may be too well shielded. This for educational purposes, of course. I was quickly going through the list and this one just happened to catch my eye... there are a number of 'police RADAR' detectors out on the market. There's no need to, execpt for 'educational' purposes, created such a detector. What 'passive RADAR' suggests to me is using the myrad of RF signals which are emitted all the time, to then monitor and intripolate the existence of objects which reflect these emissions. Back in the ancient days be fore Cable TV, and TV channels were received from the air by an antenna, the passing of an aircraft in the line of signal for a TV channel would induce a distortion of the received signal... it was very anoying... but that is the fundamental principle of 'passive' RADAR. Such a distortion received at various locations could then be used to locate the object which was moving through the signal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] copyright
Ben Loftin wrote: Hi all, I'm trying to get other people's perspective/experiences on using GPL while working for a company. Upon employment I've signed an IP agreement that has the clause "Agrees [employee] that the copyright to any copyrightable material generated by the Employee during the course of employment shall be owned by the Company in accordance with established legal precedents in respect of "Works Made for Hire"." It appears I cannot work on GPL projects unless I get written exemption by employer (not likely) although I will try. Is anybody else in this type of agreement, do you know if you are? Am I misinterpreting and gnuradio work would not count under some precedent in "Works Made for Hire"? Technically, if you 'use' GPL'd items in your 'company's product, that may make the company liable for the GPL. Hence, some companies disallow their empolyees to use GPL'd software in company products. There's the BSD license, and Net/Free-BSD which does not have the GPL requirements of 'open source'... however, even there, packages acquired which go beyond the core BSD set, may get you into GPL country. (* There have been a number of companies in the linux kernel world which have not re-released their soruces, all the while using the GPL software for their company gain. I have never heard of any company being sued over this, and who would take up the suite... perhaps someone has, but I don't recall such.) Also, I believe, and this is where a lawyer may be needed, is that the 'work for hire' covers only what you do 'at work', 'on behalf, under the direction' of the employer, or for which equipment or services owned/paided for by the employer, were used by you. If you have your home PC using your own paid for DSL/Cable connection, etc, your own sofware, your own e-mail account, etc.etc.etc... Then it is yours. Real muddy areas are if what you do 'at work' matches very closely to what you do at home, such as signal processing implementations, the only difference being that at home you used FORTRAN and punch cards, whereas at work you used APL and a modern Cathode Ray Tube with fancy upper and lower case character keyboard... Less muddy is if you're a grocerystore clerk, and you develop yet-another-basic-interpreter-that-becomes-the-next-best-thing-since-sliced-bread... John Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Groklaw and Dr. Frank Brickle discuss SDR
Groklaw.net is an interesting blog by Pamela Jones, paralegal of
mystery, who has entertainingly coordinated the free software
community's response to the SCO v. IBM lawsuit. Once in a while the
lawsuit gets slow and she has time to cover other things -- like
Katrina, FEMA, and emergency communications. Frank talks about how he
was approached by FEMA to help make DttSP and the SDR-1000 usable by
FEMA and other first responders to patch together their lockdown
government-contractor radio systems:
http://www.groklaw.net/article.php?story=20050916105216639
Many comments by readers are interesting, too.
Frank's comments were based on this earlier posting by Pamela about
how using open standards makes systems much more likely to work in
emergencies:
http://www.groklaw.net/article.php?story=2005091305273070
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fear and loathing of GNURadio in D.C.
Weber, Michael J. (US SSA) schrieb: Steve, thanks for the link... I think articles like these miss two big points: The biggest point that seems to be missed, is that the FCC is essentially an arm of business. There may be minor skirmishes which are 'won', such as the poison-pill bit quirement in 'receivers', but otherwise, the FCC has consistently regulated in favor of monopolies of the airwaves for the benefit of busness. The only time 'SDR' will become 'common' is when business finally sees it as economically feasable, and convinces the FCC that with business's oversight, chaos will not ensue. I'm particularlly pessimistic today... as I am everyday... (The next thing I expect out of the government is a characteristic signature signal required from every radio transmitting device, so it will make it easier for the government to 'find/identify' users of such equipment.) John Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MPAA at it again.
Alfred A. Aburto Jr. schrieb: > Marcus Leech wrote: If they get their way, devices like the USRP would be illegal. Why Marcus? I don't understand ... Al Because the device can digitize a 'video signal'(or any other signal with in its band, or signals translated to its band...), and does not prevent such digitization if the signal contains a marker. The MPAA wants to require all such devices to disable 'conversions' on bit patterns found in the signal, and those that don't conform, will be 'illegal'. There is a similar requirement in implementations of 1394 (Firewire) devices which disallows 'promiscuous' modes of operation for most consumer, and therefore more devices individuals can buy at cheap prices. This effects who can produce 1394 monitor equipment, or specialized applications, or do research on such topics a 'content broadcast/multicast'... I expect 802.11 will also be soon 'upgraded' to prevent promiscuous modes to be enabled without special versions of hardware, although there are features in the current standard which may have to be eliminated, like 'peer to peer' or even 'ad-hoc'... But heck as long MPAA and affiliated companies can become rich on poor programming, monopoly style market capture, etc. we will soon be eating rainbow stew and drinking free bubble-up. Another thought that just occured to me, is I next expect to see that somehow national security will be impacted by 'uncontrolled' digitizers... and to date the US representatives have groveled at the feet of the admininstration when ever the 'patriotic' card has been played. John Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MPAA at it again.
Alfred A. Aburto Jr. schrieb: Thank you ... but digitization in general is ok, right(?), just can't do, ahem, "illegal digitization, of video signals" ... the A/D would detect "illegal digitization" and not allow it, right? As long as it didn't screw up the A/D processing and software required, this may be ok I think ... The MPAA wants to require all such devices to disable 'conversions' on bit patterns found in the signal, and those that don't conform, will be 'illegal'. I think this is reasonable so long as the performance the the A/D processing is not crippled in the act of checking for illegal bit patterns ... I'd hope it would have an extremely low error rate so as to not screw up some otherwise valid A/D conversion process. I don't know how this would be implemented, and what, if any 'general digitizer' products would be affected. I gave the example of 1394 and disabling 'promiscuous' mode for most users. I ran in to this one when I didn't have the money to rent/buy a 1394 analyzer, and needed to monitor traffic between two machines. Disabling this feature has not broken the use of 1394 as the standard DV-Still-Camera interface for millions, but that disabling allows the 'entertainment' industry a potential distribution method which can not normally be 'monitored'. Of course the same group which pirates entertainment products could purchase the 'professional' hardware needed to circumvent the 'protection' scheme. In the present case it would most likely affect developers on a limited budget (or no budget), in the acquisition of parts for development and design, as well as paying for some form of certifications of conformity. John Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MPAA at it again.
Joshua Lackey schrieb: Quoting LRK ([EMAIL PROTECTED]): [...] Start reading up on Argentina folks. It's your future. What about New Zealand? Hey, at least New Zealand has WETA... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sparc <--> x86 data exchange
Three opinions... * GNU Radio should be processing data in the local machine's native byte order and data format (e.g. IEEE float). You should have to explicitly tell it to do something about byte order (e.g. convert samples to little-endian). * Any conversions we offer should say nothing about machine types (x86), rather should be specific about byte orders. E.g. we should not offer "convert longs from x86 to sparc", we should offer "output big-endian longs" and "input big-endian longs". These conversions would be implemented on all machine types, but of course on some of them there's no work to do. An extra name for "big-endian" should be "in network byte order", for people who are squirting partially-processed data over the net to another signal processing program on an arbitrary machine. (My opinions on byte order come from having co-designed and maintained the "BFD" library that the GNU binutils use to read and write object files, which require pervasive and specific attention to byte order. We changed our byte-order API several times until we got it right and easy to use.) * I'm hesitant to make GNU Radio depend on Yet Another random library package like liboil. Building it is already an exercise in frustration, as is trying to package it for a distribution. Can't we skip some premature optimization and get back to making the program do real things that real people want to do? I don't see the "obvious" GUI-operable scanners, recorders, radar screens, etc, that our capabilities are supposed to make it easy to create. We're how many years into this package?, and still re-re-rewriting the guts. Let's rather make it something that tens of thousands of people would use to record multiple FM stations, or scan and log police and ambulance frequencies, or TiVo the ham bands, or avoid DRM on over-the-air TV transmissions. Even our FM decoding is inferior to what cheap transistor radios do. Six months' focus on polish and applications would make a world of difference. Just my 2c... John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_* gains on Mac OS X much greater than on Linux
It should be pretty simple for the USRP's FPGA to swap the bytes of
16-bit samples it delivers in USB packets, if instructed in a control
register by the host. This would avoid any speed penalty for
big-endian hosts.
(It's also pretty simple to determine that a simple byte-swap would be
a complete cure for the problem, by temporarily doing the swap in software.)
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] curve fitting data points
cswiger wrote: > This is for the mathematicians out there - what is a simple > working algorithm for creating a function model to fit an > arbitrary number of data points. You could try a least squares fitted polynomial http://mathworld.wolfram.com/LeastSquaresFittingPolynomial.html has a description of how it's done. -- Cheers, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP's not Communicating
Hello, I want to transmit the data between two USRP's and make them communicate with each other. But I guess the packets are not being received properly. I am connected the two USRP's to the same laptop and trying it. Is that applicable? I mean, will it work if I do that? Or should I connect to two computers and perform that? I have been receiving this error. linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 56.25 (from [0.00, 112.50]) UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ok = False pktno = 53034 n_rcvd =1 n_right =0 ok = False pktno = 24 n_rcvd =2 n_right =0 ok = False pktno = 35 n_rcvd =3 n_right =0 ok = False pktno = 44 n_rcvd =4 n_right =0 ok = False pktno = 46 n_rcvd =5 n_right =0 ok = False pktno = 46 n_rcvd =6 n_right =0 ok = False pktno = 3872 n_rcvd =7 n_right =0 ok = False pktno = 12304 n_rcvd =8 n_right =0 ok = False pktno = 49 n_rcvd =9 n_right =0 ok = False pktno = 50 n_rcvd = 10 n_right =0 ok = False pktno = 54 n_rcvd = 11 n_right =0 ok = False pktno = 200 n_rcvd = 12 n_right =0 ok = False pktno = 63 n_rcvd = 13 n_right =0 Please suggest. Thank you Regards, Ravi -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Weird install problem, GR 3.7.8.1
Hello all. I've compiled and installed the last version on my home PC and on the notebook. Both under Linux Slackware (mostly version 14.1, some updates to -current). Both run gcc 4.9.x, Python 2.7.10. Both are AMD64 systems. On the PC all is well, but on the notebook I have some strange issues with Gnuradio-companion. 1) The block list (right of the screen) is partially warbled. I mean, some of the block category titles are split into letters, each letter a new sub directory of the previous letter. Eg: NOAA appears as N/O/A/A/, and the actual blocks are in the last A/ subdirectory. One category appears in both forms, i.e. as a normal name and as a garbled name. If the category contains sub-categories, such as Instrumentation/Wx then the garbling continues as I/n/s/t/r/u/m/e/n/t/a/t/i/o/n/W/x/ 2) I haven't been able to get rtl-sdr and the osmo driver to appear yet, even though all test programs for both programs run perfectly and communicate with the dongle. 3) Contrary to the indications, I had to point PYTHONPATH to Python's site-packages directory (not .../dist-package) for GRC to start up. I've looked over bugs and wiki, and didn't see anything similar (particularly to 1)), so I do suspect an install problem. However: - I tried with versions 3.7.5.1 and 3.7.8.1, with the same problems. - I tried compiling myself, using cmake etc, and tried with the Slackbuild script. - To be sure, I tried removing all traces of previous installs, in /usr/local/share, usr/local/lib64, etc - BTW, no error messages appear in the terminal where I start grc. I'd like to have a go at debugging this, but due to gnuradio's size I have no real idea how to start. Can anyone give me a pointer? John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird install problem, GR 3.7.8.1
On Tue, 10 Nov 2015 22:03:42 -0300 John Coppens wrote: > I'd like to have a go at debugging this, but due to gnuradio's size I have > no real idea how to start. Can anyone give me a pointer? > Investigating a little, I found that the strange directory structure seems to come from a call to 'self.platform.load_block_tree'. Manually navigating the treestore after that call (in BlockTreeWindow.py), the strange structure is already there. I've been tracing around in that function, but it's 2 AM, so I'll have to postpone further investigation till tomorrow... (and this is stretching my knowledge of Python) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird install problem, GR 3.7.8.1
On Wed, 11 Nov 2015 13:42:35 -0800 Johnathan Corgan wrote: > On Wed, Nov 11, 2015 at 6:07 AM, Frederick E. Stevens > wrote: > > > > As I recall, this behavior has cropped up in 3.6 and 3.7 of gnuradio for > > me but it wasn't much of an issue at the time. > > This afternoon, I had some time to trace where the problem originated. It seems that on some systems (mine ;) the test for isinstance(category, str) doesn't work, as the type of category is actually 'unicode'. (This is on Slackware 14.1 + some mods from -current). I changed to isinstance(category, basestring), which captures both str and unicode. (This is around line 130 in BlockTreeWindow.py) I've submitted a bug report for this - which was accepted. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Two minor problems on Mac OS X
Hi Ma, Answer to Q1 is to issue command: gnuradio-config-info --v if you are interested in GRC verions, the command is gnuradio-companion --v Kind Regards, John On 14/01/16 22:21, MA wrote: Thanks. 1- So, how should we determine a gnuradio installation's version? (Is it specified anywhere?) 2- Please take a look at this screenshot: http://imgur.com/s285JXK Notice the difference between the text in output window or blocks list and the main part of GRC. The blocks on the main section are pixelated. Is this because of X window? (It does not feel native, and the strange thing is that other sections' fonts look normal) Mehdi On Fri, Jan 15, 2016 at 1:35 AM, Michael Dickens mailto:michael.dick...@ettus.com>> wrote: Hi Mehdi - The first item looks correct; it's a default string that can be overridden by the user mostly for the purpose of package managers. I'm not sure if I understand the 2nd item. When I run GRC it looks fine. Can you send me a screenshot off-list & I'll work with you there to see what can be done. - MLD On Thu, Jan 14, 2016, at 03:54 PM, MA wrote: I've compiled the 3.7.9 (from the tar.gz file on the website) on OS X 10.11.2 Everything is OK and I even tested it with a SDR receiver to make sure it's working as expected. There are two minor problems: 1- The version string (shown on grc's "About" dialog and its welcome screen) is "v3.7.x-xxx-xunknown". Why is that? Is it a problem? How can I be certain that it's the 3.7.9? (I had 3.7.7.1 previously, but I've deleted that) 2- The fonts are almost blurred on the grc. My MacBook's screen is Retina. Is this because of that? Can it be improved? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org <mailto: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] Noise Source Output ~3dB Higher on E310?
This was a surprising one. When set with a the same seed (regardless of value) and amplitude, the noise source (gaussian) seems to have 3 dB higher power when running on E310 vs. an i7 platform. (GNU Radio commit 8220b79653c6c7999a18fed075bdb1c41bca0613 on i7) (e3xx release 3 from here: http://files.ettus.com/e3xx_images/e3xx-release-3/) This problem came up when running unit tests on modems that check BER vs. Eb/n0. Has anyone come across this before? I'm sure there's a good reason/explanation for this - but I'm too tired to think of it. -John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Doubt
Hello Guys I am new to GNU Radio. I am sorry if the question is stupid. Did anyone tried Successive Interference Cancellation using GNU Radio? If so then is there any source code available related to that? Awaiting for your reply ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Noise Source Output ~3dB Higher on E310?
Thanks guys. On Tue, Jan 26, 2016 at 8:51 AM, Philip Balister wrote: > On 01/26/2016 05:17 PM, Tomaž Šolc wrote: > > On 26. 01. 2016 12:14, Philip Balister wrote: > >> On 01/26/2016 11:35 AM, John Malsbury wrote: > >>> This was a surprising one. When set with a the same seed (regardless > of > >>> value) and amplitude, the noise source (gaussian) seems to have 3 dB > higher > >>> power when running on E310 vs. an i7 platform. > >>> > >>> (GNU Radio commit 8220b79653c6c7999a18fed075bdb1c41bca0613 on i7) > >>> > >>> (e3xx release 3 from here: > >>> http://files.ettus.com/e3xx_images/e3xx-release-3/) > >> > >> Release 3 has 3.7.7.1 which does not have the fix for this problem. > > > > Just in case anyone else is wondering, I'm guessing that Philip is > > talking about this commit: > > > > > https://github.com/gnuradio/gnuradio/commit/5335005bcfbd671a0760bde08e69ef867b7ffc24 > > Thanks. I'm at the hackfest and realized there was some out of band info > needed to complete my answer after hitting send. > > Philip > > > > > Regards > > Tomaž > > > > ___ > > 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] Fwd: RF NoC Consulting
-- Forwarded message -- From: John Malsbury Date: Wed, Mar 23, 2016 at 1:56 PM Subject: RF NoC Consulting To: "usrp-us...@lists.ettus.com" I may have a need to offload some RF NoC projects. If you think you are an expert in RF NoC and interested in some work, send me a message. -John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FW: HF transmitter hardware solutions
Dan, Lou, Ron, and others, Dan you are doing a great job of beating the drum: searching for "solutions for transmitting on HF" The question is a big one and can be broken down into three basic issues. The basic or elemental SDR platform solutions are changing rapidly. With the third generation SDRs, and tightly integrated RFICs, there are a number of excellent, high performance, solutions, as has been pointed out, and as you well know. I think your real question, Dan, asks about the rest of the HF system: the elements necessary to complete the transmitter for practical communication purposes. The question moves beyond SDR hardware to that of station building. That station building part of the system, I call the "interface". The "interface" provides the receive and transmit filtering and antenna switching, power control, amplifier stages, and other functions. The "interface" is built upon analog technology. Much information along these lines is addressed by the QRP (low power) movement within Amateur Radio. The American Radio Relay League (ARRL) publishes small paperback books devoted to QRP equipment and station building, and available for purchase on-line. The material covers homemade solutions, as well as purchased kits and turnkey solutions. Maybe, a group of interested GRC/SDR enthusiasts can collect and publish a few example systems as starters for those who want to experiment in this area. The second aspect of the "solutions" question asks if there are suitable GRC DSPs as starters, at least. With Lou's help, I have authored a library of transceiver DSPs for all of the commonly used HF transmission modes. The GRC DSPs are 'ham friendly' in the sense that they implement functional, ordinary and familiar transceiver interfaces. However, I have no easy means to publish the DSP's. Would collecting and publishing GRC DSPs be helpful at addressing your "solutions" question? If so, what is the best approach for maximum visibility to the experimenter community? Last but not least, a third issue for communication system functionality, is to use the GRC GUI to control the auxiliary functions of an HF transmitter, e.g. transmit / receiver relay. I do not know of a means to access the GPIO from the GRC GUI. My present solution is to use current from the USRP transmit or receive LED signal to control external equipment via a relay system. Maybe someone can publish a different solution. Looking forward to further discussion on the HF transmit solution question. Regards, John Petrich -Original Message- From: Ron Economos [mailto:w...@comcast.net] Sent: Wednesday, April 6, 2016 7:23 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] HF transmitter hardware solutions There's a transverter for the bladeRF. https://www.nuand.com/blog/product/hf-vhf-transverter/ hackRF specification has been changed to 1 MHz to 6 GHz. https://greatscottgadgets.com/hackrf/ Ron On 04/06/2016 07:02 AM, Daniel Pocock wrote: > > What solutions are people using for transmitting on HF bands (1 - 30 MHz)? > > There is a lot of information online about upconverters for receiving > the HF bands. > > However, like receivers, many of the SDR transmitters only seem to > cover bands above 30MHz[1] e.g. > > HackRF: 30MHz - ... > bladeRF : 300MHz - ... > USRP B2x0: 50MHz - ... > > Is anybody using a downconverter or is there some other SDR model that > natively supports the HF spectrum and is accessible to hobbyists? > > Some other things come to mind: > - power amps for HF bands > - RF switches for using a single antenna in half-duplex mode, > alternating between receive and transmit > > > > 1. > http://www.taylorkillian.com/2013/08/sdr-showdown-hackrf-vs-bladerf-vs > -usrp.html > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu
Hi, I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP N200 with SBXv3. I have been using the aptly-named and highly useful Simple_ra though I believe this is orthogonal to the issues I am seeing. when I run simple_ra with : simple_ra --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 --longitude 172.57027 --latitude -43.51944 --spde the system runs along happily for several maybe even up to 20 odd hours but, as below, I start to see one or more Ds. In one run of 23 hours, I had 10 Ds and eventually a segmentation fault - not sure if it is coincident with issuing of the final 'D'. Sometimes the D is not accompanied by UHD errors here is the terminal output from the last run: linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228 Using Volk machine: avx_64_mmx_orc gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO Found an internal GPSDO -- Setting references to the internal GPSDO -- Using subdev spec 'A:0'. -- Using LO offset of 1e+07 Hz. WARNING: Overriding original sample rate of 1e+07 with 2e+06 -- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv D UHD Error: Control packet attempt 0, sequence number 10594: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 1, sequence number 10595: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 2, sequence number 10596: RuntimeError: no control response, possible packet loss UHD Error: An unexpected exception was caught in a task loop. The task loop will now exit, things may not work. RuntimeError: link dead: timeout waiting for control packet ACK Terminated I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 15.6 GiB of memory and run 64-bit os and have the USRP on it's own subnet and NIC. Apart from setting: net.core.rmem_max = 5000 net.core.wmem_max = 1048576 I have not 'tuned' any os settings. When the application is running, the 8 cores are between 40-50% utilised. When I restart simple_ra after the error, it runs again fine until it hits an issue n-hours in the future. Any ideas of how I can narrow down the cause of this? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu
On 03/05/16 02:58, Marcus D. Leech wrote: On 05/02/2016 10:40 PM, John Shields wrote: Hi, I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP N200 with SBXv3. I have been using the aptly-named and highly useful Simple_ra though I believe this is orthogonal to the issues I am seeing. when I run simple_ra with : simple_ra --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 --longitude 172.57027 --latitude -43.51944 --spde the system runs along happily for several maybe even up to 20 odd hours but, as below, I start to see one or more Ds. In one run of 23 hours, I had 10 Ds and eventually a segmentation fault - not sure if it is coincident with issuing of the final 'D'. Sometimes the D is not accompanied by UHD errors here is the terminal output from the last run: linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228 Using Volk machine: avx_64_mmx_orc gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO Found an internal GPSDO -- Setting references to the internal GPSDO -- Using subdev spec 'A:0'. -- Using LO offset of 1e+07 Hz. WARNING: Overriding original sample rate of 1e+07 with 2e+06 -- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv D UHD Error: Control packet attempt 0, sequence number 10594: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 1, sequence number 10595: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 2, sequence number 10596: RuntimeError: no control response, possible packet loss UHD Error: An unexpected exception was caught in a task loop. The task loop will now exit, things may not work. RuntimeError: link dead: timeout waiting for control packet ACK Terminated I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 15.6 GiB of memory and run 64-bit os and have the USRP on it's own subnet and NIC. Apart from setting: net.core.rmem_max = 5000 net.core.wmem_max = 1048576 I have not 'tuned' any os settings. When the application is running, the 8 cores are between 40-50% utilised. When I restart simple_ra after the error, it runs again fine until it hits an issue n-hours in the future. Any ideas of how I can narrow down the cause of this? Kind Regards, John Do you happen to know what kind of NIC you have? Also, 2MSPS should not be chewing up much of your CPU--what kind of graphics card do you have? Is this a real, or virtual, machine setup? There Intel 82579LM is known for dropping packets under certain circumstances that shouldn't cause it to drop packets. This is basically fatal to the way UHD does network I/O--since it uses UDP, with no retry mechanism (and, indeed, it's easy to see that at higher sample rates in particular, any TCP-like mechanism is going to cause heartburn for real-time flows). If you do a: lspci -v It should show you what the Ethernet interface(s) are. If this is a *server* motherboard, the underlying graphics subsystem may be just a framebuffer, in which case, your CPU is working really hard to render even simple graphics. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks very much, as always, Marcus. To the NICs : the command gave the following (edited to remove USB, IDE etc.) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device d000 Flags: bus master, fast devsel, latency 0, IRQ 47 Memory at f740 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01) Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller Flags: bus master, fast devsel, latency 0, IRQ 44 I/O ports at e000 [size=256] Memory at f7b0 (64-bit, non-prefetchable) [size=4K] Expansion ROM at dfb0 [disabled] [size=128K] Capabilities: [40] Power Management version 2 Capabilities: [48] Vital Pr
Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu
On 03/05/16 02:58, Marcus D. Leech wrote: On 05/02/2016 10:40 PM, John Shields wrote: Hi, I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP N200 with SBXv3. I have been using the aptly-named and highly useful Simple_ra though I believe this is orthogonal to the issues I am seeing. when I run simple_ra with : simple_ra --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 --longitude 172.57027 --latitude -43.51944 --spde the system runs along happily for several maybe even up to 20 odd hours but, as below, I start to see one or more Ds. In one run of 23 hours, I had 10 Ds and eventually a segmentation fault - not sure if it is coincident with issuing of the final 'D'. Sometimes the D is not accompanied by UHD errors here is the terminal output from the last run: linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228 Using Volk machine: avx_64_mmx_orc gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO Found an internal GPSDO -- Setting references to the internal GPSDO -- Using subdev spec 'A:0'. -- Using LO offset of 1e+07 Hz. WARNING: Overriding original sample rate of 1e+07 with 2e+06 -- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv D UHD Error: Control packet attempt 0, sequence number 10594: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 1, sequence number 10595: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 2, sequence number 10596: RuntimeError: no control response, possible packet loss UHD Error: An unexpected exception was caught in a task loop. The task loop will now exit, things may not work. RuntimeError: link dead: timeout waiting for control packet ACK Terminated I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 15.6 GiB of memory and run 64-bit os and have the USRP on it's own subnet and NIC. Apart from setting: net.core.rmem_max = 5000 net.core.wmem_max = 1048576 I have not 'tuned' any os settings. When the application is running, the 8 cores are between 40-50% utilised. When I restart simple_ra after the error, it runs again fine until it hits an issue n-hours in the future. Any ideas of how I can narrow down the cause of this? Kind Regards, John Do you happen to know what kind of NIC you have? Also, 2MSPS should not be chewing up much of your CPU--what kind of graphics card do you have? Is this a real, or virtual, machine setup? There Intel 82579LM is known for dropping packets under certain circumstances that shouldn't cause it to drop packets. This is basically fatal to the way UHD does network I/O--since it uses UDP, with no retry mechanism (and, indeed, it's easy to see that at higher sample rates in particular, any TCP-like mechanism is going to cause heartburn for real-time flows). If you do a: lspci -v It should show you what the Ethernet interface(s) are. If this is a *server* motherboard, the underlying graphics subsystem may be just a framebuffer, in which case, your CPU is working really hard to render even simple graphics. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Sorry, but forgot to answer the question re: real or virtual setup - I run real. Slainte, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu
Thanks Marcus, Have put answers in-line. Kind Regards, John On 03/05/16 08:20, Marcus Müller wrote: On 03.05.2016 09:52, John Shields wrote: On 03/05/16 02:58, Marcus D. Leech wrote: On 05/02/2016 10:40 PM, John Shields wrote: the system runs along happily for several maybe even up to 20 odd hours but, as below, I start to see one or more Ds. In one run of 23 hours, I had 10 Ds and eventually a segmentation fault - not sure if it is coincident with issuing of the final 'D'. Sometimes the D is not accompanied by UHD errors here is the terminal output from the last run: linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228 Using Volk machine: avx_64_mmx_orc gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO Found an internal GPSDO -- Setting references to the internal GPSDO -- Using subdev spec 'A:0'. -- Using LO offset of 1e+07 Hz. WARNING: Overriding original sample rate of 1e+07 with 2e+06 -- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv D UHD Error: Control packet attempt 0, sequence number 10594: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 1, sequence number 10595: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 2, sequence number 10596: RuntimeError: no control response, possible packet loss UHD Error: An unexpected exception was caught in a task loop. The task loop will now exit, things may not work. RuntimeError: link dead: timeout waiting for control packet ACK Terminated 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) ... Kernel driver in use: i915 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01) ... Kernel driver in use: r8169 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01) ... Kernel driver in use: r8169 06:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet (rev c0) ... Kernel driver in use: atl1c by looking at the Realtek card, the PHY chip is the RTL8168B (single-chip Gigabit NIC Ethernet Controller for PCI Express) not sure if there is general knowledge of this Taiwanese NIC/Chip re: dropping packets or other performance issues? I note these boards are rev 1.0! They are certainly not the greatest NICs in the world when it comes to CPU efficiency, but I'm not aware of any specific prolems. Can you actually just try with the atheros interface? That would rule them out as possible source of problems. Yes, I will give the on-board Atheros a try. re: relatively high CPU for 8 cores running simple_ra - the '8' is actually only 4 real cores (2 logical cores per physical) but as can be seen from below, I don't believe I splashed out on a graphics card and just took the motherboard's capability. Perhaps my Scottish accent can be detected? Will look into getting something along those lines if it improves the graphics performance. 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) .. Kernel driver in use: i915 That's an Intel HD 4000 or so, right? At any rate, they should have enough horsepower to update a few plots via OpenGL. What indeed could be happening is that hardware rendering is not used (the wx GUI toolkit seems to be a little special sometimes, but then, who or what isn't?). So two things: 1. could you share what "glxinfo | grep renderer" says? (or was it glxinfo64? If both are present, send both :) ) 2. there was a way to dis/enable wx OpenGL usage per config file. My brain feels a bit holey these days; I'd have to research that. john@i7Ubuntu:~$ glxinfo | grep renderer GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop not sure if it is significant or not but I had to install glxinfo ( sudo apt-get install mesa-utils) General question: After things crashed, using the N210 works if you re-start simple_ra (or any other UHD sample streaming program), or do you need to power-cycle the N210? no Marcus, I just restart simple_ra and it goes off running fine - no need to touch the N200. Best regards, Marcus ___ Discuss-gnuradio mailing list D
Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu
On 03/05/16 15:01, mle...@ripnet.com wrote: It's possible that we're dealing with a memory leak somewhere. Could you watch the memory consumption of simple_ra over time? Also, could you just run something like uhd_fft with the same sample rate for long periods to see if it gets the same 'D' treatment? On 2016-05-03 04:32, John Shields wrote: Thanks Marcus, Have put answers in-line. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I should have said that the N200 was in the shack and the Ubuntu system in the house. I have several runs of Ethernet out to the shack so will do some experimentation on the different connections. Then I will move the Ubuntu system to the shack and see if colocation helps. These investigations will take some days but will let you know. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu
Thanks Marcus, The cable is cat-5e and the length is 52 meters (give or take). Based on your calculations, it seems that I am setting myself for high likelihood of a dropped packet if I were to run for 4 or 5 days continuously. I have moved the N200 over to another cable to see if the situation improves but I think that the best solution is to move the Ubuntu box into the shack rather than move house/shack closer :) Slainte, John On 03/05/16 19:12, mle...@ripnet.com wrote: The native BER of 1000BASE-T is better than 1.0e-11 or so. Which means you'd expect a bad bit roughly every half-hour at 2msps (64Mbit/sec), the bad-bit probabilities get worse as you make the cable longer. On 2016-05-03 12:59, John Shields wrote: On 03/05/16 15:01, mle...@ripnet.com wrote: It's possible that we're dealing with a memory leak somewhere. Could you watch the memory consumption of simple_ra over time? Also, could you just run something like uhd_fft with the same sample rate for long periods to see if it gets the same 'D' treatment? On 2016-05-03 04:32, John Shields wrote: Thanks Marcus, Have put answers in-line. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I should have said that the N200 was in the shack and the Ubuntu system in the house. I have several runs of Ethernet out to the shack so will do some experimentation on the different connections. Then I will move the Ubuntu system to the shack and see if colocation helps. These investigations will take some days but will let you know. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio segmentation fault
Dear All, I have been running GNURadio fairly constantly for a couple of weeks now using simple_ra although, I don't believe it is a problem with that application as HTOP doesn't indicate memory issues etc. I run GNURadio version 3.7.9.1 on an Intel® Core™ i7-2600 CPU @ 3.40GHz × 8. I have been running Ubuntu 14.04 LTS for years now but on encountering the issue recently with continuous GNURadio use, I upgraded to 15.10 but the problem still occurs. Here is what they syslog(s) say: previous (for years!) 14.04LTS May 7 15:01:34 i7Ubuntu kernel: [59309.794629] python2[3772]: segfault at 0 ip 7f8e53be91c0 sp 7ffe66518cc8 error 6 in libc-2.19.so[7f8e53b51000+1bb000] May 11 02:06:54 i7Ubuntu kernel: [97164.418968] python2[2735]: segfault at 0 ip 7fbc2dce61c0 sp 7ffdd22fa0a8 error 6 in libc-2.19.so[7fbc2dc4e000+1bb000] upgraded to 15.10 May 21 22:22:12 i7Ubuntu kernel: [643331.441347] python2[24419]: segfault at 0 ip 7faee89160e0 sp 7ffc3857e748 error 6 in libc-2.21.so[7faee8876000+1c] May 22 05:36:28 i7Ubuntu kernel: [21018.530748] python2[2408]: segfault at 0 ip 7ff267bcb882 sp 7ffdfe2d0b90 error 6 in i965_dri.so[7ff267814000+5b2000] I get no other symptoms i.e. no D's or anything bad reported by UHD. I also don't get problems with any other applications to indicate some memory issue though I wouldn't expect the regular apps to use as much memory - mind you when running simple_ra uses less than 10% of the memory. Any ideas on how I can narrow the cause down? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio segmentation fault
On 22/05/16 11:06, Marcus D. Leech wrote: On 05/22/2016 05:19 AM, Marcus Müller wrote: Hi John, I don't really know about the memory usage you see, but: Did you rebuild GNU Radio (and UHD and basically everything you did not install directly through Ubuntu's apt-get)? Upgrading a distro often changes the libc version used, and that might mean that the ABI of the very core functionality has changed, and your program is calling functions with the wrong parameters or functions that don't exist. That would be my first guess. Now, you said you upgraded in an attempt to remedy those failures, so I'm fully aware that might not be the /right/ guess, but segfaults in libc usually only happen if you call some system functionality with a non-existing / too short buffer or invalid pointer to a structure or something like that, and the most common cause for that (aside from actual bugs, but I'm not aware of anything currently, but I haven't really used simple_ra much) would be an ABI mismatch. Now, this isn't going to fix if something in simple_ra actually segfaults: So, my first attempt would really be a make clean; make; (sudo) make install . If that fails, run your simple_ra application through GDB. The trick here would probably be (Marcus L., you shout if I say something stupid, right?) to modify the simple_ra script; at the very end, replace simple_ra_receiver.py --frequency ... by gdb -ex run --args python2 simple_ra_receiver --frequency ... to let gdb run the python flow graph for you. Then, at some point gdb should catch the segfault and drop you to a command prompt; "bt" or "backtrace" is the command you want to do to see the cascade of calls going on (it might be helpful to have installed the "xyz-dbg" packages for Ubuntu's python and libc packages, and build your GNU Radio with debug symbols enabled, i.e. using -DCMAKE_BUILD_TYPE=RelWithDebInfo when calling cmake) when the segfault happened. Often, that's already sufficient to narrow down the bug. If it isn't: the lines of the backtrace start with a #number; that number is the frame number, and you can change into each frame, do a "list" (if debug symbols are present) and get the source code where the program currently is, use "print" to print variables (really invaluable if you've e.g. got a "for" loop that keeps on writing past the end of a buffer and you don't know why). Best regards, Marcus It's conceivable that this is simple_ra's fault. While it's almost-entirely written in GRC with some helper Python, there are some custom blocks used from gr-ra_blocks, written in C++. I'd be interested to know if the failure is actually from one of those... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thank you Marcus'. I used Marcus(L) build script to get UHD/GNURadio so I will do the :make clean etc. that is suggested. You can see from the syslog that, the upgrade to 15.10 did, indeed, bump the revision of libc. That was a good tip re: modifying the simple_ra run script to put GDB in first. Will run in that mode and let you know what I get. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OpenGL running out of memory
Hi, Have GNURadio 3.7.9.2 installed on Ubuntu 15.10. I have been running simple_ra but don't believe that is germane to the problem at hand. I am running simple_ra_receiver under debug (have seen segmentation errors in libc in the past and trying to narrow down) but, again, don't think this is a factor in the symptom. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", line 209, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", line 65, in draw GL.glCallList(self._grid_compiled_list_id) File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in glCheckError baseOperation = baseOperation, OpenGL.error.GLError: GLError( err = 1285, description = 'out of memory', baseOperation = glCallList, cArguments = (2L,) ) The graphics screen is frozen (grey) but the rest of the threads run OK. In terms of system memory, shows 1.9GiB of 15.6 so I don't believe the system is running out of physical memory. Cannot find anything relating to this issue vis-a-vis GNURadio. Any ideas of what is going wrong or a workaround I could implement to avoid? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenGL running out of memory
Thanks Marcus, Will give that a try. Kind Regards, John On 29/05/16 08:27, Marcus Müller wrote: Hi John, you could try and disable OpenGL acceleration for WX Gui. That's usually not a good thing, and it doesn't always help if your system randomly hangs in WX things, but if it solves this: find (or create) your ~/.gnuradio/config.conf and add [wxgui] style = nongl Best regards, Marcus On 29.05.2016 02:22, John Shields wrote: Hi, Have GNURadio 3.7.9.2 installed on Ubuntu 15.10. I have been running simple_ra but don't believe that is germane to the problem at hand. I am running simple_ra_receiver under debug (have seen segmentation errors in libc in the past and trying to narrow down) but, again, don't think this is a factor in the symptom. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", line 209, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", line 65, in draw GL.glCallList(self._grid_compiled_list_id) File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in glCheckError baseOperation = baseOperation, OpenGL.error.GLError: GLError( err = 1285, description = 'out of memory', baseOperation = glCallList, cArguments = (2L,) ) The graphics screen is frozen (grey) but the rest of the threads run OK. In terms of system memory, shows 1.9GiB of 15.6 so I don't believe the system is running out of physical memory. Cannot find anything relating to this issue vis-a-vis GNURadio. Any ideas of what is going wrong or a workaround I could implement to avoid? Kind Regards, John ___ 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] simple_ra and Ubuntu 16.04 LTS
Hi, Since I moved from 14.04 LTS to 15.10 a couple of weeks ago, I have been experiencing segmentation faults on i965_dri (graphics rendering). In order to (hopefully) move away from this issue, yesterday I upgraded to 16.04 LTS and rebuilt GNURadio (3.7.9.2) and UHD using Marcus' script - only new issue thrown up was: Checking for package python-wxgtk2.8 Failed to find package 'python-wxgtk2.8' in known package repositories SOME THINGS MAY NOT BUILD AS A RESULT (16.04 appears to have 3.0 version ) I have seen this sort of diagnostic before on (Failed to find package 'libzmq1-dev' in known package repositories) but things seemed to work OK so continued. I can get into GRC etc. I decided that I should re-compile simple_ra and followed the instructions I usually do: cd/trunk; cmake . ; make etc. at the cmake level, I got the following warnings: GNURADIO_BLOCKS_FOUND = TRUE CMake Warning (dev) at /usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "test-ra_blocks". Use the target name directly with add_custom_command, or use the generator expression $, as appropriate. Call Stack (most recent call first): lib/CMakeLists.txt:71 (GR_ADD_TEST) This warning is for project developers. Use -Wno-dev to suppress it. -- -- Checking for module SWIG -- Command "/usr/bin/swig2.0 -swiglib" failed with output: -- Found SWIG version 2.0.12. -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.11+") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version "2.7.11+", minimum required is "2") -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") -- Configuring done -- Generating done -- Build files have been written to: /home/john/gr-ra_blocks/trunk when I did a make, I got: [ 48%] Generating ra_blocks_swig.tag Scanning dependencies of target ra_blocks_swig_swig_2d0df [ 52%] Building CXX object swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o [ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df Swig source /bin/sh: 1: /usr/bin/swig2.0: not found swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134: recipe for target 'swig/ra_blocks_swig_swig_2d0df' failed make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127 make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df' CMakeFiles/Makefile2:274: recipe for target 'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all] Error 2 Makefile:138: recipe for target 'all' failed make: *** [all] Error 2 I wonder if I have made an error some way along, but cannot imagine what. Any ideas? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS
On 30/05/16 22:05, John Shields wrote: Hi, Since I moved from 14.04 LTS to 15.10 a couple of weeks ago, I have been experiencing segmentation faults on i965_dri (graphics rendering). In order to (hopefully) move away from this issue, yesterday I upgraded to 16.04 LTS and rebuilt GNURadio (3.7.9.2) and UHD using Marcus' script - only new issue thrown up was: Checking for package python-wxgtk2.8 Failed to find package 'python-wxgtk2.8' in known package repositories SOME THINGS MAY NOT BUILD AS A RESULT (16.04 appears to have 3.0 version ) I have seen this sort of diagnostic before on (Failed to find package 'libzmq1-dev' in known package repositories) but things seemed to work OK so continued. I can get into GRC etc. I decided that I should re-compile simple_ra gr-ra_blocks and followed the instructions I usually do: cd/trunk; cmake . ; make etc. at the cmake level, I got the following warnings: GNURADIO_BLOCKS_FOUND = TRUE CMake Warning (dev) at /usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "test-ra_blocks". Use the target name directly with add_custom_command, or use the generator expression $, as appropriate. Call Stack (most recent call first): lib/CMakeLists.txt:71 (GR_ADD_TEST) This warning is for project developers. Use -Wno-dev to suppress it. -- -- Checking for module SWIG -- Command "/usr/bin/swig2.0 -swiglib" failed with output: -- Found SWIG version 2.0.12. -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.11+") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version "2.7.11+", minimum required is "2") -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") -- Configuring done -- Generating done -- Build files have been written to: /home/john/gr-ra_blocks/trunk when I did a make, I got: [ 48%] Generating ra_blocks_swig.tag Scanning dependencies of target ra_blocks_swig_swig_2d0df [ 52%] Building CXX object swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o [ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df Swig source /bin/sh: 1: /usr/bin/swig2.0: not found swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134: recipe for target 'swig/ra_blocks_swig_swig_2d0df' failed make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127 make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df' CMakeFiles/Makefile2:274: recipe for target 'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all] Error 2 Makefile:138: recipe for target 'all' failed make: *** [all] Error 2 I wonder if I have made an error some way along, but cannot imagine what. Any ideas? Kind Regards, John oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks. Sorry, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS
On 30/05/16 22:29, Marcus D. Leech wrote: On 05/30/2016 06:27 PM, John Shields wrote: oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks. Sorry, John Which is a pre-req for simple_ra ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks Marcus, 16.04 comes with swig 3.0 so I removed that and installed swig 2.0 and it seems to work. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS
On 31/05/16 07:40, Marcus Müller wrote: That shouldn't be necessary. If I remember correctly, my automated test builds based on PyBOMBS go through without installing an old version of SWIG. Hence, we'd be interested in where things fail on your machine with swig3. Best regards, Marcus Am 31. Mai 2016 01:53:54 MESZ, schrieb John Shields : On 30/05/16 22:29, Marcus D. Leech wrote: On 05/30/2016 06:27 PM, John Shields wrote: oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks. Sorry, John Which is a pre-req for simple_ra ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks Marcus, 16.04 comes with swig 3.0 so I removed that and installed swig 2.0 and it seems to work. Kind Regards, John Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Sent from my Android device with K-9 Mail. Please excuse my brevity. Marcus, Here is the full trace - again this was with gr-ra-blocks and swig 3.0. When, with your advice, I swapped it out for swig 2.0 , everything worked. Also, as mentioned in the previous e-mail, GNURadio (using your script) did work correctly even with swig 3.0 john@i7Ubuntu:~/gr-ra_blocks/trunk$ cmake . -- The CXX compiler identification is GNU 5.3.1 -- The C compiler identification is GNU 5.3.1 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Build type not specified: defaulting to release. -- Boost version: 1.58.0 -- Found the following Boost libraries: -- filesystem -- system -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") Checking for GNU Radio Module: RUNTIME * INCLUDES=/usr/local/include * LIBS=/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so GNURADIO_RUNTIME_FOUND = TRUE Checking for GNU Radio Module: BLOCKS * INCLUDES=/usr/local/include * LIBS=/usr/local/lib/libgnuradio-blocks.so;/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so GNURADIO_BLOCKS_FOUND = TRUE CMake Warning (dev) at /usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "test-ra_blocks". Use the target name directly with add_custom_command, or use the generator expression $, as appropriate. Call Stack (most recent call first): lib/CMakeLists.txt:71 (GR_ADD_TEST) This warning is for project developers. Use -Wno-dev to suppress it. -- -- Checking for module SWIG -- Command "/usr/bin/swig2.0 -swiglib" failed with output: -- Found SWIG version 2.0.12. -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.11+") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version "2.7.11+", minimum required is "2") -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") -- Configuring done -- Generating done -- Build files have been written to: /home/john/gr-ra_blocks/trunk john@i7Ubuntu:~/gr-ra_blocks/trunk$ make Scanning dependencies of target gnuradio-ra_blocks [ 4%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/slicer_impl.cc.o [ 8%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/vector_power_impl.cc.o [ 12%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_folder_impl.cc.o [ 16%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_detect_impl.cc.o [ 20%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_clock_impl.cc.o [ 24%] Linking CXX shared library libgnuradio-ra_blocks.so [ 24%] Built target gnuradio-ra_blocks Scanning dependencies of target test-ra_blocks [ 28%] Building CXX object lib/CMakeFiles/test-ra_blocks.dir/test_ra_blocks.cc.o [ 32%] Building CXX object lib/CMakeFiles/test-ra_blocks.dir/qa_ra_blocks.cc.o [ 36%] Linking CXX exe
[Discuss-gnuradio] Porting from 3.6.something
I am toying with the hypothetical idea of bringing a large and fragmented OOT codebase out of the stone age. I remember hearing about a tool that would convert Cpp blocks from 3.6 to the 3.7 API. Was that a real thing? Also, what will 3.8 break and will everyone think less of me if I spend 4-5 years on 3.7? :) -John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
