Re: [Discuss-gnuradio] ImportError: cannot import name usrp
To expand on that: Libusrp isn't compatible to any modern USRP, and if
you've got code from that era: Reimplement it in modern GNU Radio,
mostly. You can't hope to copy much of that, because the last version
of GNU Radio to contain libusrp was I think 3.4.2, and that's been
obsolete since the release of GNU Radio 3.5.0, and that was 8 years
ago.
Laura, a lot of your problems seem to stem from the fact that you might
be having a hard time investigating Python errors yourself. Since you
seem to be in need of writing Python, the time-rational thing to do is
learning and practicing Python with a book or tutorial. Starting with
something as large and complex as a GNU Radio transceiver application
incorporating non-deterministic signals and even worse hardware is
really not a promising approach in terms of investing your learning
time wisely.
Best regards,
Marcus
On Tue, 2019-10-15 at 02:35 +, Kyeong Su Shin wrote:
> Hello Laura (and to whom it may concern),
>
> I believe that what you have there are legacy codes which use libusrp,
> instead of libuhd. libusrp has been replaced by libuhd a few years ago.
>
> As Nate suggested, please replace all blocks with on libusrp to libuhd. It
> shouldn't be too hard. (see:
> https://www.gnuradio.org/doc/sphinx-v3.7.9.2/uhd_blocks.html#gnuradio.uhd.usrp_sink
> ,
> https://www.gnuradio.org/doc/sphinx-v3.7.9.2/uhd_blocks.html#gnuradio.uhd.usrp_source
> )
>
> For the interpolation rate, I think you can replace that with set_samp_rate
> (not too sure, though) as I am not particularly familiar with libusrp).
>
> Regards,
> Kyeong Su Shin
> 보낸 사람: Laura Arjona 대신 Discuss-gnuradio
>
> 보낸 날짜: 2019년 10월 15일 화요일 오전 4:58
> 받는 사람: Nate Temple
> 참조: GNURadio Discussion List
> 제목: Re: [Discuss-gnuradio] ImportError: cannot import name usrp
>
> of course, thank you.
>
> This is the code (old) I am trying to adapt to use it.
>
>tx = usrp.sink_c(fusb_block_size = 1024, fusb_nblocks=8)
> tx.set_interp_rate(interp_rate)
> tx_subdev = (0,0)
> tx.set_mux(usrp.determine_tx_mux_value(tx, tx_subdev))
> subdev = usrp.selected_subdev(tx, tx_subdev)
> subdev.set_enable(True)
> subdev.set_gain(subdev.gain_range()[2])
> t = tx.tune(subdev.which(), subdev, freq)
>
> On Fri, Oct 11, 2019 at 1:39 PM Nate Temple wrote:
> > Can you post the code in question?
> >
> > On Fri, Oct 11, 2019 at 1:32 PM Laura Arjona wrote:
> > > Thank you Nate.
> > >
> > > Yes, that is the configuration I had before. But I using someone else's
> > > code for a different USRP, and getting errors with the usrp_sink_c to set
> > > the fusb block size
> > >
> > > On Fri, Oct 11, 2019 at 1:28 PM Nate Temple wrote:
> > > > You should pass in the cpu_format as an arg such as below:
> > > >
> > > > sink = uhd.usrp_sink(
> > > > ",".join(("", "")),
> > > > uhd.stream_args(
> > > > cpu_format="fc32",
> > > > channels=range(1),
> > > > ),
> > > > )
> > > >
> > > > On Fri, Oct 11, 2019 at 1:16 PM Laura Arjona wrote:
> > > > > Got it, thank you!
> > > > >
> > > > > However, usrp_sink_c is not supported anymore? Get an error there too.
> > > > >
> > > > > tx = usrp_sink_c(fusb_block_size = 1024, fusb_nblocks=8)
> > > > >
> > > > > On Fri, Oct 11, 2019 at 1:11 PM Nate Temple
> > > > > wrote:
> > > > > > Hi Laura,
> > > > > >
> > > > > > It should be:
> > > > > >
> > > > > > from gnuradio import uhd
> > > > > >
> > > > > > source = uhd.usrp_source(...)
> > > > > > ...
> > > > > >
> > > > > > I would suggest to try building out a basic flowgraph in GRC and
> > > > > > then use the generate button and checkout the source made from it.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Nate Temple
> > > > > >
> > > > > >
> > > > > > On Fri, Oct 11, 2019 at 1:06 PM Laura Arjona wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I am using a usrp b200-mini, and I am trying to define the sink
> > > > > > > as follows:
> > > > > > > tx = usrp_sink_c(fusb_block_size = 1024, fusb_nblocks=8)
> > > > > > >
> > > > > > > However, I get the error
> > > > > > > from gnuradio import usrp
> > > > > > > ImportError: cannot import name usrp
> > > > > > >
> > > > > > > I believe my GNU-radio installation is correct.
> > > > > > > Any clue of how to fix this?
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > > --
> > > > > > > Laura Arjona
> > > > > > > ___
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > Discuss-gnuradio@gnu.org
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > >
> > > > >
> > > > > --
> > > > > Laura Arjona
> > > > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > > > Neuroengineering
> > > > >
> > > > > Paul G. Allen School of Computer Science & Engineering
> > > > > 185 E Stevens Way NE
> > > > > University of Washington
> > > > > Seattl
Re: [Discuss-gnuradio] Request for Wiki update.
Hi Hans, I'm happy that Kyeong fixed that page. But honestly, you shouldn't *need* to compile GNU Radio from source, unless you want a recent development version of it. What's the reason you're doing that? Best regards, Marcus On Tue, 2019-10-15 at 08:13 +0800, HansFong wrote: > Can somebody with the appropriate powers to change a GR wiki page please add > the following to the install instructions > (https://wiki.gnuradio.org/index.php/InstallingGR)? > > In the section "Compiling from source" after "make install" add the > following: > > sudo ldconfig > > It took me half a day to compile GNUradio, another half to figure out this > last step. I'm sorry to criticize, but in my experience GNUradio is one of > the most frustrating pieces of software to install because the documentation > is so incomplete or haphazard. This goes especially for GR noobs like myself. > Cheers and 73 > > Hans > > BX2ABT > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Request for Wiki update.
Because I never succeed with pyBOMBS and the distro packages are outdated. I know I'm going to ruffle some feathers, but my intentions are noble, so here it is: GNUradio is by far the worst project I've seen in my 20 years are a Linux user when it comes to documentation. It's almost un-Linux how bad it is. Because with Linux you can RTFM (remember that one. Is hardly used nowadays, it seems) and then use google if the problem you are facing is very specific. If you still don't "get it" then maybe a question on a forum, or IRC. With GNUradio the manual (read: Wiki) is a mess, with pages not in the index, old or missing information and broken links. Then there is also information on github, but non of the afore mentioned sources will give you a working installation, because you can't see the forests for the trees. If you are an insider, maybe yes. But to a interested newcomer, not. Give you an example: compiled from source using the Wiki instruction. So GR did start up, but I got version 3.9! Isn't 3.8 the current version? But with the git reference on the Wiki you will download version 3.9. No hint whatsoever on how to install 3.8, which git reference to use, what to watch out for, etc. The Wiki has nothing on 3.8!!! This is really bad and will make for a very bad impression to people who want to try GR. There is this reflector to ask questions, but as I stated earlier, this isn't the right way to do things: RTFM, google, forum. Then there is pyBOMBS, which is supposed to make life easier. It might, if it works, but it doesn't. Apparently GR is so complex that even GR insiders can't write a script that can grok everything that is needed to install GR. The complexity of dealing with many Linux distros is a factor I can understand, but then again, I'm using (K)ubuntu and if pyBOMBS can't even install successfully on Kubuntu then I think there is a serious problem. I've been compiling software on Linux for the past 20 years, so in the end I just thought "what the heck" and did it myself. Wasn't too difficult and I did get a working piece of software, albeit not the 3.8 version I wanted. On Twitter people already told me how to compile 3.8, so I'll nuke my install and do it again. The above isn't very positive, but it's not a rant, because ranting is not productive. But since you asked I do think I need to be honest in telling you what I think about GR and hopefully it will help getting a better understanding of how outsiders look at GR and maybe will cause some improvements. I can't be (and I know I'm not) the only one who has a not so favorable impression of GR, but we radio amateurs will still be trying to install and use GR, because in essence it is a good piece of software and we desperately need something like GR on Linux. But fun installing it ain't! For sure. My suggestion for improving things: only release a new version when both the software and documentation are ready and then make a clear distinction between documentation for the old and new versions of the software. 73 and greetings from Taiwan Hans BX2ABT On 10/15/19 6:21 PM, Müller, Marcus (CEL) wrote: Hi Hans, I'm happy that Kyeong fixed that page. But honestly, you shouldn't *need* to compile GNU Radio from source, unless you want a recent development version of it. What's the reason you're doing that? Best regards, Marcus On Tue, 2019-10-15 at 08:13 +0800, HansFong wrote: Can somebody with the appropriate powers to change a GR wiki page please add the following to the install instructions (https://wiki.gnuradio.org/index.php/InstallingGR)? In the section "Compiling from source" after "make install" add the following: sudo ldconfig It took me half a day to compile GNUradio, another half to figure out this last step. I'm sorry to criticize, but in my experience GNUradio is one of the most frustrating pieces of software to install because the documentation is so incomplete or haphazard. This goes especially for GR noobs like myself. Cheers and 73 Hans BX2ABT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Request for Wiki update.
> I know I'm going to ruffle some feathers, but my intentions are noble, > so here it is: GNUradio is by far the worst project I've seen in my 20 > years are a Linux user when it comes to documentation. You've used linux for 20 years and it took you half a day to figure out you need to call ldconfig ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems switching project from USRP N210+SBX to an USRP B200-mini
Laura,
are you getting any error messages you can post?
On Mon, Oct 14, 2019 at 1:21 PM Laura Arjona wrote:
> Hello community,
>
> I have a project running on an USRP N210 (a flowgraph consisting of
> several OOT modules written all in C++).
>
> I want to run the same project on an *USRP B200-mini*. I assumed that I
> would only need to modify the *uhd_source* and *uhd_sink* configuration
> in the */apps/main.py* file
> (the rest of the project is bascially C++ code which should be independent
> on the platform).
>
> However, my usrp200-mini seems to work properly for the first command
> transmitted, and then shuts down (the transmitted signal drops to 0).
> Any help would be appreciated. Thank you very much for your time.
>
>
> *Configuration for USRP N210+SBX*
> # Configure usrp source
> def u_source(self):
> self.source = uhd.usrp_source(
> device_addr=self.usrp_address_source,
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> ),
> )
> self.source.set_samp_rate(self.adc_rate)
> self.source.set_center_freq(self.freq, 0)
> self.source.set_gain(self.rx_gain, 0)
> self.source.set_antenna("RX2", 0)
> self.source.set_auto_dc_offset(False) # Uncomment this line for SBX
> daughterboard
>
> # Configure usrp sink
> def u_sink(self):
> self.sink = uhd.usrp_sink(
> device_addr=self.usrp_address_sink,
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> )
> )
> self.sink.set_samp_rate(self.dac_rate)
> self.sink.set_center_freq(self.freq, 0)
> self.sink.set_gain(self.tx_gain, 0)
> self.sink.set_antenna("TX/RX", 0)
>
> def __init__(self, myfreq):
> gr.top_block.__init__(self)
> self.dac_rate = 100e6/50 # DAC rate
> self.adc_rate = 100e6/26# ADC rate
> self.freq = myfreq
> self.rx_gain = -5
> self.tx_gain = 25
> self.usrp_address_source = "addr=192.168.10.105"
> self.usrp_address_sink = "addr=192.168.10.105"
>
>
>
> *Configuration for USRPN210+SBX*
>
> self.source = uhd.usrp_source(
> device_addr=self.usrp_address_source,
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> ),
> )
> self.source.set_samp_rate(self.adc_rate)
> self.source.set_center_freq(self.freq, 0)
> self.source.set_gain(self.rx_gain, 0)
> self.source.set_antenna("RX2", 0)
> self.source.set_auto_dc_offset(False)
>
> # Configure usrp sink
> def u_sink(self):
> self.sink = uhd.usrp_sink(
> device_addr=self.usrp_address_sink,
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> )
> )
> self.sink.set_samp_rate(self.dac_rate)
> self.sink.set_center_freq(self.freq, 0)
> self.sink.set_gain(self.tx_gain, 0)
> self.sink.set_antenna("TX/RX", 0)
>
> def __init__(self, myfreq):
> gr.top_block.__init__(self)
> self.dac_rate = 100e6/44 # DAC rate
> self.adc_rate = 100e6/44# ADC rate
> self.rx_gain = 300
> self.tx_gain = 300
> self.usrp_address_source = "serial=31861F8"
> self.usrp_address_sink = "serial=31861F8"
>
>
> --
> *Laura Arjona *
>
>
>
>
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Request for Wiki update.
Hi Hans, Marcus, and others, I totally agree with Hans: "Because I never succeed with pyBOMBS and the distro packages are outdated." I have tried using PyBOMBS on my Mac and on my Raspberry Pi 3B+, and neither one worked. As far as distro packages, they are all way behind. Attached is a detailed procedure for installing 3.8 on a Raspberry Pi. Basically it should work for any Linux system. I welcome suggestions for corrections and/or improvement. As far as 3.8 vs. 3.9, what I have found is that all of the software is 3.8 on the maint-3.8 branch except for Gnu Radio Companion which is 3.9. So when I install an OOT module, I have to change the CMakeLists.txt to look for 3.9 instead of 3.8. Sylvain: What's so obvious about 'ldconfig'? I've used Unix/Linux for well over 20 years, and had never even heard about it until Kyeong su Shin told me recently. It all depends on one's previous experience. Glen: Nice project! So, bottom line -- what can *I* do to help with the documentation? I haven't worked on a Wiki before, but am willing to learn. I do know the basics of Markdown. Is there any sort of review or approval process? Nate: Should I contact Marc Lichtman and Cyrille Morin on this? Respectfully, Barry Duggan KV4FV see previous items in this thread here: https://lists.gnu.org/archive/html/discuss-gnuradio/2019-10/msg00074.html Build gnuradio on Raspberry Pi 3B+ Author: Barry Duggan 12 Sept 2019 OS: Raspbian Buster with desktop and recommended software 32GB microSD A. Load prerequisites sudo apt-get update --allow-releaseinfo-change sudo apt-get upgrade sudo apt-get install git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy sudo apt-get install python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev sudo apt-get install libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 sudo apt-get install liblog4cpp5-dev libzmq3-dev python3-yaml sudo apt-get install libpthread-stubs0-dev sudo pip3 install click-plugins sudo apt-get install python3-scipy D. Set up swap file sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile - To make this permanent, add this line to /etc/fstab /swapfile none swap sw 0 0 C. Clone repository cd git clone --recursive https://github.com/gnuradio/gnuradio.git git checkout maint-3.8 D. Build cd ~/gnuradio mkdir build cd build (this next command is all on one line, starting with cmake and ending with ../) cmake -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ make -j3 sudo make install sudo ldconfig ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cross-compiling UHD for E310
Hi Nate, I obtained SDK using my installation of UHD v3.15.0. user@machine:~/usrp_e310_sdk$ cat version-cortexa9hf-neon-oe-linux-gnueabi Distro: Alchemy Distro Version: 2018.04 Metadata Revision: a5dcf0c4bd9a0be2f2484b0b1b3e77f1f2128dfc Timestamp: 20190426232955 I'm trying to compile UHD from git, the last version. Thank you. Ivan > Il giorno 14 ott 2019, alle ore 21:02, Nate Temple ha > scritto: > > > Hi Ivan, > > What version of GNU Radio / UHD are you trying to compile? > > The existing release-4 SDK won't support GR 3.8 as it lacks several deps. > > Checkout this app note which covers cross compiling UHD (with RFNoC enabled) > / GR / gr-ettus. If you're not trying to use the RFNoC build, you can use > most of the instructions, but skip the cmake arg -DENABLE_RFNOC=ON > > https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source > > > Regards, > Nate Temple > >> On Mon, Oct 14, 2019 at 11:52 AM wrote: >> Hello guys! >> I'm trying to cross-compile uhd drivers for my E310 (SD image just updated). >> I installed the toolchain as in >> http://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_sdk,. >> When I try to compile the uhd drivers I obtain: >> https://pastebin.com/SAAFxXzv >> It seems that python libraries are not found. >> How can I solve? >> Thanks so much. >> Ivan >> >> >> >> Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a soli >> 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. >> http://tisca.li/smart30 >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cross-compiling UHD for E310
I forgot to say... Following the application note you recommended, I obtain the same results. Thank you. Ivan >> Il giorno 14 ott 2019, alle ore 21:02, Nate Temple >> ha scritto: > > Hi Ivan, > > What version of GNU Radio / UHD are you trying to compile? > > The existing release-4 SDK won't support GR 3.8 as it lacks several deps. > > Checkout this app note which covers cross compiling UHD (with RFNoC enabled) > / GR / gr-ettus. If you're not trying to use the RFNoC build, you can use > most of the instructions, but skip the cmake arg -DENABLE_RFNOC=ON > > https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source > > > Regards, > Nate Temple > >> On Mon, Oct 14, 2019 at 11:52 AM wrote: >> Hello guys! >> I'm trying to cross-compile uhd drivers for my E310 (SD image just updated). >> I installed the toolchain as in >> http://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_sdk,. >> When I try to compile the uhd drivers I obtain: >> https://pastebin.com/SAAFxXzv >> It seems that python libraries are not found. >> How can I solve? >> Thanks so much. >> Ivan >> >> >> >> Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a soli >> 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. >> http://tisca.li/smart30 >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Request for Wiki update.
Hi Barry, If you're just getting started with mediawiki/markdown, it would probably be best to join the GNU Radio slack channel and coordinate within the #docs channel, you can register here [0] and then login here[1] [0] - https://slack.gnuradio.org/ [1] - https://gnuradio.slack.com/ Regards, Nate Temple On Tue, Oct 15, 2019 at 12:08 PM Barry Duggan wrote: > Hi Hans, Marcus, and others, > > I totally agree with Hans: "Because I never succeed with pyBOMBS and the > distro packages are outdated." I have tried using PyBOMBS on my Mac and > on my Raspberry Pi 3B+, and neither one worked. As far as distro > packages, they are all way behind. > > Attached is a detailed procedure for installing 3.8 on a Raspberry Pi. > Basically it should work for any Linux system. I welcome suggestions for > corrections and/or improvement. > > As far as 3.8 vs. 3.9, what I have found is that all of the software is > 3.8 on the maint-3.8 branch except for Gnu Radio Companion which is 3.9. > So when I install an OOT module, I have to change the CMakeLists.txt to > look for 3.9 instead of 3.8. > > Sylvain: What's so obvious about 'ldconfig'? I've used Unix/Linux for > well over 20 years, and had never even heard about it until Kyeong su > Shin told me recently. It all depends on one's previous experience. > > Glen: Nice project! > > So, bottom line -- what can *I* do to help with the documentation? I > haven't worked on a Wiki before, but am willing to learn. I do know the > basics of Markdown. Is there any sort of review or approval process? > > Nate: Should I contact Marc Lichtman and Cyrille Morin on this? > > Respectfully, > Barry Duggan KV4FV > > see previous items in this thread here: > https://lists.gnu.org/archive/html/discuss-gnuradio/2019-10/msg00074.html > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] E320 Network Mode TX on both channels
have gnuradio companion 3.7.13.5 (UHD_3.14.1.HEAD-0-g5491b80e) loaded UHD_3.14.1.0-0-g0d934195 firmware on the e320 downloaded and installed the FPGA for network mode on the e320 created a simple grc flow. 2 signal source (cosine) each going to a channel on the UHD: USRP Sink (Mb0 Subdev A:0 and A:1) when it runs both transmit lights come on, but i only see one freq transmitted on my speca. i can get either freq to transmit out of either port, but never at the same time. is this a limitation of grc or the e320? i had tried a similar setup with a e310 in embedded mode with the same results. David Stockton (CTR) 719.554.4219 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E320 Network Mode TX on both channels
Hi David, This sounds like it might be a bug with the E320. Can you email us at supp...@ettus.com and we can debug the issue through that channel? Regards, Nate Temple On Tue, Oct 15, 2019 at 12:37 PM David Stockton (CTR) < stocktond@spacepros.org> wrote: > have gnuradio companion 3.7.13.5 (UHD_3.14.1.HEAD-0-g5491b80e) > > loaded UHD_3.14.1.0-0-g0d934195 firmware on the e320 > > downloaded and installed the FPGA for network mode on the e320 > > created a simple grc flow. 2 signal source (cosine) each going to a > channel on the UHD: USRP Sink (Mb0 Subdev A:0 and A:1) > > when it runs both transmit lights come on, but i only see one freq > transmitted on my speca. i can get either freq to transmit out of either > port, but never at the same time. > > is this a limitation of grc or the e320? > i had tried a similar setup with a e310 in embedded mode with the same > results. > > > > > David Stockton (CTR) > 719.554.4219 > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cross-compiling UHD for E310
Hi Ivan, I would not recommend to use the 'master' branch at this time with the E310 release-4 SDK. UHD 3.15.x.x bumps the deps from what is used in the release-4 SDK. I would recommend to try using the version 3.14.1.1, which is the latest stable release (note, you'll need to install python-six as described in the app note). We will be releasing a new FS/SDK for the E310 with the upcoming UHD 3.15 release. Regards, Nate Temple On Tue, Oct 15, 2019 at 12:15 PM Ivan Iudice wrote: > I forgot to say... Following the application note you recommended, I > obtain the same results. > Thank you. > > Ivan > > Il giorno 14 ott 2019, alle ore 21:02, Nate Temple > ha scritto: > > > Hi Ivan, > > What version of GNU Radio / UHD are you trying to compile? > > The existing release-4 SDK won't support GR 3.8 as it lacks several deps. > > Checkout this app note which covers cross compiling UHD (with RFNoC > enabled) / GR / gr-ettus. If you're not trying to use the RFNoC build, you > can use most of the instructions, but skip the cmake arg -DENABLE_RFNOC=ON > > > https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source > > > Regards, > Nate Temple > > On Mon, Oct 14, 2019 at 11:52 AM wrote: > >> Hello guys! >> I'm trying to cross-compile uhd drivers for my E310 (SD image just >> updated). >> I installed the toolchain as in >> http://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_sdk,. >> When I try to compile the uhd drivers I obtain: >> https://pastebin.com/SAAFxXzv >> It seems that python libraries are not found. >> How can I solve? >> Thanks so much. >> Ivan >> >> >> >> Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a >> soli 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. >> http://tisca.li/smart30 >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Request for Wiki update.
Hi Hans, hi Glen and Barry and everyone in this thread, I had a longish answer written out to this, addressing all the things that I agreed to, and explaining quite a fair bit of where you're wrong, but I decided to scrap it and reduce it to three bullet points: 1. A very honest: Thank you for the feedback! We are aware that installation of our ca. 40 lines of code project is non-trivial, and that we've been so busy releasing 3.8 that we couldn't keep up with installation instructions. I'm honestly sorry about that, but it's not easy on us, either, though we've made stellar progress in the last couple of years. 2. You (specifically) shouldn't be in a position where you need to compile things from source code or use PyBOMBS to build it. You want to use GNU Radio, not develop it itself (for now). New users wanting to try GNU Radio are the last people I want to compile GNU Radio from source. That'd be plain stupid. This isn't the 90s. Unless you really can pinpoint why you need 3.8 instead of the 3.7.13.4 (or .5) that Kubuntu packages, I'd encourage you to just go and install via `apt install gnuradio`. Many ham-relevant GNU Radio projects have not even been ported to GNU Radio 3.8+ yet, officially (gr-osmosdr, for example, but I'm hearing good things about the state of forks of that); certainly, not getting more people to run GNU Radio 3.8 won't exactly help that, but since you're clearly in no position to contribute a lot of code to these at this point, doing your learning on a stable, universally supported 3.7.13.x doesn't hurt you or the project, I think. When Ubuntu finally gets around copying the work that Maitland does for debian (which already has 3.8 packages), you'll enjoy that, too! 3. As project maintainer, my priorities are making recent GNU Radio package installation feasible to you, and we have multiple people working on packaging for different platforms, and on working on providing regular packages etc. The outlook of making source builds easier on people that struggle a bit with reading the versioning files and git usage: VERY desirable, but not high priority for now. If a set of build instructions is easy enough for a beginner to copy without mistake, then that set of instructions should become a build script for a binary package and be upstreamed to the favourite distro of the user, preferably. In that effort, I can only ask you to help: If you encounter build problems, report them in detail. Best regards, Marcus On Tue, 2019-10-15 at 22:53 +0800, HansFong wrote: > Because I never succeed with pyBOMBS and the distro packages are > outdated. > > I know I'm going to ruffle some feathers, but my intentions are > noble, > so here it is: GNUradio is by far the worst project I've seen in my > 20 > years are a Linux user when it comes to documentation. It's almost > un-Linux how bad it is. Because with Linux you can RTFM (remember > that > one. Is hardly used nowadays, it seems) and then use google if the > problem you are facing is very specific. If you still don't "get it" > then maybe a question on a forum, or IRC. > > With GNUradio the manual (read: Wiki) is a mess, with pages not in > the > index, old or missing information and broken links. Then there is > also > information on github, but non of the afore mentioned sources will > give > you a working installation, because you can't see the forests for > the > trees. If you are an insider, maybe yes. But to a interested > newcomer, not. > > Give you an example: compiled from source using the Wiki instruction. > So > GR did start up, but I got version 3.9! Isn't 3.8 the current > version? > But with the git reference on the Wiki you will download version 3.9. > No > hint whatsoever on how to install 3.8, which git reference to use, > what > to watch out for, etc. The Wiki has nothing on 3.8!!! This is > really > bad and will make for a very bad impression to people who want to > try > GR. There is this reflector to ask questions, but as I stated > earlier, > this isn't the right way to do things: RTFM, google, forum. > > Then there is pyBOMBS, which is supposed to make life easier. It > might, > if it works, but it doesn't. Apparently GR is so complex that even > GR > insiders can't write a script that can grok everything that is needed > to > install GR. The complexity of dealing with many Linux distros is a > factor I can understand, but then again, I'm using (K)ubuntu and if > pyBOMBS can't even install successfully on Kubuntu then I think there > is > a serious problem. > > I've been compiling software on Linux for the past 20 years, so in > the > end I just thought "what the heck" and did it myself. Wasn't too > difficult and I did get a working piece of software, albeit not the > 3.8 > version I wanted. On Twitter people already told me how to compile > 3.8, > so I'll nuke my install and do it again. > > The above isn't very positive, but it's not a rant, because ranting > is > not produ
Re: [Discuss-gnuradio] Cross-compiling UHD for E310
Thanks so much! UHD 3.14.1.1 just compiled! Now I have a problem installing python-six with PYTHONPATH: https://pastebin.com/tMti3EBL Could you help me? Thank you for all. Ivan Il 15.10.2019 22:08 Nate Temple ha scritto: > Hi Ivan, > > I would not recommend to use the 'master' branch at this time with the E310 release-4 SDK. UHD 3.15.x.x bumps the deps from what is used in the release-4 SDK. > > I would recommend to try using the version 3.14.1.1, which is the latest stable release (note, you'll need to install python-six as described in the app note). > > We will be releasing a new FS/SDK for the E310 with the upcoming UHD 3.15 release. > > Regards, > Nate Temple > > On Tue, Oct 15, 2019 at 12:15 PM Ivan Iudice wrote: > >> I forgot to say... Following the application note you recommended, I obtain the same results. >> Thank you. >> Ivan >> >>> Il giorno 14 ott 2019, alle ore 21:02, Nate Temple ha scritto: >> >>> Hi Ivan, >>> >>> What version of GNU Radio / UHD are you trying to compile? >>> >>> The existing release-4 SDK won't support GR 3.8 as it lacks several deps. >>> >>> Checkout this app note which covers cross compiling UHD (with RFNoC enabled) / GR / gr-ettus. If you're not trying to use the RFNoC build, you can use most of the instructions, but skip the cmake arg -DENABLE_RFNOC=ON >>> >>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source [7] >>> >>> Regards, >>> Nate Temple >>> >>> On Mon, Oct 14, 2019 at 11:52 AM wrote: >>> Hello guys! I'm trying to cross-compile uhd drivers for my E310 (SD image just updated). I installed the toolchain as in http://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_software_dev_sdk, [2]. When I try to compile the uhd drivers I obtain: https://pastebin.com/SAAFxXzv [3] It seems that python libraries are not found. How can I solve? Thanks so much. Ivan Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a soli 7,99EUR al mese. L'attivazione è gratis e disdici quando vuoi. http://tisca.li/smart30 [4] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org [5] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [6] -- by krono86 ...e vada come vuole, un uomo non puo che morire una sola volta http://www.krono86.netsons.org Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a soli 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. http://tisca.li/smart30 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RTL-SDR source not working in 3.7.14.5
There are installers for windows: http://www.gcndevelopment.com/gnuradio That will come with RTL-SDR drivers, etc. Just run the "run_grc.bat" from the /bin directory (or use the installed shortcuts) Geof On Sat, Oct 12, 2019 at 8:42 AM Chris Gorman wrote: > Hmm, > > Not too sure what is wrong. First off are you sure you have version > 3.7.14.5? I have 3.7.13.5 and can't find your newer version in the > releases (https://www.gnuradio.org/releases/gnuradio/). Assuming you > have just made a small typo, I have built gr-osmosdr successfully with > 3.7.13.5. Here are the build instructions from the README > > git clone git://git.osmocom.org/gr-osmosdr > cd gr-osmosdr/ > mkdir build > cd build/ > cmake ../ > make > sudo make install > sudo ldconfig > > It has been a while since I built this, so I don't recall the > dependencies you need to install, but you will at least need the dev > files for your rtl-sdr source. I recommend trying to install the > rtl-sdr libraries and headers as described in > https://osmocom.org/projects/rtl-sdr/wiki . (Note this needs to be > done before you install gr-osmosdr.) > > As to installing under windows, I don't know how to help with that. Sorry. > > Let me know what you get after trying to build rtl-sdr and gr-osmosdr. > > Chris > > On Sat, Oct 12, 2019 at 8:07 AM Beau Thompson wrote: > > > > Hi If i try an run any code with RTL-SDR source it will not run > > > > how can i fix this or is there a way i can have to installs under windows > > > > thanks beau > > > > > > ___ > > 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] Pybombs broken?
Hello, I'm using pybombs to install gnuradio 3.7.13.5 onto ubuntu 18.04. Pybombs seems to be unable to install dependencies anymore. Each time I run pybombs prefix init ~/Documents/gnuradio/gr37 -a gr37 -R gnuradio-default it goes for a while until it finds software that is missing and errors out. I then manually install the software and rerun the above command. I've had to do this for several dependencies now, including: mako, cppunit, pyqt4, cheetah, thrift, numpy and more. Did something change recently that broke pybombs? About a year ago I was using it without much problem, it installed everything for me. v/r, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Anaconda Python and GR
I'm having trouble with a gnuradio install. It built successfully, but I can't import gnuradio in python. I believe it is because I'm using anaconda python. My group has a linux setup script we run to configure software on fresh ubuntu installs. I ran this script and now when I type 'which python' I get: /opt/anaconda3/bin/python instead of the standard /usr/bin/python Is there a way I can overcome this by modifying the setup_env.sh script, or does it require a special gnuradio compile? Do you think this is even the problem? I'm not sure how to debug from here. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reading/processing off-air DVB-T transport stream
I am attempting to read samples of an off-air DVB-T transport stream into an IQ file for offline analysis but can't get it to work at all. I can run the dvbt_rx_8k.grc example which reads the adv16.cfile IQ TS file produced by Ron Economos, displays the FFT and 16 QAM constellation and produces a valid .ts file which can be played with a video player.. I adapted that example flow-graph for a local off-air MUX with parameters; 64QAM, 2/3 rate, 1/4 guard interval, 8K FFT. The FFT displays OK but the constellation graph does not work and show the expected 8 x 8 matrix -- instead it shows just a single dot in the middle. This https://www.mklab.rhul.ac.uk/~tom/tvdx/gr/dvbt_rx_8k_64QAM_chD44-live.grc cut-down demo attempts to sample channel channel D44 live using an RTL2832/E4000 USB stick. I have also tried using the rtl_sdr dump-to-IQ-file utility and converting the format from 8-bit uint into 32-bit float (complex) using the sox utility, eg. rtl_sdr -f 65800 -s 280 -n $[28*60] chD44.raw sox -t raw -r 280 -b 8 -c 1 -e unsigned-integer chD44.raw -t raw -r 280 -c 1 -e float chD44-sox.raw using a sample rate of 2.8M here, and processing the resultant IQ file with grc but the result is the same. I also tried with a 3.2M sample rate, the maximum permitted value with RT2832 USBs sticks but again without success. Am I doing something wrong in grc or it is just that these sample rates are nowhere near sufficient for the whole-MUX type of data I am attempting to capture? I was able to adapt the dvbt_rx_8k.grc demo for a 64QAM file (adv64.cfile also from Ron Economos) and process that OK in grc. Many thanks Tom Crane -- Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill, Egham, Surrey, TW20 0EX, England. Email: t.cr...@rhul.ac.uk Fax:+44 (0) 1784 472794 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading/processing off-air DVB-T transport stream
The bandwidth of DVB-T is 8 MHz (or 7 MHz for VHF). You can't capture that much bandwidth with an RTL-SDR. The required sample rate is (800.0 * 8) / 7 = 9.14286 Msps for an 8 MHz channel, or (800.0 * 7) / 7 = 8 Msps for a 7 MHz channel. You need an SDR that can handle these sample rates such as bladeRF, hackRF, USRP, etc. Ron On 10/15/19 18:11, Tom Crane wrote: I am attempting to read samples of an off-air DVB-T transport stream into an IQ file for offline analysis but can't get it to work at all. I can run the dvbt_rx_8k.grc example which reads the adv16.cfile IQ TS file produced by Ron Economos, displays the FFT and 16 QAM constellation and produces a valid .ts file which can be played with a video player.. I adapted that example flow-graph for a local off-air MUX with parameters; 64QAM, 2/3 rate, 1/4 guard interval, 8K FFT. The FFT displays OK but the constellation graph does not work and show the expected 8 x 8 matrix -- instead it shows just a single dot in the middle. This https://www.mklab.rhul.ac.uk/~tom/tvdx/gr/dvbt_rx_8k_64QAM_chD44-live.grc cut-down demo attempts to sample channel channel D44 live using an RTL2832/E4000 USB stick. I have also tried using the rtl_sdr dump-to-IQ-file utility and converting the format from 8-bit uint into 32-bit float (complex) using the sox utility, eg. rtl_sdr -f 65800 -s 280 -n $[28*60] chD44.raw sox -t raw -r 280 -b 8 -c 1 -e unsigned-integer chD44.raw -t raw -r 280 -c 1 -e float chD44-sox.raw using a sample rate of 2.8M here, and processing the resultant IQ file with grc but the result is the same. I also tried with a 3.2M sample rate, the maximum permitted value with RT2832 USBs sticks but again without success. Am I doing something wrong in grc or it is just that these sample rates are nowhere near sufficient for the whole-MUX type of data I am attempting to capture? I was able to adapt the dvbt_rx_8k.grc demo for a 64QAM file (adv64.cfile also from Ron Economos) and process that OK in grc. Many thanks Tom Crane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
