Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[Johnathan Corgan]

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 version of thrift than 0.9.2.

In any case, you can try this one, it applies cleanly to the 0.9.2 tag in
the thrift repository:

https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/custom/gnuradio/thrift-shutdown-fix.diff
​

Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] No revision detected MB EEPROM must be reprogrammed!

[Matija Ciganovic]

[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, I apologize!]

Dear all,

I've been working with GNURadio & UHD/USRP for quite some time now. All of
a sudden I started seeing the following messages when running my flowgraph,
on which I couldn't find any info:

UHD Warning:
No revision detected MB EEPROM must be reprogrammed!

At the time I was using UHD 3.9. Anyhow, a colleague told me that he also
used to have problems with too new versions of UHD, but that those
disappeared as he started to use UHD 003.008.005. So I erased all traces of
GNURadio & UHD and reinstalled from scratch using the build-gnuradio
script, now specifying that I want UHD version 003.008.005 installed.
Furthermore, I ran the usrp_x3xx_fpga_burner tool to rewrite the EEPROM of
the X300. Now, when I  wish to run my GNURadio flowgraph, I get the
following return messages:

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.008.005-0-g7efbd15b

-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...

UHD Warning:
No revision detected MB EEPROM must be reprogrammed!

UHD Warning:
Defaulting to X300 RevD Clock Settings. This will result in non-optimal
lock times.
Traceback (most recent call last):
  File "/home/matija/bin/phantom2_mod.py", line 270, in 
tb = phantom2_mod()
  File "/home/matija/bin/phantom2_mod.py", line 92, in __init__
channels=range(1),
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2282, in make
return _uhd_swig.usrp_sink_make(*args)
RuntimeError: RuntimeError: Unsupported board revision number:
18446744073709382690.
The maximum board revision number supported in this version is 6.
Please update your UHD version.

>>> Done (return code 1)

Did anyone else experience the same problems? Can I not use UHD 003.008.005
with the X300? I'm assuming that something weird happened during the
installation as the board revision number is so odd..
I'm using an USRP X300 with a UBX-160 daughterboard, connected over 10Gb
ethernet. Gnuradio version: 3.7.7.2. My system is 64bit Ubuntu 14.04.

Any help is greatly appreciated!

Kind regards,
Mat
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ControlPort 3.7.8rc1

[bob wole]

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:

> On Wed, Aug 5, 2015 at 1:21 AM, bob wole  wrote:
>
>>
>> > There is a directory
>>> > gnuradio-runtime/python/gnuradio/ctrlport
>>> >
>>> >
>>> > where you in controlport related stuff.
>>> >
>>> > - - Volker
>>> >
>>> >
>>> > Am 04.08.2015 um 10:09 schrieb Jeon:
>>> >
>>> > Dear Bob,
>>> >
>>> > A few months ago, I've asked a similar question (
>>> > <
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>> >
>>> >
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html
>>> )
>>> >
>>> > and Tom gave me his paper in SIGCOMM.
>>> >
>>> > Inspecting GNU Radio Applications with ControlPort and Performance
>>> Counters
>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen
>>> >
>>> > You can get one in
>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php
>>> >
>>> > It does not fully describe how it can be used, though, through
>>> this you
>>> > can get a hint.
>>> >
>>> > Regards,
>>> > Jeon.
>>> >
>>> > 2015-08-04 16:36 GMT+09:00 bob wole :
>>> >
>>> >> Ubuntu 14.04 64-bit
>>> >>
>>> >> I just installed frest gnuradio 3.7.8rc1 with control port
>>> enabled. I
>>> >> fetched gnuradio using
>>> >>
>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git
>>> >>
>>> >>
>>> >>  Gnuradio enabled component shows
>>> >>
>>> >> * gr-ctrlport
>>> >> * * thrift
>>> >>
>>> >> However, I do not see any *gr-ctrlport directory *inside the
>>> gnuradio
>>> >> directory. Where is the source code for control port? Also there
>>> are no
>>> >> examples for using control port.
>>> >>
>>> >> --
>>> >> Bob
>>> >>
>>> >
>>> You can find more information on these two pages:
>>>
>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
>>>
>>>
>>> ControlPort was reintroduced just after the 3.7.7 release so we had
>>> time to
>>> test it, but it will be available in the upcoming 3.7.8 release. The
>>> manual
>>> page linked above is from our weekly development builds.
>>>
>>> This points you to two apps that are installed with ControlPort:
>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look
>>> for
>>> usage is in our QA code. Look in gr-blocks
>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
>>> and qa_ctrlport_probes.py.
>>>
>>> Tom
>>>
>>>
>>>
>> ControlPort is written in python ?
>>
>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first
>> time. Then I ran the other two qa codes they passed successfully without
>> any core dump. When I ran qa_ctrlport_probes.py again it passed
>> successfully.
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 57403
>> .
>> --
>> Ran 5 tests in 0.509s
>>
>> OK
>> *Segmentation fault (core dumped)*
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py
>> INFO: Apache Thrift: -h sdr-dev -p 35595
>> ..
>> --
>> Ran 2 tests in 0.105s
>>
>> OK
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py
>> INFO: Apache Thrift: -h sdr-dev -p 38301
>> ..
>> --
>> Ran 2 tests in 0.134s
>>
>> OK
>>
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 38644
>> .
>> --
>> Ran 5 tests in 0.511s
>>
>> OK
>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py
>> INFO: Apache Thrift: -h sdr-dev -p 48394
>> .
>> --
>> Ran 5 tests in 0.510s
>>
>> OK
>>
>>
>> What could be the cause?  I thought I should share because it is a
>> new release and is in testing stage.
>>
>>
>> --
>> Bob
>>
>
> There is a bug in Thrift 0.9.2 that I'm going to guess is the cause of
> that seg fault. See our notes on building Thrift and the patch that we 
> have
> for it:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPo

[Discuss-gnuradio] OFDM and FEC combined

[Davi Brilhante]

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
convolutional and dummy variables. With the following parameters:

OFDM:
* FFT Length: 64
* CP Lenght: 16
* Packet Length: 96

FEC (Repetition)
* Frame Bits: 2048
* Repetitions: 2
* a prior prob: 500m

I have made individual tests using this configuration and each block works
perfectly fine. But apparently there is a bug with their integration

Then, I created file sinks in the flowgraph for debugging: One just after
the encoder, to show me how the repetition encoder works and if it's
working properly; other after the receiver, to look into the packet after
all OFDM process.

The file after reception lost part of the packets, thus, I believe it means
that they are being dropped somewhere between transmission and reception.

 For example:

If I am transmitting: "A B C\nD E F\nG H I\n"
I am receiving: "A B C\nG H I\nD E F\nG H I\nA B C\n", i.e. one packet with
"D E F\n" and other with "A B C\n" were dropped or lost along the way.

After searching for this type of problem, I found something about
"Header/Payload
Demuxer".

Best Regards,

Davi
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] mirrored spectrum around tuning freq

[Marcus Müller]

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 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 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 different from zero the mirror effect disappear.
>>
>> Why ?
>>
>> Thanks,
>> Luca
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] mirrored spectrum around tuning freq

[Martin Braun]

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 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 different from zero the mirror effect disappear.
> 
> Why ?
> 
> Thanks,
> Luca
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] mirrored spectrum around tuning freq

[Luca Pascale]

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 different from zero the mirror effect disappear.

Why ?

Thanks,
Luca
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Tom Cook]

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, 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. There's a delicate balance between
> writing code and documenting that outside of the code itself, especially
> since GNU Radio has quite a lot of contributors.
>
> Cheers,
> Marcus
>
>
> On 10.08.2015 14:44, Tom Cook wrote:
>
> 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/*rational*.grc ##that's where the block definitions for GRC reside
>>
>> found out that the non-base variant used rational_resampler_$(type), but
>> I had a look into filter, and only found rational_resampler_base_*; so I
>> guessed it was a python file.
>> Went into python/filter, and opened rational_resampler.py, based on it
>> being the only python file that was possibly relevant here.
>>
>> You know, that's really unintuitive, and I think we'll need some helpers
>> or better documentation that makes finding such things easier.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 10.08.2015 14:31, Tom Cook wrote:
>>
>> 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 automatically designs a filter that avoids all aliasing and imaging,
>>> which is done with a python wrapper around the C++
>>> rational_resampler_base_xxx's make function[1]. That's pretty handy in most
>>> use cases, but not too much if you want your own filter for some reason.
>>>
>>> If you're using the "base" variant, you *must* specify the taps
>>> yourself, because you directly invoke the C++ block's maker. If you go
>>> ahead and just use "[1.0]" as taps, you get the aliased results from my
>>> pictures.
>>>
>>> So if you happen to *want *to specify the taps, because you can
>>> integrate the functionality of a downstream filter into the resampler to
>>> save CPU cycles, it doesn't make a difference which block you use.
>>>
>>
>> Ah, I see.  Many thanks for taking the time to explain this.  Where did
>> you look to find out that 'rational resampler' block does an automatic
>> filter design for you?
>>
>> Regards,
>> Tom
>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP tuning time

[Marcus Müller]

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/marcusmueller/gnuradio.git
uhd_add_tx_tune_tag_handling

Best regards,
Marcus

PS: You're a regular poster now. Get rid of ruby-forum and directly sign
up for the mailing list!
Ruby-Forum doesn't properly reply to the mail you content-wisely reply
reliably.

On 10.08.2015 15:24, Marcus Müller wrote:
> 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 specify exactly how you want to tune (DSP/analog).
>
> Best regards,
> Marcus
>
> On 10.08.2015 15:05, Mat Mat wrote:
>> 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?
>>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-core missing / UCLA Zigbee PHY in gnuradio version 3.6.5.1

[Bastian Bloessl]

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  accordingly.


I guess I could help you better if you would come up with a more 
specific question...


Best,
Bastian

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP tuning time

[Marcus Müller]

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 specify exactly how you want to tune (DSP/analog).

Best regards,
Marcus

On 10.08.2015 15:05, Mat Mat wrote:
> 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?
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP tuning time

[Mat Mat]

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/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Marcus Müller]

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. There's a delicate
balance between writing code and documenting that outside of the code
itself, especially since GNU Radio has quite a lot of contributors.

Cheers,
Marcus

On 10.08.2015 14:44, Tom Cook wrote:
> 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/*rational*.grc ##that's where the block definitions for
> GRC reside
>
> found out that the non-base variant used
> rational_resampler_$(type), but I had a look into filter, and only
> found rational_resampler_base_*; so I guessed it was a python file.
> Went into python/filter, and opened rational_resampler.py, based
> on it being the only python file that was possibly relevant here.
>
> You know, that's really unintuitive, and I think we'll need some
> helpers or better documentation that makes finding such things easier.
>
> Best regards,
> Marcus
>
>
> On 10.08.2015 14:31, Tom Cook wrote:
>> On Mon, 10 Aug 2015 at 13:14 Marcus Müller
>> mailto:marcus.muel...@ettus.com>> 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 automatically
>> designs a filter that avoids all aliasing and imaging, which
>> is done with a python wrapper around the C++
>> rational_resampler_base_xxx's make function[1]. That's pretty
>> handy in most use cases, but not too much if you want your
>> own filter for some reason.
>>
>> If you're using the "base" variant, you /must/ specify the
>> taps yourself, because you directly invoke the C++ block's
>> maker. If you go ahead and just use "[1.0]" as taps, you get
>> the aliased results from my pictures.
>>
>> So if you happen to /want /to specify the taps, because you
>> can integrate the functionality of a downstream filter into
>> the resampler to save CPU cycles, it doesn't make a
>> difference which block you use.
>>
>>
>> Ah, I see.  Many thanks for taking the time to explain this. 
>> Where did you look to find out that 'rational resampler' block
>> does an automatic filter design for you?
>>
>> Regards,
>> Tom
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP tuning time

[Marcus Müller]

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 would have done
for you if you just used DSP tuning; but without having to use the full
sampling rate that covers the whole analog band. I do agree, it's often
easier to implement things this way, because everything stays within
control of your software.

The errors you describe sound like your USRP is actually running at a
different rate than what you've set. And in fact, the 150MHz you set are
not a rate that is possible with any master clock rate. You'll need to
use an integer factor of your master clock rate, which by default is
200MHz (but can also be configured to be 120MHz or 184.3MHz). So
possible rates are 200MS/s / 1, 200MS/s / 2, 200MS/s / 3 and so on. The
console output of your script should actually tell you that the rate is
unsupported and a different rate was used.

I'd say that it might really be a good choice to let the FPGA do this;
it's nothing you must task your CPU with if your USRP can do it! In
fact, it would not be overly hard to add the DSP-only tuning via stream
tags to the USRP sink, but since this might solve your problem
sufficiently well, why don't you try adding stream tags? For example,
replace your sinus source with a vector source with a constant list as
value (e.g. [1.0] * 1000* 3000) and a tags parameter, like the following:

[ gr.tag_utils.python_to_tag( (n*1000, pmt.intern("tx_freq"),
pmt.from_double(2.5e9 + n*1000), pmt.intern("src")) )  for n in
xrange(3000) ]

that should instruct the USRP sink to tune every 1000 samples. That way,
you don't have to interpolate to the full physical DAC rate, but just
enough to allow your frequency mod to work (which probably is much much
less).

Best regards,
Marcus


On 10.08.2015 14:00, Mat Mat wrote:
> 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. 
> Unfortunately, a new problem has arisen. you can see my flowgraph 
> attached
>
> I want my signal to be transmitted on 5.804GHz. to this end, the centre 
> frequency is set to 5.799GHz, and the signal that I wish to transmit is 
> multiplied with a sine wave of 5MHz. (I'm storing everything as a file 
> before transmitting, as things are otherwise too slow). The problem now 
> is that when I transmit the signal over the USRP, it is not transmitted 
> on 5804 MHz but on approx. 5802 MHz. Furthermore, this error appears to 
> become bigger with bigger frequency offsets: When I want the signal to 
> be transmitted with 20MHz offset to the centre frequency of the usrp 
> (thus using a sine wave of 20MHz), the difference between the intended 
> signal frequency and the true signal frequency is almost 10 MHz!
>
> Am I doing anything wrong here??
>
> kind regards and thanks so much,
> Mat
>
> Attachments:
> http://www.ruby-forum.com/attachment/10982/modulator.jpg
>
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Tom Cook]

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/*rational*.grc ##that's where the block definitions for GRC reside
>
> found out that the non-base variant used rational_resampler_$(type), but I
> had a look into filter, and only found rational_resampler_base_*; so I
> guessed it was a python file.
> Went into python/filter, and opened rational_resampler.py, based on it
> being the only python file that was possibly relevant here.
>
> You know, that's really unintuitive, and I think we'll need some helpers
> or better documentation that makes finding such things easier.
>
> Best regards,
> Marcus
>
>
> On 10.08.2015 14:31, Tom Cook wrote:
>
> 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 automatically designs a filter that avoids all aliasing and imaging,
>> which is done with a python wrapper around the C++
>> rational_resampler_base_xxx's make function[1]. That's pretty handy in most
>> use cases, but not too much if you want your own filter for some reason.
>>
>> If you're using the "base" variant, you *must* specify the taps
>> yourself, because you directly invoke the C++ block's maker. If you go
>> ahead and just use "[1.0]" as taps, you get the aliased results from my
>> pictures.
>>
>> So if you happen to *want *to specify the taps, because you can
>> integrate the functionality of a downstream filter into the resampler to
>> save CPU cycles, it doesn't make a difference which block you use.
>>
>
> Ah, I see.  Many thanks for taking the time to explain this.  Where did
> you look to find out that 'rational resampler' block does an automatic
> filter design for you?
>
> Regards,
> Tom
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Marcus Müller]

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
I had a look into filter, and only found rational_resampler_base_*; so I
guessed it was a python file.
Went into python/filter, and opened rational_resampler.py, based on it
being the only python file that was possibly relevant here.

You know, that's really unintuitive, and I think we'll need some helpers
or better documentation that makes finding such things easier.

Best regards,
Marcus

On 10.08.2015 14:31, Tom Cook wrote:
> 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 automatically designs a filter that avoids
> all aliasing and imaging, which is done with a python wrapper
> around the C++ rational_resampler_base_xxx's make function[1].
> That's pretty handy in most use cases, but not too much if you
> want your own filter for some reason.
>
> If you're using the "base" variant, you /must/ specify the taps
> yourself, because you directly invoke the C++ block's maker. If
> you go ahead and just use "[1.0]" as taps, you get the aliased
> results from my pictures.
>
> So if you happen to /want /to specify the taps, because you can
> integrate the functionality of a downstream filter into the
> resampler to save CPU cycles, it doesn't make a difference which
> block you use.
>
>
> Ah, I see.  Many thanks for taking the time to explain this.  Where
> did you look to find out that 'rational resampler' block does an
> automatic filter design for you?
>
> Regards,
> Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Tom Cook]

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 automatically designs a filter that avoids all aliasing and imaging,
> which is done with a python wrapper around the C++
> rational_resampler_base_xxx's make function[1]. That's pretty handy in most
> use cases, but not too much if you want your own filter for some reason.
>
> If you're using the "base" variant, you *must* specify the taps yourself,
> because you directly invoke the C++ block's maker. If you go ahead and just
> use "[1.0]" as taps, you get the aliased results from my pictures.
>
> So if you happen to *want *to specify the taps, because you can integrate
> the functionality of a downstream filter into the resampler to save CPU
> cycles, it doesn't make a difference which block you use.
>

Ah, I see.  Many thanks for taking the time to explain this.  Where did you
look to find out that 'rational resampler' block does an automatic filter
design for you?

Regards,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Marcus Müller]

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, which is done with a python wrapper around the C++
rational_resampler_base_xxx's make function[1]. That's pretty handy in
most use cases, but not too much if you want your own filter for some
reason.

If you're using the "base" variant, you /must/ specify the taps
yourself, because you directly invoke the C++ block's maker. If you go
ahead and just use "[1.0]" as taps, you get the aliased results from my
pictures.

So if you happen to /want /to specify the taps, because you can
integrate the functionality of a downstream filter into the resampler to
save CPU cycles, it doesn't make a difference which block you use.

Best regards,
Marcus

[1]
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python/filter/rational_resampler.py

On 10.08.2015 13:55, Tom Cook wrote:
>
> 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, using a rational resampler at 4x decimation, with no separate
> aliasing filter and the 'Filter taps' parameter left empty will mean
> that there will be aliasing in the resulting down-sampled data.  Have
> I understood you right?  I need to provide filter taps to get an
> anti-aliasing filter as part of the resampler block?
>
> Thanks again,
> Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP tuning time

[Mat Mat]

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. 
Unfortunately, a new problem has arisen. you can see my flowgraph 
attached

I want my signal to be transmitted on 5.804GHz. to this end, the centre 
frequency is set to 5.799GHz, and the signal that I wish to transmit is 
multiplied with a sine wave of 5MHz. (I'm storing everything as a file 
before transmitting, as things are otherwise too slow). The problem now 
is that when I transmit the signal over the USRP, it is not transmitted 
on 5804 MHz but on approx. 5802 MHz. Furthermore, this error appears to 
become bigger with bigger frequency offsets: When I want the signal to 
be transmitted with 20MHz offset to the centre frequency of the usrp 
(thus using a sine wave of 20MHz), the difference between the intended 
signal frequency and the true signal frequency is almost 10 MHz!

Am I doing anything wrong here??

kind regards and thanks so much,
Mat

Attachments:
http://www.ruby-forum.com/attachment/10982/modulator.jpg


-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Tom Cook]

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, using a rational resampler at 4x decimation, with no separate aliasing
filter and the 'Filter taps' parameter left empty will mean that there will
be aliasing in the resulting down-sampled data.  Have I understood you
right?  I need to provide filter taps to get an anti-aliasing filter as
part of the resampler block?

Thanks again,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Processing expectations

[Marcus Müller]

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 always better to ask how you
can figure out something rather then just relying on pre-made solutions.
>   I don't have GRC to hand, but I don't remember it being in the
> documentation for the block.  
GRC docs typically only contain a small piece of the information in the
full doxygen.

So the point here is that the doxygen [1] does mention it builds a
rational resampling polyphase FIR out of the taps that you need to supply.
Also, it quite explicitely says that you need to use a filter that will
suppress the aliases or images (depending on what's higher, decimation
or interpolation).

So the thing that's happening here is that you want to achieve a M/N
resampling; you actually[2] do the following:

--->[↑ M] --> [↓ N] -->

So you pad 1 input sample to M "intermediate" samples by simply adding
M-1 zeros after each sample, and then you throw away N-1 out N samples.
Simple as that? Not really. First of all, as you've noticed, the M
interpolation introduces aliases.
So assume the input spectrum might look like this:
input spectrum

Obviously, we're wasting sample space here. So having a sharp look, we
determine that this only needs 3/5 of the original bandwidth; hence M=3,
N=5.

What we want to have looks like:
Wanted output spectrum
I.e. we want spectrum that as closely fits the full Nyquist bandwidth,
but doesn't "overlap" the edges, ie. there's no aliasing at the edges.
Notice that at the band edges, the spectral power goes down by > 20dB.

What we actually get if we just interpolate and decimate (GRC file here
[3]) however looks like
actual output spectrum

The output spectrum is a obviously continuous piece of overlaid signal;
if you look closely, you'll notice that these two center peaks seem to
re-appear at ~+-7kHz. Something is wrong here.

But it's not really surprising: If you take a look at the intermediate
spectrum [4], there's the 3 repetitions we'd expect from interpolation.
Now, mentally cut the intermediate spectrum in five equally wide parts,
and mentally shift them the four outer ones over the center one. That
aliasing is what ruins our signal!

That demonstrates what's necessary to get rid of this: in the
intermediate spectrum, we'll need to suppress everything that isn't in
the "middle" zone. Doing that yields [5], which is what we wanted.

Here, M < N, and that's why you need an anti-alias filter; but the same
M repetitions appear for any M, and the same "cut up and overlay" logic
applies to any N; this explains why for M > N, you need an anti-imaging
filter.

The point here is, though, that you just really need one filter here,
and it needs to be the stricter one of both (cutoff at
decimation/interpolation or at interpolation/decimation). Of course, if
you follow up with another filter that already fulfills that, you might
as well just interpolate that filter to match the M*input sample rate,
and use that. Due to [2], rational resamplers don't actually run at
M*input sample rate (that would be computationally terrible!), so the
resulting filter might actually be not much worse than the minimal
filter that you'd use just to guarantee proper resampling, but you might
just save a whole separate filter.

Best regards,
Marcus

[1]
https://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1rational__resampler__base__fff.html#details
[2] Note that there's polyphase trickery that /mathematicall//y/ does
the same as just actually adding the zeros, and throwing away samples,
but without doing the unnecessary operations (who needs samples that get
thrown away? Who needs to multiply something with 0 to then add it up?)
[3] https://gist.github.com/marcusmueller/24d64e67709fafbf036f#file-spec-grc
[4]
https://gist.github.com/marcusmueller/24d64e67709fafbf036f#file-nofilter-png
[5]
https://gist.github.com/marcusmueller/24d64e67709fafbf036f#file-proper-png

On 10.08.2015 11:06, Tom Cook wrote:
> 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 out the ways of combining resampling and
> filtering.  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 don't have GRC to hand,
> but I don't remember it being in the documentation for the block.  The
> documentation for the rational_resampler_base_fff class sort of hints
> at it without saying as much, and it took me quite a while to f

Re: [Discuss-gnuradio] Processing expectations

[Tom Cook]

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 out the ways of combining resampling and
filtering.  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 don't have GRC to hand, but I
don't remember it being in the documentation for the block.  The
documentation for the rational_resampler_base_fff class sort of hints at it
without saying as much, and it took me quite a while to figure out where to
find even that.

At any rate, I've got the thing running in realtime, and performing quite
well after replacing the crummy antenna provided with the dongle with a VHF
TV antenna pointed in the right direction.

Thanks again,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio