On Tue, Aug 11, 2015 at 4:24 AM, bob wole wrote:
> Anyone successful in applying that patch to thrift 0.9.2 ? Thoughts ?
>
In the mastering of the live SDR image, I had to create a new patch that
was slightly different from the original one; I suspect the original one
was based on a different
[Note: The reason I'm posting this here is because I'm not sure whether
this is solely a UHD problem or perhaps because of some 'suboptimal'
communication between GNURadio & UHD, and I've seen some earlier posts on
this list resolving UHD-related issues.If this is off-topic and does not
belong here
On Sat, Aug 8, 2015 at 11:20 AM, bob wole wrote:
>
>
> On Fri, Aug 7, 2015 at 9:51 AM, bob wole wrote:
>
>>
>>
>> On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau wrote:
>>
>>> On Thu, Aug 6, 2015 at 1:24 AM, bob wole wrote:
>>>
On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau wrote:
>>>
I am working with the OFDM and FEC blocks combined in the same flowgraph,
but this configuration led to some issues and I am not being able to sort
this out.
I am using the OFDM Transmitter and Receiver Hier Blocks and FEC Encoder
and Decoder, but I already used "FEC Extended Decoder/Encoder" with
Could be intermodulation due to driving the RX amplifier into nonlinearity;
Luca, what gain are you using? Can you further reduce it? Can you reduce
the amplitude of your test signal?
Best regards,
Marcus
On 10.08.2015 18:31, Martin Braun wrote:
> My first thought was "IQ imbalance", but it's pre
My first thought was "IQ imbalance", but it's pretty strong. Which USRP
and daughterboard do you have?
M
On 10.08.2015 09:24, Luca Pascale wrote:
> Hi all,
>
> why when I use:
> uhd::tune_request_t tr(tuningFreq);
> USRP_DEVICE->set_rx_freq(tr);
>
> I get a spectrum that is "mirrored" around t
Hi all,
why when I use:
uhd::tune_request_t tr(tuningFreq);
USRP_DEVICE->set_rx_freq(tr);
I get a spectrum that is "mirrored" around the tuninFreq ?
See: http://picpaste.com/sp-zJquS0qK.png
with tuningFreq = 149.8 MHz, input signal at F = 150 MHz (from signal
generator)
If I use a LO offset diff
Okay. Time to fork on github, methinks, and start contributing
documentation patches.
On Mon, 10 Aug 2015 at 14:02 Marcus Müller wrote:
> With GNU Radio, never feel stupid ;)
> Documentation did turn out quite great in most places, but as soon as you
> want to figure out what happens inside, yo
Hell. I haven't tried this, but:
If you're building GNU Radio from source, you can use this:
https://github.com/marcusmueller/gnuradio/tree/uhd_add_tx_tune_tag_handling
ie. in your gnu radio directory do something like (assuming you're on
the master branch)
git pull https://github.com/marcusmuel
Hi,
On 08/10/2015 07:59 AM, Jaeho wrote:
But i don't understand how can i use these code to modify my code that i
uploaded previous thread.
>
Can you give me more hints or advices to modify old code?
I cannot give you any other advice then look at the generated py-files
and adapt you code
I'd just try. Clearly, physically retuning is bad in this case, but if
you haven't tried with the stream tag approach, you should.
Other than that, I think a relatively small patch to the USRP sink would
add a tx_tune tag, doing the same as the message of the same name,
namely allowing you to spec
well here's the thing: I need to transmit a burst every 7ms. From what
you've written about tuning times, i got somewhat pessimistic as to
whether this is enough time to retune. Or would you say that this should
be enough?
--
Posted via http://www.ruby-forum.com/.
With GNU Radio, never feel stupid ;)
Documentation did turn out quite great in most places, but as soon as
you want to figure out what happens inside, you're pretty much on your
own, often. grep/ack/git grep is a constant friend, but it's not always
easy to figure out how stuff works internally. Th
Hi Mat,
> I decided to achieve frequency hopping not by changing the centre
> frequency of the USRP, but by multiplying my signal with a sine of a
> certain frequency offset and then transmit that signal over the USRP
> with a fixed USRP.
That's cool, but it's exactly what the FPGA of the USRP wou
I see. I don't feel quite so stupid for having not found it myself, now!
On Mon, 10 Aug 2015 at 13:37 Marcus Müller wrote:
> Hi Tom,
>
> added the block, opened the block properties, had a look at the id; I knew
> that these kind of blocks live within gr-filter, so
>
> cd gr-filter
> vim grc/*r
Hi Tom,
added the block, opened the block properties, had a look at the id; I
knew that these kind of blocks live within gr-filter, so
cd gr-filter
vim grc/*rational*.grc ##that's where the block definitions for GRC reside
found out that the non-base variant used rational_resampler_$(type), but
On Mon, 10 Aug 2015 at 13:14 Marcus Müller wrote:
> Hi Tom,
>
> I just had to look this up. If you're in GRC, you have "rationale
> resampler" and "rational resampler base"; they do basically the same, but
> if you use the one without "base", and don't specify the taps, GNU Radio
> just automatic
Hi Tom,
I just had to look this up. If you're in GRC, you have "rationale
resampler" and "rational resampler base"; they do basically the same,
but if you use the one without "base", and don't specify the taps, GNU
Radio just automatically designs a filter that avoids all aliasing and
imaging, whi
hey man,
many many thanks for the detailed reply! Based on it, I decided to
achieve frequency hopping not by changing the centre frequency of the
USRP, but by multiplying my signal with a sine of a certain frequency
offset and then transmit that signal over the USRP with a fixed USRP.
Unfortun
On Mon, 10 Aug 2015 at 12:30 Marcus Müller wrote:
> [snip]
>
Thanks for the very detailed explanation, Marcus. I think quite a bit of
my trouble here is relating GNU Radio terminology to hazily-remembered
signal processing courses I took fifteen years ago and haven't used a whole
lot since.
So
Hi Tom,
> Was I supposed to know somehow that the rational resampler includes
> the necessary aliasing filters? That's not meant to be a sarcastic
> question - I'm trying to figure out where to look in the documentation
> for these sorts of things.
I think it's actually a good question! It's alway
Many thanks to all who responded here. As Martin remembered faintly, the
RTL-SDR dongle does not work well at low sample rates, and it gives
considerably better reception to run it at (eg) 1.536 Msps and then
resample it to 384 ksps than to use 384 ksps from the start.
Thanks to Tom for pointing
22 matches
Mail list logo
