[Discuss-gnuradio] Transition to new digtal TV blocks...

[Ralph A. Schmid, dk5ras]

Hi,

Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded as
source, compiled and installed. Now gnuradio brings this stuff by default.
So I wonder what may happen when I remove the duplicate blocks from the
gr-dvbt2 package with a make uninstall. Will my grc files still be
functional by using the new and probably identical blocks, or will I have to
manually rebuild my grc files?

Ralph.




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

Re: [Discuss-gnuradio] Transition to new digtal TV blocks...

[Ron Economos]

You'll have to rebuild them. All the block names have changed from 
dvbt2_xxx to dtv_dvb_xxx (for blocks that are common to both DVB-T2 and 
DVB-S2) or dtv_dvbt2_xxx.


However, there are new versions of vv003-cr23.grc, vv009-4kfft.grc and 
vv018-miso.grc in gnuradio/gr-dtv/examples that you can start with.


Ron

On 05/11/2015 01:12 AM, Ralph A. Schmid, dk5ras wrote:

Hi,

Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded as
source, compiled and installed. Now gnuradio brings this stuff by default.
So I wonder what may happen when I remove the duplicate blocks from the
gr-dvbt2 package with a make uninstall. Will my grc files still be
functional by using the new and probably identical blocks, or will I have to
manually rebuild my grc files?

Ralph.


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

Re: [Discuss-gnuradio] Transition to new digtal TV blocks...

[Ralph A. Schmid, dk5ras]

OK, tnx, no big deal, just good to know beforehand :)

Ralph.

> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> Ron Economos
> Sent: Monday, May 11, 2015 10:44 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Transition to new digtal TV blocks...
> 
> You'll have to rebuild them. All the block names have changed from
> dvbt2_xxx to dtv_dvb_xxx (for blocks that are common to both DVB-T2 and
> DVB-S2) or dtv_dvbt2_xxx.
> 
> However, there are new versions of vv003-cr23.grc, vv009-4kfft.grc and
> vv018-miso.grc in gnuradio/gr-dtv/examples that you can start with.
> 
> Ron
> 
> On 05/11/2015 01:12 AM, Ralph A. Schmid, dk5ras wrote:
> > Hi,
> >
> > Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded
> > as source, compiled and installed. Now gnuradio brings this stuff by
default.
> > So I wonder what may happen when I remove the duplicate blocks from
> > the
> > gr-dvbt2 package with a make uninstall. Will my grc files still be
> > functional by using the new and probably identical blocks, or will I
> > have to manually rebuild my grc files?
> >
> > Ralph.
> 
> ___
> 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] Question on control-loop block design

[Tom Rondeau]

On Tue, Apr 28, 2015 at 8:50 AM,  wrote:

> Hello,
>
> I've been looking into the design details of the control-loop block. I
> stumbled upon the blog post of Tom (
> http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html with
> the derivation
> https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee1fe4b09162d08633ac/1313345573084/control_loop_derivation.pdf)
> and also this article from TI:
> http://www.ti.com/lit/an/slyt169/slyt169.pdf.
>
> Now looking at the schematics of the control loop in Tom's post and the TI
> article (figure 5), you notice a slight difference after the loop filter.
> In the TI article, there is delay (z^-1) followed by an accumulator. In the
> schematics of Tom's post, the delay block is directly integrated in the
> loop. Can somebody comment on these differences?
>
> Thanks
> Ruben
>

Hi Ruben,

This is a good question, and I don't want to let it drop. I just don't have
a good answer for your right now. If I can find the time, I'll try to go
through things more carefully to understand why there is the added delay.
Just keeping the thread alive in case someone else can jump in and answer
it.

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

Re: [Discuss-gnuradio] Question on control-loop block design

[Richard Bell]

From what I remember, there shouldn't be a functional difference. The 
difference is the amount of feedback delay in the loop. You always need to make 
sure one delay exists in any feedback path you can take, to avoid race 
conditions. After that, you want to minimize the loop delay. The one 
accumulator with delay in the feedback path ensures stability. The other 
accumulator keeps the delay out of the feedback path because it minimizes the 
loop latency. 

Hope that helps. 

Rich

Sent from my iPhone

> On May 11, 2015, at 8:42 AM, Tom Rondeau  wrote:
> 
>> On Tue, Apr 28, 2015 at 8:50 AM,  wrote:
>> Hello,
>> 
>> I've been looking into the design details of the control-loop block. I 
>> stumbled upon the blog post of Tom 
>> (http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html with 
>> the derivation 
>> https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee1fe4b09162d08633ac/1313345573084/control_loop_derivation.pdf)
>>  and also this article from TI: http://www.ti.com/lit/an/slyt169/slyt169.pdf.
>> 
>> Now looking at the schematics of the control loop in Tom's post and the TI 
>> article (figure 5), you notice a slight difference after the loop filter. In 
>> the TI article, there is delay (z^-1) followed by an accumulator. In the 
>> schematics of Tom's post, the delay block is directly integrated in the 
>> loop. Can somebody comment on these differences?
>> 
>> Thanks
>> Ruben
> 
> Hi Ruben,
> 
> This is a good question, and I don't want to let it drop. I just don't have a 
> good answer for your right now. If I can find the time, I'll try to go 
> through things more carefully to understand why there is the added delay. 
> Just keeping the thread alive in case someone else can jump in and answer it.
> 
> Tom
>  
> ___
> 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] Question on control-loop block design

[Tom Rondeau]

On Mon, May 11, 2015 at 12:00 PM, Richard Bell 
wrote:

> From what I remember, there shouldn't be a functional difference. The
> difference is the amount of feedback delay in the loop. You always need to
> make sure one delay exists in any feedback path you can take, to avoid race
> conditions. After that, you want to minimize the loop delay. The one
> accumulator with delay in the feedback path ensures stability. The other
> accumulator keeps the delay out of the feedback path because it minimizes
> the loop latency.
>
> Hope that helps.
>
> Rich
>
> Sent from my iPhone
>

Yep, thanks, Richard!

Tom




> On May 11, 2015, at 8:42 AM, Tom Rondeau  wrote:
>
> On Tue, Apr 28, 2015 at 8:50 AM,  wrote:
>
>> Hello,
>>
>> I've been looking into the design details of the control-loop block. I
>> stumbled upon the blog post of Tom (
>> http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html
>> with the derivation
>> https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee1fe4b09162d08633ac/1313345573084/control_loop_derivation.pdf)
>> and also this article from TI:
>> http://www.ti.com/lit/an/slyt169/slyt169.pdf.
>>
>> Now looking at the schematics of the control loop in Tom's post and the
>> TI article (figure 5), you notice a slight difference after the loop
>> filter. In the TI article, there is delay (z^-1) followed by an
>> accumulator. In the schematics of Tom's post, the delay block is directly
>> integrated in the loop. Can somebody comment on these differences?
>>
>> Thanks
>> Ruben
>>
>
> Hi Ruben,
>
> This is a good question, and I don't want to let it drop. I just don't
> have a good answer for your right now. If I can find the time, I'll try to
> go through things more carefully to understand why there is the added
> delay. Just keeping the thread alive in case someone else can jump in and
> answer it.
>
> Tom
>
>
> ___
> 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] Is it possible to undo my mistake

[Carl Olsson]

Hi all,

I couldn't solve my problems so I decided to reinstall Ubuntu 14.04 LTS from 
the beginning on my hp elitebook 8460p. What is the safest (highest probability 
of working) way of installing gnuradio (and hackrf tools)?
I just need a simple installation. Pybombs, build script, package manager or 
something else?

Best regards,

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

Re: [Discuss-gnuradio] Is it possible to undo my mistake

[Martin Braun]

Safest for GNU Radio is package manager. Can't speak for HackRF, but you
can always use PyBOMBS. If you install GNU Radio through apt-get, and
then HackRF through PyBOMBS, you might need to set GNU Radio as already
installed in PyBOMBS.

Cheers,
Martin

On 11.05.2015 10:35, Carl Olsson wrote:
> Hi all,
> 
> I couldn't solve my problems so I decided to reinstall Ubuntu 14.04
> LTS from the beginning on my hp elitebook 8460p. What is the safest
> (highest probability of working) way of installing gnuradio (and
> hackrf tools)? I just need a simple installation. Pybombs, build
> script, package manager or something else?
> 
> Best regards,
> 
> Carl ___ 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] Is it possible to undo my mistake

[West, Nathan]

You can also get hackrf libs through Ubuntu's package manager.

Whatever install method you choose it is best to avoid deleting installed
libraries unless you really know what you are doing.

-Nathan

On Mon, May 11, 2015 at 12:37 PM, Martin Braun 
wrote:

> Safest for GNU Radio is package manager. Can't speak for HackRF, but you
> can always use PyBOMBS. If you install GNU Radio through apt-get, and
> then HackRF through PyBOMBS, you might need to set GNU Radio as already
> installed in PyBOMBS.
>
> Cheers,
> Martin
>
> On 11.05.2015 10:35, Carl Olsson wrote:
> > Hi all,
> >
> > I couldn't solve my problems so I decided to reinstall Ubuntu 14.04
> > LTS from the beginning on my hp elitebook 8460p. What is the safest
> > (highest probability of working) way of installing gnuradio (and
> > hackrf tools)? I just need a simple installation. Pybombs, build
> > script, package manager or something else?
> >
> > Best regards,
> >
> > Carl ___ 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] OFDM Transmitter and Receiver - poor synchronization with USRP1

[Martin Braun]

On 09.05.2015 15:47, Michal Vaclík wrote:
> Doesn't seem so - by connecting scope to DETECT port on S&C block I can
> see only randomly timed peeks as opposed to running with channel model
> where the peeks happen at fixed time periods.
> 
> Detection seems to get better with higher sample rates.

This might be an issue of high relative frequency offsets (which get
less severe for higher sub-carrier bandwidths). You could check how well
your OFDM signal is centered.

M

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

Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink

[Murphy, John]

Date: Sun, 10 May 2015 17:18:58 -0400
From: "Marcus D. Leech" 
You could try a simple experiment that tests your disk subsystem write
performance without SDR stuff at all.  Something like:
time dd if=/dev/zero of=some-file-on-your-disk bs=200 count=15000
This should write a 30GB file.   The 'time' command will report how long
it took.  Then it's just a simple matter of math to figure out what your
achievable long-term write rate is.

[jmurphy@localhost Documents]$ /usr/bin/time dd if=/dev/zero
of=./thrutest bs=200 count=15000
15000+0 records in
15000+0 records out
300 bytes (30 GB) copied, 54.9445 s, 546 MB/s
0.00user 15.17system 0:54.95elapsed 27%CPU (0avgtext+0avgdata 3964maxresident)k
96inputs+58593760outputs (0major+564minor)pagefaults 0swaps

That is 30GBytes written in about 55 seconds. That is 545 MBytes per
second, which it actually says in the command response.

So... I still do not see any long term or average throughput problem
here. Although even if it had said 69 MBytes/sec I would still think
that is enough to handle 56 MBytes/sec average rate under the right
circumstances.
So... do I now need to do some sort of buffer setup to handle the data
flow during periods the system is too busy to write to the disk, or
the disk is too busy to be written to?
I already have the UHD USRP Source with num_recv_frames=1024 (have
also tried 512). In this version of UHD (3.8.1) you have to enter this
in the Device Arguments param space without quotes.
I also see the advanced tab of all the blocks that has the minimum and
maximum output buffer sizes.
But... I know nothing about how any of these work, certainly not in a
quantitative sense anyhow.

Or am I still missing some reason why this will never work at all?

- John

John Murphy
jmur...@comsonics.com


On Sat, May 9, 2015 at 9:02 AM, Murphy, John  wrote:
> Marcus et al,
>
> Had to drop this to do some work on another project yesterday, but
> still want to pursue this just a little further if you don't mind,
> because the numbers you are giving all look to me like it should be
> able to be made to work.
>
> You found my SDD sequential sustained write speed of 69 MBytes/sec.
> If I attempt to save data at 14 MSamp/sec to disk with complex 16-bit
> integers I believe there is an average long-term rate of 56 MBytes/sec
> going to the disk.
>
> So I am not understanding - it seems to me like I have plenty of
> sustained throughput overhead to make this work, with the right
> buffering to take up the temporary slack.
>
> With 16 GBytes of RAM (the system is using some, but still) I would
> expect that I can buffer up something like 4 minutes of data at the
> required 56 MBytes/sec rate - seems like with the proper setup there
> should be plenty of capability to ride through whatever other kernel
> operations etc are momentarily stalling the disk writes.
>
> Thanks, I appreciate you taking the time and list bandwidth to help me
> understand this,
> - John
>
> Date: Thu, 07 May 2015 17:35:57 -0400
> From: "Marcus D. Leech" 
>
> The basic problem is that if the long-term-average offered-load on your
> write medium (your SSD in this case) is higher than it can sustain, it
> doesn't
>matter how much buffering you add in front of it, eventually, the
> piper has to be paid.   Buffering is useful to meeting short-term
> short-falls in
>throughput capacity.  They *cannot* help if offered load, on average,
> exceeds the long-term capacity of the resource.  Now, having said that,
>if you only need to record for a short time, consider adding more
> RAM, and creating a ramdisk, then stage the ramdisk out to your hard disk.
>But this ONLY WORKS if you don't need to record continuously,
> otherwise, you're back to the buffering issue
> But at 8Msps, and 4-bytes per sample, that's 32Mbyte/second, you have
> about 30 seconds/gigabyte.
>
>> On Thu, May 7, 2015 at 3:43 PM,   wrote:
>
>>> I looked at their blurb on that drive, and its *sustained* rate comes out to
>>> about 69Mbyte/second.  Sure, it'll take bursts at screaming-fast rates,
>>> because, like the Linux kernel, it has a whacking great write-behind buffer.

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

Re: [Discuss-gnuradio] Is it possible to undo my mistake

[Marcus Müller]

But if you get hackrf libs through Ubuntu's package manager, do so
before building anything related to HackRF (i.e. before running pybombs,
especially before installing gr-osmosdr); The problem is that a program
links against a specific ABI of a library -- in general, against
*exactly* the same version of the library that was there when the
program was being built. This means that getting hackrf /libhackrf0 from
Ubuntus repositories will not make your version of GNU Radio built
before that installation use that library -- you'll have to recompile
gr-osmosdr to get that functionality.

In fact, if you just use pyBombs' default setting of installing from deb
if a sufficient version can be found, Hackrf/libhackrf will
automatically be installed from Ubuntu's repos if you
pybombs install gr-osmosdr

So, my way of doing this would be, on a freshly set up system (with
nothing related to this previously installed):

* getting pybombs
* (sudo) ./pybombs install gnuradio gr-osmosdr

and you should get a running system -- Ubuntu 14.04 is probably the most
prolific target for pybombs these days, and the defaults should be
"pretty safe".

Best regards,
Marcus

On 05/11/2015 07:52 PM, West, Nathan wrote:
> You can also get hackrf libs through Ubuntu's package manager.
>
> Whatever install method you choose it is best to avoid deleting
> installed libraries unless you really know what you are doing.
>
> -Nathan
>
> On Mon, May 11, 2015 at 12:37 PM, Martin Braun  > wrote:
>
> Safest for GNU Radio is package manager. Can't speak for HackRF,
> but you
> can always use PyBOMBS. If you install GNU Radio through apt-get, and
> then HackRF through PyBOMBS, you might need to set GNU Radio as
> already
> installed in PyBOMBS.
>
> Cheers,
> Martin
>
> On 11.05.2015 10:35, Carl Olsson wrote:
> > Hi all,
> >
> > I couldn't solve my problems so I decided to reinstall Ubuntu 14.04
> > LTS from the beginning on my hp elitebook 8460p. What is the safest
> > (highest probability of working) way of installing gnuradio (and
> > hackrf tools)? I just need a simple installation. Pybombs, build
> > script, package manager or something else?
> >
> > Best regards,
> >
> > Carl ___
> 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

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