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 t
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 p
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:
|
\- gnu
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
wrote:
> Hi,
>
> Apol
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
off
That makes complete sense. Thanks for the suggestion!
On Thu, Sep 8, 2016 at 8:27 PM, Kevin Reid wrote:
> On Thu, Sep 8, 2016 at 7:08 PM, Pavan Yedavalli
> wrote:
>
>> Maybe the Head block is a good option - it looks like I should put that
>> in between the complex_to_
u, Sep 8, 2016 at 6:43 PM, Kevin Reid wrote:
> On Thu, Sep 8, 2016 at 6:34 PM, Pavan Yedavalli
> wrote:
>
>> 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 102
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
append
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 sa
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 c
e. 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 wrote:
> On 07/12/2016 08:56 PM, Pavan Yedavalli wrote:
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
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.
; I notice you don't have the external clock inputs connected to anything,
>>> and there's no GPS LOCK indicator.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2016-07-07 17:08, Pavan Yed
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
wrote:
> The 1 PPS is flashing - it just was
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, Pavan Yedavalli w
;
> 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.
>
>
>
>
>
>
>
>
shion 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 wrote:
> On 07/06/2016 02:48 PM, Pavan Yedavalli wrote:
>
> I disconnected the MIMO
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 wrote:
> On 07/05/2016 11:45 PM, Pavan Yedavalli wrote:
>
more 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 wrote:
> On 07/05/2016 09:45 PM, Pavan Yedavalli wrote:
>
> According to the spectrum analyzer, there's nothing being transmitted in
> the 900 MHz band
timed
commands around the correct code. I am not sure though. Thanks again.
On Tue, Jul 5, 2016 at 5:51 PM, Marcus D. Leech 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
> amplitude, right? That was
n Tue, Jul 5, 2016 at 4:42 PM, Marcus D. Leech 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 receiving the powe
mix, but I
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 wrote:
> On 07/05/2016 06:47 PM, Pavan Yedavalli wrote:
>
> Hi Marcus,
>
>
t
> 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
> Sen
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
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). Than
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
./include/gnura
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
implementi
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 fo
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 then
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
isplayed 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 Yedav
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 b
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"
> out1[:] = [x *
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
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 w
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
> wrote:
>
>> Hi Derek,
>>
>> Thanks. Wrt th
t;
> Good luck with the next steps.
>
> On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli
> 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 looking good. It makes sense
s 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
> wrot
requency and time synchronization between the MIMO N210s.
>
> Regards,
> Derek
>
> On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli
> wrote:
>
>> Hi Derek,
>>
>> Sorry - just another quick addition. When I run the Tx flowgraph, I get
>> this error:
>&
nd_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
>> that
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 21, 2016 at 8:04 AM, Pavan Yedavalli > wrote:
>
>>
u are working with.
>
I had 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
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 sen
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)
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 w
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 the
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
t
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 to
49 matches
Mail list logo
