[Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[George]

Hello all, 

Considering a simple gnuradio flowgraph as the following

Random source -> chunks2symbols -> complex2float -> float2complex -> 
pfb_arb_resampler-> USRP sink

which used to work without any problem in the older gnuradio distributions, in 
the newer 3.7.2.1 seems that the conversion above (from complex to float and 
float to complex) introduces a problem, that has to do with USRP transmissions. 

However, when I increased the number of taps used for the root raised cosine 
filter in pfb_arb_resampler by a factor of 100, everything seems to work 
properly.

Note that if the conversions float2complex and complex2float miss everything 
works.

Any ideas why? 

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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[George]

Hi Tom, 

You are right increasing the number of taps by 100 is not the case, after I 
debugged the results a bit more.
The problem seems to be in the number of samples consumed as you mentioned 
above.

The full definition for the filter I am using is 
firdes.root_raised_cosine(nfilts, 1.0, 1.0/nfilts, rolloff, int(11*spb*nfilts))
where nfilts=32, rolloff=0.35 and spb =4

Thanks,
-George

On Dec 18, 2013, at 5:54 PM, Tom Rondeau  wrote:

> On Tue, Dec 17, 2013 at 9:06 PM, George  wrote:
>> Hello all,
>> 
>> Considering a simple gnuradio flowgraph as the following
>> 
>> Random source -> chunks2symbols -> complex2float -> float2complex -> 
>> pfb_arb_resampler-> USRP sink
>> 
>> which used to work without any problem in the older gnuradio distributions, 
>> in the newer 3.7.2.1 seems that the conversion above (from complex to float 
>> and float to complex) introduces a problem, that has to do with USRP 
>> transmissions.
>> 
>> However, when I increased the number of taps used for the root raised cosine 
>> filter in pfb_arb_resampler by a factor of 100, everything seems to work 
>> properly.
>> 
>> Note that if the conversions float2complex and complex2float miss everything 
>> works.
>> 
>> Any ideas why?
>> 
>> Thanks,
>> -George
> 
> Bug it the pfb_arb_resampler. I was trying to be too conscientious
> about calls to work but made an assumption in the forecast function
> that's not always correct. I'm testing a few things out, still, but I
> should push this fix soon.
> 
> Still, your behavior of the filter length (increasing it by 100, that
> is) doesn't fit with what I'm seeing. What's the full filter
> definition you're using for the block?
> 
> Tom


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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[George]

Tom, 

Is there going to be a fix soon or should I go with the 3.6.5 version of 
gnuradio?

Thanks,
-George

On Dec 18, 2013, at 7:01 PM, George  wrote:

> Hi Tom, 
> 
> You are right increasing the number of taps by 100 is not the case, after I 
> debugged the results a bit more.
> The problem seems to be in the number of samples consumed as you mentioned 
> above.
> 
> The full definition for the filter I am using is 
> firdes.root_raised_cosine(nfilts, 1.0, 1.0/nfilts, rolloff, 
> int(11*spb*nfilts))
> where nfilts=32, rolloff=0.35 and spb =4
> 
> Thanks,
> -George
> 
> On Dec 18, 2013, at 5:54 PM, Tom Rondeau  wrote:
> 
>> On Tue, Dec 17, 2013 at 9:06 PM, George  wrote:
>>> Hello all,
>>> 
>>> Considering a simple gnuradio flowgraph as the following
>>> 
>>> Random source -> chunks2symbols -> complex2float -> float2complex -> 
>>> pfb_arb_resampler-> USRP sink
>>> 
>>> which used to work without any problem in the older gnuradio distributions, 
>>> in the newer 3.7.2.1 seems that the conversion above (from complex to float 
>>> and float to complex) introduces a problem, that has to do with USRP 
>>> transmissions.
>>> 
>>> However, when I increased the number of taps used for the root raised 
>>> cosine filter in pfb_arb_resampler by a factor of 100, everything seems to 
>>> work properly.
>>> 
>>> Note that if the conversions float2complex and complex2float miss 
>>> everything works.
>>> 
>>> Any ideas why?
>>> 
>>> Thanks,
>>> -George
>> 
>> Bug it the pfb_arb_resampler. I was trying to be too conscientious
>> about calls to work but made an assumption in the forecast function
>> that's not always correct. I'm testing a few things out, still, but I
>> should push this fix soon.
>> 
>> Still, your behavior of the filter length (increasing it by 100, that
>> is) doesn't fit with what I'm seeing. What's the full filter
>> definition you're using for the block?
>> 
>> Tom
> 


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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[George]

Thanks, got it!

-George


On Dec 19, 2013, at 9:21 AM, Tom Rondeau  wrote:

> On Wed, Dec 18, 2013 at 7:47 PM, George  wrote:
>> Tom,
>> 
>> Is there going to be a fix soon or should I go with the 3.6.5 version of 
>> gnuradio?
>> 
>> Thanks,
>> -George
> 
> George,
> 
> The patch was pushed last night. I will make it into the next bug
> release, which will probably be in a month, plus or minus. In the
> meantime, you can get the patch by looking at commit
> b3b8a1f4965f8283f2c3d22ae45b569b2fe6d713
> 
> Tom
> 
> 
> 
>> On Dec 18, 2013, at 7:01 PM, George  wrote:
>> 
>>> Hi Tom,
>>> 
>>> You are right increasing the number of taps by 100 is not the case, after I 
>>> debugged the results a bit more.
>>> The problem seems to be in the number of samples consumed as you mentioned 
>>> above.
>>> 
>>> The full definition for the filter I am using is
>>> firdes.root_raised_cosine(nfilts, 1.0, 1.0/nfilts, rolloff, 
>>> int(11*spb*nfilts))
>>> where nfilts=32, rolloff=0.35 and spb =4
>>> 
>>> Thanks,
>>> -George
>>> 
>>> On Dec 18, 2013, at 5:54 PM, Tom Rondeau  wrote:
>>> 
>>>> On Tue, Dec 17, 2013 at 9:06 PM, George  
>>>> wrote:
>>>>> Hello all,
>>>>> 
>>>>> Considering a simple gnuradio flowgraph as the following
>>>>> 
>>>>> Random source -> chunks2symbols -> complex2float -> float2complex -> 
>>>>> pfb_arb_resampler-> USRP sink
>>>>> 
>>>>> which used to work without any problem in the older gnuradio 
>>>>> distributions, in the newer 3.7.2.1 seems that the conversion above (from 
>>>>> complex to float and float to complex) introduces a problem, that has to 
>>>>> do with USRP transmissions.
>>>>> 
>>>>> However, when I increased the number of taps used for the root raised 
>>>>> cosine filter in pfb_arb_resampler by a factor of 100, everything seems 
>>>>> to work properly.
>>>>> 
>>>>> Note that if the conversions float2complex and complex2float miss 
>>>>> everything works.
>>>>> 
>>>>> Any ideas why?
>>>>> 
>>>>> Thanks,
>>>>> -George
>>>> 
>>>> Bug it the pfb_arb_resampler. I was trying to be too conscientious
>>>> about calls to work but made an assumption in the forecast function
>>>> that's not always correct. I'm testing a few things out, still, but I
>>>> should push this fix soon.
>>>> 
>>>> Still, your behavior of the filter length (increasing it by 100, that
>>>> is) doesn't fit with what I'm seeing. What's the full filter
>>>> definition you're using for the block?
>>>> 
>>>> Tom
>>> 
>> 


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

Re: [Discuss-gnuradio] IQ changing with restart

[George]

Is it an over-the-air transmission or TX and RX are connected with a wire and 
attenuators?

-George
-
George Sklivanitis
PhD Student and Research Assistant
Signals, Communications, and Networking Research Group
Department of Electrical Engineering
University at Buffalo, The State University of New York

Office: 238 Davis Hall, Buffalo, NY 14260

Web: http://www.buffalo.edu/~gsklivan

On Feb 11, 2014, at 11:57 AM, Martin Braun  wrote:

> On 11.02.2014 06:19, Sylvain Munaut wrote:
>> Hi,
>> 
>>> I've done my homework on this one, crawled through the web & talked to
>>> colleagues. If I am missing something obvious please point it out - it's not
>>> for lack of effort on my part!
>> 
>> I'm not really sure what you're expecting. Of course the phase
>> alignement between the Tx and Rx is going to be random depending on
>> restart.
>> 
>> Using the same clock will prevent it from drifting, but the initial
>> phase alignement is random. This is usually resolved by using training
>> sequence, headers, differential encoding, ...
> 
> I had the same thought -- it looks like a phase change. This is a PSK signal, 
> right? Have you looked at the constellation diagram?
> 
> MB
> 
> ___
> 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] Problem with undefined symbol in new block created by gr_modtool in 3.7.2

[George]

Thanks everyone. 
In order to be more specific regarding the future readers of this post, I am 
using Ubuntu 12.04 and GNU Radio v3.7.2. 
I am using the embedded gr_modtool in order to create a custom signal 
processing block from scratch. 
My block does not use FFT.
Finally, the problem was solved by just ignoring the implementation header file 
and only include the public header file in the /include/nameofBlock .

Thanks,
-George
-
George Sklivanitis


On Mar 5, 2014, at 4:49 PM, Nowlan, Sean  wrote:

> Ah, nevermind about the wiki edit. The use of pure virtual functions is 
> already discussed in 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide . Still, 
> the gr_modtool addition may be useful.
> 
> 
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On 
> Behalf Of Nowlan, Sean
> Sent: Wednesday, March 05, 2014 4:45 PM
> To: Marcus Müller; George Sklivanitis; GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] Problem with undefined symbol in new block 
> created by gr_modtool in 3.7.2
> 
> The first place I'd look is in your_block.h. Did you remember to declare any 
> public member functions to be pure virtual in that file, and then declare 
> your (non-virtual) functions in your_block_impl.h? If you forgot to declare 
> pure virtual functions, i.e., "virtual return_type your_block(args_list) = 
> 0;" in your_block.h, it will compile but you will get the undefined symbol at 
> runtime.
> 
> This probably a common pitfall and it might be worth making a note in the 
> wiki for OutOfTreeModules. I'll add that.
> 
> Architects of gr_modtool... can you add an autogen comment in *.h files 
> reminding the user to declare pure virtual functions? I think users who don't 
> deeply understand OO and particularly its  C++ syntax would benefit from this 
> reminder. I think it's a common paradigm to use other examples to fill in the 
> "guts" of gr_modtool generated C++ code, but things like this are easy to 
> miss.
> 
> Sean
> 
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On 
> Behalf Of Marcus Müller
> Sent: Wednesday, March 05, 2014 3:21 PM
> To: George Sklivanitis; GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] Problem with undefined symbol in new block 
> created by gr_modtool in 3.7.2
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi George,
> This is a little unspecific. Most probably you have a problem similar to the 
> fftw- related problem of activecat, but that's only guessing... Please heed 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors when 
> reporting errors.
> Greetings,
> Marcus
> 
> On March 5, 2014 8:57:46 PM CET, George Sklivanitis 
>  wrote:
>> Hello all,
>> 
>> I am dealing with the problem of undefined symbol when trying to 
>> execute a python script for testing my new custom block created in GNU 
>> Radio 3.7.2.
>> I used gr_modtool for creating the new block and also followed the 
>> instructions posted at
>> 
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConf
>> ig
>> 
>> for correctly configuring it but the problem still holds.
>> 
>> Any ideas?
>> 
>> Thanks,
>> -George
>> 
>> --
>> Sklivanitis Georgios
>> 
>> 
>> ---
>> -
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> - --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> -BEGIN PGP SIGNATURE-
> Version: APG v1.0.9
> 
> iQFABAEBCAAqBQJTF4c7IxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu
> ZGU+AAoJEBKNLRrpJvfojQoH/2a609iWLTsywtozQ+FcZkuQT6uCy13vX3n4b5k3
> rTvy9QP3uHuHQkiRZHDbZoJ+mZ9kFOf6NeG20RGdf8i4yCB1AZ8F7uvvdi7CebXT
> sRQxoQE+8Vz5VS+faAStAOK3+tArdRGZOU2v3gTYXGCvATaeM3A+rxsNQ7LKPwM8
> sI5KZ3xgvgikkObbFuo00MOaLA7tHzMttXxWjU5riXann1l1eOyGIzM1j0XO1gAD
> imofs0DfXHB4cE0Gi43E1gjjeqEW034dLZAS7w/c/Gq85Z0Ni+z1a35kS5UYvYhQ
> ndeEMqrLQv4ghCRnHR93ob+8YRlqMedVjDDeKQdjEh0D2jY=
> =27ny
> -END PGP SIGNATURE-
> 
> 
> ___
> 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] Import Out of Tree module in another Out of Tree module

[George Vardakis]

Good evening,

i am trying to import an out of tree module (module_A) inside another out
of tree module (module_B) in order to be able to include header files from
one to another.How can that be achieved ,and what changes would that
require to the CMakeLists files of module_B?

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

[Discuss-gnuradio] Signal distorted when using concurrently two USRP B210 devices

[George Vardakis]

Hello all,

I have two USRP B210 devices which i use in my MIMO application. When i use
the two of them concurrently in a flowgraph - or different flowgraphs - i
notice that the signal received by the streams of one of the devices (the
one whose serial number is last in lexicographical order) is distorted.
Because i transmit a known training sequence, i know what to expect, and i
observe that sometimes the real or imaginary part of the signal has flipped
its sign (i see the signal mirrored compared to the known one), or other
times it is completely distorted. When i use each device separately,
everything works fine. The UHD driver i use is the v3.9.5 one.Any ideas
about it?

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

Re: [Discuss-gnuradio] Signal distorted when using concurrently two USRP B210 devices

[George Vardakis]

Good evening,

I attach three captures to show you the problem, one with the reference
signal i transmit, one with the received samples when using the same device
for TX and RX and one with the received samples of the one device, when the
second one transmits. I also attach the flowgraph i used for this capture.
The sampling rate i use is 1MHz. The specific captures are done with the
USRPs over USB-2 ports, but i have also tried over USB-3 and observed the
same behavior.

Thank you for your time​
 same_tx_rx_device.dat
<https://drive.google.com/file/d/0BxyASy57xNmqV2pLd2xUVWRRRU0/view?usp=drive_web>
​​
 refference.dat
<https://drive.google.com/file/d/0BxyASy57xNmqT1JQd2xfWjF6SjQ/view?usp=drive_web>
​​
 different_tx_rx_device.dat
<https://drive.google.com/file/d/0BxyASy57xNmqMVhqd29NTmdiMDA/view?usp=drive_web>
​

On Tue, Jun 13, 2017 at 12:04 AM, Marcus D. Leech  wrote:

> On 06/12/2017 03:53 PM, George Vardakis wrote:
>
> Hello all,
>
> I have two USRP B210 devices which i use in my MIMO application. When i
> use the two of them concurrently in a flowgraph - or different flowgraphs -
> i notice that the signal received by the streams of one of the devices (the
> one whose serial number is last in lexicographical order) is distorted.
> Because i transmit a known training sequence, i know what to expect, and i
> observe that sometimes the real or imaginary part of the signal has flipped
> its sign (i see the signal mirrored compared to the known one), or other
> times it is completely distorted. When i use each device separately,
> everything works fine. The UHD driver i use is the v3.9.5 one.Any ideas
> about it?
>
> Thank you!
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> COuld you perhaps share a very-simple flow-graph that shows the issue?
>
> What sample-rate are you using?  Is this over USB-2 or USB-3?
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


test.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Signal distorted when using concurrently two USRP B210 devices

[George Vardakis]

Στις 13 Ιουν 2017 10:22 μ.μ., ο χρήστης  έγραψε:

In the two-USRPs scenario, one of the USRPs is transmitting, and one is
receiving?

Yes. That's the problematic scenario.

Are they "through the air" or over a cable.  If over a cable, how much
attenuation has been added to the cable.

They are through the air.






On 2017-06-13 11:16, Manolis Surligas wrote:

Ok lets explain a little bit more what actually you observe. Each burst is
a training sequence that has a duration of 64 samples and then 1000 zero
samples. This is generated using a vector source block repeatedly. As you
can see in the ok.jpeg all sequences are exactly the same. In the other
plot however the sequence constantly changes. To me, it seems that parts of
the actual sequence are randomly cropped or re-arranged. This happens only
when two different B210 are used. We also tried to transmit the sequence
from a third device with the same results.

And yes we have tried to receive from both devices each one working on a
separate flowgraph. The result was exactly the same.

On 06/13/2017 06:05 PM, mle...@ripnet.com wrote:

I'm having a hard time seeing a significant functional difference between
the two.  Could you perhaps explain?

Also, maybe a diagram showing the two configurations?

Do you get any error messages during a run?

Are you doing reception on the two USRPs within a single flow-graph, or two
separate processes?






On 2017-06-13 10:51, Manolis Surligas wrote:

Hi Marcus,

yeah we have updated the UHD on the latest version and the problem still
persists. I have started to debug the UHD and we suspect some kind of
inconsistency between the device pointers of the different devices. Perhaps
a race condition is hidden somewhere.

I also attach two plots. The first one is the problematic with two
different USRPs and the second the expected signal transmitting and
receiving using the same USRP.
On 06/13/2017 05:30 PM, mle...@ripnet.com wrote:

Thanks, George.

Two things:

Could you try updating to the most recent UHD version?

It would be helpful if you provided your .dat files in the form of plots or
graphs, highlighting the areas you consider "distortion".  This will help
us help you.








On 2017-06-13 07:23, George Vardakis wrote:

Good evening,

I attach three captures to show you the problem, one with the reference
signal i transmit, one with the received samples when using the same device
for TX and RX and one with the received samples of the one device, when the
second one transmits. I also attach the flowgraph i used for this capture.
The sampling rate i use is 1MHz. The specific captures are done with the
USRPs over USB-2 ports, but i have also tried over USB-3 and observed the
same behavior.

Thank you for your time​
 same_tx_rx_device.dat
<https://drive.google.com/file/d/0BxyASy57xNmqV2pLd2xUVWRRRU0/view?usp=drive_web>
​​
 refference.dat
<https://drive.google.com/file/d/0BxyASy57xNmqT1JQd2xfWjF6SjQ/view?usp=drive_web>
​​
 different_tx_rx_device.dat
<https://drive.google.com/file/d/0BxyASy57xNmqMVhqd29NTmdiMDA/view?usp=drive_web>
​

On Tue, Jun 13, 2017 at 12:04 AM, Marcus D. Leech  wrote:

> On 06/12/2017 03:53 PM, George Vardakis wrote:
>
> Hello all,
>
> I have two USRP B210 devices which i use in my MIMO application. When i
> use the two of them concurrently in a flowgraph - or different flowgraphs -
> i notice that the signal received by the streams of one of the devices (the
> one whose serial number is last in lexicographical order) is distorted.
> Because i transmit a known training sequence, i know what to expect, and i
> observe that sometimes the real or imaginary part of the signal has flipped
> its sign (i see the signal mirrored compared to the known one), or other
> times it is completely distorted. When i use each device separately,
> everything works fine. The UHD driver i use is the v3.9.5 one.Any ideas
> about it?
>
> Thank you!
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> COuld you perhaps share a very-simple flow-graph that shows the issue?
> What sample-rate are you using?  Is this over USB-2 or USB-3?
> ___ 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

-- 
/* Code is the Law */

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

-- 
/* Code is the Law */


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.g

Re: [Discuss-gnuradio] Signal distorted when using concurrently two USRP B210 devices

[George Vardakis]

After all this might be an expected behavior. Since the devices have
different clocks, they sample the medium at different time
instances,leading to this "distortion" of the signal. That's why this only
happens when the one USRP transmits and the other receives, and not when
the same usrp transmits and receives. This calls for some clock recovery
function.

Thank you very much for your time Marcus


Στις 14 Ιουν 2017 10:55 π.μ., ο χρήστης "George Vardakis" <
vardakis@gmail.com> έγραψε:



Στις 13 Ιουν 2017 10:22 μ.μ., ο χρήστης  έγραψε:

In the two-USRPs scenario, one of the USRPs is transmitting, and one is
receiving?

Yes. That's the problematic scenario.

Are they "through the air" or over a cable.  If over a cable, how much
attenuation has been added to the cable.

They are through the air.






On 2017-06-13 11:16, Manolis Surligas wrote:

Ok lets explain a little bit more what actually you observe. Each burst is
a training sequence that has a duration of 64 samples and then 1000 zero
samples. This is generated using a vector source block repeatedly. As you
can see in the ok.jpeg all sequences are exactly the same. In the other
plot however the sequence constantly changes. To me, it seems that parts of
the actual sequence are randomly cropped or re-arranged. This happens only
when two different B210 are used. We also tried to transmit the sequence
from a third device with the same results.

And yes we have tried to receive from both devices each one working on a
separate flowgraph. The result was exactly the same.

On 06/13/2017 06:05 PM, mle...@ripnet.com wrote:

I'm having a hard time seeing a significant functional difference between
the two.  Could you perhaps explain?

Also, maybe a diagram showing the two configurations?

Do you get any error messages during a run?

Are you doing reception on the two USRPs within a single flow-graph, or two
separate processes?






On 2017-06-13 10:51, Manolis Surligas wrote:

Hi Marcus,

yeah we have updated the UHD on the latest version and the problem still
persists. I have started to debug the UHD and we suspect some kind of
inconsistency between the device pointers of the different devices. Perhaps
a race condition is hidden somewhere.

I also attach two plots. The first one is the problematic with two
different USRPs and the second the expected signal transmitting and
receiving using the same USRP.
On 06/13/2017 05:30 PM, mle...@ripnet.com wrote:

Thanks, George.

Two things:

Could you try updating to the most recent UHD version?

It would be helpful if you provided your .dat files in the form of plots or
graphs, highlighting the areas you consider "distortion".  This will help
us help you.








On 2017-06-13 07:23, George Vardakis wrote:

Good evening,

I attach three captures to show you the problem, one with the reference
signal i transmit, one with the received samples when using the same device
for TX and RX and one with the received samples of the one device, when the
second one transmits. I also attach the flowgraph i used for this capture.
The sampling rate i use is 1MHz. The specific captures are done with the
USRPs over USB-2 ports, but i have also tried over USB-3 and observed the
same behavior.

Thank you for your time​
 same_tx_rx_device.dat
<https://drive.google.com/file/d/0BxyASy57xNmqV2pLd2xUVWRRRU0/view?usp=drive_web>
​​
 refference.dat
<https://drive.google.com/file/d/0BxyASy57xNmqT1JQd2xfWjF6SjQ/view?usp=drive_web>
​​
 different_tx_rx_device.dat
<https://drive.google.com/file/d/0BxyASy57xNmqMVhqd29NTmdiMDA/view?usp=drive_web>
​

On Tue, Jun 13, 2017 at 12:04 AM, Marcus D. Leech  wrote:

> On 06/12/2017 03:53 PM, George Vardakis wrote:
>
> Hello all,
>
> I have two USRP B210 devices which i use in my MIMO application. When i
> use the two of them concurrently in a flowgraph - or different flowgraphs -
> i notice that the signal received by the streams of one of the devices (the
> one whose serial number is last in lexicographical order) is distorted.
> Because i transmit a known training sequence, i know what to expect, and i
> observe that sometimes the real or imaginary part of the signal has flipped
> its sign (i see the signal mirrored compared to the known one), or other
> times it is completely distorted. When i use each device separately,
> everything works fine. The UHD driver i use is the v3.9.5 one.Any ideas
> about it?
>
> Thank you!
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> COuld you perhaps share a very-simple flow-graph that shows the issue?
> What sample-rate are you using?  Is this over USB-2 or USB-3?
> ___ Discuss-gnuradio mailing
> list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailma

[Discuss-gnuradio] Clock recovery without change of phase

[George Vardakis]

Hi all,

I need to perform clock recovery on a signal without constantly changing
its phase. I think that the clock recovery block in Gnuradio does exactly
that in order to maximize the energy of the signal. Is there any other way
that does not tamper with the signal phase?

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

Re: [Discuss-gnuradio] Looking for simple ra

[George Nychis]

Hi Will,

The subversion server is still up and your relevant code is at
https://www.cgran.org/svn/projects/simple_ra

Archive.org has a nice cache of CGRAN also:
https://web.archive.org/web/20140702091149/https://cgran.org/wiki/simple_ra

- George

On Mon, Oct 20, 2014 at 6:20 PM, Will Caruana 
wrote:

> I am looking to download the program  simple_ra to make a radio telescope
> for my small town of Wilbraham MA. Please let me know if you can either
> send me the files or up load them to https://github.com
>
> Thank you,
>
> Will Caruana
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Inquiry about USRP GNU Radio

[George Nychis]

If there was a MIMO project on CGRAN you can find it archived still:
https://web.archive.org/web/20140822005337/https://www.cgran.org/

I need to just link to this on the explanation...
On Oct 28, 2014 9:19 PM, "이재훈"  wrote:

> Dear
>
>
>
>
>
> Hi, my name is jaehoon Lee and a graduate student at Seoul National
> University in South Korea.
>
>
>
> Recently, I heard that CGRAN site is closed. I was so surprised because it
> is so famous GNU RADIO site.
>
>
>
> I want to experiment using USRP N210 with XCVR240 dautherboard. Could you
> give me some example code or project about MIMO transmission?
>
>
>
> By using 4 USRPs, 2 USRPs will be transmitter and 2 USRP will be
> receivers.
>
>
>
> Thanks for reading my request.
>
>
>
> Best regards
>
>
>
>
>
> Jaehoon Lee
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RuntimeError: b200: 2 RX 1 TX and 1 RX 2 TX configurations not possible

[George Sklivanitis]

Hi all,

I think what Lefteris tries to implement is a 2x2 loopback with a USRP-B210.

At least this is what I can see from the flowgraph attached in the first
email.
Is that possible with B210?

Best,
George

On Mon, Nov 17, 2014 at 5:47 PM, Ben Hilburn  wrote:

> Hi Lefteris -
>
> We recently added that warning. We think we got it right, but it's
> possible something is wrong with the logic that makes it fire.
>
> Can you share your GRC flowgraph?
>
> Cheers,
> Ben
>
> On Mon, Nov 17, 2014 at 2:28 PM, Marcus D. Leech 
> wrote:
>
>>  On 11/17/2014 05:15 PM, Lefteris Kampianakis wrote:
>>
>>  Hello,
>>
>>  FYI I am having problems even with a simpler configuration like this:
>>
>>  USRP_source_channel1 --> USRP_sink_channel1
>> USRP_source_channel2 --> USRP_sink_channel2
>>
>>
>>  Does anyone face the same issue? It is really frustrating because 1/3
>> executions are wasted and this causes problems with later design, that has
>> to have an execution rate of > 1Hz
>>
>> Thank you in advance
>>  Lefteris
>>
>>
>>
>>
>>
>>
>> On Fri, Nov 14, 2014 at 6:32 PM, Lefteris Kampianakis <
>> e.kampianakis...@ieee.org> wrote:
>>
>>>Hello,
>>>
>>>  I have a B210 and I am trying to transmit and receive from all it's
>>> channels simultaneously. My setup is a macmini late 2012 with Ubuntu 12.04
>>> install. I compiled and installed gnuradio from source using the gnuradio
>>> build script. I have developed the attached very simple GRC script that
>>> looks like this
>>>
>>>  signal_source@1khz --> USRP_sink_channel1
>>> signal_source@2khz --> USRP_sink_channel2
>>>
>>>  USRP_source_channel1 --> WX_GUI_scope_channel1
>>> USRP_source_channel2 --> WX_GUI_scope_channel2
>>>
>>>  The problem I have is that I get the following message at random times
>>> and on average on 1/3 executions of the GRC script.
>>>
>>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.008.000-18-g864f84b5
>>>
>>> Using Volk machine: avx_64_mmx_orc
>>> -- Operating over USB 3.
>>> -- Initialize CODEC control...
>>> -- Initialize Radio control...
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Asking for clock rate 32.00 MHz
>>> -- Actually got clock rate 32.00 MHz
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Asking for clock rate 28.00 MHz
>>> -- Actually got clock rate 28.00 MHz
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Tune Request: 915.00 MHz
>>> --   The RF LO does not support the requested frequency:
>>> -- Requested LO Frequency: 915.00 MHz
>>> -- RF LO Result: 914.99 MHz
>>> --   Attempted to use the DSP to reach the requested frequency:
>>> -- Desired DSP Frequency: -0.01 MHz
>>> -- DSP Result: -0.01 MHz
>>> --   Successfully tuned to 915.00 MHz
>>> --
>>> -- Tune Request: 915.00 MHz
>>> --   The RF LO does not support the requested frequency:
>>> -- Requested LO Frequency: 915.00 MHz
>>> -- RF LO Result: 914.99 MHz
>>> --   Attempted to use the DSP to reach the requested frequency:
>>> -- Desired DSP Frequency: -0.01 MHz
>>> -- DSP Result: -0.01 MHz
>>> --   Successfully tuned to 915.00 MHz
>>> --
>>> -- Asking for clock rate 28.00 MHz
>>> -- Actually got clock rate 28.00 MHz
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Tune Request: 915.00 MHz
>>> --   The RF LO does not support the requested frequency:
>>> -- Requested LO Frequency: 915.00 MHz
>>> -- RF LO Result: 914.99 MHz
>>> --   Attempted to use the DSP to reach the requested frequency:
>>> -- Desired DSP Frequency: 0.01 MHz
>>> -- DSP Result: 0.01 MHz
>>> --   Successfully tuned to 915.00 MHz
>>> --
>>> -- Tune Request: 915.00 MHz
>>> --   The RF LO does not support the requested frequency:
>>> -- Requested LO Frequency: 915.00 MHz
>>> -- RF LO Result: 914.99 MHz
>

[Discuss-gnuradio] A few questions regarding QT GUI development

[George Hadley]

Greetings all,

I recently began using gnuradio and GRC with a pair of USRPs. 
It's my understanding that plans are underway to ultimately remove WX in 
v3.9 as a GUI option from gnuradio, and replace it with QT. It's also my 
understanding that QT GUI development is underway in future versions of 
gnuradio. I'm interested in attempting to help develop for gnuradio and 
have forked a copy of the source from github.


With that in mind, I have a few questions:

1. Who is involved with QT GUI development for gnuradio?
2. What future improvements, especially functionality related, are
   planned for gnuradio QT? All I have been able to find in the
   3.8.0 roadmap is that grc will "introduce a QT version of GRC"
   (what does that mean?) and that gr-qtgui will be switching
   examples to use gr-qtgui instead of gr-wxgui. Functionality I'm
   most interested in includes X/Y mode for the QT GUI Time Sink
   and the ability to pause the output of the Time, Frequency, and
   Waterfall sinks (as is available via the "Stop" button in the WX
   counterparts.
3. In looking over the WX and QT GUI options, I personally prefer
   the layout and functionality of the WX GUI components
   (specifically, the instrumentation options). Are there any plans
   to attempt to replicate the layout and options of the WX
   components? (Perhaps the old WX layout style and functionality
   are being abandoned for good reason; if that's the case, if
   anybody could clarify that for me or point me in the right
   direction I would be most appreciative.)

   Thanks everyone, and I look forward to hearing from you!

--George

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

[Discuss-gnuradio] A few questions regarding QT GUI development

[George Hadley]

Greetings all,

I recently began using gnuradio and GRC with a pair of USRPs. 
It's my understanding that plans are underway to ultimately remove WX in 
v3.9 as a GUI option from gnuradio, and replace it with QT. It's also my 
understanding that QT GUI development is underway in future versions of 
gnuradio. I'm interested in attempting to help develop for gnuradio and 
have forked a copy of the source from github.


With that in mind, I have a few questions:

1. Who is involved with QT GUI development for gnuradio?
2. What future improvements, especially functionality related, are
   planned for gnuradio QT? All I have been able to find in the
   3.8.0 roadmap is that grc will "introduce a QT version of GRC"
   (what does that mean?) and that gr-qtgui will be switching
   examples to use gr-qtgui instead of gr-wxgui. Functionality I'm
   most interested in includes X/Y mode for the QT GUI Time Sink
   and the ability to pause the output of the Time, Frequency, and
   Waterfall sinks (as is available via the "Stop" button in the WX
   counterparts.
3. In looking over the WX and QT GUI options, I personally prefer
   the layout and functionality of the WX GUI components
   (specifically, the instrumentation options). Are there any plans
   to attempt to replicate the layout and options of the WX
   components? (Perhaps the old WX layout style and functionality
   are being abandoned for good reason; if that's the case, if
   anybody could clarify that for me or point me in the right
   direction I would be most appreciative.)

   Thanks everyone, and I look forward to hearing from you!

--George

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

Re: [Discuss-gnuradio] A few questions regarding QT GUI development

[George Hadley]

Aha! The middle menu button click works after all :-) Thank you very 
much for your help everyone!


I was able to get the middle button click functionality to work in the 
individual sinks (QT GUI Time Sink, QT GUI Frequency Sink, QT GUI 
Constellation Sink, and QT GUI Waterfall Sink) however, I was not able 
to get the middle button menu functionality to work in the "master" 
instrumentation block (QT GUI Sink). That may be an issue with my 
installation of gnuradio; unsure.


Per your suggestion I'll look over the manual page and see what I can do 
to help; thank you so much for yours!


--George

On 3/24/2015 12:54 PM, Tom Rondeau wrote:
On Tue, Mar 24, 2015 at 9:01 AM, George Hadley <mailto:ghad...@purdue.edu>> wrote:


Greetings all,

I recently began using gnuradio and GRC with a pair of
USRPs. It's my understanding that plans are underway to ultimately
remove WX in v3.9 as a GUI option from gnuradio, and replace it
with QT. It's also my understanding that QT GUI development is
underway in future versions of gnuradio. I'm interested in
attempting to help develop for gnuradio and have forked a copy of
the source from github.


Adding a bit to what Marcus said.

With that in mind, I have a few questions:

 1. Who is involved with QT GUI development for gnuradio?


Mostly, but not solely, me. More people working on this feature would 
be nice.


 1. What future improvements, especially functionality
related, are planned for gnuradio QT? All I have been able
to find in the 3.8.0 roadmap is that grc will "introduce a
QT version of GRC" (what does that mean?) and that
gr-qtgui will be switching examples to use gr-qtgui
instead of gr-wxgui. Functionality I'm most interested in
includes X/Y mode for the QT GUI Time Sink and the ability
to pause the output of the Time, Frequency, and Waterfall
sinks (as is available via the "Stop" button in the WX
counterparts.


We have plans to discuss the features we need next week at our 
hackfest. There are really two that come to mind that need attention.
The first is a strip-chart feature of the time plots (instead of 
waiting for a full number of samples, this would plot any new samples 
immediately and move the graph to the right -- used for slow signals 
mainly). The second is a persistence mode in the time plots.


The X/Y mode would be nice, sure, but it's basically what the 
Constellation plot does.


And we have already switched all GNU Radio example to QT instead of 
WX. That happened a while ago, but I guess that info still persists on 
the wiki (which page? It should be amended).


As Marcus pointed out, click the middle mouse button (or whatever's 
equivalent button 3 on your system). That menu has most of the 
instrumentation that's available in WX, just as a menu instead of the 
instrumentation panel. Including the ability to stop and save images.


 1. In looking over the WX and QT GUI options, I personally
prefer the layout and functionality of the WX GUI
components (specifically, the instrumentation options).
Are there any plans to attempt to replicate the layout and
options of the WX components? (Perhaps the old WX layout
style and functionality are being abandoned for good
reason; if that's the case, if anybody could clarify that
for me or point me in the right direction I would be most
appreciative.)

Thanks everyone, and I look forward to hearing from you!

--George


I don't like the instrumentation panel in WX. It's clunky and doesn't 
scale well. And it takes up a lot of screen real estate that could be 
used for looking at the signals. However, I know that a lot of people 
like it for quick access to some of the features. As I said, it's all 
available in the drop-down menu, but it can take a few clicks to get 
to the right thing.


I'm actually working on this now. Something to hack on while at ELC, 
basically. My main goal with it, though, is that I want a button or 
trigger to hide the panel, so you can open it up or close it depending 
on what you are doing or trying to see. But really, this is just 
adding QT widgets to do what's already available in the menus, so 
nothing really "new" just, hopefully, more user friendly.


One thing that would be really appreciated is if you want to look over 
the manual page and make suggestions and add material to make it more 
clear to people what the capabilities are and how to use them.


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

And we'll probably have more to-do's next week when we chat about this 
at the hackfest.


Thanks for your interest.

Tom

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

[Discuss-gnuradio] [UHD] Cause of sequence errors (SSSSS...) when using USRP N210 as transmitter?

[George Hadley]

Hello,

I'm working on developing some gnuradio exercises, some of 
which involve using USRP N210 devices as transmitters. When I attempt to 
run the related flowgraphs, I get a stream of sequence errors (S) in the 
GRC log window. Attached are a pair of GRC flowgraphs in which I am 
getting this error. I have tried installing the latest images to the 
USRPs and updating to the latest version of gnuradio available on the 
github master branch. Can somebody please point me to what I'm doing 
wrong? I've searched around on the topic for quite awhile, to no avail.


Thanks,
George




  Mon Jul  6 09:03:20 2015
  
options

  author
  George Hadley


  alias
  


  category
  Custom


  comment
  


  description
  Implements a basic narrowband FM transmitter


  _enabled
  True


  _coordinate
  (10, 10)


  _rotation
  0


  generate_options
  qt_gui


  id
  usrp_fm_tx2


  max_nouts
  0


  realtime_scheduling
  


  run_options
  prompt


  run
  True


  thread_safe_setters
  


  title
  USRP FM Transmitter


  window_size
  1280, 1024

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (280, 123)


  _rotation
  0


  id
  audio_interp


  value
  4

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (184, 123)


  _rotation
  0


  id
  audio_rate


  value
  44100

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (104, 123)


  _rotation
  0


  id
  fd


  value
  100

  
  
variable_qtgui_entry

  comment
  


  value
  200


  _enabled
  True


  _coordinate
  (184, 11)


  gui_hint
  


  _rotation
  0


  id
  freq


  label
  Frequency (MHz)


  type
  int

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (8, 123)


  _rotation
  0


  id
  samp_rate


  value
  25

  
  
analog_nbfm_tx

  audio_rate
  audio_rate


  alias
  


  comment
  


  affinity
  


  _enabled
  1


  _coordinate
  (376, 331)


  _rotation
  0


  id
  analog_nbfm_tx_0


  max_dev
  5e3


  maxoutbuf
  0


  minoutbuf
  0


  quad_rate
  audio_rate * audio_interp


  tau
  75e-6

  
  
analog_wfm_tx

  audio_rate
  192000


  alias
  


  comment
  


  affinity
  


  _enabled
  0


  _coordinate
  (376, 227)


  _rotation
  0


  id
  analog_wfm_tx_0


  max_dev
  75e3


  maxoutbuf
  0


  minoutbuf
  0


  quad_rate
  768000


  tau
  75e-6

  
  
audio_sink

  alias
  


  comment
  


  affinity
  


  device_name
  plughw


  _enabled
  0


  _coordinate
  (488, 131)


  _rotation
  0


  id
  audio_sink_0


  num_inputs
  1


  ok_to_block
  True


  samp_rate
  48000

  
  
blocks_wavfile_source

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  file
  /home/grcuser/Documents/ECE440/Development/Experiments/4_SidebandModulation/audio/audiotest.wav


  _coordinate
  (8, 291)


  _rotation
  0


  id
  blocks_wavfile_source_0


  maxoutbuf
  0


  minoutbuf
  0


  nchan
  1


  repeat
  True

  
  
uhd_usrp_sink

  alias
  


  ant0
  TX/RX


  bw0
  0


  center_freq0
  freq*1e6


  norm_gain0
  False


  gain0
  20


  ant10
  


  bw10
  0


  center_freq10
  0


  norm_gain10
  False


  gain10
  0


  ant11
  

Re: [Discuss-gnuradio] [UHD] Cause of sequence errors (SSSSS...) when using USRP N210 as transmitter?

[George Hadley]

I am indeed running inside a VM presently. Details below:

Hardware:
USRP N210 (2x) connected to dual-port gigabit ethernet card: 
http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096


Software:
Windows 7 host OS
VirtualBox VM running Mint Linux 17.1 (Mate Desktop edition)
Network settings:
+ Adapter enabled and attached to NAT
+ No port forwarding settings defined

It may be noteworthy that the receive operation of the USRPs works as 
expected. Only transmit doesn't appear to be working properly.


Thanks,
George


On 7/9/2015 9:11 AM, mle...@ripnet.com wrote:


This is usually due to your network subsystem re-ordering packets, 
which is never supposed to happen but certain

 1GiGe interfaces, particularly USB ones, do this quite a bit.

Are you running inside a VM?

What kind of network interface do you have?

On 2015-07-09 09:09, George Hadley wrote:


Hello,

 I'm working on developing some gnuradio exercises, some of which 
involve using USRP N210 devices as transmitters. When I attempt to run the 
related flowgraphs, I get a stream of sequence errors (S) in the GRC log 
window. Attached are a pair of GRC flowgraphs in which I am getting this error. 
I have tried installing the latest images to the USRPs and updating to the 
latest version of gnuradio available on the github master branch. Can somebody 
please point me to what I'm doing wrong? I've searched around on the topic for 
quite awhile, to no avail.

Thanks,
George


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


--
George Hadley
ECE Lab Coordinator
Purdue University

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

Re: [Discuss-gnuradio] [UHD] Cause of sequence errors (SSSSS...) when using USRP N210 as transmitter?

[George Hadley]

I installed UHD in windows but didn't find FastDatagramThreshold.reg in 
/share/uhd/FastSendDatagramThreshold.reg as suggested in 
the Windows specific notes. I pulled the UHD source off github and ran 
the file in question, setting the threshold to 2048. Unfortunately, this 
did not have any apparent effect on the sequence errors in GRC.


The two ethernet ports are given unique IP addresses, and the USRPs are 
matched to these addresses. The IPv4 connection properties for the 
ethernet ports are as follows:


IP Address: 192.168.10 (20).1 ( USRP uses 192.168.10 (20).2 )
Subnet Mask: 255.255.255.0

(No DNS Server Addresses specified)

Thank you for your continued assistance,
George

On 7/9/2015 9:29 AM, mle...@ripnet.com wrote:


See the windows-specific notes here:

http://files.ettus.com/manual/page_transport.html#transport_udp_params

Does setting the FastDatagramTheshold help?

Do you two ethernet ports have distinct addresses, and do your two 
USRPs have distinct addresses to match?


On 2015-07-09 09:21, George Hadley wrote:


I am indeed running inside a VM presently. Details below:

Hardware:
USRP N210 (2x) connected to dual-port gigabit ethernet card: 
http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096


Software:
Windows 7 host OS
VirtualBox VM running Mint Linux 17.1 (Mate Desktop edition)
Network settings:
+ Adapter enabled and attached to NAT
+ No port forwarding settings defined

It may be noteworthy that the receive operation of the USRPs works as 
expected. Only transmit doesn't appear to be working properly.


Thanks,
George


On 7/9/2015 9:11 AM, mle...@ripnet.com wrote:


This is usually due to your network subsystem re-ordering packets, 
which is never supposed to happen but certain

 1GiGe interfaces, particularly USB ones, do this quite a bit.

Are you running inside a VM?

What kind of network interface do you have?

On 2015-07-09 09:09, George Hadley wrote:

Hello,

 I'm working on developing some gnuradio exercises, some of which 
involve using USRP N210 devices as transmitters. When I attempt to run the 
related flowgraphs, I get a stream of sequence errors (S) in the GRC log 
window. Attached are a pair of GRC flowgraphs in which I am getting this error. 
I have tried installing the latest images to the USRPs and updating to the 
latest version of gnuradio available on the github master branch. Can somebody 
please point me to what I'm doing wrong? I've searched around on the topic for 
quite awhile, to no avail.

Thanks,
George


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



--
George Hadley
ECE Lab Coordinator
Purdue University


--
George Hadley
ECE Lab Coordinator
Purdue University

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

Re: [Discuss-gnuradio] [UHD] Cause of sequence errors (SSSSS...) when using USRP N210 as transmitter?

[George Hadley]

UHD version is 3.008.004.

Looking at the connection properties in the Windows Network/Sharing 
Center, I see "Realtek PCIe GBE Family Controller" listed as the 
ethernet controller. Looking at the network settings through the VM, the 
adapter type "Intel PRO/1000 MT Desktop (82540EM) is listed.


Thank you for crossposting and your continued assistance.
George

On 7/9/2015 10:19 AM, mle...@ripnet.com wrote:


What version of UHD are you using?

Any idea what ethernet controller is used on that dual-port card?

You'd have to go into windows configuration to determine this, since I 
think that 'lspci' on the VM side will see some kind of emulated 
network card.


I've taken the liberty of copying this to the usrp-users list, since 
this is more USRP-centric, than GnuRadio-centric.


On 2015-07-09 09:21, George Hadley wrote:


I am indeed running inside a VM presently. Details below:

Hardware:
USRP N210 (2x) connected to dual-port gigabit ethernet card: 
http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096


Software:
Windows 7 host OS
VirtualBox VM running Mint Linux 17.1 (Mate Desktop edition)
Network settings:
+ Adapter enabled and attached to NAT
+ No port forwarding settings defined

It may be noteworthy that the receive operation of the USRPs works as 
expected. Only transmit doesn't appear to be working properly.


Thanks,
George


On 7/9/2015 9:11 AM, mle...@ripnet.com wrote:


This is usually due to your network subsystem re-ordering packets, 
which is never supposed to happen but certain

 1GiGe interfaces, particularly USB ones, do this quite a bit.

Are you running inside a VM?

What kind of network interface do you have?

On 2015-07-09 09:09, George Hadley wrote:

Hello,

 I'm working on developing some gnuradio exercises, some of which 
involve using USRP N210 devices as transmitters. When I attempt to run the 
related flowgraphs, I get a stream of sequence errors (S) in the GRC log 
window. Attached are a pair of GRC flowgraphs in which I am getting this error. 
I have tried installing the latest images to the USRPs and updating to the 
latest version of gnuradio available on the github master branch. Can somebody 
please point me to what I'm doing wrong? I've searched around on the topic for 
quite awhile, to no avail.

Thanks,
George


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



--
George Hadley
ECE Lab Coordinator
Purdue University


--
George Hadley
ECE Lab Coordinator
Purdue University

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

[Discuss-gnuradio] Pass boolean parameter to gnuradio script from command line

[George Vardakis]

Hi all!

I need to give the user the option to pass a boolean parameter when
executing my script from command line, something like '--split-image=True',
where split_image is a parameter of a block. What is the way to do that
from gnuradio without needing to translate inside my code the 'True' string
to the boolean True? The 'parameter' block in gnuradio does not support
boolean type as i saw...

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

Re: [Discuss-gnuradio] Pass boolean parameter to gnuradio script from command line

[George Vardakis]

Thank you Marcus I'll give it a try :)

Στις 18 Ιουλ 2017 12:05 μ.μ., ο χρήστης "Marcus Müller" 
έγραψε:

> Hi George,
>
> you could go into gnuradio/grc/blocks, change parameter.xml to have
>
>   
>   Boolean
>   bool
>   type:bool
>   
>
>
> and then change grc/core/generator/flow_graph.tmpl and in the
>
> #for $param in $parameters
>
>
> loop add an if type == "bool": clause that adds a binary option (something
> with ..action="store_true", see [1]). great chance to contribute :) .
>
> Alternatively, just use an int parameter, and use bool(parameter_id)
> whereever you need a true or false. You'll have to pass 0 for False, and
> any other int for True, then.
>
> Best regards,
>
> Marcus
>
> [1] https://docs.python.org/2/library/optparse.html#
> standard-option-actions
>
> On 18.07.2017 10:40, George Vardakis wrote:
>
> Hi all!
>
> I need to give the user the option to pass a boolean parameter when
> executing my script from command line, something like '--split-image=True',
> where split_image is a parameter of a block. What is the way to do that
> from gnuradio without needing to translate inside my code the 'True' string
> to the boolean True? The 'parameter' block in gnuradio does not support
> boolean type as i saw...
>
> Thank you!
>
>
> ___
> 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] Couldn't find the block named "Source"

[George Vardakis]

Hi there!

You should also download the gr-osmosdr module which will then provide you
with the osmocom source block which you will use with your rtl device
You can find more instructions here https://osmocom.org/
projects/sdr/wiki/rtl-sdr

Στις 24 Ιουλ 2017 20:32, ο χρήστης "Nipun Pruthi" 
έγραψε:

> Recently i got my first sdr (RTL-SDR 2832U)...
> I am following some tutorials to use it with gnuradio..
> I am using Ubuntu 16.04LTS and installed the following using command line:
>
>- GNU Radio (apt install gnuradio)
>- GNU Radio dev (apt install gnuradio-dev)
>- RTL-SDR (apt install rtl-sdr)
>
> In tutorial, he instructed to click on block with name "*Source*" in the
> right side of screen and select *rtl-sdr*..
> But i couldn't find the block named *Source*...
>
> Help me to find the same.
>
> ___
> 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] Rotating constellations and varying LOs with USRP B210 + Board Mounted GPSDO

[George Sklivanitis]

Hi everyone,

Has anyone noticed unstable LOs or carrier frequency offsets when using
USRP B210s with board mounted GPSDOs?

We have recently been doing field tests using GPS-disciplined oscillators
for both USRP B210s and USRP N210 and occasionally both transmitter and
receiver flowgraphs lose GPS lock, although clock reference leds in the
USRP panel are ON.

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

Re: [Discuss-gnuradio] Rotating constellations and varying LOs with USRP B210 + Board Mounted GPSDO

[George Sklivanitis]

Hi Nicolas,

Thanks for the response. I have already posted my question to the
USRP-users list.

I am using the clock reference only from the GPSDO mounted on each of the
B210s. I am not exporting the time reference from one device to the other.

We have been testing communication links between GPS disciplined B210s and
N210s, each on it's own GPSD0 mounted clock, as well as between B210s with
their own GPSD0 mounted clock and N210s that receive an external REF and
PPS from a GPS-disciplined octoclock.

We observed the same thing. LED indicators on all devices show that the
clock reference locks but constellations keep rotating. Should we address
the residual CFO or is there something wrong with the hardware?

Thanks,
George

On Mon, Sep 11, 2017 at 7:32 AM, Nicolas Cuervo 
wrote:

> Hello George,
>
> this question would be better posted in the USRP-usrs list. However, the
> answer to this is "yes". There is a known issue on the B210 when using
> GPSDOs and it's report of PLL lock. Are you using the clock reference only
> from the GPSDO mounted on each of the USRPs? or are you also exporting the
> time reference from one device to the other?
>
> On Wed, Aug 30, 2017 at 6:14 PM, George Sklivanitis <
> george.sklivani...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> Has anyone noticed unstable LOs or carrier frequency offsets when using
>> USRP B210s with board mounted GPSDOs?
>>
>> We have recently been doing field tests using GPS-disciplined oscillators
>> for both USRP B210s and USRP N210 and occasionally both transmitter and
>> receiver flowgraphs lose GPS lock, although clock reference leds in the
>> USRP panel are ON.
>>
>> Thanks,
>> George
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: Random test failures when compiling GNURadio from source

[Kevin George]

Hello,

We have been trying to compile and run GNURadio from source and the make
tests have been failing randomly.

*Machine Details*

*Intel NUC (x86-64 machine)*
*Ubuntu 16.04.03*
*GNU Radio version 3.7.11*
*gcc version 5.4.0 20160609 *

*Commands used*
*git clone --recursive https://github.com/gnuradio/gnuradio
*

*git checkout v3.7.11*

*mkdir build*

*cd build*

*cmake -DENABLE_GR_QTGUI=OFF -DCMAKE_INSTALL_PREFIX=/usr/local ../*

*make -j4*
*make test*

Out of every 4 compilations, 1/2 would fail the make test e.g
qa_constellation_receiver(attached
error with email) or
qa_ofdm_sync_sc_cfb. Our fix so far has been to* re-run the build with no
modifications and the tests pass*.

I have seen similar errors pop up in the mailing lists and the cause is
usually incorrect setting of seed.
e.g
https://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00318.html
Does this issue still persist? or known?


-- 
Regards
Kevin
151/213 Testing: qa_constellation_receiver
151/213 Test: qa_constellation_receiver
Command: "/bin/sh" 
"/tmp/workarea-gnuradio/gnuradio/build/gr-digital/python/digital/qa_constellation_receiver_test.sh"
Directory: /tmp/workarea-gnuradio/gnuradio/build/gr-digital/python/digital
"qa_constellation_receiver" start time: Oct 30 19:53 UTC
Output:
--
F.
==
FAIL: test_basic (__main__.test_constellation_receiver)
--
Traceback (most recent call last):
  File 
"/tmp/workarea-gnuradio/gnuradio/gr-digital/python/digital/qa_constellation_receiver.py",
 line 132, in test_basic
self.assertTrue(correct > req_correct)
AssertionError: False is not true

--
Ran 2 tests in 0.725s

FAILED (failures=1)
Constellation is . Differential is True.  
Required correct is 0.8. Correct is 0.773026315789. FAIL.

Test time =   1.62 sec
--
Test Failed.
"qa_constellation_receiver" end time: Oct 30 19:53 UTC
"qa_constellation_receiver" time elapsed: 00:00:01
--
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ImportError: cannot import name QObject

[George Rykowski]

This issue started Thursday (8/16/2018) after I performed software updates via 
macports. While running gnuradio-companion, I run my code (which was running 
fine for weeks) and now get this error:

 

Generating: '/Users/georgerykowski/Documents/GNUradio/TCM_with_ENG_2MS.py'

 

Executing: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u /Users/georgerykowski/Documents/GNUradio/TCM_with_ENG_2MS.py

 

Traceback (most recent call last):

  File "/Users/georgerykowski/Documents/GNUradio/TCM_with_ENG_2MS.py", line 20, 
in 

    from PyQt4.QtCore import QObject, pyqtSlot

ImportError: cannot import name QObject

 

>>> Done (return code 1)

 

When I try running another program, I get this error:

 

Executing: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u /Users/georgerykowski/Documents/GNUradio/ENG_file_run_USRP.py

 

Traceback (most recent call last):

  File "/Users/georgerykowski/Documents/GNUradio/ENG_file_run_USRP.py", line 
33, in 

    from gnuradio import qtgui

  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/qtgui/__init__.py",
 line 37, in 

    from range import Range, RangeWidget

  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/qtgui/range.py",
 line 67, in 

    class RangeWidget(QtGui.QWidget):

AttributeError: 'module' object has no attribute 'QWidget'

 

>>> Done (return code 1)

 

The error appear to occur in the GUI code. A colleague of mine updated his code 
and the same issue appeared, so I suspect others have seen this. Have others 
seen this, or similar issues? If yes, is there a workaround? Am I bringing the 
issue to the proper discussion forum (e.g. should I go to a Python group)?

 

I am running MacOS 10.13.6

 

Thank you

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

Re: [Discuss-gnuradio] ImportError: cannot import name QObject

[George Rykowski]

Hi Adrian,

 

I am using a MacBook Pro and assume am running the ‘standard’ Apple version of 
Python (version 2.7.10).

 

George

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

Re: [Discuss-gnuradio] ImportError: cannot import name QObject

[George Rykowski]

Michael,

 

Thank you!

 

George

 

From: Michael Dickens 
Date: Tuesday, August 21, 2018 at 12:08 PM
To: George Rykowski , 
Subject: Re: [Discuss-gnuradio] ImportError: cannot import name QObject

 

Hi George - Yes this is a known issue that I'm working on; see also < 
https://trac.macports.org/ticket/56993 >. On this ticket is provided a way to 
revert back to the prior PyQt4 release that doesn't have this issue. We'll get 
a fix in place as soon as we can. - MLD

 

On Tue, Aug 21, 2018, at 12:34 PM, George Rykowski wrote:

This issue started Thursday (8/16/2018) after I performed software updates via 
macports. While running gnuradio-companion, I run my code (which was running 
fine for weeks) and now get this error:

 

Generating: '/Users/georgerykowski/Documents/GNUradio/TCM_with_ENG_2MS.py'

 

Executing: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u /Users/georgerykowski/Documents/GNUradio/TCM_with_ENG_2MS.py

 

Traceback (most recent call last):

  File "/Users/georgerykowski/Documents/GNUradio/TCM_with_ENG_2MS.py", line 20, 
in 

from PyQt4.QtCore import QObject, pyqtSlot

ImportError: cannot import name QObject

 

>>> Done (return code 1)

 

When I try running another program, I get this error:

 

Executing: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 -u /Users/georgerykowski/Documents/GNUradio/ENG_file_run_USRP.py

 

Traceback (most recent call last):

  File "/Users/georgerykowski/Documents/GNUradio/ENG_file_run_USRP.py", line 
33, in 

from gnuradio import qtgui

  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/qtgui/__init__.py",
 line 37, in 

from range import Range, RangeWidget

  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/qtgui/range.py",
 line 67, in 

class RangeWidget(QtGui.QWidget):

AttributeError: 'module' object has no attribute 'QWidget'

 

>>> Done (return code 1)

 

The error appear to occur in the GUI code. A colleague of mine updated his code 
and the same issue appeared, so I suspect others have seen this. Have others 
seen this, or similar issues? If yes, is there a workaround? Am I bringing the 
issue to the proper discussion forum (e.g. should I go to a Python group)?

 

I am running MacOS 10.13.6

 

Thank you

___

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] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

[George Rykowski]

I have been seeing this error regularly for a couple weeks. As I am running my 
code, the error stops execution, on average, approximately every 10 minutes 
(though, once or twice, I have received the error quickly in sequence). My code 
is simple: I am reading in a recorded waveform (using File Source) and sending, 
over USB3, to a USRP B210 for transmission (using UHD: USRP Sink). 

 

libc++abi.dylib: terminating with uncaught exception of type uhd::usb_error: 
RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

 

>>> Done (return code -6)

 

My laptop is a MacBook Pro 2018 using MacOS High Sierra version 10.13.6, and 
running GNUradio Companion 3.7.13.4.

 

Has anyone seen this error? If yes, any hints as to how I can fix?

 

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

Re: [Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

[George Rykowski]

Michael, thank you for the response. I’ve discovered the issue and it is the 
USB-C adapter I was using for the USB connection to the USRP B210. The MacBook 
Pro 2018 provides 4 USB-C ports, so adapters are generally required. I was 
using the following:

 

https://www.amazon.com/gp/product/B07BGTV9J4/ref=ask_ql_qh_dp_hza 

 

Even though it uses 2 USB-C ports to provide power and connectivity, for some 
reason the adapter would occasionally force an I/O error on the USB interface. 
I am now using the following Apple adapter, which has worked flawlessly:

 

https://www.apple.com/shop/product/MJ1K2AM/A/usb-c-digital-av-multiport-adapter 

 

 

From: Michael Dickens 
Date: Monday, August 27, 2018 at 3:15 PM
To: George Rykowski , 
Subject: Re: [Discuss-gnuradio] uhd::usb_error: RuntimeError: USBError -9: usb 
tx2 submit failed: LIBUSB_ERROR_PIPE

 

Hi George - I haven't seen this error yet, but of course I'm just one Mac UHD / 
GR user; I'll try testing my B210 for longer. In the meantime, how is UHD & GR 
installed? If MacPorts, have you tried the "uhd-devel" port? Sometimes it has 
fixes to the release. - MLD

 

On Mon, Aug 27, 2018, at 3:46 PM, George Rykowski wrote:

I have been seeing this error regularly for a couple weeks. As I am running my 
code, the error stops execution, on average, approximately every 10 minutes 
(though, once or twice, I have received the error quickly in sequence). My code 
is simple: I am reading in a recorded waveform (using File Source) and sending, 
over USB3, to a USRP B210 for transmission (using UHD: USRP Sink). 

 

libc++abi.dylib: terminating with uncaught exception of type uhd::usb_error: 
RuntimeError: USBError -9: usb tx2 submit failed: LIBUSB_ERROR_PIPE

 

>>> Done (return code -6)

 

My laptop is a MacBook Pro 2018 using MacOS High Sierra version 10.13.6, and 
running GNUradio Companion 3.7.13.4.

 

Has anyone seen this error? If yes, any hints as to how I can fix?

 

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

[Discuss-gnuradio] Can I use PyBOMBS with a macport installed GNU Radio?

[George Rykowski]

Hello,

 

I have a need to install the FMComms2/3/4 source block in order to access my 
Zedboard/AD9361 SDR from my Macbook Pro. I see the gr-iio package on CGRAN. Can 
I install PyBOMBS, then install gr-iio, into my GNU radio that was built using 
macports?

 

TIA, George

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

Re: [Discuss-gnuradio] Can I use PyBOMBS with a macport installed GNU Radio?

[George Rykowski]

Michael,

 

Thank you. Everything works as expected!

 

George

 

From: Discuss-gnuradio  
on behalf of Michael Dickens 
Date: Tuesday, March 12, 2019 at 2:06 PM
To: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] Can I use PyBOMBS with a macport installed GNU 
Radio?

 

gr-iio is in MacPorts ... and if you need something related to GR ping me & we 
can work together to make it happen. - MLD

 

On Tue, Mar 12, 2019, at 3:05 PM, George Rykowski wrote:

Hello,

 

I have a need to install the FMComms2/3/4 source block in order to access my 
Zedboard/AD9361 SDR from my Macbook Pro. I see the gr-iio package on CGRAN. Can 
I install PyBOMBS, then install gr-iio, into my GNU radio that was built using 
macports?

 

TIA, George

___

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] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'

[George Refseth]

On 01/08/2014 04:19 PM, ikjtel wrote:
OK, this error seems to be all fixed now, but as a result I now have a 
doubt about pybombs .


[The background of the problem is in the previous posting (yesterday) 
about this, but essentially the problem started when I changed the 
pybombs recipe for libusb in order to force pybombs to build libusb 
from source rather than to use the libusb-1.0-0-dev (that was 
originally set in "satisfy_deb"). ]


Once this was changed, pybombs did in fact fetch the libusb source and 
built that - however, subsequent compiles were still looking in 
/usr/include for the .h files (and finding the old, bad ones).  I 
bypassed that error.


Then the linker also bombed out, again where pybombs should have 
looked in its own built-from-source copy of libusb.  At that point I 
posted the first message about the linker problem late last night...


Same problem with libfaad2, fix recipe, and fix the cmake file that set 
up where to look for both header files and library.
That was your solution also? Btw. I was working with gr-drm in a pybombs 
environment.


regards
George



I offer the following message as 'documentation' of the claim that 
pybombs is still trying to link against the system copy of libusb and 
not its own local copy of libusb that it built from source...  Note 
that it prints the library location...


make[2]: *** No rule to make target 
`/usr/lib/x86_64-linux-gnu/libusb-1.0.so', needed by 
`gr-fcd/lib/libgnuradio-fcd-3.7.3git.so.0.0.0'.  Stop.


After I fixed that, gnuradio compiled cleanly under pybombs...

Best

Max




___
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] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'

[George Refseth]

On 01/08/2014 04:19 PM, ikjtel wrote:
OK, this error seems to be all fixed now, but as a result I now have a 
doubt about pybombs .


[The background of the problem is in the previous posting (yesterday) 
about this, but essentially the problem started when I changed the 
pybombs recipe for libusb in order to force pybombs to build libusb 
from source rather than to use the libusb-1.0-0-dev (that was 
originally set in "satisfy_deb"). ]


Once this was changed, pybombs did in fact fetch the libusb source and 
built that - however, subsequent compiles were still looking in 
/usr/include for the .h files (and finding the old, bad ones).  I 
bypassed that error.


Then the linker also bombed out, again where pybombs should have 
looked in its own built-from-source copy of libusb.  At that point I 
posted the first message about the linker problem late last night...


I offer the following message as 'documentation' of the claim that 
pybombs is still trying to link against the system copy of libusb and 
not its own local copy of libusb that it built from source...  Note 
that it prints the library location...


Same problem with libfaad2, fix recipe, and fix the cmake file that set 
up where to look for both header files and library.

That was your solution also?

regards
George



make[2]: *** No rule to make target 
`/usr/lib/x86_64-linux-gnu/libusb-1.0.so', needed by 
`gr-fcd/lib/libgnuradio-fcd-3.7.3git.so.0.0.0'.  Stop.


After I fixed that, gnuradio compiled cleanly under pybombs...

Best

Max




___
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] followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'

[George Refseth]

On 01/08/2014 06:17 PM, ikjtel wrote:


On Jan. 8, 2013, George wrote:
> Same problem with libfaad2, fix recipe, and fix the cmake file that
> set up where to look for both header files and library.
> That was your solution also?

Hate to admit, was in a hurry so I just nuked the system library copy, 
and replaced it with the ones that pybombs compiled.  That worked, but 
not anywhere near as cleanly as the solution you've outlined... :-/


Did not work the way I expected either, had to uninstall the system 
variant before cmake found that it could actually use the variant I put 
first.
I reran from cmake, but it resolved to the system header files and lib, 
and I don't understand why.
The recipe is included below, while the cmake file is here: 
https://github.com/rfz-com/gr-drm/commit/0f062bb97b1e742b829260653418c64520c4ee1d


faad2.lwr
---
category: baseline
source: wget://http://downloads.sourceforge.net/faac/faad2-2.7.tar.gz
satisfy_deb: libfaad-dev
#satisfy_rpm: faad2-devel
configure {
 . bootstrap
 ./configure --without-xmms --with-drm --without-mpeg4ip --with-pic
}
install {
 make
 cp include/faad.h include/neaacdec.h $prefix/include
 cp libfaad/.libs/libfaad.a $prefix/lib
 cp libfaad/.libs/libfaad.a $prefix/lib64
}




Best

Max


___
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] Problem with undefined symbol in new block created by gr_modtool in 3.7.2

[George Sklivanitis]

Hello all,

I am dealing with the problem of undefined symbol when trying to execute a
python script for testing my new custom block created in GNU Radio 3.7.2.
I used gr_modtool for creating the new block and also followed the
instructions posted at

http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig

for correctly configuring it but the problem still holds.

Any ideas?

Thanks,
-George

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

[Discuss-gnuradio] embedding

[George Refseth]

Hi

Anyone with input as to the feasibility of maintaining either gnu-radio 
or math-lab design and have something embeddable without pulling the 
whole environment into the target? Generating c or c++ to be compiled 
for the target with or without a real-time os.


What I foresee as a problem is the transfer of design from modelling to 
run-time, and that becomes a one-way road and only done once so that one 
looses the value of the model be it gnu-radio or math-lab based.


best regards,
George Refseth

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

[Discuss-gnuradio] CGRAN down, working on it

[George Nychis]

It looks like CGRAN is down for some reason.  The machine that hosts it is
still up and I haven't found the cause of the problem yet.  Still digging.

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

Re: [Discuss-gnuradio] CGRAN down, working on it

[George Nychis]

Something must have been upgraded on the machine, and a significant number
of the dependencies needed to run Trac have disappeared.  For example,
python has disappeared from the machine :P

This might take a while, sorry.


On Sat, May 3, 2014 at 1:15 PM, George Nychis  wrote:

> It looks like CGRAN is down for some reason.  The machine that hosts it is
> still up and I haven't found the cause of the problem yet.  Still digging.
>
> - George
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CGRAN down, working on it

[George Nychis]

We are almost back up completely.  Everything is back in place except for
the Trac browser for the SVN code.  The SVN server is still accessible and
all of the wiki is back up and running.  Just need to get the SVN browser
working again... let me know if anyone else finds any issues.


On Sat, May 3, 2014 at 1:58 PM, George Nychis  wrote:

> Something must have been upgraded on the machine, and a significant number
> of the dependencies needed to run Trac have disappeared.  For example,
> python has disappeared from the machine :P
>
> This might take a while, sorry.
>
>
> On Sat, May 3, 2014 at 1:15 PM, George Nychis  wrote:
>
>> It looks like CGRAN is down for some reason.  The machine that hosts it
>> is still up and I haven't found the cause of the problem yet.  Still
>> digging.
>>
>> - George
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

The machine that runs CGRAN down in some basement somewhere at Carnegie
Mellon has hit some issues again.  Given that I'm no longer at the
university, these issues are becoming harder for me to address.  At this
point, it's probably best for CGRAN to "move on" as we've all been in
discussion about over time.

What I can do if everyone still finds CGRAN useful is:

   1.  Provide a more reliable host and machine for it
   2.  Update it to be more useful to the community (e.g., more towards git)

It still gets a lot of hits (~16,000 a month) and every time it goes down
people hunt me down and ask when it's coming back up.  So it seems as
though the community still uses it.

I can update it with Pybombs or Gitlib or whatever people feel is
appropriate.  It can be more of a portal page even, without a repository if
most people just use Github now anyway.  Do people still like it is a
standalone service, or is it better to just "roll it in" to the GNU Radio
webpage somewhere now?  I want to do whatever the community finds is most
useful.

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

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

Thanks for the feedback, Chris and Martin.  What I'm going to do is keep
CGRAN down until we have some sort of plan/resolution and use it as a form
of motivation.  Every time I've managed to resurrect CGRAN from the dead, I
just leave it go and forget about it for some time again.  I think that the
down time might help us come to a conclusion sooner.

Several people have e-mailed me about access to the repository.  I was able
to get the repo back up, and it should be anonymously readable here:
https://www.cgran.org/svn/projects

To address Chris' thoughts, I've always felt CGRAN was useful in two
aspects:  1) To find useful and up-to-date projects (albeit rare), and 2)
To find more historical projects that highlight the capabilities of GNU
Radio and SDRs and to resurrect and/or build from them.  I know the latter
has been a killer, but I've found multiple times that people came to CGRAN
to dig up old code and build something new from it.  But if anything, these
two types of projects need to be clearly marked and separated.
Academically, I know that students are very willing to take brutally dead
code and use pieces of it for projects.

Maintenance over time is simply just difficult.  Once projects are
complete, many people move on but GNU Radio keeps on chugging.  I know that
I lost time to maintain my projects.  Pybombs could at least guide the user
to get correct versions, let them know there is a mismatch, etc.  It can
also provide the link from a project to where the actual code and
repository are.  I think that pybomb entries can point to github locations,
right?

On Mon, Sep 29, 2014 at 2:07 PM, Martin Braun 
wrote:

> This is something that comes up at our dev calls (and other dev meetings)
> regularly, and we really need to address it sooner rather than later.
>
> George, if the support burden is getting to much, we can surely fix a
> short-term solution by migrating stuff to some temporary location (let's
> take this specific discussion offline, though).
>
> In the future, we'd like to have something that ties in nicely with
> Pybombs, and also uses the gits. How exactly, that's something we need to
> decide, and any community input on this is appreciated.
>
> Cheers,
> M
>
>
> On 29.09.2014 11:01, George Nychis wrote:
>
>> The machine that runs CGRAN down in some basement somewhere at Carnegie
>> Mellon has hit some issues again.  Given that I'm no longer at the
>> university, these issues are becoming harder for me to address.  At this
>> point, it's probably best for CGRAN to "move on" as we've all been in
>> discussion about over time.
>>
>> What I can do if everyone still finds CGRAN useful is:
>>
>> 1.  Provide a more reliable host and machine for it
>> 2.  Update it to be more useful to the community (e.g., more towards
>> git)
>>
>> It still gets a lot of hits (~16,000 a month) and every time it goes
>> down people hunt me down and ask when it's coming back up.  So it seems
>> as though the community still uses it.
>>
>> I can update it with Pybombs or Gitlib or whatever people feel is
>> appropriate.  It can be more of a portal page even, without a repository
>> if most people just use Github now anyway.  Do people still like it is a
>> standalone service, or is it better to just "roll it in" to the GNU
>> Radio webpage somewhere now?  I want to do whatever the community finds
>> is most useful.
>>
>> Thanks!
>> George
>>
>>
>> ___
>> 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] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

Marcus, thanks for keeping up-to-date projects on CGRAN!  Since you've
always been actively involved, what would you like to see different and/or
improved?  It can still be the place where your projects live, I am just
trying to make CGRAN more friendly to changes in the current community and
to be more supportive of newer projects.  The clear example has always been
making it more git-centric.

On Mon, Sep 29, 2014 at 2:37 PM, Marcus D. Leech  wrote:

>  On 09/29/2014 05:31 PM, George Nychis wrote:
>
> Thanks for the feedback, Chris and Martin.  What I'm going to do is keep
> CGRAN down until we have some sort of plan/resolution and use it as a form
> of motivation.  Every time I've managed to resurrect CGRAN from the dead, I
> just leave it go and forget about it for some time again.  I think that the
> down time might help us come to a conclusion sooner.
>
>  Several people have e-mailed me about access to the repository.  I was
> able to get the repo back up, and it should be anonymously readable here:
> https://www.cgran.org/svn/projects
>
>  To address Chris' thoughts, I've always felt CGRAN was useful in two
> aspects:  1) To find useful and up-to-date projects (albeit rare), and 2)
> To find more historical projects that highlight the capabilities of GNU
> Radio and SDRs and to resurrect and/or build from them.  I know the latter
> has been a killer, but I've found multiple times that people came to CGRAN
> to dig up old code and build something new from it.  But if anything, these
> two types of projects need to be clearly marked and separated.
> Academically, I know that students are very willing to take brutally dead
> code and use pieces of it for projects.
>
>  Maintenance over time is simply just difficult.  Once projects are
> complete, many people move on but GNU Radio keeps on chugging.  I know that
> I lost time to maintain my projects.  Pybombs could at least guide the user
> to get correct versions, let them know there is a mismatch, etc.  It can
> also provide the link from a project to where the actual code and
> repository are.  I think that pybomb entries can point to github locations,
> right?
>
> On Mon, Sep 29, 2014 at 2:07 PM, Martin Braun 
> wrote:
>
>> This is something that comes up at our dev calls (and other dev meetings)
>> regularly, and we really need to address it sooner rather than later.
>>
>> George, if the support burden is getting to much, we can surely fix a
>> short-term solution by migrating stuff to some temporary location (let's
>> take this specific discussion offline, though).
>>
>> In the future, we'd like to have something that ties in nicely with
>> Pybombs, and also uses the gits. How exactly, that's something we need to
>> decide, and any community input on this is appreciated.
>>
>> Cheers,
>> M
>>
>>I have projects on CGRAN that are actively maintained.  Most notably,
> simple-ra.  But also, simple_fm_rcv, meteor_detector, multimode, and
> SIDSuite.
>
> While I'm willing to find another place for them, it's, as one might
> expect, a pain
>
>
>
>
>> On 29.09.2014 11:01, George Nychis wrote:
>>
>>>  The machine that runs CGRAN down in some basement somewhere at Carnegie
>>> Mellon has hit some issues again.  Given that I'm no longer at the
>>> university, these issues are becoming harder for me to address.  At this
>>> point, it's probably best for CGRAN to "move on" as we've all been in
>>> discussion about over time.
>>>
>>> What I can do if everyone still finds CGRAN useful is:
>>>
>>> 1.  Provide a more reliable host and machine for it
>>> 2.  Update it to be more useful to the community (e.g., more towards
>>> git)
>>>
>>> It still gets a lot of hits (~16,000 a month) and every time it goes
>>> down people hunt me down and ask when it's coming back up.  So it seems
>>> as though the community still uses it.
>>>
>>> I can update it with Pybombs or Gitlib or whatever people feel is
>>> appropriate.  It can be more of a portal page even, without a repository
>>> if most people just use Github now anyway.  Do people still like it is a
>>> standalone service, or is it better to just "roll it in" to the GNU
>>> Radio webpage somewhere now?  I want to do whatever the community finds
>>> is most useful.
>>>
>>> Thanks!
>>> George
>>>
>>>
>>>   ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>&

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

I agree with Martin that once we go to git, every project has its own
independent repo.  That shouldn't take much time at all to do, I can just
run some svn2git magic to spit out separate repositories.  The question
will be where those repositories live.  I can host the repositories again.
I could replace the tired Trac interface with Gitlab and then host the
repositories locally and through there.  If that's the case, Github
repositories could be forked in Gitlab and/or point to the Github repos?
(e.g., for people who only want their code on Github).  I think the
downside of Gitlab is that it doesn't seem to be very customizable to, for
example, have a coherent single Wiki of some sort like Trac dd.  It will be
a bunch of separate Wikis buried in to each separate repository's page.

So I think we are agreeing so far on git with multiple repositories for
each project.  What we need to figure out is what the frontend is.

On Mon, Sep 29, 2014 at 3:47 PM, Martin Braun 
wrote:

> On 29.09.2014 14:55, Marcus D. Leech wrote:
>
>> I have no religious convictions about git vs svn.
>>
>> I'd have to change a couple of scripts [...]
>>
>
> When CGRAN was inaugurated, github wasn't as popular as it was (and GNU
> Radio was still on SVN itself). We would not have gone for a central SVN
> repo if github had been on our radar back then.
>
> I guess most people either share Marcus' sentiment, or are biased towards
> git. So, ditching SVN is pretty much a no-brainer.
>
> However, one major difference between SVN and git is that the latter
> doesn't have the concept of every dir being a repo in and of itself.
> This means if we simply pushed everything to a giant github repo, that
> would not be terribly useful (definitely not a replacement for CGRAN),
> although I can see that being a temp solution so that at the very least,
> nothing is lost (a big advantage of using github is that they're less
> likely to lose data).
>
> Really, every CGRAN project should be pulled into it's own little repo,
> e.g. on github. Migrating from SVN to git is really easy (even with
> preserving history and all). I guess we could put up instructions on how to
> do that if there's popular demand.
>
> However, there's also the wiki pages on CGRAN. We do need a strategy for
> those (and a way to access them).
>
> Keep the ideas and comments coming, people!
>
> Cheers,
>
> M
>
> ___
> 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] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

Marcus,  I like the idea of an uber-repo with external submodules.  That
would mean these submodules could link to a repo we could provide the user,
a repo they already have on github, or a repo they have on some other
external server.  But in the end, our uber repo would point to all of them
and then they could update the commit that external submodule points to
over time.  Thanks for that suggestion.

Rick, thanks for this suggestion also!  I will make sure that we are able
to include some sort of snapshot.  When you say snapshot here, does that
act as some sort of release or history?  It must be different than a tag,
since you say tags are part of a snapshot.  Can you give me an example
snapshot provided by some other service?

On Thu, Oct 2, 2014 at 7:51 AM, Marcus Müller 
wrote:

>  Hi everyone,
>
> that seems to be a nice solution you're proposing, George. What about
> having a uber-repo that uses external submodules? This way, you could have
> your single CGRAN repo, with all the packages as submodules, some
> documentation in a single wiki, all per gitlab, and just keep the projects
> as independent repos, hosted on a cgran machine or on
> github/osmocom/wherever. We get the functionality to backup "all the GNU
> Radio ecosystem" at once by running some git submodule update command, and
> pybombs could just clone that repo, and init submodules as the user
> installs them.
>
> Greetings,
> Marcus
>
>
> On 30.09.2014 01:00, George Nychis wrote:
>
> I agree with Martin that once we go to git, every project has its own
> independent repo.  That shouldn't take much time at all to do, I can just
> run some svn2git magic to spit out separate repositories.  The question
> will be where those repositories live.  I can host the repositories again.
> I could replace the tired Trac interface with Gitlab and then host the
> repositories locally and through there.  If that's the case, Github
> repositories could be forked in Gitlab and/or point to the Github repos?
> (e.g., for people who only want their code on Github).  I think the
> downside of Gitlab is that it doesn't seem to be very customizable to, for
> example, have a coherent single Wiki of some sort like Trac dd.  It will be
> a bunch of separate Wikis buried in to each separate repository's page.
>
> So I think we are agreeing so far on git with multiple repositories for
> each project.  What we need to figure out is what the frontend is.
>
> On Mon, Sep 29, 2014 at 3:47 PM, Martin Braun  
> 
> wrote:
>
>
>  On 29.09.2014 14:55, Marcus D. Leech wrote:
>
>
>  I have no religious convictions about git vs svn.
>
> I'd have to change a couple of scripts [...]
>
>
>  When CGRAN was inaugurated, github wasn't as popular as it was (and GNU
> Radio was still on SVN itself). We would not have gone for a central SVN
> repo if github had been on our radar back then.
>
> I guess most people either share Marcus' sentiment, or are biased towards
> git. So, ditching SVN is pretty much a no-brainer.
>
> However, one major difference between SVN and git is that the latter
> doesn't have the concept of every dir being a repo in and of itself.
> This means if we simply pushed everything to a giant github repo, that
> would not be terribly useful (definitely not a replacement for CGRAN),
> although I can see that being a temp solution so that at the very least,
> nothing is lost (a big advantage of using github is that they're less
> likely to lose data).
>
> Really, every CGRAN project should be pulled into it's own little repo,
> e.g. on github. Migrating from SVN to git is really easy (even with
> preserving history and all). I guess we could put up instructions on how to
> do that if there's popular demand.
>
> However, there's also the wiki pages on CGRAN. We do need a strategy for
> those (and a way to access them).
>
> Keep the ideas and comments coming, people!
>
> Cheers,
>
> M
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

Let me add one more thing about CGRAN while we are still trying to narrow
down how to handle this.  One reason I put CGRAN in place was to host code
that might "disappear."  For example, students post it on university
webpages and when they graduate, that hosting gets taken down.
Additionally, someone creates an account on some code hosting service, and
the project later gets taken down.  That was the "archive" part of cgrAn.
I guess the more we talk about just linking to a bunch of things, I wonder
if we will lose one of those initial goals.

On Mon, Oct 6, 2014 at 10:15 AM, West, Nathan 
wrote:

> On Mon, Oct 6, 2014 at 1:43 AM, Bastian Bloessl 
> wrote:
> > On 10/06/2014 08:21 AM, Martin Braun wrote:
> >>
> >> but I don't really like this except as a temporary/transition solution.
> >> Assume CGRAN really takes off and grows. Do you really want all OOTs out
> >> there in a single repo? What exactly is their logical connection, which
> >> would warrant them all being tied together in a super-repo?
> >> This would require someone to keep updating the submodules, too, which
> >> seems unnecessary.
> >
> >
> >
> >>
> >> In the long run, I would assume people want to host their OOTs on github
> >> (or similar services), and CGRAN would simply be a link to those.
> >> As I said, during a transition time, we might want something else.
> >> But submodules are messy, and I suggest not using them for this
> >> particular application.
> >
> >
> > Since, git 1.8.2 a git submodule can track a branch [1] (as opposed to
> > pointing to a commit). That means that it is not necessary to update the
> > submodules in the super-repo. A submodule is very similar to a pybombs
> > recipe, a link to a repo and a branch.
> > Most likely most of the repos (i.e. GNU Radio apps/modules) will be
> hosted
> > at github or similar services. So nothing would change for the authors of
> > the modules. (That's at least my understanding of the proposed solution)
> >
> >
> > Best,
> > Bastian
> >
> >
> > [1]
> >
> https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186
>
>
> My $0.02 cents on CGRAN:
>
> Having a directory of projects along with metadata such as author name
> and contact, status, GR API version compatibility, etc along with a
> source mirror and link to origin is really valuable. From this
> perspective I like CCAN: they have a 'package' format so they can
> parse and display that metadata in a convenient way on their web site
> (for an example see http://ccodearchive.net/info/cpuid.html ). We can
> use gr_modtool to either fill in a mod_info type file or request
> authors put data in their README in a nice way. Then CGRAN can display
> all of the project information, potentially provide a mirror, and
> point to the original source.
>
> I agree with Martin that the super-repo feels weird in the sense that
> there is no shared history or relationship between the histories of
> each project. If the goal is to make it easy to clone all projects at
> once then pybombs almost does that already and it's very easy to
> modify (actually it's probably a bug that pybombs fetch doesn't work
> with --all). I do think it is convenient/useful to have a single
> base-URI to get all OOT modules from assuming someone doesn't mind
> paying for the bandwidth to have people constantly downloading OOT
> projects. Also, what happens to a submodule if the origin disappears
> (for example someone loses interest and eventually deletes their
> github repo)?
>
> Nathan.
>
> ___
> 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] CGRAN down indefinitely, but hopefully not for long (want feedback)

[George Nychis]

Interesting, Chris.  Thanks for that info.  The question would be, do we
mirror everything?  It seems like that's a possibility.  It's nothing I
think I could automatically set up.  I typically have left it up to the
authors to decide given their software license.

On Mon, Oct 6, 2014 at 10:28 AM, Chris Kuethe 
wrote:

> It looks like github can mirror another git repo. It looks like mirrors
> don't update automatically; the docs suggest using a cron job to automate,
> so if the hypothetical grad student's repository goes away the CGRAN
> version could remain at the last published version.
>
>
> On Mon, Oct 6, 2014 at 10:22 AM, George Nychis  wrote:
>
>> Let me add one more thing about CGRAN while we are still trying to narrow
>> down how to handle this.  One reason I put CGRAN in place was to host code
>> that might "disappear."  For example, students post it on university
>> webpages and when they graduate, that hosting gets taken down.
>> Additionally, someone creates an account on some code hosting service, and
>> the project later gets taken down.  That was the "archive" part of cgrAn.
>> I guess the more we talk about just linking to a bunch of things, I wonder
>> if we will lose one of those initial goals.
>>
>> On Mon, Oct 6, 2014 at 10:15 AM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>> On Mon, Oct 6, 2014 at 1:43 AM, Bastian Bloessl 
>>> wrote:
>>> > On 10/06/2014 08:21 AM, Martin Braun wrote:
>>> >>
>>> >> but I don't really like this except as a temporary/transition
>>> solution.
>>> >> Assume CGRAN really takes off and grows. Do you really want all OOTs
>>> out
>>> >> there in a single repo? What exactly is their logical connection,
>>> which
>>> >> would warrant them all being tied together in a super-repo?
>>> >> This would require someone to keep updating the submodules, too, which
>>> >> seems unnecessary.
>>> >
>>> >
>>> >
>>> >>
>>> >> In the long run, I would assume people want to host their OOTs on
>>> github
>>> >> (or similar services), and CGRAN would simply be a link to those.
>>> >> As I said, during a transition time, we might want something else.
>>> >> But submodules are messy, and I suggest not using them for this
>>> >> particular application.
>>> >
>>> >
>>> > Since, git 1.8.2 a git submodule can track a branch [1] (as opposed to
>>> > pointing to a commit). That means that it is not necessary to update
>>> the
>>> > submodules in the super-repo. A submodule is very similar to a pybombs
>>> > recipe, a link to a repo and a branch.
>>> > Most likely most of the repos (i.e. GNU Radio apps/modules) will be
>>> hosted
>>> > at github or similar services. So nothing would change for the authors
>>> of
>>> > the modules. (That's at least my understanding of the proposed
>>> solution)
>>> >
>>> >
>>> > Best,
>>> > Bastian
>>> >
>>> >
>>> > [1]
>>> >
>>> https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186
>>>
>>>
>>> My $0.02 cents on CGRAN:
>>>
>>> Having a directory of projects along with metadata such as author name
>>> and contact, status, GR API version compatibility, etc along with a
>>> source mirror and link to origin is really valuable. From this
>>> perspective I like CCAN: they have a 'package' format so they can
>>> parse and display that metadata in a convenient way on their web site
>>> (for an example see http://ccodearchive.net/info/cpuid.html ). We can
>>> use gr_modtool to either fill in a mod_info type file or request
>>> authors put data in their README in a nice way. Then CGRAN can display
>>> all of the project information, potentially provide a mirror, and
>>> point to the original source.
>>>
>>> I agree with Martin that the super-repo feels weird in the sense that
>>> there is no shared history or relationship between the histories of
>>> each project. If the goal is to make it easy to clone all projects at
>>> once then pybombs almost does that already and it's very easy to
>>> modify (actually it's probably a bug that pybombs fetch doesn't work
>>> with --all). I do think it is convenient/useful to have a single
>>> base-URI to get all OOT modules from assuming someone doesn't mind
>>> paying for the bandwidth to have people constantly downloading OOT
>>> projects. Also, what happens to a submodule if the origin disappears
>>> (for example someone loses interest and eventually deletes their
>>> github repo)?
>>>
>>> Nathan.
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] how to learn of decimation rate in general_work() ?

[George Nychis]

I am using stream tags to get the timestamp of its corresponding sample in
general_work().  Now, if I want to calculate the time of an arbitrary
sample in the incoming sample stream I need to know the decimation rate.
 This tells me how much clock time is added per-sample.  So I can calculate
the offset between the timestamped sample and the sample I care about, and
then multiple that offset by the time per sample.

Is there a good way to learn of the decimation rate in general_work() to do
this?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] not getting timestamps from UHD received stream tags

[George Nychis]

I am trying to read incoming RX timestamps from the UHD sample stream.  I'd
like to calculate the approximate time a preamble is received in the OFDM
code.

The issue is that, despite getting incoming frames and preambles, I do not
seem to be getting timestamp values.  I use get_tags_in_range() on
"rx_time":
https://github.com/gnychis/grforwarder/blob/8f8c4e6cf79a2d635a0eb3bcad9b5ab325f1e373/gr-digital/lib/digital_ofdm_sampler.cc#L78

However, the size of the rx_time tags is consistently zero:
https://github.com/gnychis/grforwarder/blob/8f8c4e6cf79a2d635a0eb3bcad9b5ab325f1e373/gr-digital/lib/digital_ofdm_sampler.cc#L99

The output of the OFDM receiver code:
ok: True pktno: 637  n_rcvd: 18  n_right: 17
got a preamble, size of time_tags: 0
ok: True pktno: 638  n_rcvd: 19  n_right: 18
got a preamble, size of time_tags: 0
ok: True pktno: 639  n_rcvd: 20  n_right: 19
got a preamble, size of time_tags: 0
...

Is there something I am missing to enable the RX timestamp on the incoming
samples, or am I not properly reading the stream tag?  My branch came from
the GR master 4 days ago (309ca769af).

Thanks a bunch.

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

Re: [Discuss-gnuradio] not getting timestamps from UHD received stream tags

[George Nychis]

Bingo, didn't realize they were only incoming at those points in time.
 Problem solved, thanks Josh!

On Mon, Feb 6, 2012 at 9:18 PM, Josh Blum  wrote:

>
>
> On 02/06/2012 06:13 PM, George Nychis wrote:
> > I am trying to read incoming RX timestamps from the UHD sample stream.
>  I'd
> > like to calculate the approximate time a preamble is received in the OFDM
> > code.
> >
> > The issue is that, despite getting incoming frames and preambles, I do
> not
> > seem to be getting timestamp values.  I use get_tags_in_range() on
> > "rx_time":
> >
> https://github.com/gnychis/grforwarder/blob/8f8c4e6cf79a2d635a0eb3bcad9b5ab325f1e373/gr-digital/lib/digital_ofdm_sampler.cc#L78
> >
> > However, the size of the rx_time tags is consistently zero:
> >
> https://github.com/gnychis/grforwarder/blob/8f8c4e6cf79a2d635a0eb3bcad9b5ab325f1e373/gr-digital/lib/digital_ofdm_sampler.cc#L99
> >
> > The output of the OFDM receiver code:
> > ok: True pktno: 637  n_rcvd: 18  n_right: 17
> > got a preamble, size of time_tags: 0
> > ok: True pktno: 638  n_rcvd: 19  n_right: 18
> > got a preamble, size of time_tags: 0
> > ok: True pktno: 639  n_rcvd: 20  n_right: 19
> > got a preamble, size of time_tags: 0
> > ...
> >
> > Is there something I am missing to enable the RX timestamp on the
> incoming
> > samples, or am I not properly reading the stream tag?  My branch came
> from
> > the GR master 4 days ago (309ca769af).
> >
>
> The timestamps are only sent on the very first packet and after overflow
> conditions. Are you seeing at least one tag at the very beginning of
> streaming?
>
> -Josh
>
> ___
> 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 learn of decimation rate in general_work() ?

[George Nychis]

>
>
> Hey George,
>
> You can use the relative_rate data member of the blocks. Setting the
> decimation actually sets the relative_rate to 1.0/decimation. You can get
> this value with the accessor function "relative_rate()".
>
>
Hey Tom,

Using this I can get the decimation rate, but is there a way to get the
rate of samples from the ADC?  That way I can compute the real clock time
in-between samples.  For the USRP2, despite the ADC running running at
400Msps, it's rate through the FPGA is actually 100Msps, right?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to learn of decimation rate in general_work() ?

[George Nychis]

On Wed, Feb 8, 2012 at 7:34 PM, Ian Buckley  wrote:

> Just to confirm, the USRP2/N2x0 ADC samples at 100MHz.  (The DAC output
> however runs at 400MHz, its fed samples at 100MHz and it has built in 4x
> interpolation which may be the source of confusion).
>
> On Feb 8, 2012, at 4:12 PM, Tom Rondeau wrote:
>
> On Tue, Feb 7, 2012 at 5:37 PM, George Nychis  wrote:
>
>>
>>> Hey George,
>>>
>>> You can use the relative_rate data member of the blocks. Setting the
>>> decimation actually sets the relative_rate to 1.0/decimation. You can get
>>> this value with the accessor function "relative_rate()".
>>>
>>>
>> Hey Tom,
>>
>> Using this I can get the decimation rate, but is there a way to get the
>> rate of samples from the ADC?  That way I can compute the real clock time
>> in-between samples.  For the USRP2, despite the ADC running running at
>> 400Msps, it's rate through the FPGA is actually 100Msps, right?
>
>
> Actually, I think the ADC is running at 100 Msps, which I think you can
> get with the "get_clock_rate(mboard)" method. The rate that they come
> across is then determined by the decimation rate. You can query sample rate
> from the USRP via the UHD with the "get_sampl_rate()" method.
>
>

Great, thanks a bunch for the info Tom & Ian!  I'm using UHD, so I will
use get_sampl_rate()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc

[George Nychis]

A bit late on this conversation... I just noticed it after I posted an
update for CGRAN.

GNU Radio has been largely successful in the academic community, because it
provides us the flexibility to perform the style of research we need.
 Ultimately though, the limitations of the framework that were put in place
to achieve this flexibility, I believe hurt the ability of GNU Radio to
support more high-end applications.  I'm not talking about the lack of
someone coming around to do it, I'm talking about the lack of GNU Radio and
USRP to support many of the current wireless standards today.  This is
going to be slightly biased in my area of research... but, what would be a
great app?  Show interoperability of GNU Radio and 802.11, ZigBee, DECT,
RFID (thanks Michael), NFC, Bluetooth, etc.

To me, pushing GNU Radio to the next level has never been about building
the next set of applications on what is currently supported, but really
pushing the platform to the next level.  Being able to support low latency
applications, support wide ranges of MAC protocols, different PHYs.  This
opens up the ability to build so much more and new on GNU Radio.

I can't express how many times I've gotten personal e-mails about my MAC
work and about projects on GNU Radio of people wanting to do some pretty
cool things and I'm just like... "well, the architecture just doesn't
support that."  For example, meta-data between blocks IMO was something
brain-dead that should have been in GNU Radio 7 years ago which would have
really enabled new things to be done with the framework.  Instead, it took
7 years for stream tags ;)  This is functionality that pushes the frame and
the architecture, that is the kind of stuff that I think will push the
platform.

So to me, it's not about having the next demodulation block, it's about
what is going to happen to the architecture and the framework to support an
802.11, a ZigBee, DECT, RFID, NFC, Bluetooth, Xbox controller... things
that people want to play with and showcase the capabilities of the radio.

I think what "we" should be doing is taking what is "hot" in the radio
world, and asking whether or not it can be supported by GNU Radio and the
USRP.  I really think that GNU Radio needs to get passed its major
application being simple streaming or demodulation and really push packet
radio.  Two way low latency communication.  Networks, I suppose.

To me, I go "well, in 6 years GNU Radio really hasn't changed" ... has it?
 Yeah, block details, new blocks, the amount of bandwidth from the USRP,
but like, what has fundamentally pushed the limitations of the system?

Just my 10 cents!  I am unbelievably grateful for GNU Radio and the USRP.
 They truly transformed my view of the RF world, the radio, and have given
me invaluable experience that I would have never gotten on any other
platform.  The community itself is great, and I've been happy to be a part
of it (in and out) for the past 6 years.  That's the reassuring part that
I'm on your side, these are just my thoughts on where I wish GNU Radio &
USRP would go :)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CGRAN wants your GNU Radio projects!

[George Nychis]

Just your friendly CGRAN update to the mailing list.  I've seen a slowdown
in projects posted to the CGRAN, yet not a slowdown in account signups.
 So, I thought I'd just e-mail out a quick update.

The usual quick blurb (https://www.cgran.org/):
*The Comprehensive GNU Radio Archive Network (CGRAN) is a free open source
repository for 3rd party GNU Radio applications that are not officially
supported by the  GNU Radio project. CGRAN provides a subversion repository
for users to develop or submit new applications, and wiki access for full
project documentation. *
*
*
Recent projects:

   - 
Logitech27MHzTransceiver<https://www.cgran.org/wiki/Logitech27MHzTransceiver>
-
   Transceiver for 27 MHz wireless keyboards from Logitech
   - Stream Tagging Tools <https://www.cgran.org/wiki/stt> - A growing
   collection of blocks relating to handling tags
   - simple_ra <https://www.cgran.org/wiki/simple_ra> - A simple Radio
   Astronomy application to replace gr-radio-astronomy
   - gr_iqtx <https://www.cgran.org/wiki/gr_iqtx> - A tool for sending
   generic I/Q data from a FIFO, and providing various analysis options
   - RSSI-based 802.15.4
localization<https://www.cgran.org/wiki/RSSIbased802154localization> -
   802.15.4 receiver with RSSI feature added, and application code for channel
   estimation, ranging and localization

*Note: * I've noticed a general move from SVN to git.  I don't have the
time to move CGRAN to git right now, but I am more than okay with someone
hosting their code on github, and adding their project to the project list,
linking to their github.  Because ultimately, your code is available in a
public location that people can fork from, etc.  CGRAN can still provide
you the exposure to the GNU Radio community if you want it, just link to
your github.

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

Re: [Discuss-gnuradio] Reminder about call today

[George Nychis]

Hey all,

I actually really want to join the call, because I have a GSoC idea, but I
have a conflict with teaching assistant duties during that time.

So I thought I'd briefly share, and if it does become of interest then
maybe someone can get ahold of me and I could try to mentor or something.
 I thought it might be cool to show that GNU Radio and the USRPP can be
more than just about wireless technology, pushing forward on a hot topic
recently: PowerLine networking.

I've been trying to dig up details of PowerLine implementations, but I
think they are typically very "wireless PHY" oriented.  I think they are in
general OFDM based with Turbo Convolutional Codes.  I think that GNU Radio
already provides a lot of the blocks that would be necessary to build the
PHY. I am not sure of what the necessary frontend might be for this, but
maybe by the summer if Matt and GNU Radio folks are truly interested, a
prototype could be made.

Some info i found on PowerLine details:
http://helpfromageek.com/2011/05/18/white-paper-powerline-networking/


On Thu, Feb 16, 2012 at 10:50 AM, Tom Rondeau  wrote:

> This is just a reminder about today's Developers' Call. Due to other
> conflicts, the time has been changed from the normal time to 1600 EST or
> 2100 UTC.
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216
>
> We'll probably want to spend a significant amount of time on discussing
> the projects we want to put forward for the GSoC, so please join us if you
> are interested in participating.
>
> Thanks,
> Tom
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reminder about call today

[George Nychis]

>
>
> Interesting thought. Powerline communications have been discussed for
> quite a while, but they tend to be horrible channels (old copper, long
> distances, bad shielding, etc.). So yes, I'd expect OFDM for the
> equalization and multipath (or 'echos' in this case) issues and heavy
> channel coding are required.
>
> My main question regarding this topic is to figure out what would be
> necessary to create a test bed to try it out on? Obviously, we aren't going
> to stick the Rx/Tx port of the USRP into a wall socket :)
>
>
Trust me, I am far from an EE person, so ignore any outrageous
misunderstandings ;)  I guess this will start as more of question:  since
we can't stick Rx/Tx directly in to a wall socket... what actually needs to
happen to stick an Rx/Tx in to a wall socket?  I'm guessing a bunch of
filtering goes on with the actual power, but beyond that I have no clue.  I
guess part of this is I was wondering if it is feasible to develop a
frontend to stick a USRP in to a wall socket.  Then, due to the horrible
channels you mention, I think it makes for an interesting/feasible 3 month
project to get communication through to power line with those channels.
 Even measurement on what those channels are like would be interesting, and
I know whatever might come out of this would really open up the ability for
the academic community to directly research power line networks.

Thanks, Tom!

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

Re: [Discuss-gnuradio] Reminder about call today

[George Nychis]

>
>
> OFDM for the equalization and FEC for the channel errors has been a
> successful technique used in residential power-line communications.
> However, commercial buildings tend to have long and unpredictable
> power delay profiles, requiring long symbol times.  In addition, there
> are enormous sources of interference (primarily impulse noise) from
> things like elevator motors and paper shredders (!), as well as strong
> shortwave RF induced signals.  Finally, some installations use
> multiple transformers between floors, with their own very
> unpredictable channel response.
>

Hey Jonathan,

This was a super informative post, it's really interesting to hear about
experience of actually building PLC in practice.  I haven't seen very many
studies on it, but it seems like different buildings have greatly varying
profiles.  I didn't think of things like elevator motors in office
buildings, but that's got to introduce a lot of interference.

If you ever do this again, I would love to see some of the channels over
time.  I ordered some basic PLC equipment, but all I really have access to
are packets :P


>
> As an alternative, one commercial R&D contract I did a while back was
> to use DSSS/CDMA with long codes to reduce the interference by the
> coding gain, then use additional delay correlators to receive and
> combine echos (a basic RAKE receiver).  This worked extremely well for
> interference rejection, without FEC at the data level, but at the
> expense of a low bit rate and long synchronization times.  Since the
> communication requirement was a unidirectional broadcast, this worked
> out well.
>

Nice, I guess with unidirectional broadcast that does work out well for
you.  How do you actually get echoes in a PL?  I never thought about this.


>
> The initial implementation was done in GNU Radio with a chipping rate
> of 2 Mcps, then ported to the USRP2 FPGA (minus the rake) for chipping
> rates up to 25 Mcps.
>
> I think this goes to the point that GNU Radio is an excellent tool for
> experimentation, R&D, prototyping, etc., and not so much for chasing
> existing standards.
>
> > My main question regarding this topic is to figure out what would be
> > necessary to create a test bed to try it out on? Obviously, we aren't
> going
> > to stick the Rx/Tx port of the USRP into a wall socket :)
>
> That company made some generic 50-ohm to wall socket power couplers
> for the project, but I don't know if they ever made them commercially.
>  I still have a pair in my lab to play with :)
>
>
It would be really cool to be able to hook up the USRP to a PL and
understand various channels in different types of buildings.  Totally not
conducive to my dissertation, but I find it interesting.

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

Re: [Discuss-gnuradio] Power line communications

[George Nychis]

On Mon, Feb 20, 2012 at 6:32 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:

> On Mon, Feb 20, 2012 at 07:32, Johnathan Corgan
>  wrote:
>
> >> If you ever do this again, I would love to see some of the channels over
> >> time.  I ordered some basic PLC equipment, but all I really have access
> to
> >> are packets :P
> >
> > I'll try to grab a spectrum analyzer plot from my lab.
>
> Below are two images of the RF spectrum as received through a power
> coupler plugged into a wall socket in my office building.
>
> The first is DC-500MHz:
>
> http://gnuradio.org/data/power-line-500MHz.jpg
>
> The green line is the thermal noise floor in the RF bandwidth used
> (the measurement setup has a NF of about 9dB).
>
> There are no quiet parts of the spectrum, and many narrowband signals.
>  FM radio stations are obvious around 100 MHz.
>
> The 125MHz spectral line and 100 MHz harmonics go away when I unplug a
> USRP N210 on the same power strip :-)
>
> A zoom of the first 50 MHz:
>
> http://gnuradio.org/data/power-line-50MHz.jpg
>
> It's pretty noisy all over.
>
>
Wow... so let me make sure I get this straight.  That's just a passive
reading of the RF spectrum on your wall socket... you are not introducing
any form of transmission on the line?  The USRP N210 was simply just
plugged in to the power strip, right?

If so, that's unbelievably noisy.  I didn't expect it to be *that* bad.
 The FM stations are definitely clear.

It's very hard for me to find specs of commercial power line equipment, but
it typically operates between 2-28MHz?  Even within that short range, given
your zoomed in snapshot, there is almost a 40dB difference in the amount of
noise from across that band from valley to peak.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] discussion on USRP-->Wall Socket for Power Line Comms

[George Nychis]

Okay!  So apparently there is some interest in power line communication for
GSoC.  But, what we would want to do is already have a safe way of
connecting the USRP in to the wall socket for the student(s), and for the
future of GNU Radio and USRP power line communications development.

So, as a goal of this thread I'd like to get some feedback on how we can
make this possible.  Ideally, something off-the-shelf would be great,
providing the highest amount of safety for those experimenting with it.

Please keep in mind my background is not EE, but I am more than happy to
try and lead this and test/try/sacrifice what needs to be done.

Jonathan mentioned that for a project he was working on before, generic
50-ohm wall socket power couplers were made.  I don't know how difficult it
would be to replicate something like this.

Evan Merewether suggested picking up some power line telephone extenders
from Radio Shack and dissecting them.

Ideally, I think we could connect whatever it is to a basic TX/RX.

Any thoughts here?

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

Re: [Discuss-gnuradio] discussion on USRP-->Wall Socket for Power Line Comms

[George Nychis]

>
>
>
> Maybe something a little more accessible from MAXIM:
>
>  http://www.maxim-ic.com/products/powerline/
>
> They have an evaluation kit which might have some testpoints to
> connect up to a USRP, or try to ship off samples through their 10/100
> ethernet interface.
>
>
Thanks, Brian!

I will poke around the max series evaluation kits to see if there is
something there that could work out at a reasonable price.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Citation of GNUradio codes

[George Nychis]

Hi Nazmul,

I've seen most people just cite "GNU Radio. http://gnuradio.org"; ...
ultimately benchmark_tx and benchmark_rx use large parts of the entire GNU
Radio project.

- George

On Fri, Feb 24, 2012 at 7:16 PM, Nazmul Islam wrote:

> Hello,
>
> I have used the benchmark_tx and benchmark_rx codes for one of my projects
> and I am submitting a conference paper based on that work. I want to cite
> these codes or at least the GNU radio website for this purpose. Is there a
> specific format that I should follow? Or can I just use IEEE's standard
> webpage citation format?
>
> I apologize in advance if a similar question has already been asked here.
> I searched for similar questions in the mailing list but could not find one.
>
> Suggestions will be appreciated.
>
> Thanks,
>
> Nazmul
>
>
> --
> Muhammad Nazmul Islam
>
> Graduate Student
> Electrical & Computer Engineering
> Wireless Information & Networking Laboratory
> Rutgers, USA.
>
>
> ___
> 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] uhd running parallel tx/rx flowgraphs

[George Nychis]

On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech  wrote:

> **
> On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
>
> Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
> do, is to start both the flowgraphs, and just listen for packets.
>
>  In which case, the TX side is running--even if you aren't sending any
> *data* bits, it's still transmitting, and blocking the receiver.
>
> You'll have to get more sophisticated about half-duplex flow management,
> using tagging to tell UHD to turn on/off the TX side.
>
> Josh probably has better words of wisdom on this than I.
>

Hi Marcus,

I'm working with Apurv, so I'm going to chime in here :)

I tried doing some searching on the mailing list, but I wasn't really able
to find much on this.  I also thought that auto tr would handle this.  I
found a post from Josh on the mailing list that said Auto TR is always
enabled in UHD.

http://www.ruby-forum.com/topic/1527488
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

[George Nychis]

It's be good if you can chime in here, Josh :)

It seems like this is something that should be fixed about tunnel.py in
future GNU Radio releases for use with UHD.

I'm trying to do my fair share of research here and tackle it. If what you
say is true, Marcus, the control I need is over the TX chain.

I did a bunch of reading through the UHD docs here:
http://files.ettus.com/uhd_docs/doxygen/html/annotated.html

I see various controls using tx_streamer and tx_metadata_t to use tags to
control samples to be part of a burst. Like, marking the start and end of
my TX burst of samples which can construct a packet.

No prob, I can do that. But it seems like there needs to be some sort of
UHD stream command which turns the TX chain in to an "on-demand" chain and
not continuously streaming. On the other hand, I would like RX to be
continuous.

I see the RX control to specify stream controls here:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html

That is clearly documented as control of samples to the host to be
continuous or not.

However, I don't see that same control for the TX stream. Tx_metadata_t and
t_streamer control the bursts, but don't seem to control the overall
stream? Maybe I am missing something.

On Sunday, February 26, 2012, Marcus D. Leech wrote:

> **
> On 02/26/2012 08:54 PM, George Nychis wrote:
>
>
>
> On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech 
> 
> > wrote:
>
>>  On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
>>
>> Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
>> do, is to start both the flowgraphs, and just listen for packets.
>>
>>  In which case, the TX side is running--even if you aren't sending any
>> *data* bits, it's still transmitting, and blocking the receiver.
>>
>> You'll have to get more sophisticated about half-duplex flow management,
>> using tagging to tell UHD to turn on/off the TX side.
>>
>> Josh probably has better words of wisdom on this than I.
>>
>
>  Hi Marcus,
>
>  I'm working with Apurv, so I'm going to chime in here :)
>
>  I tried doing some searching on the mailing list, but I wasn't really
> able to find much on this.  I also thought that auto tr would handle this.
>  I found a post from Josh on the mailing list that said Auto TR is always
> enabled in UHD.
>
>  http://www.ruby-forum.com/topic/1527488
>
>
>   Yes, it is enabled in UHD.  But since Gnu Radio is a *streaming* model,
> you need to take special measures to control TX from within a
>   Gnu Radio flow-graph.  YOu need to insert a tag in the stream to control
> the transmitter, otherwise, you'll be continuously streaming.
>
> What you do is insert a burst-tagger into your stream, and set it to send
> the appropriate tags for UHD into the stream using the trigger
>   input.  I just can't off the top of my head, remember what those stream
> tags are at the moment.  But the basic issue is that Gnu Radio
>   uses a streaming model, and while UHD itself (at the C++ level) has
> fine-grianed control over transmitter functions, etc, gr-uhd doesn't
>   directly expose any of that, because there's just not mechanism within
> Gnu Radio to expose that stuff.  The stream tagging, however,
>   does allow you to control the transmitter state.  In the particular case
> of the XCVR2450, the hardware is physically incapable of
>   TX and RX at the same time.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

[George Nychis]

It's be good if you can chime in here, Josh :)

It seems like this is something that should be fixed about tunnel.py in
future GNU Radio releases for use with UHD.

I'm trying to do my fair share of research here and tackle it. If what you
say is true, Marcus, the control I need is over the TX chain.

I did a bunch of reading through the UHD docs here:
http://files.ettus.com/uhd_docs/doxygen/html/annotated.html

I see various controls using tx_streamer and tx_metadata_t to use tags to
control samples to be part of a burst. Like, marking the start and end of
my TX burst of samples which can construct a packet.

No prob, I can do that. But it seems like there needs to be some sort of
UHD stream command which turns the TX chain in to an "on-demand" chain and
not continuously streaming. On the other hand, I would like RX to be
continuous.

I see the RX control to specify stream controls here:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html

That is clearly documented as control of samples to the host to be
continuous or not.

However, I don't see that same control for the TX stream. Tx_metadata_t and
t_streamer control the bursts, but don't seem to control the overall
stream? Maybe I am missing something.

On Sunday, February 26, 2012, Marcus D. Leech wrote:

> **
> On 02/26/2012 08:54 PM, George Nychis wrote:
>
>
>
> On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech 
> 
> > wrote:
>
>>  On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
>>
>> Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
>> do, is to start both the flowgraphs, and just listen for packets.
>>
>>  In which case, the TX side is running--even if you aren't sending any
>> *data* bits, it's still transmitting, and blocking the receiver.
>>
>> You'll have to get more sophisticated about half-duplex flow management,
>> using tagging to tell UHD to turn on/off the TX side.
>>
>> Josh probably has better words of wisdom on this than I.
>>
>
>  Hi Marcus,
>
>  I'm working with Apurv, so I'm going to chime in here :)
>
>  I tried doing some searching on the mailing list, but I wasn't really
> able to find much on this.  I also thought that auto tr would handle this.
>  I found a post from Josh on the mailing list that said Auto TR is always
> enabled in UHD.
>
>  http://www.ruby-forum.com/topic/1527488
>
>
>   Yes, it is enabled in UHD.  But since Gnu Radio is a *streaming* model,
> you need to take special measures to control TX from within a
>   Gnu Radio flow-graph.  YOu need to insert a tag in the stream to control
> the transmitter, otherwise, you'll be continuously streaming.
>
> What you do is insert a burst-tagger into your stream, and set it to send
> the appropriate tags for UHD into the stream using the trigger
>   input.  I just can't off the top of my head, remember what those stream
> tags are at the moment.  But the basic issue is that Gnu Radio
>   uses a streaming model, and while UHD itself (at the C++ level) has
> fine-grianed control over transmitter functions, etc, gr-uhd doesn't
>   directly expose any of that, because there's just not mechanism within
> Gnu Radio to expose that stuff.  The stream tagging, however,
>   does allow you to control the transmitter state.  In the particular case
> of the XCVR2450, the hardware is physically incapable of
>   TX and RX at the same time.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

[George Nychis]

A quick question on how the trigger works in UHD.  I have some basic code
integrated with the help of your suggestions.

Burst tagger port 0 is the raw complex sample stream.  Burst tagger port 1
is the trigger.  Let's say the raw complex sample stream has an outgoing
packet.  I'm assume that I change the value on port 1 that corresponds to
the first sample of the preamble to a value of '1': which is the trigger
like "hey, here is the start of the burst!"  My question is, for *all*
indexes on port 1 that correspond to samples in the packet on port 1,
should those also be of value 1?  Or only just the first sample?  What
about the last sample?

Just trying to understand exactly how the trigger works.


On Mon, Feb 27, 2012 at 9:12 PM, Josh Blum  wrote:

>
>
> On 02/27/2012 05:30 PM, George Nychis wrote:
> > It's be good if you can chime in here, Josh :)
> >
> > It seems like this is something that should be fixed about tunnel.py in
> > future GNU Radio releases for use with UHD.
> >
>
> Like removing it altogether :-)
>
> > That is clearly documented as control of samples to the host to be
> > continuous or not.
> >
>
> Basically, RX is intended to work on a continuous streaming model, which
> is why stream command inst swigged up. The start()/stop() methods are
> actually the ones issuing the command.
>
> When and if the pmt based message passing gets merged, i was going to
> implement control messages to deal with streaming, possibly other
> things. This lets you tie the uhd source block into a control plane.
>
> As is stands now, i guess someone could just forward the stream command
> stuff, so long as the work() function knew to block when there is
> definitely not supposed to be samples. That way you avoid the scheduler
> marking the block done on a timeout.
>
> > However, I don't see that same control for the TX stream. Tx_metadata_t
> and
> > t_streamer control the bursts, but don't seem to control the overall
> > stream? Maybe I am missing something.
> >
>
> You can use stream tags to control start/stop of burst and transmit
> times. See the usrp sink header or the tags demo in gr-uhd.
>
> Now that being said, the framer blocks in tunnel.py could be more
> intelligent and properly shutoff streaming (aka end a burst) when there
> is no data. That way you avoid underflow when there isnt a continuous
> supply of data to modulate.
>
> -Josh
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

Hi all,

I'm going to be hacking carrier sense in to the FPGA on the USRP2 very
soon.  Basically, taking what I did with the "in-band" project from the
USRP1 with carrier sense, and moving it forward to USRP2.

The idea is, just like you can set a timestamp to "gate" a packet on its
way out: only transmit it at time X, you can do something similar with
carrier sense.  If the burst has the carrier sense flag set, then you wait
for the carrier to become idle, then transmit the packet.

For the in-band implementation, I had a command to set the value at which
the carrier is determined to be busy/idle.  This was stored in memory in
the FPGA.  Then, when bursts came with a carrier sense bit set, that value
is used.

OK:  so I'd like to re-do this implementation to keep this kind of stuff
alive, and I will use it myself.  But in doing so, I'd like to implement it
in a way that jives well with the higher ups.  If I'm going to do it, I'd
like to do it right so that it lives on through future versions of GNU
Radio.  So that means doing it using UHD.

For the life of me, I can't find the UHD header spec.  But I imagine
somewhere in there we can fit a bit to gate based on carrier sense, and a
new command to set the carrier sense threshold.

If you have any advice/guidance on how you'd like to see this implemented,
let me know.  I sincerely would like this to live long and prosper in GNU
Radio and the USRPs.

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

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

>
>
> I totally like and support your idea and would love to help realizing
> it. Using the timestamp logic inside UHD as a reference is a great idea
> that also came to my mind a while ago.
> There are a few things from the architecture point of view though that
> need to be discussed. Let's take a CSMA MAC as an example, I guess that
> goes into the right direction :-) Just having the "if channel free,
> transmit packet"-logic inside the FPGA wouldn't make much sense in a
> multi-user environment. What would happen is that if the channel is busy
> and multiple nodes have packets in their tx queues, they would all end
> up sending their packets more or less at the same time after the channel
> gets idle again (assuming all nodes are in sensing range). In a
> practical system, one would now start to move parts of the CSMA state
> machine, i.e the random backoff, into the FPGA. Trying to control this
> via UHD is probably a bad idea as UHD's main business is transportation.
>
> I do think we need something like what you have suggested but I am still
> a bit puzzled about the right way of implementing it.
>
>
Hi Andre,

Yeppp, the idea is to build part of the MAC in to the FPGA... the part that
requires low latency operation.  So, after the simple "transmit when idle"
logic, you put some basic form of back off in to the logic also.

I have a paper which argues low latency MAC functionality should be built
in to the FPGA, but controlled from the host, otherwise it's as good as
worthless implementing it on the host.  If you try to build this part of
the MAC at the host, the latency of receiving the channel state (latency
from FPGA -> host), making a decision and performing an action (host ->
FPGA), completely makes the information stale.  You end up with a decision
that is something like 1-2ms old, which clearly the state of the channel
changes at a more finer-grain than that.

Sooo... you either implement this kind of functionality in a "split" kind
of way where the function sits in the FPGA since it requires low latency,
or it's as good as worthless ;)  I'd rather have some form of carrier sense
that's commonly used in some side-FPGA implementation, rather than throwing
in the towel and saying GNU Radio and the USRP's architecture can never
support something like this that's usable due to the latency.  I get tons
of e-mails about my split-functionality MAC work, asking if it's usable but
it got deprecated along with the m-block, so there is a set of users out
there that I think would be happy with some basic usable carrier sense and
back-off.  Otherwise we're constantly in the: let's avoid the whole idea of
support a true MAC thing, and GNU Radio and USRP continue life as a
source/sink.

(http://dl.acm.org/citation.cfm?id=1558984)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

On Sun, Mar 4, 2012 at 10:01 AM, Marcus D. Leech  wrote:

> George,
>>
>>
>> I do think we need something like what you have suggested but I am still
>> a bit puzzled about the right way of implementing it.
>>
>> Best regards,
>> Andre
>>
>>  I think a more fundamental issue is that "carrier sense" isn't actually
> defined in any kind of general way.  Certainly for *some* types of
>  PHYs, you can do simple energy-presence detection.  But usually, it's
> more complicated than that, and it varies widely from PHY to
>  PHY.  In some, you'll need to run a correlator before you even know
> whether the channel is busy or not.  In others, simple energy
>  detection works.
>
> I don't think there's a general-purpose way of doing this, but that's just
> my POV.
>
>
Definitely, there are MACs whose form of carrier sense is detecting
preamble rather than detecting energy.  In my same piece of work, we put a
matched filter in the FPGA and the host specifies the coefficients of the
match filter, then you gate on that.  But, I don't think it's unreasonable
to think basic energy detection is not general purpose enough?  I think
supporting some basic form of energy detection would start to enable better
MAC implementations...

and afterwards I have every intention of rolling a match filter in to the
FPGA also.  So, maybe your suggestion is I build a separate FPGA
implementation if people want MAC functionality.  I can do that if people
believe that the functionality is not general enough.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

Let me put it this way... I'm going to build it because I need it ;)  But
what I'm asking/hoping for is for it to be useful beyond just me and
actually have a lifespan beyond my immediate use of it.  So, I'd like to
get some feedback on how others might like to see it tied in to UHD, or the
type of flexibility the implementation should have.  For example, the
programmability of the threshold, the type of back off, the control of the
back off, etc.

You don't get these types of people on the list very often because they
simply look at GNU Radio and USRPs architecture and go: well, it doesn't
support that... moving right along to another platform (e.g., WARP, Sora,
etc.).  But speaking from my area (wireless networking, not so much
wireless communications), it is this kind of functionality that a lot of
people want/need to build a network on top of the OFDM code, for example.

You can say that energy sensing isn't general enough or any implementation
of it wouldn't be general enough, but IMO staying away from it more
significantly limits possible applications of the platform rather than
expanding it.  I think this type of functionality can further support a new
set of applications and networks.  I don't feel as though it threatens the
flexibility of GNU Radio because it's not fundamentally changing the
architecture. It's exploiting the tight-control that UHD was put in place
to try and enable. It's functionality that sleeps in the FPGA unless you
need it to build your application.

Like I said, I can build it as a separate FPGA firmware for those who want
to use the functionality (though I fear it gets deprecated quite quickly in
that way)... but it would be good to hear what kind of functionality and
flexibility people would like to see in a carrier sense implementation, how
it could be controlled, etc.  Otherwise, I will go off and "do my thang"
and you simply get what comes out of it ;)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

[George Nychis]

On Mon, Mar 5, 2012 at 9:26 AM, David Knox  wrote:

>
> > I just don't want to loose all the flexibility of software by moving the
> > critical but interesting things to hardware.
> >
> > (* But of course, it all depends upon your goals. *)
>
> George (and others),
>I think that the above statement is the basic
> issue here and seems to summarize the issues with offering a 'solution for
> everyone'; although, offering to do this is still noble sentiment from you,
> George.  I have been using the USRP1 for a few years now, using code based
> on the old deprecated mblock code (and your code too!) and there have been
> a
> few times when I have wondered about whether I needed to crack open the
> FPGA
> code or not... and suffer through the re-fitting and then the required
> timing verification that this would require above and beyond verifying any
> functional changes I was considering in Verilog.
>
>
Thanks David!  This kind of thing can impact the design of what I build.
 What in particular were you thinking about opening up the FPGA to modify
that you felt it wasn't flexible enough?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] detecting spectrum holes

[George Nychis]

Finding white space in the spectrum can be done by looking at power across
the bins you are monitoring.  I have done White space research with the
USRP2 and the WBX, and they worked out great for me.  So you're on the
right track!

Take a look at this work, Section 3.1:
http://static.usenix.org/event/nsdi10/tech/full_papers/yang.pdf

They have a basic technique for detecting white space.  Their paper was not
about the TV bands, but the technique should work elsewhere.

Best of luck, and welcome!

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

[Discuss-gnuradio] IEEE DySPAN 2012: Call for Demonstrations

[George Nychis]

Hey all,

The GNU Radio community is a strong and large one whose area fits great
with DySpan, as I'm sure many of you are familiar with.  I've seen so many
great demonstrations of various dynamic spectrum access techniques using
GNU Radio, and I am hoping that that some strong demos using GNU Radio will
show up for DySpan 2012 this year!

Przemysław and I are the demo chairs, and we have a great set of submission
reviewers this year (e.g., your very own Tom Rondeau!).

If you've got something awesome to show off and want some great exposure, I
strongly suggest you check out the CFD below!


[Apologize if you receive multiple copies of this message]
[Please feel free to forward this CFP to your contacts]

-

IEEE DySPAN 2012: Call for Demonstrations
IEEE SYMPOSIUM ON NEW FRONTIERS IN DYNAMIC SPECTRUM ACCESS NETWORKS
(DySPAN 2012) 16 - 19 October 2012, Bellevue, WA, USA
http://www.ieee-dyspan.org/2012/

This is a call for proposals to demonstrate systems, prototypes,
critical technology components and algorithms at IEEE DySPAN 2012,
which will be held in Bellevue, WA, USA, between 16 and 19 October,
2012.

IEEE DySPAN 2012 will provide the opportunity to conduct live
demonstrations of dynamic spectrum systems. The event will offer an
invaluable opportunity to demonstrate and interact with other
world-leading researchers in the field of dynamic spectrum access.
Apart from demonstrations performed by participating groups, IEEE
DySPAN 2012 will create a unique opportunity to conduct experiments.
These include (but are not limited to) spectral occupancy measurements, and
co-existence and system interaction measurements.

To participate in the demonstration and experimentation activities,
candidates shall complete the demonstration form (available at
http://www.ieee-dyspan.org/2012/cfpdemonstrations.html) to provide
a description of the planned demonstration and/or experimentation. The form
must be sent before submission deadline via
https://moo.cmcl.cs.cmu.edu/dyspan12demos. All submissions will
be peer-reviewed to ensure quality.

In addition to the demonstration form, prospective demo presenters
must submit a 2-page IEEE conference style paper describing the
demonstration and results. The papers will be reviewed by the demo
committee selected by IEEE DySPAN demo chairs, and the review results of
the paper will have impact on the final decision in accepting
demonstrations. To submit a demo paper, please go to again to
https://moo.cmcl.cs.cmu.edu/dyspan12demos. Accepted demo papers will be
included in IEEE DySPAN proceedings and IEEE eXplore.

Important Dates:
Paper Submissions Due: 18 May 2012
Acceptance Notification: 27 July 2012
Camera-Ready Paper Due: 17 August 2012

For enquiries, please contact DySPAN 2012 Demonstration Chairs.

Best Regards,
IEEE DySPAN 2012 Demo Chairs

George Nychis, Carnegie Mellon University, Pittsburg, PA, USA (
gnyc...@cmu.edu)
Przemyslaw Pawelczak, Fraunhofer Heinrich Hertz Institute, Berlin,
Germany (przemyslaw.pawelc...@hhi.fraunhofer.de)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with FW and FPGA images

[George Sklivanitis]

Hello everyone,

The last 2 days I am dealing with a problem of using gnuradio with USRP2s.

I have successfully installed both gnuradio and uhd using the
build-gnuradio scipt into 3 brand new core i-7 laptops.

However, after using the default usrp2_card_burner gui for burning the
firmware and fpga images into a Kingston 2GB SD card provided with the
USRP2 I cannot find the USRP2 device neither when using the command
uhd_find_devices nor by doing ping in 192.168.10.2. Sometimes USRP2 appears
to be found but afterwards the communication is compromised. I have also
tried disabling the firewall of ubuntu but nothing changed.

Are there any new images for UHD_003.004.001-27-g93d4a16f revision in the
main branch that I am not aware of?

Thanks,
George



-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with FW and FPGA images

[George Sklivanitis]

Hi Josh,

The sequence of the LEDs is D and F coming green just in the same way as
the video apart from the B led where I cannot see why to come green?

The ethernet is properly configured.

The green led on the ethernet also goes on. There is no way that the
ethernet jack is faulty or sth like that as the same usrp2 with the same
settings is just working fine on another laptop with UHD_003.004.000 - 325-
g7e296167 revision.

I don't really know what's the problem, may be I will try solving it by
monitoring the serial output.

The thing that really attracted my attention is that sometimes there is a
connection and after just typing uhd_find_devices the connection is lost.

Any other ideas guys?

Thanks again,
George

On Fri, Apr 13, 2012 at 2:00 AM, Josh Blum  wrote:

>
>
> On 04/12/2012 05:15 PM, George Sklivanitis wrote:
> > Hello everyone,
> >
> > The last 2 days I am dealing with a problem of using gnuradio with
> USRP2s.
> >
> > I have successfully installed both gnuradio and uhd using the
> > build-gnuradio scipt into 3 brand new core i-7 laptops.
> >
> > However, after using the default usrp2_card_burner gui for burning the
> > firmware and fpga images into a Kingston 2GB SD card provided with the
> > USRP2 I cannot find the USRP2 device neither when using the command
> > uhd_find_devices nor by doing ping in 192.168.10.2. Sometimes USRP2
> appears
> > to be found but afterwards the communication is compromised. I have also
> > tried disabling the firewall of ubuntu but nothing changed.
> >
> > Are there any new images for UHD_003.004.001-27-g93d4a16f revision in the
> > main branch that I am not aware of?
> >
>
> Few things I can think of:
>
> 1) Do you see this boot sequence on power up?
> https://www.youtube.com/watch?v=REDK7M-83WQ
>
> 2) Do you see the green LED on the ethernet jack go on?
>
> 3) The serial port can also help:
>
> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#monitor-the-serial-output
>
> 4) ethernet configured? just a thought:
> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking
>
> -Josh
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: Problem with FW and FPGA images

[George Sklivanitis]

-- Forwarded message --
From: George Sklivanitis 
Date: Fri, Apr 13, 2012 at 2:30 AM
Subject: Re: [Discuss-gnuradio] Problem with FW and FPGA images
To: Nick Foster 


Hi Nick,

I am sorry but I have been misunderstood.
Actually the same USRP2 that is not working and cannot manage to connect
with one of my laptops, it actually works very well with one of my other
laptop that use a UHD_003.004.000-325-g7e296167 revision of uhd.

So I believe ethernet works just fine. Maybe the ethernet jack of my laptop
does not operate that good. You think that one might be an issue?

Thanks,
George

On Fri, Apr 13, 2012 at 2:18 AM, Nick Foster  wrote:

> George,
>
> Seeing as it's flaky and you have a second USRP which works, it does sound
> to me like you might have a USRP with a damaged network connection. I can
> issue an RMA for that device if you want.
>
> Best,
> Nick
>
>
> On Thu, Apr 12, 2012 at 11:12 PM, George Sklivanitis <
> george.sklivani...@gmail.com> wrote:
>
>> Hi Josh,
>>
>> The sequence of the LEDs is D and F coming green just in the same way as
>> the video apart from the B led where I cannot see why to come green?
>>
>> The ethernet is properly configured.
>>
>> The green led on the ethernet also goes on. There is no way that the
>> ethernet jack is faulty or sth like that as the same usrp2 with the same
>> settings is just working fine on another laptop with UHD_003.004.000 - 325-
>> g7e296167 revision.
>>
>> I don't really know what's the problem, may be I will try solving it by
>> monitoring the serial output.
>>
>> The thing that really attracted my attention is that sometimes there is a
>> connection and after just typing uhd_find_devices the connection is lost.
>>
>> Any other ideas guys?
>>
>> Thanks again,
>> George
>>
>> On Fri, Apr 13, 2012 at 2:00 AM, Josh Blum  wrote:
>>
>>>
>>>
>>> On 04/12/2012 05:15 PM, George Sklivanitis wrote:
>>> > Hello everyone,
>>> >
>>> > The last 2 days I am dealing with a problem of using gnuradio with
>>> USRP2s.
>>> >
>>> > I have successfully installed both gnuradio and uhd using the
>>> > build-gnuradio scipt into 3 brand new core i-7 laptops.
>>> >
>>> > However, after using the default usrp2_card_burner gui for burning the
>>> > firmware and fpga images into a Kingston 2GB SD card provided with the
>>> > USRP2 I cannot find the USRP2 device neither when using the command
>>> > uhd_find_devices nor by doing ping in 192.168.10.2. Sometimes USRP2
>>> appears
>>> > to be found but afterwards the communication is compromised. I have
>>> also
>>> > tried disabling the firewall of ubuntu but nothing changed.
>>> >
>>> > Are there any new images for UHD_003.004.001-27-g93d4a16f revision in
>>> the
>>> > main branch that I am not aware of?
>>> >
>>>
>>> Few things I can think of:
>>>
>>> 1) Do you see this boot sequence on power up?
>>> https://www.youtube.com/watch?v=REDK7M-83WQ
>>>
>>> 2) Do you see the green LED on the ethernet jack go on?
>>>
>>> 3) The serial port can also help:
>>>
>>> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#monitor-the-serial-output
>>>
>>> 4) ethernet configured? just a thought:
>>> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking
>>>
>>> -Josh
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Sklivanitis Georgios
>> Postgraduate Student
>> Telecommunications Division
>> Technical University of Crete
>> ECE Dept.
>> Tel. : 28210 59257
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257




-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with FW and FPGA images

[George Sklivanitis]

Hi Josh,

I think you may be right, but neither ifconfig eth0 nor dmesg reports an
error.

Furthermore, the drivers and operating systems running in both laptops are
the same. It's UBUNTU 11.04 in some Toshiba Satellite laptops.

Any other ideas guys?

Thanks so much for your help.
George

On Fri, Apr 13, 2012 at 2:32 AM, Josh Blum  wrote:

>
>
> On 04/12/2012 11:12 PM, George Sklivanitis wrote:
> > Hi Josh,
> >
> > The sequence of the LEDs is D and F coming green just in the same way as
> > the video apart from the B led where I cannot see why to come green?
> >
> > The ethernet is properly configured.
> >
> > The green led on the ethernet also goes on. There is no way that the
> > ethernet jack is faulty or sth like that as the same usrp2 with the same
> > settings is just working fine on another laptop with UHD_003.004.000 -
> 325-
> > g7e296167 revision.
> >
> > I don't really know what's the problem, may be I will try solving it by
> > monitoring the serial output.
> >
> > The thing that really attracted my attention is that sometimes there is a
> > connection and after just typing uhd_find_devices the connection is lost.
> >
>
> I think you have isolated the problem. Sounds like the laptop has a
> buggy ethernet port/ethernet driver. When the connection is lost:
>
> Do you have to run ifconfig ethx  again?
>
> Does ifconfig ethx report errors?
>
> Does dmesg report errors?
>
> -Josh
>



-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Tweaking digital_bert_tx and digital_bert_rx

[George Sklivanitis]

Hello everyone,

Lately, I have been trying to tweak the way both digital_bert_tx and
digital_bert_rx are working by introducing in the transmitter side my own
generated random .dat file instead of transmitting an infinite vector of
ones (default) while at the receiver side I consider the transmitted data
known and I am making use of the error_rate block for evaluating the Bit
Error Rate.

However, the file source that I am using as a reference input in my error
rate block at the receiver seems to introduce overflows after some time at
the receiver as I am repeatedly giving as an input a predefined randomized
sequence of bytes. Moreover, using a scope sink at the output of the
error_rate block I get probability of error close to 1/2 either
transmitting or not.

Does anybody have an idea of what could be the problem in the above
scenario or even better has tried something similar in the past?

Thanks,
George

The experiment takes place in the latest revision of both gnuradio and UHD,
Ubuntu 11.04-64bit in Intel core-i7 laptops.


-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help using UCLA Zigbee PHY examples updated for UHD

[George Nychis]

Henry, If you are able to update this code for UHD, please consider
committing your changes to CGRAN so others don't have to go through the
same process :)

https://www.cgran.org/wiki/UCLAZigBee



On Tue, May 15, 2012 at 7:01 PM, Josh Blum  wrote:

>
> > File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ucla_blks/ieee802_15_4_pkt.py",
> line 241, in __init__
> > self._watcher = _queue_watcher_thread(self._rcvd_pktq,
> self.callback, self.chan_num)
> >  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line
> 50, in __getattr__
> > return getattr(self._hb, name)
> >AttributeError: 'gr_hier_block2_sptr' object has no attribute
> 'chan_num'
> >
>
> Looks like a pretty strait forward error. There is no chan_num
> attribute. So what class is "self" and why is it missing chan_num? How
> does chan_num get initialized?
>
> Perhaps there is a command line option you are not passing, and there
> isnt any input checking/sanitation, so the error falls all the way
> through to this part of the code.
>
> -josh
>
> ___
> 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] Dynamic parameter modification in a custom block

[George Sklivanitis]

Hello all,

I am dealing with the problem of finding a way to dynamically give values
to a parameter of a custom block that I 've made in gnuradio
by the output of another custom block.
The solution of function probe that I have found in previous conversations
in the forum does not fit me as the value to be changed dynamically is
entered ad-hoc by the user.
I will try to simplify my problem to the rest of the community by giving
the following example
let us assume the following flowgraph implementation

signal_source -> custom_block(arg amplitude) -> file_sink  (1)

file_source -> custom_block2  -> file_sink  (2)

Would it be possible to use as the amplitude argument in (1) the output of
the custom_block2 in (2).

Thanks
-George

-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CGRAN downtime - working on it

[George Nychis]

Having some issues with CGRAN right now and actively working on it.  So if
you experience problems, hang in there.

The SVN repo should be working just fine, but having some web issues.

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

Re: [Discuss-gnuradio] CGRAN downtime - working on it

[George Nychis]

Back alive... if anyone has issues please let me know.

On Mon, Jun 4, 2012 at 11:42 AM, George Nychis  wrote:

> Having some issues with CGRAN right now and actively working on it.  So if
> you experience problems, hang in there.
>
> The SVN repo should be working just fine, but having some web issues.
>
> - George
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: Dynamic parameter modification in a custom block

[George Sklivanitis]

Any ideas guys?

-- Forwarded message --
From: George Sklivanitis 
Date: Mon, Jun 4, 2012 at 12:08 AM
Subject: Dynamic parameter modification in a custom block
To: discuss-gnuradio@gnu.org


Hello all,

I am dealing with the problem of finding a way to dynamically give values
to a parameter of a custom block that I 've made in gnuradio
by the output of another custom block.
The solution of function probe that I have found in previous conversations
in the forum does not fit me as the value to be changed dynamically is
entered ad-hoc by the user.
I will try to simplify my problem to the rest of the community by giving
the following example
let us assume the following flowgraph implementation

signal_source -> custom_block(arg amplitude) -> file_sink  (1)

file_source -> custom_block2  -> file_sink  (2)

Would it be possible to use as the amplitude argument in (1) the output of
the custom_block2 in (2).

Thanks
-George

-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257




-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dynamic parameter modification in a custom block

[George Sklivanitis]

Thank you so much for the response Michael.
I will try to figure out what's going on with both ways and I will post
updates to the list too.

Thanks,
George

On Mon, Jun 4, 2012 at 2:30 PM, Michael Dickens  wrote:

> Hi George - I believe there are 2 possible solutions, though I've never
> used or tested either myself.  If you just want to verify that what you
> want to do works, I think (1) should be quite straight forward.
>
> 1) This method will certainly work, but it's not very robust : Make your
> "custom_block2" take an argument which is of the "custom_block1" smart
> pointer type, such that the amplitude can be set any time the former
> performs the computation to do so.  Instantiation of the "custom_block2"
> would take a smart pointer to the "custom_block1", and then store that
> reference for future use; because this is a C++ object, just use "." or
> "->" to access the object's variable or method.
>
> 2) I don't know if stream tags are in place well enough yet, nor if they
> would work in the manner you require.  The idea is that there's a tag plane
> (sort of like a control plane) that "overlays" (or is in parallel with) the
> graph (data-flow) plane, where tags can be inserted -- a timestamp, or a
> value that might get used downstream.  Since "custom_block1" isn't
> downstream from "custom_block2", tags might not work.  Maybe there's a
> branch for this sort of non-downstream async control?
>
> Hope this helps; good luck! - MLD
>
> On Jun 4, 2012, at 3:52 PM, George Sklivanitis wrote:
> > I am dealing with the problem of finding a way to dynamically give
> values to a parameter of a custom block that I 've made in gnuradio
> > by the output of another custom block.
> > The solution of function probe that I have found in previous
> conversations in the forum does not fit me as the value to be changed
> dynamically is entered ad-hoc by the user.
> > I will try to simplify my problem to the rest of the community by giving
> the following example
> > let us assume the following flowgraph implementation
> >
> > signal_source -> custom_block(arg amplitude) -> file_sink  (1)
> >
> > file_source -> custom_block2  -> file_sink  (2)
> >
> > Would it be possible to use as the amplitude argument in (1) the output
> of the custom_block2 in (2).
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Sklivanitis Georgios
Postgraduate Student
Telecommunications Division
Technical University of Crete
ECE Dept.
Tel. : 28210 59257
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[George Nychis]

Hi all,

I'm observing some odd behavior that I can't seem to figure out.  This is
in (your favorite script) tunnel.py

Here, self.sink is instantiated as a uhd_transmitter() and then self.source
is a uhd_receiver().  Both are connected respectively to their part of the
flow graph:
https://github.com/gnychis/gnuradio-3.5.0-dmr/blob/b3b9be2380553706f152fbf4ffee6804aef8525c/gr-digital/examples/ofdm/tunnel.py#L54

The weird thing that I am observing is that whichever (uhd_transmitter or
uhd_receiver) is instantiated _last_ is the part of the flow graph that
operates properly.  If the receiver is instantiated last, the receiver is
able to receive packets (from another device) without a problem, but the
transmitted packets are unable to be decoded by a standalone receiver (a
different device running a receiver only).  It is actually transmitting (we
see power out of the antenna), but whatever it is transmitting is
undecodable by our receiver.

If you instantiate the transmitter before the receiver, then the
transmitter works just fine and our standalone receiver can receive its
packets.  But, this breaks the uhd_receiver() running on the transceiving
device.

Has anyone else observed this?  I have double checked that both are setting
the sampling rates, independent of which is instantiated first (bandwidth
is the same)... so I'm a little confused what would make the difference
here.

Thanks a bunch!

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

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[George Nychis]

A little more information about this...

The UHD version is 003.004.000-322fb97.
Daughterboard: xcvr2450
usrp: n200

Interestingly, what seems to break things is the call to set_freq().  If I
comment out the set_freq() in the instantiation of the receiver, the
transmitter will work.  If I comment it out in the instantiation of the
transmitter, the receiver will work.  This is despite both calls to
set_freq() taking the same frequency.  This must trigger whatever tuning is
happening that breaks the opposing chain.

Trying a newer version of UHD now...

On Thu, Jun 14, 2012 at 4:12 PM, George Nychis  wrote:

> Hi all,
>
> I'm observing some odd behavior that I can't seem to figure out.  This is
> in (your favorite script) tunnel.py
>
> Here, self.sink is instantiated as a uhd_transmitter() and then
> self.source is a uhd_receiver().  Both are connected respectively to their
> part of the flow graph:
>
> https://github.com/gnychis/gnuradio-3.5.0-dmr/blob/b3b9be2380553706f152fbf4ffee6804aef8525c/gr-digital/examples/ofdm/tunnel.py#L54
>
> The weird thing that I am observing is that whichever (uhd_transmitter or
> uhd_receiver) is instantiated _last_ is the part of the flow graph that
> operates properly.  If the receiver is instantiated last, the receiver is
> able to receive packets (from another device) without a problem, but the
> transmitted packets are unable to be decoded by a standalone receiver (a
> different device running a receiver only).  It is actually transmitting (we
> see power out of the antenna), but whatever it is transmitting is
> undecodable by our receiver.
>
> If you instantiate the transmitter before the receiver, then the
> transmitter works just fine and our standalone receiver can receive its
> packets.  But, this breaks the uhd_receiver() running on the transceiving
> device.
>
> Has anyone else observed this?  I have double checked that both are
> setting the sampling rates, independent of which is instantiated first
> (bandwidth is the same)... so I'm a little confused what would make the
> difference here.
>
> Thanks a bunch!
>
> - George
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[George Nychis]

Hi Josh,

Thanks a bunch for these pointers/patches and looking in to it!  We are
currently testing them out, shouldn't take long.  However, we did verify
that reverting to the older version (003.003.002) did work for us as it did
for King (thanks!).

Stay tuned... we'll let you know ASAP.

- George


On Mon, Jun 18, 2012 at 1:51 PM, Josh Blum  wrote:

>
> > Thanks for the tip. I think I figured it out.
> >
> > The property to use an LO offset was true for TX and not RX. This would
> > mean that tuning an individual chain and using it would be fine; but
> > since there is a shared LO, the offset would not be compensated for by
> > the DSP on the chain in the other direction, hence, it not working.
> >
> > If you dont mind trying, here is a simple 1 liner patch:
> > http://pastebin.com/KiR3e6j0
> >
>
> Another quick way to test this without the patch would be to tell the
> tune request to use an LO offset of 0. Example:
>
> usrp_source/sink.set_center_frequency(uhd.tune_request(my_freq, 0))
>
> -josh
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[George Nychis]

Your attached patch also fixes the problem!  Thanks a bunch for helping
narrow down this issue :)

On Mon, Jun 18, 2012 at 3:59 PM, George Nychis  wrote:

> Hi Josh,
>
> Thanks a bunch for these pointers/patches and looking in to it!  We are
> currently testing them out, shouldn't take long.  However, we did verify
> that reverting to the older version (003.003.002) did work for us as it
> did for King (thanks!).
>
> Stay tuned... we'll let you know ASAP.
>
> - George
>
>
> On Mon, Jun 18, 2012 at 1:51 PM, Josh Blum  wrote:
>
>>
>> > Thanks for the tip. I think I figured it out.
>> >
>> > The property to use an LO offset was true for TX and not RX. This would
>> > mean that tuning an individual chain and using it would be fine; but
>> > since there is a shared LO, the offset would not be compensated for by
>> > the DSP on the chain in the other direction, hence, it not working.
>> >
>> > If you dont mind trying, here is a simple 1 liner patch:
>> > http://pastebin.com/KiR3e6j0
>> >
>>
>> Another quick way to test this without the patch would be to tell the
>> tune request to use an LO offset of 0. Example:
>>
>> usrp_source/sink.set_center_frequency(uhd.tune_request(my_freq, 0))
>>
>> -josh
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Remove USRP filters.

[George Nychis]

Hey Michael,

I just purchased an Ubertooth One and it came in the mail today, pumped to
play around with it!  I was excited to find the project.  It fills in a
huge gap of commodity bluetooth sensing.

In downloading the ubertooth code, I stumbled in to your gr-bluetooth code
and then just so happened to find this thread active here.  You should
consider putting gr-bluetooth up on CGRAN (https://www.cgran.org).  It's
where a lot of GNU Radio users go to find projects, and I know that this is
one a lot of people would like to use, and possibly keep up to date!

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

[Discuss-gnuradio] CGRAN now breaking projects in to categories, feedback wanted!

[George Nychis]

Hi all,

CGRAN has grown significantly beyond my expectations over the past 4 years!
 It started off as two personal projects with the hope of providing
somewhere for people to develop applications outside of the main GNU Radio
code base.  Now we have 38 projects and a few others in development but not
listed!

However, this growth has made our "project list" page a nightmare:
daunting/challenging to parse through.  So, I've attempted to break it down
in to categories:
https://www.cgran.org/wiki/Projects

I'd really like your feedback on the categories.  The "Applications"
category name is me, but I really couldn't think of how to describe
these projects which don't fall anywhere else.  The way I broke down the
standards is decent, but maybe there is a better way to describe "other
standards" or maybe not use "consumer" standards as a heading.  But, I
definitely see some separation there.  Trying to nail down what it is, and
could use your help!

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

Re: [Discuss-gnuradio] CGRAN "release tagging"

[George Nychis]

If there is anything fundamentally that I can change about the CGRAN
repository to help, let me know!

On Thu, Sep 13, 2012 at 4:00 PM, Richard Farina  wrote:

> On 09/13/2012 03:31 PM, mle...@ripnet.com wrote:
> >
> >
> > I've tried, and failed to tag the current version of multimode on
> > CGRAN to allow distributions like pentoo to pick it up by release tag
> FYI, I actually put it in mainstream gentoo earlier this week so that
> more than my users have access :-)
>
> Thanks,
> Zero
> > identifier. Have others who are using CGRAN as their SVN repo had a
> > problem tagging/branching?
> >
> > If you've been successful, could you
> > perhaps hit me in the head with some clue?
> >
> > -Marcus
> >
> >
> >
> >
> >
> > ___
> > 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] CGRAN: some traffic statistics, top projects, call for new projects!

[George Nychis]

Hey all,

I hope you're enjoying #grhack with your airhorn ;)

CGRAN (https://cgran.org) still continues to grow, and its traffic far
exceeds ever what I thought it was.  Here are some numbers:


   - *Page Views Per Day:  *~1000+
   - *Unique Visitors: *1,598 (in 1 week)
   - *Demographics:  *visitors from 83 countries, top 3:  US, Canada,
   Germany
   - *Registered Users Accounts: * 311
   - *"Project Page <https://www.cgran.org/wiki/Projects>" Views Per Day:  ~
   *100
   - *Top 5 Projects (in past week):  *1) Mode S
Receiver<https://www.cgran.org/wiki/gr-air-modes>,
   2) Funcube Dongle <https://www.cgran.org/wiki/FuncubeDongle>, 3)
AIS<https://www.cgran.org/wiki/AIS>,
   4) RDS <https://www.cgran.org/wiki/RDS>, 5)
Smartnet<https://www.cgran.org/wiki/Smartnet>

So, either Nick uses botnets to refresh his project pages, or we should
thank him for providing 3 of the top 5 projects ;)  To give a traffic
perspective, Mode S Receiver gets ~80 hits a day, whereas Smartnet gets
around 12 hits a day.

I hope this shows that CGRAN is still very active, and in fact growing.
 People do visit it quite often to see what kind of GNU Radio projects
there are out there.  So, *please* *keep building on it!*  People will find
your projects this way.

Note, you do not have to use the SVN repository.  You are free to create a
project page and link to external code sources (e.g., github).

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

[Discuss-gnuradio] SRRC pulse shaping question

[George Sklivanitis]

Hello all,

I have a question applying to everybody that have tried transmitting
symbols in different kinds of modulation (BPSK, QPSK, GMSK etc).
I am using the following configuration in GNU Radio ( random source block
-> bytes to symbols -> SRRC block -> file sink)

The attached figure plots the generated symbols (+1,-1)  with red color
along with the upsampled SRRC waveform (blue)
For some reason that I am not able to understand the last 8-bits do not
have a correspondence with the waveform created. In other words
the waveform is "cut" at the last byte.
Can anyone help me with the above.

Thanks,
-George

-- 
Sklivanitis Georgios
PhD Student
<>___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SRRC pulse shaping question

[George Sklivanitis]

The filter is consisted of 55 taps.
I tried by sending zeros. Though zeros are interpreted in -1's from the 
modulation mapping block.
Moreover, the zeros will be taken into account as symbols to be shaped, 
therefore, the same thing will happen.


-George

On 12/5/12 12:07 AM, Brian Padalino wrote:
Have you taken into account the group delay of the filter?  How long 
is your filter?  Try sending zeroes at the end to flush your filter 
state?


Brian


On Tue, Dec 4, 2012 at 11:35 PM, George Sklivanitis 
mailto:george.sklivani...@gmail.com>> 
wrote:


Hello all,

I have a question applying to everybody that have tried
transmitting symbols in different kinds of modulation (BPSK, QPSK,
GMSK etc).
I am using the following configuration in GNU Radio ( random
source block -> bytes to symbols -> SRRC block -> file sink)

The attached figure plots the generated symbols (+1,-1) with red
color along with the upsampled SRRC waveform (blue)
For some reason that I am not able to understand the last 8-bits
do not have a correspondence with the waveform created. In other words
the waveform is "cut" at the last byte.
Can anyone help me with the above.

Thanks,
-George

-- 
Sklivanitis Georgios

PhD Student

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





--
Sklivanitis Georgios
Ph.D Student
Communications Division,
Department of Electronics and Electrical Engineering
University at Buffalo, The State University of New York
North Campus, Office 205, Furnas Hall
Buffalo, NY 14260
www.acsu.buffalo.edu/~gsklivan

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

Re: [Discuss-gnuradio] SRRC pulse shaping question

[George Sklivanitis]

I think this means creating a new block as I cannot come up with a quick 
way of implementing the above.

In any case, thanks much.

-George

On 12/5/12 12:27 AM, Brian Padalino wrote:
You'll need to figure out how to flush the filter state and send 
actual 0+0j samples through.  Maybe you can set a flag and multiply 
the samples coming out by 1 or 0 depending if you are flushing or not?


Brian


On Wed, Dec 5, 2012 at 12:11 AM, George Sklivanitis 
mailto:george.sklivani...@gmail.com>> 
wrote:


The filter is consisted of 55 taps.
I tried by sending zeros. Though zeros are interpreted in -1's
from the modulation mapping block.
Moreover, the zeros will be taken into account as symbols to be
shaped, therefore, the same thing will happen.

-George


On 12/5/12 12:07 AM, Brian Padalino wrote:

Have you taken into account the group delay of the filter?  How
long is your filter?  Try sending zeroes at the end to flush your
filter state?

Brian


On Tue, Dec 4, 2012 at 11:35 PM, George Sklivanitis
mailto:george.sklivani...@gmail.com>> wrote:

Hello all,

I have a question applying to everybody that have tried
transmitting symbols in different kinds of modulation (BPSK,
QPSK, GMSK etc).
I am using the following configuration in GNU Radio ( random
source block -> bytes to symbols -> SRRC block -> file sink)

The attached figure plots the generated symbols (+1,-1)  with
red color along with the upsampled SRRC waveform (blue)
For some reason that I am not able to understand the last
8-bits do not have a correspondence with the waveform
created. In other words
the waveform is "cut" at the last byte.
Can anyone help me with the above.

Thanks,
-George

-- 
Sklivanitis Georgios

PhD Student

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





-- 
Sklivanitis Georgios

Ph.D Student
Communications Division,
Department of Electronics and Electrical Engineering
University at Buffalo, The State University of New York
North Campus, Office 205, Furnas Hall
Buffalo, NY 14260
www.acsu.buffalo.edu/~gsklivan  <http://www.acsu.buffalo.edu/%7Egsklivan>





--
Sklivanitis Georgios
Ph.D Student
Communications Division,
Department of Electronics and Electrical Engineering
University at Buffalo, The State University of New York
North Campus, Office 205, Furnas Hall
Buffalo, NY 14260
www.acsu.buffalo.edu/~gsklivan

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

[Discuss-gnuradio] Custom block one input/output variable number of output/inputs

[George Sklivanitis]

Hello everybody,

In the following case study gr_file_source-> pll_clock_sync->
gr_complex_to_float -> custom_block(1 input, 2outputs) in gnuradio, by
printing the counter of noutput_items of my custom block, I observe that it
reaches a multiple of 2 samples then it gets to zero and restarts again.
Overall the number of output samples are the expected ones but why the
counter over the item restarts at some time instants?

Thanks,
-George


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

[Discuss-gnuradio] Fwd: Custom block one input/output variable number of output/inputs

[George Sklivanitis]

Hello everybody,

In the following case study gr_file_source-> pll_clock_sync->
gr_complex_to_float -> custom_block(1 input, 2outputs) in gnuradio, by
printing the counter of noutput_items of my custom block, I observe that it
reaches up to a number of samples then it gets to zero and restarts again.
Overall the number of output samples is the expected ones but why the
counter over the noutput_items restarts at some time instants?

Thanks,
-George


-- 
Sklivanitis Georgios
Postgraduate Student





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

[Discuss-gnuradio] Gr_Extras Packet_Framer problem

[George Sklivanitis]

Hello all,

I have just installed the Extras package and trying to use the Packet
Framer.
By using a gr_vector_f -> float_to_short -> Stream_to_Blobs ->
Packet_Framer ->  GMSK Mod
i get the following error

gr_fir_fff: using SSE
Uhandler caught exception: in method
'gr_block_gw_message_type_work_args_return_value_set', argument 2 of type
'int'
Traceback (most recent call last):
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/extras/block_gateway.py",
line 53, in eval
try: self._callback()
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/extras/block_gateway.py",
line 124, in __gr_block_handle
) for i in self.__out_indexes],
TypeError: in method 'gr_block_gw_message_type_work_args_return_value_set',
argument 2 of type 'int'
thread[thread-per-block[5]: ]: caught unrecognized
exception


any suggestions on how to resolve this. I also saw Josh's proposal in Guy's
similar problem but didn't work for me.

Thanks,
-George

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