Re: [Discuss-gnuradio] How to change a flowgraph in c++ dynamically

[Marcus Müller]

Hi Mostafa,
I mean the run option "run to completion" in the GRC. GRC is like LEGO for
communication engineers, if you play around with it, you'll soon be having
fun and have an easier time understanding hints like this ;)
See http://imgur.com/YPUvyzm

Greetings,
Marcus



On Thu, May 15, 2014 at 8:11 AM, Mostafa Alizadeh wrote:

> Hi Marcus,
>
> what do you mean by *"run to completion" *?
>
> best,
> Mostafa
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] saving raw data after correct frame reception

[Activecat]

On Thu, May 15, 2014 at 3:09 PM, Marcus Müller wrote:

> Hi,
>
> sorry I didn't mention earlier:
>
> >Unnecessary historical value increases CPU utilization.
> Is not inherently true, GNU Radio only ensures that buffer is not being
> freed up for overwriting later.
>
> So actually, if you're really interested in but a few hundred historical
> samples, using set_history() is the way to go, as far as I can see.
>
> If, on the other hand, you try to get a history of several thousand
> samples, this might exceed the actual buffer size or reduce the free space
> for the source so that efficient "large sample chunks at once" behaviour is
> no longer possible, and that might hit your CPU in the end.
>
> Greetings,
> Marcus
>


Thank you for highlighting this to me.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] low frequency in GRC

[jason sam]

I am using GNU Radio Companion 3.7.3...when i set the frequency of my
signal source to low values(in Hz or kHz),i get no signal on my scope or
fft sink??
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] LTE and USRP

[Coll Perales, Baldomero]

Hello,

I considering the possibility to purchase some USRP boards. My objective is
to work with open source code of LTE. I've seen the OpenLTE project
(http://openlte.sourceforge.net/, http://sourceforge.net/projects/openlte/)
which looks pretty nice. It seems that it works with USRP B2X0 (Bus Series).
Do you know if it is compatible with USRP networked series (USRP N200/N210)?

Do you know any other project that is developing LTE using gnu-radio/USRP?

Thanks in advance for your help,
Regards,
Baldo






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

Re: [Discuss-gnuradio] LTE and USRP

[Coll Perales, Baldomero]

Thanks Marcus for your fast response. I’ll do it :).

I'm adding this question again (sorry): Do you know any other project that is 
developing LTE using gnu-radio/USRP?

Regards,
Baldo

De: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Enviado el: jueves, 15 de mayo de 2014 11:20
Para: Coll Perales, Baldomero
Asunto: Re: [Discuss-gnuradio] LTE and USRP

Hello Baldo,
UHD makes device access absolutely transparent -- so if you can use one USRP 
for a purpose, you can also use another one, if it meets the specs. 
As far as I can see, you can do downlink captures even with low-end non-UHD 
devices like the rtl-sdr dongles, so this should be a breeze. From a spec point 
of view, N200 is mainly inferior to B200 by means of maximum achievable 
sampling rate, so as long as your f_sample stays low enough, everything doable 
with an B200 should be doable with an N200, too. 
However, since openLTE is but one of many applications of the USRP device 
class, I think the right way to deal with that is writing an emai to the 
openLTE mailing list :)

Greetings,
Marcus

On Thu, May 15, 2014 at 11:13 AM, Coll Perales, Baldomero  wrote:
Hello,

I considering the possibility to purchase some USRP boards. My objective is
to work with open source code of LTE. I've seen the OpenLTE project
(http://openlte.sourceforge.net/, http://sourceforge.net/projects/openlte/)
which looks pretty nice. It seems that it works with USRP B2X0 (Bus Series).
Do you know if it is compatible with USRP networked series (USRP N200/N210)?

Do you know any other project that is developing LTE using gnu-radio/USRP?

Thanks in advance for your help,
Regards,
Baldo






___
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] B200 clock calibration

[Robert Light]

Hi, In case we use on-board oscillator , how is ADF4001 configured? Does CP 
(pin20) output affect the VCXO_Tune ? Is it possible to control this chip 
directly from the command line? 

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

Re: [Discuss-gnuradio] low frequency in GRC

[Mike Jameson]

If you attach your GRC flowgraph I'll take a look at it for you.

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com


On Thu, May 15, 2014 at 10:06 AM, jason sam  wrote:

> I am using GNU Radio Companion 3.7.3...when i set the frequency of my
> signal source to low values(in Hz or kHz),i get no signal on my scope or
> fft sink??
>
> ___
> 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] How to change a flowgraph in c++ dynamically

[Mostafa Alizadeh]

Hi Marcus,

Thank you,



On Thu, May 15, 2014 at 11:58 AM, Marcus Müller wrote:

> Hi Mostafa,
> I mean the run option "run to completion" in the GRC. GRC is like LEGO for
> communication engineers, if you play around with it, you'll soon be having
> fun and have an easier time understanding hints like this ;)
> See http://imgur.com/YPUvyzm
>
> Greetings,
> Marcus
>
>
>
>
> On Thu, May 15, 2014 at 8:11 AM, Mostafa Alizadeh 
> wrote:
>
>> Hi Marcus,
>>
>> what do you mean by *"run to completion" *?
>>
>> best,
>> Mostafa
>>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] LTE and USRP

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Baldo,

there is also gr-lte [1] as another alternative for an LTE receiver in
this case.

happy hacking
Johannes

[1] https://github.com/kit-cel/gr-lte

On 15.05.2014 11:13, Coll Perales, Baldomero wrote:
> Hello,
> 
> I considering the possibility to purchase some USRP boards. My
> objective is to work with open source code of LTE. I've seen the
> OpenLTE project (http://openlte.sourceforge.net/,
> http://sourceforge.net/projects/openlte/) which looks pretty nice.
> It seems that it works with USRP B2X0 (Bus Series). Do you know if
> it is compatible with USRP networked series (USRP N200/N210)?
> 
> Do you know any other project that is developing LTE using
> gnu-radio/USRP?
> 
> Thanks in advance for your help, Regards, Baldo
> 
> 
> 
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTdK2wAAoJEO7fmkDsqywMX1EP/27SHUvDEJZ2nc24kmw/dbgz
18zHmilolB1mCqnyfxo1CZ9yUFrCNEZNa9m4+AtzNIcef2e1WKzKaAX3qxCbzNg6
0uq8ksCr6X6CBsYQwSU2goT0utBocnzTBKkCsLfrhAJ4KmiPIsDa8ECo/fGsNQs3
IjdeakcprGOhWDl4g7krE0U860CZ85cGrI4W+23oXQ0M2/ZGjSyHeTDZtz1TyuWI
ki9UhlHMM+dDxN1DvDpfmQVhEwEQ13NPlX5e0ZIOzyiORVn80sMJ6/hO3nM92noY
BYxGNC7c80gjzEr0QULjPo9mduLbEBgsOx+zxqH9fg6SsGjMYJivyG4tErNnGqdX
efMU+CcW7h8NnsLFWXzms6es0jUmR9EUbZtLXAE7aRRI2fXZjf/EHKg8vd/AVwX2
a6OwXInCiLafhDB2aSVQHll0WWqfZ1tQDelTkMzN+A6RuREVGAfk6CO1M826SIRE
GiNtO6+nDKfUzOVmAetlSbsm1k7j0JVYeyylVEX7Uu9WdH71OFcYWOqo19yDfMHK
Aoan+2Du2zf0qiGIrkeb1AGvYRiao0Xl02Qy/kfYyg388OyoEA9r17FNCbbbay7j
5jDLP/0MfhAEMxdjJfoc1q6wRonTKw3/g01+PyrNDUkCsIz07I8AV/W7linI9I+x
wFOrZvYAiatGjbm5ElRr
=4D5M
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] LTE and USRP

[Martin Braun]

On 15.05.2014 11:35, Coll Perales, Baldomero wrote:

Thanks Marcus for your fast response. I’ll do it :).

I'm adding this question again (sorry): Do you know any other project
that is developing LTE using gnu-radio/USRP?


AFAIK, Johannes' project is the only one that uses GNU Radio, but 
there's other stand-alone LTE projects, such as OpenAirInterface
(http://www.openairinterface.org/) and libLTE 
(https://github.com/ismagom/liblte).


Using these is considered advanced usage, though -- I assume you know 
what you're doing, but just in case.


Martin

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

Re: [Discuss-gnuradio] Root rasied cosine parameters issue

[Tom Rondeau]

On Thu, May 15, 2014 at 7:55 AM, Irfan Ullah  wrote:

> Hi all,
> I have problem with pulse shaping RRC filter parameters when I set the
> parameters as
>
> interpolation=4Gain=nfiltssample rate=1   symbol rate=1  Alpha=0.5
> Num Taps=11*sps*nfilts
>
> (nfilts = 32,  sps=4)
>
> but my output constellation have much ISI please any one tell me the
> reason. check the parameters uf there is any problem then inform me.
>  my flowgraph is attached with this mail
>

Irfan,

You seem to have confused the RRC taps in a normal FIR filter and the
polyphase filterbank resampler implementation that we've used in our PSK
mod/demod blocks. When just using the RRC filter as a filter, like the Root
Raised Cosine Block in your example, you want to define it like you
normally would:

interpolation: 4
gain: 4 (to account for the loss when interpolating)
sample rate: samples_per_symbol
symbol rate: 1
alpha: (whatever between 0 and 1; generally <= 0.5)
num taps: ~45

Your use of nfilts in your email suggests you've pulled those ideas out of
using the PFB resampler. That resampler block takes in a large prototype
filter, which we define based on the number of filters in the PFB
filterbank (32 is default and usually enough). Using this filterbank allows
us to set an arbitrary real number of samples per symbol. Using just the
interpolating FIR filter means we can only use integer values for this.

Also, remember that using an RRC filter /will/ result in ISI. You have to
use a secondary RRC filter to remove the ISI. In another posting of yours,
I also saw that you used both an RRC decimating filter and the PFB clock
sync, which implements this for us. You don't need both. Read the clock
sync documentation closely:

http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1pfb__clock__sync__ccf.html

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

Re: [Discuss-gnuradio] OFDM cyclic prefixer

[Yuri P.M]

Thank you very much, for your help Mr. Economos,

For sure I will take a look at this project,

Yuri.

2014-05-14 21:12 GMT-03:00 Ron Economos :

>  If you haven't already, you may want to take a look
> at this GnuRadio DVB-T implementation.
>
> https://github.com/BogdanDIA/gr-dvbt
>
> Ron
>
>
> On 5/14/2014 1:50 PM, Yuri P.M wrote:
>
>  Hi,
>
>  Thanks Mr. Economos and Mr. Braun,
>
>  I left this parameter in blank (I guess this is the same as an empty
> string), it seems that it is working now.
>
>  Actually I am trying to modulate ISDB-T data stream. I am working with
> vectors, instead of data stream.
>
>  Thanks again.
>
>
> 2014-05-14 5:28 GMT-03:00 Martin Braun :
>
>> On 14.05.2014 04:36, Ron Economos wrote:
>>
>>> If you're sending packets, then Length Tag Key should be
>>> set to the packet length you're using. If you're sending
>>> a stream (like DVB-T), then this field is not used (and
>>> left blank).
>>>
>>
>>  It needs an empty string, in this case.
>>
>>
>>  The OFDM cyclic prefixer is used after the (reverse)
>>> FFT block. The FFT Length in the OFDM Cyclic Prefixer
>>> block should match the FFT Size in the FFT block.
>>>
>>
>>  That's right. The block doesn't check if the input is actually OFDM.
>>
>> Martin
>>
>>>
>>> Ron
>>>
>>> On 5/13/2014 6:06 PM, Yuri P.M wrote:
>>>
 Hello,

 My name is Yuri.
 ​ I very new to GNU Radio, and I'm using GRC 3.7.1.​


 I am doing a research, and I need to modulate specific signal in OFDM.
 I would like to insert cyclic prefix (or guard interval in my project,
 the same thing with a different name).

 I looked at the examples
 ​under gr-digital
 ​/examples/ofdm, and I've also read some papers about OFDM technics.

 My doubt is: what is the parameter "Length Tag Key"? I've seen it
 working in the examples located in the folder above, I've tried to do
 the same in my project, but it states a message that this parameter is
 missing.

 By chance, does this cyclic prefixer block only works with other
 blocks of the same category? I mean, do I need to use OFDM carrier
 allocator before it, or something like that?

 Thank you for your attention,

 Yuri.

>>>
>>>
> ___
> 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] LTE and USRP

[Paul Sutton]

Hi Baldo,

There is also LibLTE - https://github.com/libLTE/libLTE
It's a modular LTE library with minimal external dependencies. It's
compatible with UHD devices and is LGPLv3.
It's under development but currently provides eNodeB and UE
implementations for most of the downlink. Among the example programs are
downlink PSS and MIB scanners as well as an initial UE implementation
which receives and demodulates the downlink broadcast channel (PBCH).
The UE example has been tested with both test and live commercial eNodeBs.
As it's a modular library, it doesn't depend on a specific framework
like gnuradio but can be used easily in most SDR frameworks. We're
currently porting the UE example to gnuradio and hope to make it
available soon.

Regards,
Paul

On 15/05/14 10:35, Coll Perales, Baldomero wrote:
> Thanks Marcus for your fast response. I’ll do it :).
>
> I'm adding this question again (sorry): Do you know any other project that is 
> developing LTE using gnu-radio/USRP?
>
> Regards,
> Baldo
>
> De: Marcus Müller [mailto:marcus.muel...@ettus.com] 
> Enviado el: jueves, 15 de mayo de 2014 11:20
> Para: Coll Perales, Baldomero
> Asunto: Re: [Discuss-gnuradio] LTE and USRP
>
> Hello Baldo,
> UHD makes device access absolutely transparent -- so if you can use one USRP 
> for a purpose, you can also use another one, if it meets the specs. 
> As far as I can see, you can do downlink captures even with low-end non-UHD 
> devices like the rtl-sdr dongles, so this should be a breeze. From a spec 
> point of view, N200 is mainly inferior to B200 by means of maximum achievable 
> sampling rate, so as long as your f_sample stays low enough, everything 
> doable with an B200 should be doable with an N200, too. 
> However, since openLTE is but one of many applications of the USRP device 
> class, I think the right way to deal with that is writing an emai to the 
> openLTE mailing list :)
>
> Greetings,
> Marcus
>
> On Thu, May 15, 2014 at 11:13 AM, Coll Perales, Baldomero  
> wrote:
> Hello,
>
> I considering the possibility to purchase some USRP boards. My objective is
> to work with open source code of LTE. I've seen the OpenLTE project
> (http://openlte.sourceforge.net/, http://sourceforge.net/projects/openlte/)
> which looks pretty nice. It seems that it works with USRP B2X0 (Bus Series).
> Do you know if it is compatible with USRP networked series (USRP N200/N210)?
>
> Do you know any other project that is developing LTE using gnu-radio/USRP?
>
> Thanks in advance for your help,
> Regards,
> Baldo
>
>
>
>
>
>
> ___
> 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
>
> -- 
> 
> Paul Sutton Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-87-9813473 | p...@softwareradiosystems.com
>
> PGP Key ID: 3B4A5292
> Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
>  

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

Re: [Discuss-gnuradio] grc-mimo setup

[Mike Jameson]

Your device hint in the 'Device Addr' section of the 'UHD Source' block
should be "addr=192.168.10.2" and in a separate 'UHD source' block the
"Device Addr" should be "addr=192.168.10.3"

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com


On Thu, May 15, 2014 at 1:39 PM, xianda  wrote:

>  Hello all:
>Environment: 2 usrp N210,mimo cable(they connect with each
> other and share the Ethernet)
>
>And i use the gnuradio companion to set up a very simple
> example.And the example is attached on the email.And I run this simple
> example,an error comes:
>   RuntimeError: ValueError: Could not resolve device hint ""
> to a single device.
>
>   And ping 192.168.10.2 and ping 192.168.10.3,it's all ok.
>   Can someone help me to solve it?Thank you very much.
> Best regards
>
>
>
> ___
> 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] grc-mimo setup

[xianda]

Hi Mike
Thank you for your reply.
Now I change the addr but a new error comes:
thread[thread-per-block[1]: ]: LookupError: 
KeyError: Cannot find an item size:

thread[thread-per-block[2]: ]: LookupError: 
KeyError: Cannot find an item size:

Can you help me?Thank you.

Best regrads

At 2014-05-15 20:48:44,"Mike Jameson"  wrote:

Your device hint in the 'Device Addr' section of the 'UHD Source' block should 
be "addr=192.168.10.2" and in a separate 'UHD source' block the "Device Addr" 
should be "addr=192.168.10.3"


Mike


--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com



On Thu, May 15, 2014 at 1:39 PM, xianda  wrote:

 Hello all:
   Environment: 2 usrp N210,mimo cable(they connect with each other 
and share the Ethernet)
  
   And i use the gnuradio companion to set up a very simple 
example.And the example is attached on the email.And I run this simple 
example,an error comes:
  RuntimeError: ValueError: Could not resolve device hint "" to a 
single device.
 
  And ping 192.168.10.2 and ping 192.168.10.3,it's all ok.
  Can someone help me to solve it?Thank you very much.
Best regards




___
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] LTE and USRP

[Coll Perales, Baldomero]

Thanks Paul,

LibLTE looks like very promising. I'll follow the advances. By the way, do you 
know if it will be compatible with USRP2 or only with new ones (N Series - 
UHD-based)?

Thanks,
Baldo

-Mensaje original-
De: Paul Sutton [mailto:p...@softwareradiosystems.com] 
Enviado el: jueves, 15 de mayo de 2014 14:31
Para: Coll Perales, Baldomero
CC: discuss-gnuradio@gnu.org
Asunto: Re: [Discuss-gnuradio] LTE and USRP

Hi Baldo,

There is also LibLTE - https://github.com/libLTE/libLTE It's a modular LTE 
library with minimal external dependencies. It's compatible with UHD devices 
and is LGPLv3.
It's under development but currently provides eNodeB and UE implementations for 
most of the downlink. Among the example programs are downlink PSS and MIB 
scanners as well as an initial UE implementation which receives and demodulates 
the downlink broadcast channel (PBCH).
The UE example has been tested with both test and live commercial eNodeBs.
As it's a modular library, it doesn't depend on a specific framework like 
gnuradio but can be used easily in most SDR frameworks. We're currently porting 
the UE example to gnuradio and hope to make it available soon.

Regards,
Paul

On 15/05/14 10:35, Coll Perales, Baldomero wrote:
> Thanks Marcus for your fast response. I’ll do it :).
>
> I'm adding this question again (sorry): Do you know any other project that is 
> developing LTE using gnu-radio/USRP?
>
> Regards,
> Baldo
>
> De: Marcus Müller [mailto:marcus.muel...@ettus.com] Enviado el: 
> jueves, 15 de mayo de 2014 11:20
> Para: Coll Perales, Baldomero
> Asunto: Re: [Discuss-gnuradio] LTE and USRP
>
> Hello Baldo,
> UHD makes device access absolutely transparent -- so if you can use one USRP 
> for a purpose, you can also use another one, if it meets the specs. 
> As far as I can see, you can do downlink captures even with low-end non-UHD 
> devices like the rtl-sdr dongles, so this should be a breeze. From a spec 
> point of view, N200 is mainly inferior to B200 by means of maximum achievable 
> sampling rate, so as long as your f_sample stays low enough, everything 
> doable with an B200 should be doable with an N200, too. 
> However, since openLTE is but one of many applications of the USRP 
> device class, I think the right way to deal with that is writing an 
> emai to the openLTE mailing list :)
>
> Greetings,
> Marcus
>
> On Thu, May 15, 2014 at 11:13 AM, Coll Perales, Baldomero  
> wrote:
> Hello,
>
> I considering the possibility to purchase some USRP boards. My 
> objective is to work with open source code of LTE. I've seen the 
> OpenLTE project (http://openlte.sourceforge.net/, 
> http://sourceforge.net/projects/openlte/)
> which looks pretty nice. It seems that it works with USRP B2X0 (Bus Series).
> Do you know if it is compatible with USRP networked series (USRP N200/N210)?
>
> Do you know any other project that is developing LTE using gnu-radio/USRP?
>
> Thanks in advance for your help,
> Regards,
> Baldo
>
>
>
>
>
>
> ___
> 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
>
> --
> 
> Paul Sutton Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-87-9813473 | p...@softwareradiosystems.com
>
> PGP Key ID: 3B4A5292
> Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292 
>  


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

Re: [Discuss-gnuradio] LTE and USRP

[Paul Sutton]

USRP2 is also UHD-based and it is compatible with LibLTE.

On 15/05/14 13:56, Coll Perales, Baldomero wrote:
> Thanks Paul,
>
> LibLTE looks like very promising. I'll follow the advances. By the way, do 
> you know if it will be compatible with USRP2 or only with new ones (N Series 
> - UHD-based)?
>
> Thanks,
> Baldo
>
> -Mensaje original-
> De: Paul Sutton [mailto:p...@softwareradiosystems.com] 
> Enviado el: jueves, 15 de mayo de 2014 14:31
> Para: Coll Perales, Baldomero
> CC: discuss-gnuradio@gnu.org
> Asunto: Re: [Discuss-gnuradio] LTE and USRP
>
> Hi Baldo,
>
> There is also LibLTE - https://github.com/libLTE/libLTE It's a modular LTE 
> library with minimal external dependencies. It's compatible with UHD devices 
> and is LGPLv3.
> It's under development but currently provides eNodeB and UE implementations 
> for most of the downlink. Among the example programs are downlink PSS and MIB 
> scanners as well as an initial UE implementation which receives and 
> demodulates the downlink broadcast channel (PBCH).
> The UE example has been tested with both test and live commercial eNodeBs.
> As it's a modular library, it doesn't depend on a specific framework like 
> gnuradio but can be used easily in most SDR frameworks. We're currently 
> porting the UE example to gnuradio and hope to make it available soon.
>
> Regards,
> Paul
>
> On 15/05/14 10:35, Coll Perales, Baldomero wrote:
>> Thanks Marcus for your fast response. I’ll do it :).
>>
>> I'm adding this question again (sorry): Do you know any other project that 
>> is developing LTE using gnu-radio/USRP?
>>
>> Regards,
>> Baldo
>>
>> De: Marcus Müller [mailto:marcus.muel...@ettus.com] Enviado el: 
>> jueves, 15 de mayo de 2014 11:20
>> Para: Coll Perales, Baldomero
>> Asunto: Re: [Discuss-gnuradio] LTE and USRP
>>
>> Hello Baldo,
>> UHD makes device access absolutely transparent -- so if you can use one USRP 
>> for a purpose, you can also use another one, if it meets the specs. 
>> As far as I can see, you can do downlink captures even with low-end non-UHD 
>> devices like the rtl-sdr dongles, so this should be a breeze. From a spec 
>> point of view, N200 is mainly inferior to B200 by means of maximum 
>> achievable sampling rate, so as long as your f_sample stays low enough, 
>> everything doable with an B200 should be doable with an N200, too. 
>> However, since openLTE is but one of many applications of the USRP 
>> device class, I think the right way to deal with that is writing an 
>> emai to the openLTE mailing list :)
>>
>> Greetings,
>> Marcus
>>
>> On Thu, May 15, 2014 at 11:13 AM, Coll Perales, Baldomero  
>> wrote:
>> Hello,
>>
>> I considering the possibility to purchase some USRP boards. My 
>> objective is to work with open source code of LTE. I've seen the 
>> OpenLTE project (http://openlte.sourceforge.net/, 
>> http://sourceforge.net/projects/openlte/)
>> which looks pretty nice. It seems that it works with USRP B2X0 (Bus Series).
>> Do you know if it is compatible with USRP networked series (USRP N200/N210)?
>>
>> Do you know any other project that is developing LTE using gnu-radio/USRP?
>>
>> Thanks in advance for your help,
>> Regards,
>> Baldo
>>
>>
>>
>>
>>
>>
>> ___
>> 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
>>
>> --
>> 
>> Paul Sutton Ph.D.
>>
>> Software Radio Systems (SRS)
>> http://www.softwareradiosystems.com
>>
>> +353-87-9813473 | p...@softwareradiosystems.com
>>
>> PGP Key ID: 3B4A5292
>> Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292 
>>  

-- 

Paul Sutton Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

+353-87-9813473 | p...@softwareradiosystems.com

PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
 


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

Re: [Discuss-gnuradio] grc-mimo setup

[Mike Jameson]

A sample rate of 32e3 is very low.  I suggest trying with a minimum sample
rate of 100e6/128 (always divide the N210's master clock rate by an even
number to use as a sample rate) which is 781250.

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com


On Thu, May 15, 2014 at 1:55 PM, xianda  wrote:

> Hi Mike
> Thank you for your reply.
> Now I change the addr but a new error comes:
> thread[thread-per-block[1]: ]: LookupError:
> KeyError: Cannot find an item size:
>
> thread[thread-per-block[2]: ]: LookupError:
> KeyError: Cannot find an item size:
>
> Can you help me?Thank you.
>
> Best regrads
>
>
> At 2014-05-15 20:48:44,"Mike Jameson"  wrote:
>
> Your device hint in the 'Device Addr' section of the 'UHD Source' block
> should be "addr=192.168.10.2" and in a separate 'UHD source' block the
> "Device Addr" should be "addr=192.168.10.3"
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: http://ettus.com
>
>
> On Thu, May 15, 2014 at 1:39 PM, xianda  wrote:
>
>>  Hello all:
>>Environment: 2 usrp N210,mimo cable(they connect with each
>> other and share the Ethernet)
>>
>>And i use the gnuradio companion to set up a very simple
>> example.And the example is attached on the email.And I run this simple
>> example,an error comes:
>>   RuntimeError: ValueError: Could not resolve device hint ""
>> to a single device.
>>
>>   And ping 192.168.10.2 and ping 192.168.10.3,it's all ok.
>>   Can someone help me to solve it?Thank you very much.
>> Best regards
>>
>>
>>
>> ___
>> 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] grc-mimo setup

[Martin Braun]

This was a UHD bug we fixed a couple of weeks back. If you're using 
git/master, you can just git pull, rebuild UHD and it will work.


Otherwise, you can set otw_format=sc16 in the streamer args and it will 
solve the problem as well.


Cheers,
M


On 15.05.2014 14:55, xianda wrote:

Hi Mike
Thank you for your reply.
Now I change the addr but a new error comes:
thread[thread-per-block[1]: ]: LookupError:
KeyError: Cannot find an item size:

thread[thread-per-block[2]: ]:
LookupError: KeyError: Cannot find an item size:

Can you help me?Thank you.

Best regrads

At 2014-05-15 20:48:44,"Mike Jameson"  wrote:

Your device hint in the 'Device Addr' section of the 'UHD Source'
block should be "addr=192.168.10.2" and in a separate 'UHD source'
block the "Device Addr" should be "addr=192.168.10.3"

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com 
Web: http://ettus.com


On Thu, May 15, 2014 at 1:39 PM, xianda mailto:wangxianda920...@163.com>> wrote:

  Hello all:
Environment: 2 usrp N210,mimo cable(they connect
with each other and share the Ethernet)

And i use the gnuradio companion to set up a
very simple example.And the example is attached on the email.And
I run this simple example,an error comes:
   RuntimeError: ValueError: Could not resolve
device hint "" to a single device.

   And ping 192.168.10.2 and ping 192.168.10.3,it's
all ok.
   Can someone help me to solve it?Thank you very much.
Best regards



___
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] grc-mimo setup

[xianda]

Hello 
  Thank you so much.
  1.And i set the wire format as Complex int16.And it run.Thank you 
again.I'm so happy.This device bring us so many happy.
  But what do you mean "git pull"?Sorry for my poor english.
  Can you tell me what command i should type into the shell?And then 
rebuild UHD.
  2.Another question.If i write the c++ documend in the uhd,and one 
document is using for transmit and the other one is using for receive.And i 
puzzled.In the gnuradio companion mode we can put the source and sink into the 
same document.But now two c++ document and i want to run them at the same time 
as in the gnuradio mode.How can i do it?
  Thank you again for your quick reply.
Best regards
At 2014-05-15 21:05:31,"Martin Braun"  wrote:
>This was a UHD bug we fixed a couple of weeks back. If you're using 
>git/master, you can just git pull, rebuild UHD and it will work.
>
>Otherwise, you can set otw_format=sc16 in the streamer args and it will 
>solve the problem as well.
>
>Cheers,
>M
>
>
>On 15.05.2014 14:55, xianda wrote:
>> Hi Mike
>> Thank you for your reply.
>> Now I change the addr but a new error comes:
>> thread[thread-per-block[1]: ]: LookupError:
>> KeyError: Cannot find an item size:
>>
>> thread[thread-per-block[2]: ]:
>> LookupError: KeyError: Cannot find an item size:
>>
>> Can you help me?Thank you.
>>
>> Best regrads
>>
>> At 2014-05-15 20:48:44,"Mike Jameson"  wrote:
>>
>> Your device hint in the 'Device Addr' section of the 'UHD Source'
>> block should be "addr=192.168.10.2" and in a separate 'UHD source'
>> block the "Device Addr" should be "addr=192.168.10.3"
>>
>> Mike
>>
>> --
>> Mike Jameson M0MIK BSc MIET
>> Ettus Research Technical Support
>> Email: supp...@ettus.com 
>> Web: http://ettus.com
>>
>>
>> On Thu, May 15, 2014 at 1:39 PM, xianda > > wrote:
>>
>>   Hello all:
>> Environment: 2 usrp N210,mimo cable(they connect
>> with each other and share the Ethernet)
>>
>> And i use the gnuradio companion to set up a
>> very simple example.And the example is attached on the email.And
>> I run this simple example,an error comes:
>>RuntimeError: ValueError: Could not resolve
>> device hint "" to a single device.
>>
>>And ping 192.168.10.2 and ping 192.168.10.3,it's
>> all ok.
>>Can someone help me to solve it?Thank you very much.
>> Best regards
>>
>>
>>
>> ___
>> 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

Re: [Discuss-gnuradio] grc-mimo setup

[Mike Jameson]

If you built GNU Radio and UHD using pybombs then you can just run:

./pybombs update gnuradio

Alternatively, if you build manually you can go into the 'uhd/host/build'
directory and run:

git pull
cmake ../
make
sudo make install

Mike

--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com


On Thu, May 15, 2014 at 2:29 PM, xianda  wrote:

> Hello
>   Thank you so much.
>   1.And i set the wire format as Complex int16.And it run.Thank
> you again.I'm so happy.This device bring us so many happy.
>   But what do you mean "git pull"?Sorry for my poor english.
>   Can you tell me what command i should type into the shell?And
> then rebuild UHD.
>   2.Another question.If i write the c++ documend in the uhd,and
> one document is using for transmit and the other one is using for
> receive.And i puzzled.In the gnuradio companion mode we can put the source
> and sink into the same document.But now two c++ document and i want to run
> them at the same time as in the gnuradio mode.How can i do it?
>   Thank you again for your quick reply.
> Best regards
> At 2014-05-15 21:05:31,"Martin Braun"  wrote:
> >This was a UHD bug we fixed a couple of weeks back. If you're using
> >git/master, you can just git pull, rebuild UHD and it will work.
> >
> >Otherwise, you can set otw_format=sc16 in the streamer args and it will
> >solve the problem as well.
> >
> >Cheers,
> >M
> >
> >
> >On 15.05.2014 14:55, xianda wrote:
> >> Hi Mike
> >> Thank you for your reply.
> >> Now I change the addr but a new error comes:
> >> thread[thread-per-block[1]: ]: LookupError:
> >> KeyError: Cannot find an item size:
> >>
> >> thread[thread-per-block[2]: ]:
> >> LookupError: KeyError: Cannot find an item size:
> >>
> >> Can you help me?Thank you.
> >>
> >> Best regrads
> >>
> >> At 2014-05-15 20:48:44,"Mike Jameson"  wrote:
> >>
> >> Your device hint in the 'Device Addr' section of the 'UHD Source'
> >> block should be "addr=192.168.10.2" and in a separate 'UHD source'
> >> block the "Device Addr" should be "addr=192.168.10.3"
> >>
> >> Mike
> >>
> >> --
> >> Mike Jameson M0MIK BSc MIET
> >> Ettus Research Technical Support
> >> Email: supp...@ettus.com 
> >> Web: http://ettus.com
> >>
> >>
> >> On Thu, May 15, 2014 at 1:39 PM, xianda  >> > wrote:
> >>
> >>   Hello all:
> >> Environment: 2 usrp N210,mimo cable(they connect
> >> with each other and share the Ethernet)
> >>
> >> And i use the gnuradio companion to set up a
> >> very simple example.And the example is attached on the email.And
> >> I run this simple example,an error comes:
> >>RuntimeError: ValueError: Could not resolve
> >> device hint "" to a single device.
> >>
> >>And ping 192.168.10.2 and ping 192.168.10.3,it's
> >> all ok.
> >>Can someone help me to solve it?Thank you very
> much.
> >> Best regards
> >>
> >>
> >>
> >> ___
> >> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] grc-mimo setup

[xianda]

Hi Mike
Thank you for your patience.Thanks again.

At 2014-05-15 22:01:00,"Mike Jameson"  wrote:

If you built GNU Radio and UHD using pybombs then you can just run:


./pybombs update gnuradio


Alternatively, if you build manually you can go into the 'uhd/host/build' 
directory and run:


git pull

cmake ../

make

sudo make install



Mike



--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com



On Thu, May 15, 2014 at 2:29 PM, xianda  wrote:
Hello
  Thank you so much.
  1.And i set the wire format as Complex int16.And it run.Thank you 
again.I'm so happy.This device bring us so many happy.
  But what do you mean "git pull"?Sorry for my poor english.
  Can you tell me what command i should type into the shell?And then 
rebuild UHD.
  2.Another question.If i write the c++ documend in the uhd,and one 
document is using for transmit and the other one is using for receive.And i 
puzzled.In the gnuradio companion mode we can put the source and sink into the 
same document.But now two c++ document and i want to run them at the same time 
as in the gnuradio mode.How can i do it?
  Thank you again for your quick reply.
Best regards

At 2014-05-15 21:05:31,"Martin Braun"  wrote:
>This was a UHD bug we fixed a couple of weeks back. If you're using
>git/master, you can just git pull, rebuild UHD and it will work.
>
>Otherwise, you can set otw_format=sc16 in the streamer args and it will
>solve the problem as well.
>
>Cheers,
>M
>
>
>On 15.05.2014 14:55, xianda wrote:
>> Hi Mike
>> Thank you for your reply.
>> Now I change the addr but a new error comes:
>> thread[thread-per-block[1]: ]: LookupError:
>> KeyError: Cannot find an item size:
>>
>> thread[thread-per-block[2]: ]:
>> LookupError: KeyError: Cannot find an item size:
>>
>> Can you help me?Thank you.
>>
>> Best regrads
>>
>> At 2014-05-15 20:48:44,"Mike Jameson"  wrote:
>>
>> Your device hint in the 'Device Addr' section of the 'UHD Source'
>> block should be "addr=192.168.10.2" and in a separate 'UHD source'
>> block the "Device Addr" should be "addr=192.168.10.3"
>>
>> Mike
>>
>> --
>> Mike Jameson M0MIK BSc MIET
>> Ettus Research Technical Support
>> Email: supp...@ettus.com 
>> Web: http://ettus.com
>>
>>
>> On Thu, May 15, 2014 at 1:39 PM, xianda > > wrote:
>>
>>   Hello all:
>> Environment: 2 usrp N210,mimo cable(they connect
>> with each other and share the Ethernet)
>>
>> And i use the gnuradio companion to set up a
>> very simple example.And the example is attached on the email.And
>> I run this simple example,an error comes:
>>RuntimeError: ValueError: Could not resolve
>> device hint "" to a single device.
>>
>>And ping 192.168.10.2 and ping 192.168.10.3,it's
>> all ok.
>>Can someone help me to solve it?Thank you very much.
>> Best regards
>>
>>
>>
>> ___
>> 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


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

Re: [Discuss-gnuradio] low frequency in GRC

[jason sam]

Actually i think the problem is that i have very low sample rate according
to the 1024 FFT..


On Thu, May 15, 2014 at 7:38 PM, jason sam  wrote:

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

Re: [Discuss-gnuradio] B200 clock calibration

[Nick Foster]

The ADF4001's output charge pump is tristated when not locking to an
external reference, and a resistor divider holds the VCTCXO's tuning input
at 1/2 Vcc. The B200 hardware can use the AD9361's low-speed DAC to drive
the VCTCXO's tuning input via AUXDAC1 if R118 is populated; however, this
functionality is not supported by the B200 UHD driver.

--n


On Thu, May 15, 2014 at 2:48 AM, Robert Light  wrote:

> Hi, In case we use on-board oscillator , how is ADF4001 configured? Does
> CP (pin20) output affect the VCXO_Tune ? Is it possible to control this
> chip directly from the command line?
>
> ___
> 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] B200 clock calibration

[Marcus Leech]

The only way to really make this work "properly" is to go closed-loop.  At that point, you might as well use an external reference.  I've pointed out before
  that 10MHz OCXOs are available cheaply, and generally achieve 100PPB *at worst*, even the "scrap pulls" that are cheaply available on eBay usually
  acheive better than 50PPB.  $20.00 and a bit of soldering, and you have a pretty-darned good reference that you can even share among multiple units,
  with a bit of skill.
 
This is perhaps better than voiding warantees on expensive hardware
 
 

on May 15, 2014, Nick Foster  wrote:

The ADF4001's output charge pump is tristated when not locking to an external reference, and a resistor divider holds the VCTCXO's tuning input at 1/2 Vcc. The B200 hardware can use the AD9361's low-speed DAC to drive the VCTCXO's tuning input via AUXDAC1 if R118 is populated; however, this functionality is not supported by the B200 UHD driver.
 
--n


On Thu, May 15, 2014 at 2:48 AM, Robert Light  wrote:
Hi, In case we use on-board oscillator , how is ADF4001 configured? Does CP (pin20) output affect the VCXO_Tune ? Is it possible to control this chip directly from the command line?

 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://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] Dev Call May Live Broadcast

[Martin Braun]

Follow the dev call on:

http://youtu.be/5EZkxdO1oYo

Cheers,
M

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

[Discuss-gnuradio] Developer call live now!

[Philip Balister]

http://youtu.be/5EZkxdO1oYo

Philip

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

Re: [Discuss-gnuradio] low frequency in GRC

[madengr]

Regarding the low sample rate, I have had this issue too when decimating to
narrow bandwidths.  I assume sample rate is an integer for most blocks
therefore one can't go below 1 samp/sec?

Lou
KD4HSO




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/low-frequency-in-GRC-tp48237p48266.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] low frequency in GRC

[Marcus Leech]

Gnu Radio is a streaming architecture. Sample-rate is actually almost-entirely meaningless within the flowgraph, and only really
  has meaning "at the edges" when interfacing to the real world.  The only exception is the throttle block, and even it doesn't
  produce *precise* sample-rates.
 
For things like FFT blocks, the sample-rate is just used to calculate internal decimation functions to deliver the requested display update rate.
 
The other main issue is that Gnu Radio buffers qutie a bit.  So if your samples are dribbling into the flow-graph at very low rates, it takes a while for
  the buffers to fill to the point where downstream blocks get "woken up" by the scheduler to process the buffered samples.
 
 
 

on May 15, 2014, madengr  wrote:
Regarding the low sample rate, I have had this issue too when decimating tonarrow bandwidths. I assume sample rate is an integer for most blockstherefore one can't go below 1 samp/sec?LouKD4HSO--View this message in context: http://gnuradio.4.n7.nabble.com/low-frequency-in-GRC-tp48237p48266.htmlSent from the GnuRadio mailing list archive at Nabble.com.___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] MSF/DCF/RBU Time Station Receiver Implementation

[Iain Young, G7III]

Hi Everyone,

In recent days I had the idea to plug my LF preamp and antenna into my
192k Soundcard. Even with Nyquist being his usual pain, that still gives
me DC to 96kHz. Perfect for certain time stations :)

I lashed up a linear receiver, put it on 59kHz, and what do I hear ?
"pip pip pip" from MSF. Switch to 76.5kHz, and hear DCF's simpler 100ms 
and 200ms "pip pip pip". Thought I'd get adventurous and tried 66.666k,

and I hear pips again (not quite the same, more of this later)

I lashed up a quick Goertzel filter at 250Hz, and re-tuned so I was
250Hz off from MSF. Hacked up some code to actually decode the
output of GRC to the timecode bits for MSF. It decodes perfectly,
even without parity checking!

DCF, I haven't quite got around to that bit yet, but it was detecting
the 100mS and 200mS very well, despite the periodic (relatively) wide
band noise that was around last night.

In case anyone is interested, the flow graphs are located at
http://hal.g7iii.net/GRC/Radio_Clocks/

They are in .grc format, and .png Feel free to use them, however be
aware as well as device changes, you will probably have to fiddle with
the threshold and squelch levels, but they might be a useful starting
point for anyone wanting to do a WWV/WWVB/JJY/BPM decoder.


Now, RBU, There's a thing. It is a little more complex, as rather
than just a carrier, it uses two tones. Only each 100mS is divided,
and there are periods of time with an unmodulated carrier, and even
no carrier at all within each 100mS period.

The gory details are located at
http://en.wikipedia.org/wiki/RBU_%28radio_station%29

This is challenging. The best I have come up with is in the RBU
flowgraphs at the same URL using the CTCSS Squelch block (incl
with a Goertzel filter ahead of it), but I get missing 100mS "packets"
[for want of a better term], and even some times when it thinks both
the 100Hz and 312.5Hz tones are active at the same time! (This is most
likely one squelch not closing before the other opens)

Is this the approach other folks would take with trying to decode
RBU ? Or are there other approaches that might work better ? Suggestions
would be welcomed, and if anyone wants a recording of RBU to test
their own code with, just holler.


Iain

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

Re: [Discuss-gnuradio] MSF/DCF/RBU Time Station Receiver Implementation

[Marcus Leech]

I worked on a WWVB receiver a few years back.  Then realized that I'm in an apparent "null" in the WWVB transmit pattern.  Even
  my commercial WWVB clocks cannot receive it.  Sigh.
 
 
 

on May 15, 2014, Iain Young, G7III  wrote:
Hi Everyone,In recent days I had the idea to plug my LF preamp and antenna into my192k Soundcard. Even with Nyquist being his usual pain, that still givesme DC to 96kHz. Perfect for certain time stations :)I lashed up a linear receiver, put it on 59kHz, and what do I hear ?"pip pip pip" from MSF. Switch to 76.5kHz, and hear DCF's simpler 100ms and 200ms "pip pip pip". Thought I'd get adventurous and tried 66.666k,and I hear pips again (not quite the same, more of this later)I lashed up a quick Goertzel filter at 250Hz, and re-tuned so I was250Hz off from MSF. Hacked up some code to actually decode theoutput of GRC to the timecode bits for MSF. It decodes perfectly,even without parity checking!DCF, I haven't quite got around to that bit yet, but it was detectingthe 100mS and 200mS very well, despite the periodic (relatively) wideband noise that was around last night.In case anyone is interested, the flow graphs are located athttp://hal.g7iii.net/GRC/Radio_Clocks/They are in .grc format, and .png Feel free to use them, however beaware as well as device changes, you will probably have to fiddle withthe threshold and squelch levels, but they might be a useful startingpoint for anyone wanting to do a WWV/WWVB/JJY/BPM decoder.Now, RBU, There's a thing. It is a little more complex, as ratherthan just a carrier, it uses two tones. Only each 100mS is divided,and there are periods of time with an unmodulated carrier, and evenno carrier at all within each 100mS period.The gory details are located athttp://en.wikipedia.org/wiki/RBU_%28radio_station%29This is challenging. The best I have come up with is in the RBUflowgraphs at the same URL using the CTCSS Squelch block (inclwith a Goertzel filter ahead of it), but I get missing 100mS "packets"[for want of a better term], and even some times when it thinks boththe 100Hz and 312.5Hz tones are active at the same time! (This is mostlikely one squelch not closing before the other opens)Is this the approach other folks would take with trying to decodeRBU ? Or are there other approaches that might work better ? Suggestionswould be welcomed, and if anyone wants a recording of RBU to testtheir own code with, just holler.Iain___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

Re: [Discuss-gnuradio] MSF/DCF/RBU Time Station Receiver Implementation

[Iain Young, G7III]

On 15/05/14 20:30, Marcus Leech wrote:


I worked on a WWVB receiver a few years back.  Then realized that I'm in an
apparent "null" in the WWVB transmit pattern.  Even
my commercial WWVB clocks cannot receive it.  Sigh.


Ah, that's unfortunate, to say the least. And now they've gone and
complicated it even further with the Phase Shift Keying stuff.

I have a similar issue with BBC Radio 4 Longwave here, despite not
being particularly far from the transmitter, it is def weak with me.

Which reminds me. DCF, Radio 4, and TDF (France) also twiddle the phase
of the signal for a more accurate timecode. I have the details of that
twiddling, but am at a bit of a loss as to how I might use the PSK
blocks and friends within GRC to decode them.

(For me, it's moving from the deep end of the pool where I'm very happy
fiddling around, and the deep ocean, so if anyone has any suggestions
on where to start that would also be appreciated.)

My PSK knowledge is entirely from Amateur Radio, although I did manage 
to write a PSK receiver in GRC that would receive all the fldigi PSK

modes, but even that was converted from someone else's raw python
flowgraph doing the same thing!)


Iain

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

Re: [Discuss-gnuradio] MSF/DCF/RBU Time Station Receiver Implementation

[madengr]

Iain Young, G7III wrote
> I lashed up a quick Goertzel filter at 250Hz, and re-tuned so I was
> 250Hz off from MSF. Hacked up some code to actually decode the
> output of GRC to the timecode bits for MSF. It decodes perfectly,
> even without parity checking!

Thank you for the post.  I was experimenting with WWVB reception also and
will have to try this for NDB DX reception.  What advantage does the
Goertzel filter have as opposed to just using a narrow band FIR?  I see you
still have to specify the 250 Hz offset in the filter, so I assume it
doesn't help with detection if you drift off frequency.

Thanks,
Lou
KD4HSO





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/MSF-DCF-RBU-Time-Station-Receiver-Implementation-tp48268p48271.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] not responding B100

[Vincenzo Pellegrini]

Hi Tapiwa,

There should be object code for fixing the B100 USB interface in the UHD
tree under /host/build/utils.

cmake compiled it for you when you built the whole UHD.

The bin file to use is fx2_init_eeprom.
Use the --help option to get usage info.

You also need the suitable b100_boot.bin and b100_eeprom.bin
to be flashed into the B100.

I'm actually having those but I'm not sure whether or not they're
the good version for your board revison.
I'm actually haning no clue on the versioning of such files.
Seeking advice from other list members on this.

Best

Vincenzo
Il giorno 13/mag/2014 12:10, "Tapiwa Chiwewe"  ha
scritto:

> Hi Vince,
>
> I hope I find you well. I found your message online about a non-responsive
> B100. I seem to be having a problem similar to yours, may I ask if you ever
> found a solution to the 'bricked' B100?
>
> Kind regards
> Tapiwa
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Message Passing

[Activecat]

On Wed, May 14, 2014 at 10:25 PM, Tom Rondeau  wrote:

> On Wed, May 14, 2014 at 7:06 AM, Activecat  wrote:
>
>> On Wed, May 14, 2014 at 6:49 PM, Koslowski, Sebastian (CEL) <
>> sebastian.koslow...@kit.edu> wrote:
>>>
>>> I retried by putting the definition of  on top of
>>  in the xml file, it works.
>> It seems that the "sink" definition must be placed on top of "source" ..
>>
>> Problem solved, thank everyone !
>>
>
> Yes, this is the strictness of the XML DTD. Glad you got it working.
>  Tom
>

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

[Discuss-gnuradio] Ice-related Build Problem

[Dan CaJacob]

Building GR with the latest pybombs completes successfully, but when
calling a GR binary, there's an error about ICE (which built without
problems):

$:~/pybombs/src/gnuradio/build$ gnuradio-config-info -v
gnuradio-config-info: error while loading shared libraries: libIce.so.35:
cannot open shared object file: No such file or directory

This is on Ubuntu 12.04 x64

Very Respectfully,

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

Re: [Discuss-gnuradio] Ice-related Build Problem

[Dan CaJacob]

Running find to search for the missing library does find it at:

/usr/lib64/libIce.so.35

Very Respectfully,

Dan CaJacob


On Fri, May 16, 2014 at 1:20 AM, Dan CaJacob  wrote:

> Building GR with the latest pybombs completes successfully, but when
> calling a GR binary, there's an error about ICE (which built without
> problems):
>
> $:~/pybombs/src/gnuradio/build$ gnuradio-config-info -v
> gnuradio-config-info: error while loading shared libraries: libIce.so.35:
> cannot open shared object file: No such file or directory
>
> This is on Ubuntu 12.04 x64
>
> Very Respectfully,
>
> Dan CaJacob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] installed ieee_802_15_4 . do following modifications

[lingeswar kandregula]

On Sun, May 11, 2014 at 8:55 PM, Bastian Bloessl wrote:
Do you have a dated GNU Radio installation that does not support the
REQUIRED_COMPONENTS in cmake?

you could do this in lib/CMakeLists.txt

 list(APPEND gr_ieee802_15_4_libs
 ${Boost_LIBRARIES}
  gnuradio-blocks
  gnuradio-pmt
  gnuradio-runtime
)

but maybe better update your installation.

Bastian



On 05/11/2014 05:20 PM, lingeswar kandregula wrote:

> thanks for the reply.
> i did the changes to those two files and tried installing. it installed
> and got the same error.  and the phy block is installed before running
> heirarchical block under ieee_802_15_4. while checking with ldd, i got
> the following
>
> ldd libgnuradio-ieee802_15_4.so
>  linux-gate.so.1 =>  (0xb7713000)
>  libboost_system.so.1.46.1 => /usr/lib/libboost_system.so.1.46.1
> (0xb76cd000)
>  libboost_thread.so.1.46.1 => /usr/lib/libboost_thread.so.1.46.1
> (0xb76b6000)
>  libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb769a000)
>  libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb75b5000)
>  libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7597000)
>  libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb73ed000)
>  /lib/ld-linux.so.2 (0xb7714000)
>  libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb73c1000)
>
>
>
>
>
> On Sun, May 11, 2014 at 5:56 PM, Bastian Bloessl  > wrote:
>
> Hi Lingeswar,
>
>
>  >
>
> "/usr/local/lib/python2.7/__dist-packages/ieee802_15_4/__ieee802_15_4_swig.py",
>  > line 22, in swig_import_helper
>  >  _mod = imp.load_module('_ieee802_15___4_swig', fp, pathname,
> description)
>  > ImportError: /usr/local/lib/libgnuradio-__ieee802_15_4.so: undefined
>
>  > symbol: _ZN2gr6blocks12count_bits32Ej
>
> I guess libgnuradio-ieee802_15_4.so is not linked against
> libgnuradio-blocks.so. You can check that with
>
> ldd libgnuradio-ieee802_15_4.so
>
> Are you using the most recent version of 15.4? Linking should work
> latest since this commit
>
>
> https://github.com/bastibl/gr-__ieee802-15-4/commit/__a586256ad5e3fe1cf8c998a68a7276__adf6e2d691
> <
> https://github.com/bastibl/gr-ieee802-15-4/commit/a586256ad5e3fe1cf8c998a68a7276adf6e2d691
> >
>
> Best,
> Bastian
>
>
>

-- 
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://ccs.uibk.ac.at/~bloessl/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio