Re: [Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

To Kyeong and Cinaed: Thank you for the suggestions. I am still having a ton of the same issues. What I did was the following: 1) Removed the pybombs and prefix directories to start from scratch. Is this all I need to do in order to get rid of everything I previously installed? I have a feeling

[Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

It looks like it was a permission problem to open gnuradio-companion. If I run "sudo gnuradio-companion," it will open correctly. Having said that, I am seeing another problem of "No module named tutorial" when running python grc flowgraphs. On a previous computer that successfully ran the same

[Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

Hi, I successfully followed the instructions on github to install pybombs, cloning the directory and then running sudo python setup.py install Everything successfully finished: PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and installing binary packages: Install tree: | \-

Re: [Discuss-gnuradio] How to Transmit Orthogonal Waveforms

Hi, Preliminarily, I think I may have found what I needed in the vector source block and making the vector a numpy array of 0s and 1s (where I want my rectangular pulse). I will keep the list posted. Thanks. On Wed, Sep 14, 2016 at 9:55 AM, Pavan Yedavalli <psy2...@columbia.edu> wrote:

[Discuss-gnuradio] How to Transmit Orthogonal Waveforms

Hi, Apologies for sending this again. I want to transmit orthogonal waveforms from my USRP N210, and I have tried to mimic the example from ofdm_tx.py. One thing is that I don't need these signals to have any header, CRC, or any stuff involved with an actual OFDM signal. I just need them to be

Re: [Discuss-gnuradio] File Sink Output Size Problem

That makes complete sense. Thanks for the suggestion! On Thu, Sep 8, 2016 at 8:27 PM, Kevin Reid <kpr...@switchb.org> wrote: > On Thu, Sep 8, 2016 at 7:08 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> Maybe the Head block is a good option -

Re: [Discuss-gnuradio] File Sink Output Size Problem

at 6:43 PM, Kevin Reid <kpr...@switchb.org> wrote: > On Thu, Sep 8, 2016 at 6:34 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> My current flowgraph consists of a signal source (cosine) -> >> stream_to_vector of size 1024 -> forward FFT of size 10

[Discuss-gnuradio] File Sink Output Size Problem

Hi, This is probably a very simple question, but I have an issue when I am using the file sink. My current flowgraph consists of a signal source (cosine) -> stream_to_vector of size 1024 -> forward FFT of size 1024 -> complex_to_mag of size 1024 -> file sink of size 1024 (unbuffered OFF and

[Discuss-gnuradio] Transmitting Orthogonal Waveforms

Hi, I want to transmit orthogonal waveforms from my USRP N210, and I have tried to mimic the sample ofdm_tx.py. One thing is that I don't need these signals to have any header, CRC, or any stuff involved with an actual OFDM signal. I just need them to be offset square pulses, basically. Having

[Discuss-gnuradio] Importing other flowgraphs for use in my flowgraph's main()

Hi, I was wondering if there was a way to import flowgraphs into other flowgraphs. For example, I have a flowgraph that contains a block that I created. In the main() of this, I want to actually run two other flowgraphs that do a simple transmission and reception to get a received power before I

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

. It seems like the timed commands should be the solution to aligning the tuning, but for some reason that's not working. Did I wrap them around the correct commands? Thanks again. On Tue, Jul 12, 2016 at 6:03 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/12/2016 08:56 PM, Pavan

Re: [Discuss-gnuradio] Variation in Tx power across USRPs

Hi Marcus M. and Marcus L., Thanks for the help. Good point about this being more of a USRP digest question. Thanks for referring this to that as well. And unfortunately, that was the correct assumption that I did not use a torque-controlled wrench to connect them either, which maybe I could look

[Discuss-gnuradio] Variation in Tx power across USRPs

Hi, I was doing a quick test to see whether all of the USRPs are transmitting at the same level, so I did a single setup where I connected each USRP's Tx/Rx output to a spectrum analyzer (with attenuations). After sequentially doing it, I am getting up to 5 dB of variation across different USRPs.

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

; On Fri, Jul 8, 2016 at 12:12 AM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> It's an Octoclock-G (https://www.ettus.com/product/details/OctoClock-G >> is what I ordered). And yes, that is true about the external clock inputs >> and GPS lock. Does that matter

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

Hi Marcus, Is this the only type of GPS antenna that I can use on the Octoclock-G? https://www.ettus.com/product/details/GPS-ANT-3V Or can I use any other type of antenna at 1.57 GHz or 1.23 GHz? On Fri, Jul 8, 2016 at 1:33 PM, Pavan Yedavalli <psy2...@columbia.edu> wrote: >

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

gt; Pavan: > > Do you have any way of verifying that you have 1PPS and 10MHz coming out > of those ports on the Octoclock-G, as seen at the ends of the cables? > [Looking for both the broken-Octoclock and broken-cables case]. > > > > > > > > > On 2016-07-08 00:12

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

Octoclock-G? > > If it's just an Octoclock, then it has no internal clocks, and acts as a > high-quality clock/pps distributor. > > I notice you don't have the external clock inputs connected to anything, > and there's no GPS LOCK indicator. > > > > > > > > &

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

for the same reason, right? So the receive side LO offsets could also be causing problems in narrowing down the issue, I'm assuming? Thanks again. On Wed, Jul 6, 2016 at 5:47 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/06/2016 02:48 PM, Pavan Yedavalli wrote: > > I discon

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

I disconnected the MIMO cable and now have all 4 directly connected to the Octoclock, but I get the same results in which the offset changes at every run (using the above code). On Tue, Jul 5, 2016 at 9:11 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/05/2016 11:45 PM, Pavan

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

attenuation because the Tx gain was already quite low. Thanks for the suggestion. On Tue, Jul 5, 2016 at 7:29 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/05/2016 09:45 PM, Pavan Yedavalli wrote: > > According to the spectrum analyzer, there's nothing being transmitted in >

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

around the correct code. I am not sure though. Thanks again. On Tue, Jul 5, 2016 at 5:51 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/05/2016 08:20 PM, Pavan Yedavalli wrote: > > I see, but the offset in phase between the two radios will affect the >

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

, Jul 5, 2016 at 4:42 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/05/2016 07:28 PM, Pavan Yedavalli wrote: > > The way I'm doing it is the following (please correct me if there is a > fundamental error in assumptions): I am actually using an RSSI circuit that > is rec

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

have confirmed the accurate functioning of the RSSI circuit/receiver as well as the static nature of the channel, so its reading is very reliable. On Tue, Jul 5, 2016 at 4:19 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/05/2016 06:47 PM, Pavan Yedavalli wrote: > > Hi Mar

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

; stays constant across different runs of the file/flowgraph. Are you saying > that that offset cannot be constant due to the randomness of the LO phase > offset at each run? Thanks again. > > > _ > From: mle...@ripnet.com > Sent: Tuesday, July 5, 20

[Discuss-gnuradio] random phase offset constantly changing with octoclock setup

Hi, Despite all of my boards being connected via the Octoclock (ref and pps), I am constantly getting different phase offsets every time I run a gnuradio flowgraph (or python file). I am not sure why this is happening, but I do know that I need to call one of the functions, set_time_now() and/or

Re: [Discuss-gnuradio] S printouts and then either U printouts (and fails/stops transmitting) or seg fault with 4 USRPs

Just an update on this: I switched everything to a desktop with a dedicated ethernet port, and connected all 4 USRPs to a switch, which is then directly connected via ethernet to the computer. This has eliminated the Us, which means that it is actually working decently (and not crapping out).

[Discuss-gnuradio] make command errors with: gnuradio/io_signature.h: No such file or directory

Hi, I just installed pybombs and gnuradio successfully, but when I run make in the correct directory, it says gnuradio/io_signature.h: No such file or directory. I have a feeling it's because I made my prefix /path/to/prefix as opposed to /usr/local, because I can find the file in

[Discuss-gnuradio] S printouts and then either U printouts (and fails/stops transmitting) or seg fault with 4 USRPs

Hi, I am connecting 4 USRPs to the Octoclock and my host CPU, and created two of my own blocks (one in python and one in C++), but neither of them runs very long, as countless Ss are streamed out and then finally Us, which signify underruns and so they stop transmitting. I was told that

[Discuss-gnuradio] Fwd: Multiplying the inputs with a scalar/vector in my own block

Hi Marcus, I was told to send this to the list again and see if anyone can help. Thank you. The new situation is as follows: 1.) I had an error in my python block code where I was unnecessarily doing a list comprehension, which was slowing everything down. So, now the block does not produce Us

[Discuss-gnuradio] Pythonic way of how to quit the process if U is displayed on output

Hi, Sometimes my computer acts up and displays Us on the output, meaning that there are underruns. However, this does not happen too often, but is a pain when I am running an automated trial because it freezes the entire program. Is there a way in python to tell whether a U is printed out and

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

Hi Marcus, Thanks for the suggestion. While still using the Python block, I tried changing the sources to CONST_WAVE and decreasing the sample rate to 500K, and proceeded to do that all the way down to 1, and it still was producing Us on the output. Having said that, I turned to implementing the

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

at the beginning, it doesn't seem to transmit again. This is the case for basically everything below 30.72 MHz. At the default 100 MHz, it shows a stream of Ls. I'm guessing that adjusting this rate is probably not the right approach. Thanks. On Wed, Jun 8, 2016 at 10:34 AM, Pavan Yedavalli <psy2...@columbia.

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

Hi Marcus, Thanks for getting back to me. To address both things you mentioned: (1) Yes, that was a typo. One of them should have said in0; I made a mistake while copying over; the code was correct, however, and that behavior still existed. (2) This is interesting. I am seeing Us on the output

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

Sorry - that is a typo. That should be in0, like you said, and the next line should be in1. I made a mistake copying over. Thanks for pointing that out! On Tue, Jun 7, 2016 at 5:05 PM, wrote: > > >>> out0[:] = [x * 1 for x in in1] > ?? IS THIS A TYPO - meaning "in0" >

Re: [Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

Sorry, and just as an addition, obviously I could use the "Multiply by" blocks in GRC, but I am trying to do a much more complex loop involving this block, so multiplying is only part of the process, and I'm running into issues there already. Thanks. On Tue, Jun 7, 2016 at 4:30

[Discuss-gnuradio] Multiplying the inputs with a scalar/vector in my own block

Hi, I created my own block because I wanted to multiply the source sinusoids by weights before transmitting them out, as shown in the attached GRC diagram (my_block.png). However, in my work() function for the block created, I am seeing that simply multiplying the inputs by anything (first test

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

wgraph is crude though and can definitely be improved > so don't pay too close attention to the exact number of the deviation. If > you do make a more rigorous one please share it with us. > > On Tue, May 3, 2016 at 6:38 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

nt then. > > Good luck with the next steps. > > On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> Hi Derek, >> >> Thanks for getting back to me. I lowered the Tx gain by about 15 dB on >> each channel, and then now it's

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

antennas and let > the air do your combining. You may want to keep the attenuators in line > until you are comfortable with the power levels. You'll be able to see when > your receiver is clipping in the Scope GUI. > > Derek > > On Fri, Apr 29, 2016 at 11:32 AM, Pavan Yedavalli

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

hould see > is frequency and time synchronization between the MIMO N210s. > > Regards, > Derek > > On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> Hi Derek, >> >> Sorry - just another quick addition. When I run the

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

ent/files/kb/mimo_and_sync_with_usrp_updated.pdf >> >> If this is your first use of USRPs and GNU Radio then I'd suggest reading >> through the tutorials available online and not get too focused on MIMO >> until you feel comfortable with the basics of the environment and tools

[Discuss-gnuradio] Feedback with Transmitters and Receiver

menting a protocol level time synchronization > in software/DSP. The paper I linked to talks about one way, there are > certainly others. I do not know of any example projects implementing them > though so you would have to develop your own. > > Regards, > Derek > > On Thu, Apr 2

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

ad to take down the setup because I am moving labs, but I will send some flowgraphs and the diagram of the system next week. Thank you again for being so patient and trying to help me. I think I'm just a bit lost on a few of the simple things, but once those are figured out, then I think it should be

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

Hi Martin, I guess I have a few questions: 1.) Are there any examples in the gnuradio codebase/flowgraph repository that show how to do synchronized feedback between two USRPs? In other words, I send a signal from a transmit USRP, and then I receive that signal at the receive USRP, and then I

Re: [Discuss-gnuradio] Synced MIMO cable clock of both boards changes at every call to tb.start()?

Hi Martin, Okay, thank you - so there does appear to be some variation coming from somewhere that I guess is not due to clock changes. My test was the following: 1.) Transmit with a single antenna and receive using uhd_fft. The received peak tone is very stable in magnitude (.01 dB or even less)

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

Hi Martin, Thank you again for getting back to me. Let me elaborate on the process that I am doing, and hopefully what I need will be clarified. I have two USRPs connected via MIMO cable that are transmitting a sin wave and one USRP receiving that sin wave. I am trying to implement a system in

Re: [Discuss-gnuradio] Synced MIMO cable clock of both boards changes at every call to tb.start()?

Hi Martin, Thank you for getting back to me. I'm still a bit confused though. You are saying that I need to call set_time_now() or set_time_unknown_pps() to sync the clocks? So, simply connecting the MIMO cable between the two USRPs is not sufficient for the clocks to be synced? And as far as

[Discuss-gnuradio] Synced MIMO cable clock of both boards changes at every call to tb.start()?

Does the start() function in GNURadio reinitialize the clocks on the USRPs every time it is called? I have two USRPs connected via MIMO cable, so they are synced, but my flowgraph calls start() after every loop, which I'm realizing may be changing the constant but random offset of the clock every

[Discuss-gnuradio] Feedback with Transmitters and Receiver

Hi, I have been trying to do some research using MIMO transmitters and feedback from a receiver. Specifically, I have two antennas connected to two USRPs, and I am transmitting the same signal from both of those (MIMO synchronized) to another USRP and antenna.This receive USRP and antenna needs