Hi Marcus,
After doing more analysis, it seems pretty clear that the signal keeps
coming down whenever U is printed out, though I'm not sure how to explain
the wrong multiplication aspect - perhaps the USRP is doing a multiply on
whatever samples it receives, which is fewer than what it needs to
Hmm so I tried it out an realized my solution doesn't quite get me what I
needed.
By invoking uhd::device::sptr usrp = dummy_usrp->get_device() I put my usrp
pointer in the wrong namespace since I wanted access to set_gpio_attr(...)
Going to go think about this more
On Wed, Jun 8, 2016 at 2:06
Hi Devin,
this won't work out for the simple reason that timed commands happen in
the FPGA on the USRP, and C++ happens in your PC, and the coupling
between both is loose at best – there's always some random latency bus
(network, USB,…) between the USRP and the host, and hence, these two
clocks
Hello,
For my applications the MAC layer of my waveform requires me to implement a
few timers (e.g. for slot and frame times, etc).
What I'd like to do is exclusively use the USRP clock for these timers.
I've tried mixing the system clock and the USRP clock before (see a few
messages on this
Hi Marcin,
uh-oh.
So two things:
I've reworked the gr-prefs system lately, because it was broken (no only
under windows) wildly. I don't think this is part of the 3.7.9.2 maint
version yet. Would you share the output of "gnuradio-config-info --version"?
Then:
You seem to have found a bug in our
Hi Pavan,
> I am seeing Us on the output basically every time.
That means the USRP ran out of samples to transmit when they were due to
be transmitted!
> So, this means the block isn't fast enough to handle 30.72 million
> samples per second?
It seems like it, yes.
> Should I lower that sampling
Ah sorry, I meant to mention I'm writing it in c++ not python.
Yes, I saw that get_device() returns a sptr. I think I had a poor choice of
words.
I was unclear on how to even pass the existing usrp into my oot module, BUT
I think I have a better idea now.
Would something this work?:
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
The same flow graph and the same SDR hardware with the same settings and
same drivers should produce the same results (if samples are not being
dropped by the host computer or something else). That said, I've seen weird
things like this pop up due to variations in the driver versions for the
get_device() returns a shared pointer. Note this function is not exposed
in Python -- you need to pass the object into another C++ object, and
there call get_device().
M
On 06/08/2016 06:38 AM, Santos Campos wrote:
> Hi, Martin!
> I tried taking a peek at how the usrp sink might handle a
Hi @all.
Maybe I should introduce my project first: I want to make a flowgraph that
prints the channel impulse response of an OFDM(DAB) ensemble on a Scope
Sink.
CIR = IFFT {Received PRS x PRS*}
What I have done is:
1. wrote a matlab script that generates a binary file with samples of the
phase
Hi,
I've installed GNURadio 3.7.9.2 Win64 Binaries from
http://www.gcndevelopment.com/gnuradio/downloads.htm using full
Windows Installer.
On the first run I can only read:
setting gnuradio environment
Traceback (most recent call last):
File "gnuradio-companion.py", line 130, in
main()
I was reminded about some of Michael Ossmann's work with yardstick one: Great
Scott Gadgets - YARD Stick One
| |
| | | | | | | |
| Great Scott Gadgets - YARD Stick OneYARD Stick One YARD Stick One is a sub-1
GHz wireless test tool controlled by your computer. YARD Stick One is
Hi, Martin!
I tried taking a peek at how the usrp sink might handle a preceding usrp
source (for inspiration).
Does it (and the way you described) declare a usrp device and do some kind
of shallow copy with the get_device() method?
On Mon, Jun 6, 2016 at 5:54 PM, Martin Braun
Hello dear community !
I'm actually trying to develop an application with GRC that does CPFSK
mod/demod but I haven't got some satisfying results yet and I hope you will
be able to get me back in the right way.
The flowgraph i've made (
https://www.dropbox.com/s/6vuyleerbwl3df2/UAT.png?dl=0) is
Hi Ingen,
On 08.06.2016 07:58, ingen wrote:
> I'm a beginner working in Spectrum Sensing. I have been checking the
> code given in the /usrp_spectrum_sense.py/ file in GNU Radio.
> (https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/python/usrp_spectrum_sense.py)
>
> The power
I'm a beginner working in Spectrum Sensing. I have been checking the
code given in the /usrp_spectrum_sense.py/ file in GNU Radio.
(https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/python/usrp_spectrum_sense.py)
The power calculated (at line 303) is in dB as given below :
17 matches
Mail list logo
