Re: [Discuss-gnuradio] fastnoise_source is not thread-safe

[Paul Wicks]

>
> I'm also wondering whether C++11 is allowed in gnuradio.


C++ 11 is supported in the next branch:
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-10/msg00152.html

-Paul Wicks

On Thu, Jan 25, 2018 at 3:45 PM, Markus Wirsing 
wrote:

> Hello,
>
> I noticed that the fastnoise_source block is not thread safe, as it
> calls rand(), which keeps global state.
> This makes it non-reproducable between multiple runs once more than one
> such source is used.
>
> I also opened an issue about this on github:
> https://github.com/gnuradio/gnuradio/issues/1542
> However, there were no reactions to it.
>
> I'm considering to write a fix for it when I find the time.
> However, I'm not sure about the requirements that need to be met that it
> can later be included in gnuradio.
>
> Would this already require me to have a CRA?
> I'm also wondering whether C++11 is allowed in gnuradio.
> I guess it is not as I found this message on the mailing list:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00014.html
> It might be worth mentioning that on the coding guide in the wiki though:
> https://wiki.gnuradio.org/index.php/Coding_guide_impl
> It also might be worth considering to change that rule.
> C++11 is pretty well supported by now. And it does add some nice features.
>
> I think the easiest fix would be to use random::ran_int() in place of
> rand() or lrand48(). That way it would also be possible to get rid of
> the (slightly) biased method of using a linear congruence to reduce the
> range.
>
> However, while looking at the code in random.cc
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-
> runtime/lib/math/random.cc
> I noticed that it keeps raw pointers to the different random generators.
> I don't see why this is done. If I don't misunderstand anything, it
> would work equally well to have the objects as members in the class.
> With the added benefit of having them correctly deconstructed in the
> case of exceptions. Even though that may not be of much relevance in
> this case.
> But it at least would make sense to use unique pointers instead of raw
> pointers.
> So if I find the time to create a fix for the other problem, would some
> cleanup in this place be appreciated too?
>
> I have no experience so far with submitting code to open source projects.
> These issues seem to be a good starting point. However, before investing
> time, I want to make sure my work can actually be used.
>
> Appreciating any feedback on the proposed changes and on the necessary
> formalities,
> Markus
>
> ___
> 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] fastnoise_source is not thread-safe

[Markus Wirsing]

Hello,

I noticed that the fastnoise_source block is not thread safe, as it
calls rand(), which keeps global state.
This makes it non-reproducable between multiple runs once more than one
such source is used.

I also opened an issue about this on github:
https://github.com/gnuradio/gnuradio/issues/1542
However, there were no reactions to it.

I'm considering to write a fix for it when I find the time.
However, I'm not sure about the requirements that need to be met that it
can later be included in gnuradio.

Would this already require me to have a CRA?
I'm also wondering whether C++11 is allowed in gnuradio.
I guess it is not as I found this message on the mailing list:
https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00014.html
It might be worth mentioning that on the coding guide in the wiki though:
https://wiki.gnuradio.org/index.php/Coding_guide_impl
It also might be worth considering to change that rule.
C++11 is pretty well supported by now. And it does add some nice features.

I think the easiest fix would be to use random::ran_int() in place of
rand() or lrand48(). That way it would also be possible to get rid of
the (slightly) biased method of using a linear congruence to reduce the
range.

However, while looking at the code in random.cc
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/math/random.cc
I noticed that it keeps raw pointers to the different random generators.
I don't see why this is done. If I don't misunderstand anything, it
would work equally well to have the objects as members in the class.
With the added benefit of having them correctly deconstructed in the
case of exceptions. Even though that may not be of much relevance in
this case.
But it at least would make sense to use unique pointers instead of raw
pointers.
So if I find the time to create a fix for the other problem, would some
cleanup in this place be appreciated too?

I have no experience so far with submitting code to open source projects.
These issues seem to be a good starting point. However, before investing
time, I want to make sure my work can actually be used.

Appreciating any feedback on the proposed changes and on the necessary
formalities,
Markus

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

Re: [Discuss-gnuradio] OFDM channel tap questions

[Robert McGwier]

Orthogonality (as the O in OFDM) guarantees a fixed phase relationship for
every symbol unless a pattern is introduced in an effort to reduce peak to
average power ratio (which I do not believe is happening here).  PAPR is
bane of OFDM and much research has gone in to reduce this problem which
requires high linearity in the amplifiers in cell towers.  Linearity is
typically accompanied by poor efficiency (lots of heat goes along with
watts).

In addition to this ,  there is indeed a random process involved in the
synchronization.  Schmidl-Cox is imperfect and "fine tuning" of the
sampling phase also has some randomness.  On the air you will have phase
offsets due to frequency dependent group delay through the analog
components of the RF systems,  group delay due to multipath, and on and
on.  I didn't open your grc file but I assume this was the perfect "wire"
channel with additive noise in which case ignore all of the other analog
stuff I added.

Bob


On Fri, Jan 12, 2018 at 2:22 PM, Jeff Long  wrote:

> Ah, normalization was the secret. The phase offset is there because the
> subcarriers frequencies each look like a phasor that keeps moving (at a
> rate relative to its offset). You want to predict what the phase will be at
> the next symbol.
>
>
> On 01/12/2018 01:59 PM, edwin wrote:
>
>> Hi Jeff,
>>
>> I just found out that if I normalize these taps by the FFT number(64 in
>> this case), they have magnitude of 1! Now my questions are:
>>
>> Why are there phase offset? The phase offset for each subchannel seems
>> different. Is it because of imperfect synchronization?
>>
>>
>> Regards,
>>
>> Edwin
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
Research Professor Virginia Tech
Chief Scientist:  The Ted and Karyn Hume Center for National Security and
Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn, Trustee K4KDJ
Director of AMSAT
Member of PVRC (Roanoke-Blacksburg), TAPR,  life member of ARRL and AMSAT,
NRVR.ORG (Rocketry)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP N210, sometimes, cannot receive packets

[Jeff Long]

Try breaking this up into 3 separate programs and start the receivers
first. It might be that the receivers aren't even getting started before
the transmitter is done.

On Thu, Jan 25, 2018 at 8:38 AM, Kurniawan Irianto 
wrote:

> Hi Jeff,
>
> I am really sorry for the unclear description of my setup. I build my
> program on python so I don't have GRC file but the flowgraph is similar to
> the attached GRC file.
>
> Maybe this could make more clear about my setup. I have 3 USRP nodes
> (N210s) that act like Source and 2 Sinks. I connect the USRPs to a PC
> (Personal Computer) through a switch. At the USRPs, there is no GPSDO. I
> run the USRPs in one flowgraph and from a PC. Hopefully, the attached GRC
> file will make it clear about my program.
>
> Thank you so much for your time.
>
> Kirianto
>
>
> On 25 January 2018 at 12:45, Jeff Long  wrote:
>
>> I can't understand your setup from the description, maybe a GRC file or
>> source code would help. In any case, it sounds like you may have 3 USRPs
>> tied together in one flowgraph, which could cause a problem.
>>
>> On Thu, Jan 25, 2018 at 6:13 AM, Kurniawan Dwi Irianto <
>> kdwiiria...@gmail.com> wrote:
>>
>>> Hi Jeff,
>>>
>>> Thank you for your quick response. I didn't do anything with the clock
>>> sync since I don't have gpsdo embedded on the N210 or any sync devices. I
>>> just used the normal setting for usrp_source and usrp_sink. I set up the
>>> antenna for  tx gain to 35 and rx_gain to 15. I assume the clock sync is
>>> the problem. And for the sample rate, I used 2 Msps. For the flowgraph, I
>>> used file source block for the data I want to transmit and source sink
>>> block to receive the data. If the the sink nodes could receive the packets,
>>> I could see and read the file from the source node. My program is in no GUI
>>> mode, so I can only read the file. If the sink can receive the packets, I
>>> can read the file without any errors. But sometimes it cannot receive any
>>> packets. I am not sure. Perhaps it can receive the signal but cannot decode
>>> the packets.
>>>
>>> Thanks again for your feedbacks.
>>>
>>> Kirianto
>>>
>>>
>>> On 25 January 2018 at 11:51, Jeff Long  wrote:
>>>
 How are the clocks in the N210s synced? What rates are you using? What
 symptoms are you seeing that tell you the sinks are not receiving packets?

 On Thu, Jan 25, 2018 at 5:34 AM, Kurniawan Dwi Irianto <
 kdwiiria...@gmail.com> wrote:

> Hallo guys,
>
> I have a configuration using gnuradio-companion as follows;
>
> #  #  #
> # sink_1 #  <- - - - -  # source #- - - - - --># sink_0  #
> #  #  #
>
> The devices I am using are USRP N210s and it is with SBX daughterboard
> and without GPSDO. The distance between the nodes is 1 meter. I use BPSK
> Modulation to transmit the packets and the frequency is 2.485 GHz. I would
> like to broadcast packets from source to sink_0 and sink_1. One of the 
> sink
> can receive the packet but the other one hardly can. In 10 times run of 
> the
> program, both of the sink can successfully receive the packets only 1 or 2
> times. Most of the run, only one sink can receive the packets. Moreover, 
> If
> I disable one of the sink and run of the program to transmit the packet
> from source to sink. In the 10 times run, the sink can receive it only 5 
> or
> 6 times. There are 4 times it fail to receive the packets. I have known 
> yet
> where is the problem. Any suggestion would be helpful.
>
> Thank you in advance.
>
> Best regard,
> Kirianto
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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


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

Re: [Discuss-gnuradio] USRP N210, sometimes, cannot receive packets

[Jeff Long]

I can't understand your setup from the description, maybe a GRC file or
source code would help. In any case, it sounds like you may have 3 USRPs
tied together in one flowgraph, which could cause a problem.

On Thu, Jan 25, 2018 at 6:13 AM, Kurniawan Dwi Irianto <
kdwiiria...@gmail.com> wrote:

> Hi Jeff,
>
> Thank you for your quick response. I didn't do anything with the clock
> sync since I don't have gpsdo embedded on the N210 or any sync devices. I
> just used the normal setting for usrp_source and usrp_sink. I set up the
> antenna for  tx gain to 35 and rx_gain to 15. I assume the clock sync is
> the problem. And for the sample rate, I used 2 Msps. For the flowgraph, I
> used file source block for the data I want to transmit and source sink
> block to receive the data. If the the sink nodes could receive the packets,
> I could see and read the file from the source node. My program is in no GUI
> mode, so I can only read the file. If the sink can receive the packets, I
> can read the file without any errors. But sometimes it cannot receive any
> packets. I am not sure. Perhaps it can receive the signal but cannot decode
> the packets.
>
> Thanks again for your feedbacks.
>
> Kirianto
>
>
> On 25 January 2018 at 11:51, Jeff Long  wrote:
>
>> How are the clocks in the N210s synced? What rates are you using? What
>> symptoms are you seeing that tell you the sinks are not receiving packets?
>>
>> On Thu, Jan 25, 2018 at 5:34 AM, Kurniawan Dwi Irianto <
>> kdwiiria...@gmail.com> wrote:
>>
>>> Hallo guys,
>>>
>>> I have a configuration using gnuradio-companion as follows;
>>>
>>> #  #  #
>>> # sink_1 #  <- - - - -  # source #- - - - - --># sink_0  #
>>> #  #  #
>>>
>>> The devices I am using are USRP N210s and it is with SBX daughterboard
>>> and without GPSDO. The distance between the nodes is 1 meter. I use BPSK
>>> Modulation to transmit the packets and the frequency is 2.485 GHz. I would
>>> like to broadcast packets from source to sink_0 and sink_1. One of the sink
>>> can receive the packet but the other one hardly can. In 10 times run of the
>>> program, both of the sink can successfully receive the packets only 1 or 2
>>> times. Most of the run, only one sink can receive the packets. Moreover, If
>>> I disable one of the sink and run of the program to transmit the packet
>>> from source to sink. In the 10 times run, the sink can receive it only 5 or
>>> 6 times. There are 4 times it fail to receive the packets. I have known yet
>>> where is the problem. Any suggestion would be helpful.
>>>
>>> Thank you in advance.
>>>
>>> Best regard,
>>> Kirianto
>>>
>>> ___
>>> 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] USRP N210, sometimes, cannot receive packets

[Kurniawan Dwi Irianto]

Hi Jeff,

Thank you for your quick response. I didn't do anything with the clock sync
since I don't have gpsdo embedded on the N210 or any sync devices. I just
used the normal setting for usrp_source and usrp_sink. I set up the antenna
for  tx gain to 35 and rx_gain to 15. I assume the clock sync is the
problem. And for the sample rate, I used 2 Msps. For the flowgraph, I used
file source block for the data I want to transmit and source sink block to
receive the data. If the the sink nodes could receive the packets, I could
see and read the file from the source node. My program is in no GUI mode,
so I can only read the file. If the sink can receive the packets, I can
read the file without any errors. But sometimes it cannot receive any
packets. I am not sure. Perhaps it can receive the signal but cannot decode
the packets.

Thanks again for your feedbacks.

Kirianto

On 25 January 2018 at 11:51, Jeff Long  wrote:

> How are the clocks in the N210s synced? What rates are you using? What
> symptoms are you seeing that tell you the sinks are not receiving packets?
>
> On Thu, Jan 25, 2018 at 5:34 AM, Kurniawan Dwi Irianto <
> kdwiiria...@gmail.com> wrote:
>
>> Hallo guys,
>>
>> I have a configuration using gnuradio-companion as follows;
>>
>> #  #  #
>> # sink_1 #  <- - - - -  # source #- - - - - --># sink_0  #
>> #  #  #
>>
>> The devices I am using are USRP N210s and it is with SBX daughterboard
>> and without GPSDO. The distance between the nodes is 1 meter. I use BPSK
>> Modulation to transmit the packets and the frequency is 2.485 GHz. I would
>> like to broadcast packets from source to sink_0 and sink_1. One of the sink
>> can receive the packet but the other one hardly can. In 10 times run of the
>> program, both of the sink can successfully receive the packets only 1 or 2
>> times. Most of the run, only one sink can receive the packets. Moreover, If
>> I disable one of the sink and run of the program to transmit the packet
>> from source to sink. In the 10 times run, the sink can receive it only 5 or
>> 6 times. There are 4 times it fail to receive the packets. I have known yet
>> where is the problem. Any suggestion would be helpful.
>>
>> Thank you in advance.
>>
>> Best regard,
>> Kirianto
>>
>> ___
>> 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] USRP N210, sometimes, cannot receive packets

[Jeff Long]

How are the clocks in the N210s synced? What rates are you using? What
symptoms are you seeing that tell you the sinks are not receiving packets?

On Thu, Jan 25, 2018 at 5:34 AM, Kurniawan Dwi Irianto <
kdwiiria...@gmail.com> wrote:

> Hallo guys,
>
> I have a configuration using gnuradio-companion as follows;
>
> #  #  #
> # sink_1 #  <- - - - -  # source #- - - - - --># sink_0  #
> #  #  #
>
> The devices I am using are USRP N210s and it is with SBX daughterboard and
> without GPSDO. The distance between the nodes is 1 meter. I use BPSK
> Modulation to transmit the packets and the frequency is 2.485 GHz. I would
> like to broadcast packets from source to sink_0 and sink_1. One of the sink
> can receive the packet but the other one hardly can. In 10 times run of the
> program, both of the sink can successfully receive the packets only 1 or 2
> times. Most of the run, only one sink can receive the packets. Moreover, If
> I disable one of the sink and run of the program to transmit the packet
> from source to sink. In the 10 times run, the sink can receive it only 5 or
> 6 times. There are 4 times it fail to receive the packets. I have known yet
> where is the problem. Any suggestion would be helpful.
>
> Thank you in advance.
>
> Best regard,
> Kirianto
>
> ___
> 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] USRP N210, sometimes, cannot receive packets

[Kurniawan Dwi Irianto]

Hallo guys,

I have a configuration using gnuradio-companion as follows;

#  #  #
# sink_1 #  <- - - - -  # source #- - - - - --># sink_0  #
#  #  #

The devices I am using are USRP N210s and it is with SBX daughterboard and
without GPSDO. The distance between the nodes is 1 meter. I use BPSK
Modulation to transmit the packets and the frequency is 2.485 GHz. I would
like to broadcast packets from source to sink_0 and sink_1. One of the sink
can receive the packet but the other one hardly can. In 10 times run of the
program, both of the sink can successfully receive the packets only 1 or 2
times. Most of the run, only one sink can receive the packets. Moreover, If
I disable one of the sink and run of the program to transmit the packet
from source to sink. In the 10 times run, the sink can receive it only 5 or
6 times. There are 4 times it fail to receive the packets. I have known yet
where is the problem. Any suggestion would be helpful.

Thank you in advance.

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