Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Great to hear that you work finds its way into the official thing! 

 

At the moment, as the RF stuff works, I am trying to learn about all this
crazy video file stuff, for being able to create transport streams with my
own content. Up to now I am still testing with the cartoon .ts :) Still my
laptop (with DVBViewer software) will not decode the audio, while the DVB
tester decodes audio just fine. 

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ron
Economos
Sent: Tuesday, April 7, 2015 8:14 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Yes, rotated constellations are a new feature of DVB-T2. More reading here.

http://www.etsi.org/deliver/etsi_ts/102800_102899/102831/01.02.01_60/ts_1028
31v010201p.pdf

See section 9.2.3. In addition to the rotation, the I and Q components of a
QAM/QPSK symbol are cyclically delayed. Since there's a time and a frequency
interleaver after the modulator, the I and Q components of a symbol get sent
at a different time and a different frequency (OFDM carrier). Almost all
DVB-T2 broadcasters turn this feature on, even with 256QAM. All DVB-T2
receivers must support rotated constellations.

Be sure to change the "Constellation rotation" parameter in both the
Modulator block and the Frame Mapper block, or the receiver will get
confused.

BTW, both the DVB-T2 and DVB-S2 transmitters will be included in GNU Radio
in the next release (3.7.7) as part of gr-dtv.

If you place a Scope Sink after the modulator, you can see the "virtual"
constellation mentioned in the link above.



Ron

On 04/06/2015 10:14 PM, Ralph A. Schmid, dk5ras wrote:

It _is_ intended:

 

http://dcis2009.unizar.es/FILES/CR2/p41.pdf

 

So forget about my question :)

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org

[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 07:04
To: discuss-gnuradio@gnu.org  
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hmm, now I see, there is an option "constellation rotation" in the modulator
block. Maybe this is not an accident, but wanted behavior?! I will check
this evening...


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 06:39
To: discuss-gnuradio@gnu.org  
Subject: [Discuss-gnuradio] DVB-T/T2

 

Hi,

 

With Rons help I got the DVB-T/T2 flowgraphs up and running.

 

DVB-T works great, no issues at all, while DVB-T2 is somehow flaky in
reception.

 

When using a cheap DVB-x tester, the DVB-T2 constellation is phase shifted.
I have no real world T2 signals to compare, but at least the tester shows
normal constellation views when looking at S and T signals off the air.

 

This is how things look:

 

http://dk5ras.dyndns.org/tmp/DVB/

 

The flowgraphs are almost original, just adopted to the USRP B210, and I
added channel slider...

 

Any ideas what I could tweak?

 

Ralph.

 

 

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

Re: [Discuss-gnuradio] DVB-T/T2

[Ron Economos]

The test clips have AC3 audio. AC3 is not used much at all in Europe 
because broadcasters have to pay an extra licensing fee to Dolby to 
transmit it. It looks like DVBViewer does not come with an AC3 decoder, 
but you can add one.


http://www.dvbviewer.com/en/index.php/index.php?page=manual&chapter=j&sub=j2

Ron

On 04/07/2015 12:09 AM, Ralph A. Schmid, dk5ras wrote:


Great to hear that you work finds its way into the official thing!

At the moment, as the RF stuff works, I am trying to learn about all 
this crazy video file stuff, for being able to create transport 
streams with my own content. Up to now I am still testing with the 
cartoon .ts :) Still my laptop (with DVBViewer software) will not 
decode the audio, while the DVB tester decodes audio just fine.


Ralph.

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

[Discuss-gnuradio] finding information

[sudarshan kumar m p]

Hi all,

I am trying to add a block which does an extra clever work. This needs a
sound knowledge on editing several subdirectories like swig, grc and
cmakefiles.txt etc. as you have stated in the out of tree modules page.
kindly share about where can I learn about editing them.

Thanking you in advance.

with regards
*sudarshan kumar m p*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] finding information

[Marcus Müller]

Hi Sudarshan,

we're not really hiding any information there -- basically, the trick
would be to look at other OOTs, experiment yourself and come here if any
specific questions arise.

However, "does an extra clever work" doesn't really explain why you'd
need to divert from the "standard" workflow as explained in the Guided
Tutorials [1] -- if you haven't read those, I recommend doing that; it's
a quick and fun read if you already know half of the stuff in there, and
it explains a lot about how things work together, so it might even
answer your questions :)

Best regards,
Marcus

[1]https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

On 04/07/2015 10:41 AM, sudarshan kumar m p wrote:
> Hi all,
>
> I am trying to add a block which does an extra clever work. This needs a
> sound knowledge on editing several subdirectories like swig, grc and
> cmakefiles.txt etc. as you have stated in the out of tree modules page.
> kindly share about where can I learn about editing them.
>
> Thanking you in advance.
>
> with regards
> *sudarshan kumar m p*
>
>
>
> ___
> 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] N210 XCVR2450 Max Transmit Gain

[David Halls]

?Dear All,


For some experiments I would like to transmit using N210s with XCVR2450 with 
maximum transmit gain.

I can see Ettus website that the XCVR2450 board in the transmit path has a gain 
of:
 VGA: 0-30 dB range
 BB: 0-5 dB range?

Can I just set the gain via GNU Radio/UHD to 35, or do I need to set these two 
values individually, and if so how.

I read this thread, but didn't quite follow

http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00462.html?

Thanks!







NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

[Discuss-gnuradio] Error in creating a block

[Vishwanatha H G]

Hi all,
 I crated a block named costas_loop_cc. it works fine for 2psk, 4psk,4qam
and 8psk. But it does not support to 16QAM i.e order 16. when I execute
with order 16 it shows the error like this:
Generating: "/home/lekha/Downloads/mpsk_stage6.py"

Generating: "/home/lekha/Downloads/mpsk_stage6.py"

Executing: "/home/lekha/Downloads/mpsk_stage6.py"

Using Volk machine: sse4_1_32
Traceback (most recent call last):
  File "/home/lekha/Downloads/mpsk_stage6.py", line 443, in 
tb = mpsk_stage6()
  File "/home/lekha/Downloads/mpsk_stage6.py", line 285, in __init__
self.costas_loop_cc_0 = digital.costas_loop_cc(.1, 16)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/digital/digital_swig.py",
line 1104, in make
return _digital_swig.costas_loop_cc_make(*args, **kwargs)
RuntimeError: order must be 2, 4, or 8

I used QAM_constellation.py code for constellation ploting of 16 QAM . Why
it does not support for order 16? how should I make it work? any
alternative for 16QAM demod?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Transmission issue in USRP N210

[Zamrath Nizam]

Hi all,

I have recently installed openbts-2.8 on a banana-pi (Processor: armv7)
board to work with USRP N210. Had all the pre-requisite installations and
procedures been done, I noticed that, the transmitter is not working.

Though this issue seems to be related with openbts but since they are not
responding, I would like to have some suggestions from you to resolve this
issue.

In a previous thread 'Marcus' has stated that LED A is not working because
openbts is not talking to USRP. i.e. USRP is not configured to receive
samples.

Is he pointing to a receiving issue (probably I was looking for a
transmission issue) or am I the one who is confused?

Can anyone please shed some light on this.

Thank you.

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

Re: [Discuss-gnuradio] Transmission issue in USRP N210

[Marcus D. Leech]

On 04/07/2015 08:14 AM, Zamrath Nizam wrote:

Hi all,

I have recently installed openbts-2.8 on a banana-pi (Processor: 
armv7) board to work with USRP N210. Had all the pre-requisite 
installations and procedures been done, I noticed that, the 
transmitter is not working.


Though this issue seems to be related with openbts but since they are 
not responding, I would like to have some suggestions from you to 
resolve this issue.


In a previous thread 'Marcus' has stated that LED A is not working 
because openbts is not talking to USRP. i.e. USRP is not configured to 
receive samples.


Is he pointing to a receiving issue (probably I was looking for a 
transmission issue) or am I the one who is confused?


Can anyone please shed some light on this.

Thank you.

Best,
Zamrath Nizam


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

Can you ping the N210?

If you use:

uhd_usrp_probe --args addr=192.168.10.2

What happens?

Is your ethernet interface configured for 192.168.10.1 ?


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

Re: [Discuss-gnuradio] Transmission issue in USRP N210

[Zamrath Nizam]

Hi Marcus,

> Can you ping the N210?

Yes. "ping 192.168.10.2" works fine.

> If you use: uhd_usrp_probe --args addr=192.168.10.2, What happens?

"uhd_usrp_probe" also works fine. Couldn't check with --args. I am away
from the board now for few hours. Until then...

> Is your ethernet interface configured for 192.168.10.1 ?

Yes. Configured statically in "/etc/network/interfaces" file.

Thanks,
Zamrath Nizam

On Tue, Apr 7, 2015 at 6:13 PM, Marcus D. Leech  wrote:

>  On 04/07/2015 08:14 AM, Zamrath Nizam wrote:
>
>  Hi all,
>
>  I have recently installed openbts-2.8 on a banana-pi (Processor: armv7)
> board to work with USRP N210. Had all the pre-requisite installations and
> procedures been done, I noticed that, the transmitter is not working.
>
>  Though this issue seems to be related with openbts but since they are
> not responding, I would like to have some suggestions from you to resolve
> this issue.
>
>  In a previous thread 'Marcus' has stated that LED A is not working because
> openbts is not talking to USRP. i.e. USRP is not configured to receive
> samples.
>
>  Is he pointing to a receiving issue (probably I was looking for a
> transmission issue) or am I the one who is confused?
>
>  Can anyone please shed some light on this.
>
>  Thank you.
>
>  Best,
> Zamrath Nizam
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  Can you ping the N210?
>
> If you use:
>
> uhd_usrp_probe --args addr=192.168.10.2
>
> What happens?
>
> Is your ethernet interface configured for 192.168.10.1 ?
>
>
>
> ___
> 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] Transmission issue in USRP N210

[Marcus Müller]

The other Marcus here, I was the one that said something about the LEDs:

If your N210's transmit LED is not on, then openBTS simply did not
instruct the USRP to send samples.
Thus, you will have to fix the problem on openBTS side. I'm pretty sure
we went through all the diagnostics that made sense, and your USRP and
UHD are working fine.

Greetings,
Marcus

On 04/07/2015 02:56 PM, Zamrath Nizam wrote:
> Hi Marcus,
>
>> Can you ping the N210?
> Yes. "ping 192.168.10.2" works fine.
>
>> If you use: uhd_usrp_probe --args addr=192.168.10.2, What happens?
> "uhd_usrp_probe" also works fine. Couldn't check with --args. I am away
> from the board now for few hours. Until then...
>
>> Is your ethernet interface configured for 192.168.10.1 ?
> Yes. Configured statically in "/etc/network/interfaces" file.
>
> Thanks,
> Zamrath Nizam
>
> On Tue, Apr 7, 2015 at 6:13 PM, Marcus D. Leech  wrote:
>
>>  On 04/07/2015 08:14 AM, Zamrath Nizam wrote:
>>
>>  Hi all,
>>
>>  I have recently installed openbts-2.8 on a banana-pi (Processor: armv7)
>> board to work with USRP N210. Had all the pre-requisite installations and
>> procedures been done, I noticed that, the transmitter is not working.
>>
>>  Though this issue seems to be related with openbts but since they are
>> not responding, I would like to have some suggestions from you to resolve
>> this issue.
>>
>>  In a previous thread 'Marcus' has stated that LED A is not working because
>> openbts is not talking to USRP. i.e. USRP is not configured to receive
>> samples.
>>
>>  Is he pointing to a receiving issue (probably I was looking for a
>> transmission issue) or am I the one who is confused?
>>
>>  Can anyone please shed some light on this.
>>
>>  Thank you.
>>
>>  Best,
>> Zamrath Nizam
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>  Can you ping the N210?
>>
>> If you use:
>>
>> uhd_usrp_probe --args addr=192.168.10.2
>>
>> What happens?
>>
>> Is your ethernet interface configured for 192.168.10.1 ?
>>
>>
>>
>> ___
>> 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] Clipping Complex Samples to +/- 1.0?

[Michael Dickens]

Hi John - There aren't a lot of choices to do clipping; this is
basically:

{{{
float* in = (float*) INPUT;
float* out = (float*) OUTPUT;
for(int nn=0; nnhttp://libvolk.org/doxygen/volk_32f_x2_max_32f.html > & <
http://libvolk.org/doxygen/volk_32f_x2_min_32f.html >, which would
auto-magically handle the whole loop for you.

Maybe someone else can come up with a good reference for a branchless
version of this? Hope this helps! - MLD

On Mon, Apr 6, 2015, at 08:25 PM, John Malsbury wrote:
> This may be more of a general C++ question than a GNU Radio
> question... Is there any super convenient and fast way to clip a
> complex signal to +/- 1.0 on both I & Q? Something other than
> splitting them up into floats and using branchless_clip or if
> statements?

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

Re: [Discuss-gnuradio] DVB-T/T2

[Bogdan Diaconescu]

Hi Ron,
I have not followed the development of DVB-T2/S2 lately. Are there receiver 
implementations for the T2/S2 or just transmitters?
Thanks,
Bogdan
 


 On Tuesday, April 7, 2015 1:32 PM, "Ralph A. Schmid, dk5ras" 
 wrote:
   

 #yiv0268530338 #yiv0268530338 -- _filtered #yiv0268530338 {panose-1:2 4 5 3 5 
4 6 3 2 4;} _filtered #yiv0268530338 {font-family:Calibri;panose-1:2 15 5 2 2 2 
4 3 2 4;} _filtered #yiv0268530338 {panose-1:2 11 5 2 4 2 4 2 2 3;} _filtered 
#yiv0268530338 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 
4;}#yiv0268530338 #yiv0268530338 p.yiv0268530338MsoNormal, #yiv0268530338 
li.yiv0268530338MsoNormal, #yiv0268530338 div.yiv0268530338MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv0268530338 
a:link, #yiv0268530338 span.yiv0268530338MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv0268530338 a:visited, #yiv0268530338 
span.yiv0268530338MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv0268530338 
p.yiv0268530338MsoAcetate, #yiv0268530338 li.yiv0268530338MsoAcetate, 
#yiv0268530338 div.yiv0268530338MsoAcetate 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;color:black;}#yiv0268530338 
span.yiv0268530338SprechblasentextZchn {color:black;}#yiv0268530338 
span.yiv0268530338E-MailFormatvorlage19 {color:windowtext;}#yiv0268530338 
span.yiv0268530338E-MailFormatvorlage20 {color:#1F497D;}#yiv0268530338 
p.yiv0268530338BalloonText, #yiv0268530338 li.yiv0268530338BalloonText, 
#yiv0268530338 div.yiv0268530338BalloonText 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv0268530338 
span.yiv0268530338BalloonTextChar {}#yiv0268530338 
span.yiv0268530338E-MailFormatvorlage23 {color:#1F497D;}#yiv0268530338 
span.yiv0268530338E-MailFormatvorlage24 {color:#1F497D;}#yiv0268530338 
.yiv0268530338MsoChpDefault {font-size:10.0pt;} _filtered #yiv0268530338 
{margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv0268530338 
div.yiv0268530338WordSection1 {}#yiv0268530338 Great to hear that you work 
finds its way into the official thing!   At the moment, as the RF stuff works, 
I am trying to learn about all this crazy video file stuff, for being able to 
create transport streams with my own content. Up to now I am still testing with 
the cartoon .ts :) Still my laptop (with DVBViewer software) will not decode 
the audio, while the DVB tester decodes audio just fine.   Ralph.  From: 
discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ron 
Economos
Sent: Tuesday, April 7, 2015 8:14 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2  Yes, rotated constellations are a new 
feature of DVB-T2. More reading here.

http://www.etsi.org/deliver/etsi_ts/102800_102899/102831/01.02.01_60/ts_102831v010201p.pdf

See section 9.2.3. In addition to the rotation, the I and Q components of a 
QAM/QPSK symbol are cyclically delayed. Since there's a time and a frequency 
interleaver after the modulator, the I and Q components of a symbol get sent at 
a different time and a different frequency (OFDM carrier). Almost all DVB-T2 
broadcasters turn this feature on, even with 256QAM. All DVB-T2 receivers must 
support rotated constellations.

Be sure to change the "Constellation rotation" parameter in both the Modulator 
block and the Frame Mapper block, or the receiver will get confused.

BTW, both the DVB-T2 and DVB-S2 transmitters will be included in GNU Radio in 
the next release (3.7.7) as part of gr-dtv.

If you place a Scope Sink after the modulator, you can see the "virtual" 
constellation mentioned in the link above.



RonOn 04/06/2015 10:14 PM, Ralph A. Schmid, dk5ras wrote:
It _is_ intended: http://dcis2009.unizar.es/FILES/CR2/p41.pdf So forget about 
my question :) Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ralph 
A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 07:04
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2 Hmm, now I see, there is an option 
"constellation rotation" in the modulator block. Maybe this is not an accident, 
but wanted behavior?! I will check this evening...
Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ralph 
A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 06:39
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] DVB-T/T2 Hi, With Rons help I got the DVB-T/T2 
flowgraphs up and running. DVB-T works great, no issues at all, while DVB-T2 is 
somehow flaky in reception. When using a cheap DVB-x tester, the DVB-T2 
constellation is phase shifted. I have no real world T2 signals to compare, but 
at least the tester shows normal constellation views when looking at S and T 
signals off the air. This is how things look: http://dk5ras.dyndns.org/tmp/DVB/ 
The flowgraphs are almost original, just adopted to the USRP B210, and I added 
chann

Re: [Discuss-gnuradio] Error in creating a block

[Tom Rondeau]

On Tue, Apr 7, 2015 at 7:06 AM, Vishwanatha H G <
vishwanatha.1si12ec...@gmail.com> wrote:

> Hi all,
>  I crated a block named costas_loop_cc. it works fine for 2psk, 4psk,4qam
> and 8psk. But it does not support to 16QAM i.e order 16. when I execute
> with order 16 it shows the error like this:
> Generating: "/home/lekha/Downloads/mpsk_stage6.py"
>
> Generating: "/home/lekha/Downloads/mpsk_stage6.py"
>
> Executing: "/home/lekha/Downloads/mpsk_stage6.py"
>
> Using Volk machine: sse4_1_32
> Traceback (most recent call last):
>   File "/home/lekha/Downloads/mpsk_stage6.py", line 443, in 
> tb = mpsk_stage6()
>   File "/home/lekha/Downloads/mpsk_stage6.py", line 285, in __init__
> self.costas_loop_cc_0 = digital.costas_loop_cc(.1, 16)
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/digital/digital_swig.py",
> line 1104, in make
> return _digital_swig.costas_loop_cc_make(*args, **kwargs)
> RuntimeError: order must be 2, 4, or 8
>
> I used QAM_constellation.py code for constellation ploting of 16 QAM . Why
> it does not support for order 16? how should I make it work? any
> alternative for 16QAM demod?
>

You mean that you wrote your own version of the costas loop block? If so,
then it's up to you to add support for those modulations. But the Costas
loop is not designed for QAM signals, just QPSK. And frankly, it's
originally designed just for BPSK, then it was extended to QPSK, and we
added support for 8PSK.

You can look into the constellation_receiver block to see how other
modulations are supported. The constellation objects have the ability to
simply calculate the minimum Euclidean distance from the sample to all
possible points in the known constellation. It works, but it's slow. The
Costas loop is a trick for these three specific ones.

Read the digital modulation page of the GNU Radio manual for more info on
the constellation objects:
http://gnuradio.org/doc/doxygen/page_digital.html

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

[Discuss-gnuradio] Two Clock Drift Compensation, howto ?

[Roland Schwarz]

Dear all!

When I have multiple hw audio (or other) sources and sinks gnuradio is
suffering from the "two clock problem".

>From the docs I have read, one means to mitigate against under- or over-
runs is to have the sender always be a little faster.

While I understand that this will help keep the sink always filled it
will not avoid buffer under runs, or am I misunderstanding something?

Also the only way for the source to keep up is to throw away samples at
times.

Has anyone came up with an idea of how this problem could (should) be
addressed in a proper way in gnu-radio? (I mean without changing hw.)

>From a little test set up I have seen that I could program a sink and a
source, referencing a common buffer. The buffer level (a smoothed
version) could be the driving variable to a dynamically programmed
sample rate converter that is set up so as to keep the buffer level
constant.

Is this a too hakish attempt to address the problem?

Has anyone already tried this?

Is there a more straight forward way, i.e. using a regular input-output
module?

I am thankful for any hints or comments.

Roland

-- 
_
  _  _  | Roland Schwarz
 |_)(_  |
 | \__) | mailto:roland.schw...@blackspace.at
| http://www.blackspace.at

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

Re: [Discuss-gnuradio] pccc encoder

[Achilleas Anastasopoulos]

There are several issues with your code:

1) a PCCC encoder (as any digital communication encoder) cannot accept a
"sine wave" as its input!
it only accepts discrete information.
In this case it should be numbers {0,1,2,...,X-1} where X is the input
alphabet size of your fsm's.

2) The output cardinality of the PCCC is the product of the output
cardinalities of the two FSMs that you are using,
so in your case is 2^3 x 2^3 = 64, which is not consistent with the size of
the modulation you are using

3) The interleaver length is user-defined and there is no such thing as an
appropriate length (the longer the better performance... )



I suggest you look and try to understand the EXAMPLE (aptly named pccc.grc)
in the gr-trellis/examples/grc
and let us know if you have any questions on this particular example.
Then you can move on to change it according to your needs.

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

Re: [Discuss-gnuradio] Help Me

[Martin Braun]

Hi,

I recommend having a look at this page: 
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors


Also, in your case, there is a separate document generated somewhere in 
the build directory from a docbook XML file.


M

On 06.04.2015 14:17, Marbellys Ramos Guerrero wrote:

Hi, How do I Generate New locks and use the fsm const variable &FSM is the .cc 
?When I write the block and compiled by the terminal , it generates an error that 
fsm is not declared.


In the .cc file I'm uploading on the part of make ( const fsm & FSM , int ST ) 
is what I can not make it generates compile error that fsm is not a variable .



___
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] Transmission issue in USRP N210

[Zamrath Nizam]

Hi Marcus and Marcus,

Thank you for the valuable comments given. It made us to shrink all our
focus on OpenBTS. But I see an inactive list in openbts side made me to
wait for there response for a while. That's why I thought to circulate this
in gnuradio list hoping for any assistance to overcome this.

I have freshly installed openbts for three times upto now beside few many
build cleans and installs. But I saw no breakthrough. Truth to be told,
when I build openbts on banana-pi, I encountered following errors and did
few manipulations given accordingly.

i) SIPEngine.cpp:1620:60: error: too few arguments to function 'int
rtp_session_set_local_addr(RtpSession*, const char*, int, int)'
   rtp_session_set_local_addr(mSession, "0.0.0.0", mRTPPort );

Changed line 291, "ORTP_PUBLIC int rtp_session_set_local_addr(RtpSession
*session,const char *addr, int rtp_port, int rtcp_port);" into,
"ORTP_PUBLIC int rtp_session_set_local_addr(RtpSession *session,const char
*addr, int rtp_port);"

ii) SIPMessage.cpp:39:44: error: expected ',' or ';' before 'VERSION'
  static const char* userAgent = "OpenBTS " VERSION " Build Date " __DATE__;

Changed line 39 of "trunk/SIP/SIPMessage.cpp" ("static const char*
userAgent = "OpenBTS " VERSION " Build Date " __DATE__;") into, "static
const char* userAgent = "OpenBTS Build Date " __DATE__;"

iii) OpenBTS.cpp:375:48: error: ‘VERSION’ was not declared in this scope
  LOG(ALERT) << "OpenBTS (re)starting, ver " << VERSION << " build date "
<< __DATE__;

Changed line 375 of "trunk/apps/OpenBTS.cpp" ("LOG(ALERT) << "OpenBTS
(re)starting, ver " << VERSION << " build date " << __DATE__;") into,
"LOG(ALERT) << "OpenBTS (re)starting, build date " << __DATE__;"

Had above changes done, build was successfully compiled. Change i) was done
according to "
http://linphone.sourcearchive.com/documentation/3.0.0-3/rtpsession_8h_4a0c6522db89dbbf368abaeafb850e64.html
".

Anyone has a hint?

Thank you.

Best regards,
Zamrath Nizam

PS: First Marcus, The output corresponding to "uhd_usrp_probe --args
addr=192.168.10.2" is,

---
-- UHD Device 0
---
Device Address:
 type: usrp2
 addr: 192.168.10.2
 name:
 serial: F3A31F



On Tue, Apr 7, 2015 at 6:40 PM, Marcus Müller 
wrote:

>  The other Marcus here, I was the one that said something about the LEDs:
>
> If your N210's transmit LED is not on, then openBTS simply did not
> instruct the USRP to send samples.
> Thus, you will have to fix the problem on openBTS side. I'm pretty sure we
> went through all the diagnostics that made sense, and your USRP and UHD are
> working fine.
>
> Greetings,
> Marcus
>
>
> On 04/07/2015 02:56 PM, Zamrath Nizam wrote:
>
> Hi Marcus,
>
>
>  Can you ping the N210?
>
>  Yes. "ping 192.168.10.2" works fine.
>
>
>  If you use: uhd_usrp_probe --args addr=192.168.10.2, What happens?
>
>  "uhd_usrp_probe" also works fine. Couldn't check with --args. I am away
> from the board now for few hours. Until then...
>
>
>  Is your ethernet interface configured for 192.168.10.1 ?
>
>  Yes. Configured statically in "/etc/network/interfaces" file.
>
> Thanks,
> Zamrath Nizam
>
> On Tue, Apr 7, 2015 at 6:13 PM, Marcus D. Leech  
>  wrote:
>
>
>   On 04/07/2015 08:14 AM, Zamrath Nizam wrote:
>
>  Hi all,
>
>  I have recently installed openbts-2.8 on a banana-pi (Processor: armv7)
> board to work with USRP N210. Had all the pre-requisite installations and
> procedures been done, I noticed that, the transmitter is not working.
>
>  Though this issue seems to be related with openbts but since they are
> not responding, I would like to have some suggestions from you to resolve
> this issue.
>
>  In a previous thread 'Marcus' has stated that LED A is not working because
> openbts is not talking to USRP. i.e. USRP is not configured to receive
> samples.
>
>  Is he pointing to a receiving issue (probably I was looking for a
> transmission issue) or am I the one who is confused?
>
>  Can anyone please shed some light on this.
>
>  Thank you.
>
>  Best,
> Zamrath Nizam
>
>
> __
> _
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  Can you ping the N210?
>
> If you use:
>
> uhd_usrp_probe --args addr=192.168.10.2
>
> What happens?
>
> Is your ethernet interface configured for 192.168.10.1 ?
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] pybombs bombs

[Mike Willis]

Hi All,

I made a mistake this morning and tried to refresh gnuradio with
pybombs to test an FCD ProPlus against the latest main branch. Pybombs
has worked fine up until now and I successfully installed it on a
different machine on Sunday. Today it crashed and I found it had an
empty volk directory which I fixed with the --recursive option noted
here in another thread.

Unfortunately since this, UHD will no longer compile complaining about
boost not having a type unint_32. I can build the rest of gnuradio by
deleting UHD from the recipie but this does not help me operate my
B200.

Any suggestions? I have scoured the web and not found a solution.

Mike

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

Re: [Discuss-gnuradio] pybombs bombs

[Richard Bell]

If it were me, the easiest way to get around an issue like this is to start
over. You might have a linker problem.

./pybombs remove

delete the pybombs and target directories

clone the latest version of pybombs

./pybombs install gnuradio

If you still have an issue then go from there.

v/r,
Rich



On Tue, Apr 7, 2015 at 11:28 AM, Mike Willis  wrote:

> Hi All,
>
> I made a mistake this morning and tried to refresh gnuradio with
> pybombs to test an FCD ProPlus against the latest main branch. Pybombs
> has worked fine up until now and I successfully installed it on a
> different machine on Sunday. Today it crashed and I found it had an
> empty volk directory which I fixed with the --recursive option noted
> here in another thread.
>
> Unfortunately since this, UHD will no longer compile complaining about
> boost not having a type unint_32. I can build the rest of gnuradio by
> deleting UHD from the recipie but this does not help me operate my
> B200.
>
> Any suggestions? I have scoured the web and not found a solution.
>
> Mike
>
> ___
> 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] Two Clock Drift Compensation, howto ?

[Stephen Harrison]

Hi Roland,

I have used the method you suggest in the distant past to match sample
rates of audio hardware with nominally equal but independent clocks. I
found it worked "ok" as long as the resampler you are using can handle
small dynamic offsets ie: +/- 0.1Hz without noticeable artifacts. The FIFO
used to measure the difference in rate also adds some latency.

On Tue, Apr 7, 2015 at 7:34 AM, Roland Schwarz  wrote:

> Dear all!
>
> When I have multiple hw audio (or other) sources and sinks gnuradio is
> suffering from the "two clock problem".
>
> From the docs I have read, one means to mitigate against under- or over-
> runs is to have the sender always be a little faster.
>
> While I understand that this will help keep the sink always filled it
> will not avoid buffer under runs, or am I misunderstanding something?
>
> Also the only way for the source to keep up is to throw away samples at
> times.
>
> Has anyone came up with an idea of how this problem could (should) be
> addressed in a proper way in gnu-radio? (I mean without changing hw.)
>
> From a little test set up I have seen that I could program a sink and a
> source, referencing a common buffer. The buffer level (a smoothed
> version) could be the driving variable to a dynamically programmed
> sample rate converter that is set up so as to keep the buffer level
> constant.
>
> Is this a too hakish attempt to address the problem?
>
> Has anyone already tried this?
>
> Is there a more straight forward way, i.e. using a regular input-output
> module?
>
> I am thankful for any hints or comments.
>
> Roland
>
> --
> _
>   _  _  | Roland Schwarz
>  |_)(_  |
>  | \__) | mailto:roland.schw...@blackspace.at
> | http://www.blackspace.at
>
> ___
> 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] pybombs bombs

[Mike Willis]

Thanks - I tried that. Same issue.Something wrong with UHD and my setup perhaps?

Mike

/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:96:48: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_dst_addr(), (uint32_t)0x0c);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_dst_endpoint(), (uint32_t)0x04);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get(), (uint32_t)0x0a0b0c0d);
   ^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_src_addr(), (uint32_t)0x0a);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:103:48: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_src_endpoint(), (uint32_t)0x0b);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:103:48: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:104:44: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_dst_addr(), (uint32_t)0x0c);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:104:44: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32

Re: [Discuss-gnuradio] DVB-T/T2

[Ron Economos]

Only transmitter implementations for now. They are here:

https://github.com/drmpeg/gr-dvbs2

https://github.com/drmpeg/gr-dvbt2

The DVB-T2 implementation supports T2-Lite, tone reservation PAPR 
reduction and MISO processing.


Ron

On 04/07/2015 06:38 AM, Bogdan Diaconescu wrote:

Hi Ron,

I have not followed the development of DVB-T2/S2 lately. Are there 
receiver implementations for the T2/S2 or just transmitters?


Thanks,
Bogdan



On Tuesday, April 7, 2015 1:32 PM, "Ralph A. Schmid, dk5ras" 
 wrote:



Great to hear that you work finds its way into the official thing!
At the moment, as the RF stuff works, I am trying to learn about all 
this crazy video file stuff, for being able to create transport 
streams with my own content. Up to now I am still testing with the 
cartoon .ts :) Still my laptop (with DVBViewer software) will not 
decode the audio, while the DVB tester decodes audio just fine.

Ralph.

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

Re: [Discuss-gnuradio] DVB-T/T2

[Ron Economos]

The DVB-T2 transmitter repository is here:

https://github.com/drmpeg/gr-dvbt2

In the README, there are links to test transport streams for a few 
representative flow graphs.


gr-dvbt2 is also part of pybombs.

Ron

On 04/07/2015 08:02 AM, g.roel...@telenet.be wrote:

Hi,
Can someone share the files used?
So we can reproduce the work?


*Van: *"Ron Economos" 
*Aan: *discuss-gnuradio@gnu.org
*Verzonden: *Dinsdag 7 april 2015 08:14:22
*Onderwerp: *Re: [Discuss-gnuradio] DVB-T/T2

Yes, rotated constellations are a new feature of DVB-T2. More reading 
here.


http://www.etsi.org/deliver/etsi_ts/102800_102899/102831/01.02.01_60/ts_102831v010201p.pdf

See section 9.2.3. In addition to the rotation, the I and Q components 
of a QAM/QPSK symbol are cyclically delayed. Since there's a time and 
a frequency interleaver after the modulator, the I and Q components of 
a symbol get sent at a different time and a different frequency (OFDM 
carrier). Almost all DVB-T2 broadcasters turn this feature on, even 
with 256QAM. All DVB-T2 receivers must support rotated constellations.


Be sure to change the "Constellation rotation" parameter in *both* the 
Modulator block and the Frame Mapper block, or the receiver will get 
confused.


BTW, both the DVB-T2 and DVB-S2 transmitters will be included in GNU 
Radio in the next release (3.7.7) as part of gr-dtv.


If you place a Scope Sink after the modulator, you can see the 
"virtual" constellation mentioned in the link above.


Virtual 16QAM

Ron

On 04/06/2015 10:14 PM, Ralph A. Schmid, dk5ras wrote:

It _is_ intended:

http://dcis2009.unizar.es/FILES/CR2/p41.pdf

So forget about my question :)

Ralph.

*From:*discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On
Behalf Of *Ralph A. Schmid, dk5ras
*Sent:* Tuesday, April 7, 2015 07:04
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] DVB-T/T2

Hmm, now I see, there is an option "constellation rotation" in the
modulator block. Maybe this is not an accident, but wanted
behavior?! I will check this evening...


Ralph.

*From:*discuss-gnuradio-bounces+ralph=schmid@gnu.org

[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On
Behalf Of *Ralph A. Schmid, dk5ras
*Sent:* Tuesday, April 7, 2015 06:39
*To:* discuss-gnuradio@gnu.org 
*Subject:* [Discuss-gnuradio] DVB-T/T2

Hi,

With Rons help I got the DVB-T/T2 flowgraphs up and running.

DVB-T works great, no issues at all, while DVB-T2 is somehow flaky
in reception.

When using a cheap DVB-x tester, the DVB-T2 constellation is phase
shifted. I have no real world T2 signals to compare, but at least
the tester shows normal constellation views when looking at S and
T signals off the air.

This is how things look:

http://dk5ras.dyndns.org/tmp/DVB/

The flowgraphs are almost original, just adopted to the USRP B210,
and I added channel slider...

Any ideas what I could tweak?

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] pybombs bombs

[Tom Rondeau]

On Tue, Apr 7, 2015 at 4:19 PM, Mike Willis  wrote:

> Thanks - I tried that. Same issue.Something wrong with UHD and my setup
> perhaps?
>
> Mike
>

Have you asked on the usrp-users list? Seems a problem more related to the
UHD than PyBOMBS or GNU Radio. Unless it's a change in configuration that
we need to have reflected in the PyBOMBS recipe.

Tom



> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:96:48: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_dst_addr(), (uint32_t)0x0c);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_dst_endpoint(), (uint32_t)0x04);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get(), (uint32_t)0x0a0b0c0d);
>^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_src_addr(), (uint32_t)0x0a);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:103:48: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_src_endpoint(), (uint32_t)0x0b);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:103:48: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:104:44: error:
> ‘uint32_t’ was

[Discuss-gnuradio] SDRA-2015 Call For Papers

[Markus Heller]

Dear list,

excuses for repeated posting. Two weeks before abstract submission
deadline I'd like to direct your attention to the 

Software Defined Radio Academy 2015 in Friedrichshafen (HAMRADIO
subconference)

http://www.sdra-2015.de/pages/call-for-papers.html

Please feel invited to submit papers and presentations, posters and
talks.

Quote >
SDRA-2015 invites researchers from acadaemia, industry and radio
amateurs to submit papers for oral and poster presentations on recent,
unpublished research that addresses theoretical aspects, algorithms,
applications, hardware and software architectures for applied Software
Defined Radio systems and resources and other aspects of SDR, as well as
survey and discussion papers. The invitation particularly addresses open
source research and projects. We also particularly invite specialists
giving introductory talks and tutorials on SDR technologies.


SDRA Topics:
  * Advances in GNURadio related projects and research
  * Algorithms, applications, architectures in SDR systems
  * Real Time signal processing
  * Innovative applications using modern ADC/DAC environments
<

If you require support in any way, we'll be happy to help you. Please
contact us at:

sdra-2...@darc.de

best regards

markus
dl8rds







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

Re: [Discuss-gnuradio] pybombs bombs

[Mike Willis]

Hi Tom.

 

I think this is the right place as UHD is part of the standard Gnuradio build, 
so it doesn’t really matter if you have a usrp or not, it will crash the build.

 

Mike

 

From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: 07 April 2015 23:06
To: Mike Willis
Cc: Richard Bell; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] pybombs bombs

 

On Tue, Apr 7, 2015 at 4:19 PM, Mike Willis mailto:willis...@gmail.com> > wrote:

Thanks - I tried that. Same issue.Something wrong with UHD and my setup perhaps?

Mike

 

Have you asked on the usrp-users list? Seems a problem more related to the UHD 
than PyBOMBS or GNU Radio. Unless it's a change in configuration that we need 
to have reflected in the PyBOMBS recipe.

 

Tom

 

 

/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:96:48: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_dst_addr(), (uint32_t)0x0c);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_dst_endpoint(), (uint32_t)0x04);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get(), (uint32_t)0x0a0b0c0d);
   ^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_src_addr(), (uint32_t)0x0a);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;
  ^
In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:103:48: error:
‘uint32_t’ was not declared in this scope
 BOOST_CHECK_EQUAL(sid.get_src_endpoint(), (uint32_t)0x0b);
^
/home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:103:48: note:
suggested alternative:
In file included from
/home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
 from /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
/usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
  typedef unsigned intuint32_t;

Re: [Discuss-gnuradio] pybombs bombs

[Tom Rondeau]

On Tue, Apr 7, 2015 at 7:12 PM, Mike Willis  wrote:

> Hi Tom.
>
>
>
> I think this is the right place as UHD is part of the standard Gnuradio
> build, so it doesn’t really matter if you have a usrp or not, it will crash
> the build.
>
>
>
> Mike
>

It's technically an optional dependency, required only for gr-uhd. The
failure you're experiencing it happening when building libuhd, which is not
a GNU Radio project.

As I said, if this is a failure in the PyBOMBS uhd recipe, that's our
concern. A problem in libuhd itself is something that the usrp-users list
would be much better place to get help on this problem.

Tom



>
>
> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf
> Of *Tom Rondeau
> *Sent:* 07 April 2015 23:06
> *To:* Mike Willis
> *Cc:* Richard Bell; GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] pybombs bombs
>
>
>
> On Tue, Apr 7, 2015 at 4:19 PM, Mike Willis  wrote:
>
> Thanks - I tried that. Same issue.Something wrong with UHD and my setup
> perhaps?
>
> Mike
>
>
>
> Have you asked on the usrp-users list? Seems a problem more related to the
> UHD than PyBOMBS or GNU Radio. Unless it's a change in configuration that
> we need to have reflected in the PyBOMBS recipe.
>
>
>
> Tom
>
>
>
>
>
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:96:48: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_dst_addr(), (uint32_t)0x0c);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:97:44: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_dst_endpoint(), (uint32_t)0x04);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:98:48: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get(), (uint32_t)0x0a0b0c0d);
>^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:101:35: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:20:
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: error:
> ‘uint32_t’ was not declared in this scope
>  BOOST_CHECK_EQUAL(sid.get_src_addr(), (uint32_t)0x0a);
> ^
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:102:44: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;
>   ^
> In file included from /usr/local/include/boost/test/unit_test.hpp:19:0,
>  from
> /home/mike/pybombs/src/uhd/host/tests/sid_t_te

Re: [Discuss-gnuradio] pccc encoder

[dcardona]

HI
Thank you very much for your response, you really helped me.

In my last post, i made a mistake. The fsm that i wanted to use is
fsm=1,2,[13,11]. If i understood well, i should use a 16qam modulation.

But i`m using an error rate block, just like in the example pccc.grc (only
that i`m not using any channel), and at the number sink i`m having a ber
value, when i shouldn`t have any. 
I dont`n know where is my mistake.


If you could help me, i really appreciate.
FUNCIONApccc_random_chunks_pcccdeccombo.grc

  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/pccc-encoder-tp53173p53214.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] pybombs bombs

[Michael Dickens]

I just issued a pull request to fix this issue. The problem is that on a
few systems, such as yours, "unit32_t" is undefined in the top-level
namespace, and should really be "boost::uint32_t" anyway to match the
actual values being compared. This fix is just for a test, so it won't
make any difference on UHD functionality. Look for those changes to be
integrated soonish ... - MLD

On Tue, Apr 7, 2015, at 04:19 PM, Mike Willis wrote:
> Thanks - I tried that. Same issue.Something wrong with UHD and my setup
> perhaps?
> 
> /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:96:48: note:
> suggested alternative:
> In file included from
> /home/mike/pybombs/src/uhd/host/include/uhd/types/sid.hpp:22:0,
>  from
>  /home/mike/pybombs/src/uhd/host/tests/sid_t_test.cpp:21:
> /usr/local/include/boost/cstdint.hpp:263:30: note:   ‘boost::uint32_t’
>   typedef unsigned intuint32_t;

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

Re: [Discuss-gnuradio] error while running example of detect_ff block

[Ron Economos]

In your .xml file, the line:

howto.detect_ff($pfa, $L, $samples)

should be:

howto.howto_detect_ff($pfa, $L, $samples)

Ron

On 04/07/2015 09:38 PM, Abhishek Shukla wrote:

hey,
i have successfully imported "detect_ff" block. but right now I am 
getting runtime error while running example on grc as follows.

  File "/home/abhishek/top_block.py", line 84, in 
tb = top_block()
  File "/home/abhishek/top_block.py", line 53, in __init__
self.howto_detect_ff_0 = howto.detect_ff(100, 16, 1500)
AttributeError: 'module' object has no attribute 'detect_ff'

>>> Done
It seems there is some problem with my class name in .cc file, but i 
am not getting what exactly it is. Please help me out with this.
i have attached .cc, .xml file and also screen shot of given example 
is provided


Any help will be appreciated,
Thanks in advance,
Abhishek



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

Re: [Discuss-gnuradio] DVB-T/T2

[Bogdan Diaconescu]

Ok, it would be useful to have receivers too like for the DVB-T. 

Bogdan 


 On Tuesday, April 7, 2015 11:23 PM, Ron Economos  wrote:
   

  Only transmitter implementations for now. They are here:
 
 https://github.com/drmpeg/gr-dvbs2
 
 https://github.com/drmpeg/gr-dvbt2
 
 The DVB-T2 implementation supports T2-Lite, tone reservation PAPR reduction 
and MISO processing.
 
 Ron
 
 On 04/07/2015 06:38 AM, Bogdan Diaconescu wrote:
  
  Hi Ron, 
  I have not followed the development of DVB-T2/S2 lately. Are there receiver 
implementations for the T2/S2 or just transmitters? 
  Thanks,
  Bogdan
   
 
 
   On Tuesday, April 7, 2015 1:32 PM, "Ralph A. Schmid, dk5ras" 
 wrote:
   
 
   #yiv5839327111 -- filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv5839327111 
filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5839327111 
filtered {panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv5839327111 filtered 
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5839327111 
p.yiv5839327111MsoNormal, #yiv5839327111 li.yiv5839327111MsoNormal, 
#yiv5839327111 div.yiv5839327111MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv5839327111 
a:link, #yiv5839327111 span.yiv5839327111MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5839327111 a:visited, #yiv5839327111 
span.yiv5839327111MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5839327111 
p.yiv5839327111MsoAcetate, #yiv5839327111 li.yiv5839327111MsoAcetate, 
#yiv5839327111 div.yiv5839327111MsoAcetate 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;color:black;}#yiv5839327111 
span.yiv5839327111SprechblasentextZchn {color:black;}#yiv5839327111 
span.yiv5839327111E-MailFormatvorlage19 {color:windowtext;}#yiv5839327111 
span.yiv5839327111E-MailFormatvorlage20 {color:#1F497D;}#yiv5839327111 
p.yiv5839327111BalloonText, #yiv5839327111 li.yiv5839327111BalloonText, 
#yiv5839327111 div.yiv5839327111BalloonText 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv5839327111 
span.yiv5839327111BalloonTextChar {}#yiv5839327111 
span.yiv5839327111E-MailFormatvorlage23 {color:#1F497D;}#yiv5839327111 
span.yiv5839327111E-MailFormatvorlage24 {color:#1F497D;}#yiv5839327111 
.yiv5839327111MsoChpDefault {font-size:10.0pt;}#yiv5839327111 filtered 
{margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv5839327111 
div.yiv5839327111WordSection1 {}#yiv5839327111Great to hear that you work 
finds its way into the official thing!     At the moment, as the RF stuff 
works, I am trying to learn about all this crazy video file stuff, for being 
able to create transport streams with my own content. Up to now I am still 
testing with the cartoon .ts :) Still my  laptop (with DVBViewer software) will 
not decode the audio, while the DVB tester decodes audio just fine.     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] pybombs bombs

[Mike Willis]

Hi Tom,

 

I understand your point and it’s a general problem with modules in the recipes 
that are included by default that if any one of them fails to build, so does 
the system. Imagine if I had no USRP and didn’t even know what one was. If I 
came to install Gnuradio it would fail under this system. I would need to know 
there is a USRP list and subscribe to it, even without any usrp. So, really the 
issue is the pybombs recipe including things that are not part of gnuradio by 
default. Effectively they become part of the system by doing that.

 

Mike  

 

From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: 08 April 2015 00:32
To: Mike Willis
Cc: Richard Bell; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] pybombs bombs

 

On Tue, Apr 7, 2015 at 7:12 PM, Mike Willis mailto:willis...@gmail.com> > wrote:

Hi Tom.

 

I think this is the right place as UHD is part of the standard Gnuradio build, 
so it doesn’t really matter if you have a usrp or not, it will crash the build.

 

Mike

 

It's technically an optional dependency, required only for gr-uhd. The failure 
you're experiencing it happening when building libuhd, which is not a GNU Radio 
project.

 

As I said, if this is a failure in the PyBOMBS uhd recipe, that's our concern. 
A problem in libuhd itself is something that the usrp-users list would be much 
better place to get help on this problem.

 

Tom

 

 

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