, which I am currently investigating.
Vlad.
John Andrews-5 wrote:
>
> On Wed, Jun 15, 2011 at 9:53 AM, Vlad Stoianovici <
> stoianovici_v...@yahoo.com> wrote:
>
>>
>> Dear list,
>> I'm using a typical UHD USRP source (USRP2) --> Low-Pass filter -->
Dear list,
I'm using a typical UHD USRP source (USRP2) --> Low-Pass filter --> GMSK
Demod --> Packet Decoder --> File Sink receiver flow-graph in GnuRadio to
receive the signal I'm transmitting with a mirrored transmitting flow.
The problem is that the Packet Decoder (Output type - "byte"; Access
Marcus,
I'm familiar with installing UHD and then GNURadio, not so much with
updating UHD.
What are the differences?
Any suggestions or links to direct me?
Thank you.
Vlad.
Marcus D. Leech wrote:
>
>
> This indicates that your USRP-N2XX firmware is at level 10, while the
> host side is exp
al
steps: cmake ../, make, make test, sudo make install, sudo ldconfig in the
uhd build folder? or is there a different way of going about this?
Thanks!
Vlad.
Josh Blum-3 wrote:
>
>
>
> On 06/03/2011 09:11 AM, Vlad Stoianovici wrote:
>>
>> Dear list,
>> I get a str
Dear list,
I get a strange error when trying to compile a GRC model:
-- Opening a USRP2/N-Series device...
Traceback (most recent call last):
File "/home/vl/GnuRadio/Surse/top_block.py", line 43, in
tb = top_block()
File "/home/vl/GnuRadio/Surse/top_block.py", line 28, in __init__
nu
Dear Marcus and Bob,
I did understand that the block was hollow, but this thread is kindda old,
so I thought that in the mean time maybe someone implemented the code and
functionality you are referring to.
I'm using GRC, but I don't have time to start learning python with the sole
purpose of being
Dear list and Josh,
I'm still getting this error when using the QAM Demod block (qamX_demod is
not connected internally).
Are there any new developments concerning these blocks?
Vlad.
Josh Blum-2 wrote:
>
> Well, when you receive a qam signal, and lock to it, you still have some
> unknown ph
Thanks Josh!
It's working fine now.
Vlad.
Josh Blum-3 wrote:
>
>
> UHD seems to communicate, but the firmware images are likely out of date
> since the serial is not read.
>
> This is an error for the old gnuradio/usrp2 driver. You will want to use
> the gr-uhd blocks instead.
>
> Get the
Hi!
You can find some help here http://
http://www.mathworks.com/support/solutions/en/data/1-D2KBPZ/index.html?product=CB&solution=1-D2KBPZ
and here http://
http://www.mathworks.com/support/solutions/en/data/1-CUN7JZ/?solution=1-CUN7JZ
.
Also try adressing your questions to usrp-us...@lists.e
maware (fw).
Vlad Stoianovici wrote:
>
> Hi Marcus,
> I figured that the firmware might be out of date especially since they are
> almost a year old (this is why I mentioned them).
> Since I'm new to UHD could you tell me where exactly are they located in
> the UH
Hi Marcus,
I figured that the firmware might be out of date especially since they are
almost a year old (this is why I mentioned them).
Since I'm new to UHD could you tell me where exactly are they located in the
UHD folder.
Is there any further compiling necessary in order to obtain the .bin fi
Hi Bomi!
Don't know if you still need this but there is a block in GRC called
Rational Resampler, try using that combined with the USRP2's decimation (for
example Decimation 4 and Rational Resample rate of 8/25 for a 8M band) for
trimming your baseband!
HTH.
Vlad.
Bomi wrote:
>
>
>
> Hello
Tom,
You are right, it doesn't make any sense, I was thinking about the reverse
method, taking for example just 10 MHz out of a total band of 12.5 by filtering
or resampling, but that is totally different since you have extra band and you
just eliminate the extra part, but here you can't just ma
13 matches
Mail list logo
