2025 IEEE Aerospace Conference

[Eugene Grayver]

Hello,



I am chairing the Software Defined and Cognitive Radio session at the upcoming 
IEEE Aerospace Conference (http://www.aeroconf.org<http://www.aeroconf.org/>).  
This large conference will take place March, 2025 in Big Sky, Montana.  The 
conference provides a world-class technical program and provides excellent 
opportunities for both networking and recreation. This is one of the few 
conferences where SDR can be put in the context of a complete system and can be 
applied to new missions and concepts of operations.

Abstracts are due now, but I can take them until August, while the full paper 
is due end of October.  This session will focus on flexible radio 
architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of 
existing systems and testbeds are of significant interest.  This year I’d like 
to introduce work related to machine learning as applied to wireless 
communications.



Please forward this to your colleagues working in the areas of SDR and 
cognitive radio.

Regards,

Eugene




Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

minor bug in control_loop.h

[Eugene Grayver]

Hi,

Found a minor (but annoying to track down!) bug in 
include/gnuradio/blocks/control_loop.h.

If the input is NaN, then neither of the if statements evaluates to true, and 
the program segfaults.

My company policy requires jumping through some hoops to make a direct github 
contribution.

I suggest a patch:

instead of 'int index', make it 'uint8_t index' and that will solve the 
segfault.

static inline float tanhf_lut(float x)
{
if (x > 2)
return 1;
else if (x <= -2)
return -1;
else {
int index = 128 + 64 * x;
return tanh_lut_table[index];
}
}

Eugene.

logging pattern

[Eugene Grayver]

Hi,

Is there a way to set the log message pattern in the new GR logging API (based 
on spdlog)?  I took a quick look at the code:
https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/logger.cc
and it appears that the pattern is always set to 'default_pattern.'

Separately, I see that the 'add_default_sink' function is exposed to Python.  
How can I use this?  I assume a C++ instance of a spdlog::sink is created.  The 
pointer must then be somehow brought into Python world.

Thanks.

RE: Adding an external static library to OOT module

[Eugene Grayver]

Please ignore this email.

From: Eugene Grayver
Sent: Tuesday, September 5, 2023 9:45 PM
To: 'discuss-gnuradio@gnu.org' 
Subject: Adding an external static library to OOT module

Hello,

I want to add an external library (say /home/user/libmy.a) to an OOT module.  
Note that this library is not  in the same folder structure as the oot-module. 
I can easily add it to the library in lib/CmakeFiles.txt.  However, it also 
needs to be added (AFAIK) to the CmakeFiles.txt in 
python/bindings/CmakeFiles.txt.  In the 'olden days' of 3.7, the SWIG-based 
built allowed me to add this.  However, the new GR_PYBIND_MAKE_OOT macro does 
not seem to allow it.

Any suggestions?

Thanks.

Adding an external static library to OOT module

[Eugene Grayver]

Hello,

I want to add an external library (say /home/user/libmy.a) to an OOT module.  
Note that this library is not  in the same folder structure as the oot-module. 
I can easily add it to the library in lib/CmakeFiles.txt.  However, it also 
needs to be added (AFAIK) to the CmakeFiles.txt in 
python/bindings/CmakeFiles.txt.  In the 'olden days' of 3.7, the SWIG-based 
built allowed me to add this.  However, the new GR_PYBIND_MAKE_OOT macro does 
not seem to allow it.

Any suggestions?

Thanks.

2024 IEEE Aerospace Conference

[Eugene Grayver]

Hello,



I am chairing the Software Defined and Cognitive Radio session at the upcoming 
IEEE Aerospace Conference (http://www.aeroconf.org<http://www.aeroconf.org/>).  
This large conference will take place March 2-9, 2024 in Big Sky, Montana.  The 
conference provides a world-class technical program and provides excellent 
opportunities for both networking and recreation. This is one of the few 
conferences where SDR can be put in the context of a complete system and can be 
applied to new missions and concepts of operations.

Abstracts are due now, but I can take them until August, while the full paper 
is due end of October.  This session will focus on flexible radio 
architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of 
existing systems and testbeds are of significant interest.  This year I’d like 
to introduce work related to machine learning as applied to wireless 
communications.



Please forward this to your colleagues working in the areas of SDR and 
cognitive radio.

Regards,

Eugene





Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

2023 IEEE Aerospace Conference

[Eugene Grayver]

Hello,



I am chairing the Software Defined and Cognitive Radio session at the upcoming 
IEEE Aerospace Conference (http://www.aeroconf.org<http://www.aeroconf.org/>).  
This large conference will take place March 4-11, 2023 in Big Sky, Montana.  
The conference provides a world-class technical program and provides excellent 
opportunities for both networking and recreation. This is one of the few 
conferences where SDR can be put in the context of a complete system and can be 
applied to new missions and concepts of operations.



Last year there were a few papers dealing with application of machine/deep 
learning to radio design.  I hope to see even more next year!

Abstracts are due soon, but I can take them a later as well, while the full 
paper is due end of October.  This session will focus on flexible radio 
architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of 
existing systems and testbeds are of significant interest.  This year I’d like 
to introduce work related to machine learning as applied to wireless 
communications.



Please forward this to your colleagues working in the areas of SDR and 
cognitive radio.

Regards,

Eugene





Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

Subtle issue (problem?) with channel_model2

[Eugene Grayver]

The channel model2 has the potential to lock up the flowgraph if the delay and 
frequency are provided from the same (two-output) sync_block.  The lockup 
happens after millions of samples for reasonable values of offset rate.  The 
frequency input is consumed by the 'VCO' block at a the output​​ rate of the 
resampler.  However, the timing input is consumed at the input​​ rate of the 
resampler.Given a sufficiently long simulation the frequency buffer can 
become full while the resampler buffer is empty (or vv).  This will take ~ 16k 
/ rate_offset.  I would suggest changing the order of the VCO and resampler.

Note that there is a slight difference in the output that would have to be 
accounted for when computing the frequency (negligible for 99.99% of 
applications).




Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

Re: Block alias

[Eugene Grayver]

core/generator/flow_graph.py.mako:214

self.${blk.name}.set_block_alias(${blk.params['alias'].get_evaluated()})

Just remove quotes.  NOTE: this WILL BREAK any existing flowgraphs that set the 
block alias, and they will have to add quotes around the current block alias.  
I can't think of any way to preserve backward compatibility.

While we are on the subject of aliases, can we also make a one-line change to 
set the thread name based on the alias rather than the block name!




Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274



From: Paul Atreides 
Sent: Wednesday, September 1, 2021 1:46 PM
To: Eugene Grayver 
Cc: discuss-gnuradio@gnu.org 
Subject: Re: Block alias


Which one line in GRC should be changed?

I’d be happy to help you submit a pull request for the one line that needs to 
be changed.

You can message me directly if you’d like help with that.



On Sep 1, 2021, at 13:58, Eugene Grayver  wrote:


I'd like to suggest a minor change to the way block alias is handled in GRC.  
Currently it is treated as a string.  It should be treated as 'any'.  The 
current approach does not scale to large flowgraphs, especially with multiple 
hierarchical blocks.  We should be able to set the alias based on 
parameters/variables.  Should be a one-line change in GRC.

While on the topic, I don't recall if gr 3.9 has finally exposed the 
set_block_alias on python blocks.  My old version still does not.





Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

Block alias

[Eugene Grayver]

I'd like to suggest a minor change to the way block alias is handled in GRC.  
Currently it is treated as a string.  It should be treated as 'any'.  The 
current approach does not scale to large flowgraphs, especially with multiple 
hierarchical blocks.  We should be able to set the alias based on 
parameters/variables.  Should be a one-line change in GRC.

While on the topic, I don't recall if gr 3.9 has finally exposed the 
set_block_alias on python blocks.  My old version still does not.





Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

2021 IEEE Aerospace Conference

[Eugene Grayver]

Hello,

I am chairing the Software Defined and Cognitive Radio session at the upcoming 
IEEE Aerospace Conference (http://www.aeroconf.org).  
This large conference will take place March 6-13, 2021 in Big Sky, Montana.  
The conference provides a world-class technical program and provides excellent 
opportunities for both networking and recreation. This is one of the few 
conferences where SDR can be put in the context of a complete system and can be 
applied to new missions and concepts of operations.

Last year there were a few papers dealing with application of machine/deep 
learning to radio design.  I hope to see even more next year!

Abstracts are due soon, but I can take them a bit later as well, while the full 
paper is due end of October.  This session will focus on flexible radio 
architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of 
existing systems and testbeds are of significant interest.  This year I'd like 
to introduce work related to machine learning as applied to wireless 
communications.

Please forward this to your colleagues working in the areas of SDR and 
cognitive radio.

Regards,

Eugene.

[Discuss-gnuradio] Making the fractional resampler faster

[Eugene Grayver]

The fractional resampler is frequently the most computationally expensive block 
in a transmitter (and even in a receiver).  It is also notoriously difficult to 
parallelize.GR comes with a few options for non-integer resampling: 
polyphase, mmse, rational.  I benchmarked all of them on a variety of machine 
for a rate change of 1.023.  Turns out the old fractional_resampler is a bit 
faster than the polyphase.   However, it was still too slow (could not keep up 
at ~30 Msps).

A one-line change to the fractional_resampler_[cc/ff] increases throughput by 
almost 3x.  The current fractional resampler uses the basic filter kernel.  The 
filter kernel is really pretty clever - uses SIMD via VOLK and goes to great 
lengths to keep everything aligned on cache boundaries.  All that overhead is 
worth it when the filter has lots of taps.  However, the resampler filter is 
exactly 8 taps.  The overhead of calling into the filter kernel is much, much 
larger than the work done in the kernel.

Simply replace the line:

  out[oo] = d_resamp->interpolate([ii], d_mu);

with
  auto TAPS = taps[(int) d_mu];
   out[oo] = in[ii+0] * TAPS[7] + in [ii+1] * TAPS[6] + ... in [ii+7] * 
TAPS[0].

taps come from 'interpolator_taps.h'

I wish I could just post the diff myself, but company policy does not allow me 
to.

Instant speedup of 2.5X (complex), 3X (real).  It may be even faster if we used 
a SIMD intrinsic, but compilers are really pretty good at optimizing these days!


In the immortal words of Donald Knuth: Premature optimization is the root of 
all evil.


Eugene Grayver, Ph.D.
Principal Engineer
Digital Communications Implementation Division
(310) 336-1274

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

[Discuss-gnuradio] LDPC in GNURadio

[Eugene Grayver]

Neither of these implementations is even remotely fast enough for real-time 
applications.  There are a few open-source fast LDPC decoders that take 
advantage of modern processors.  The real stand-out is the one by Bertrand Le 
Gal (https://github.com/blegal/Fast_LDPC_decoder_for_x86).  I have done an 
extensive study of available decoders and that one is at least 3x faster than 
the nearest competitor (see here http://aff3ct.github.io/hof_ldpc.html).  A 
paper coming out soon describes this decoder  running at 1 Gbps on a server.

Creating a GR wrapper for it is a trivial exercise (took me about 2 days). In 
my wrapper I use dlopen to read in a dynamic library for a particular code.  
The dynamic libraries are built for all the available matrices.

Unfortunately it does not support arbitrary matrices and matrices cannot be set 
at runtime.  Bertrand is very helpful and has created matrices for codes when I 
asked.  We (or he) can put in a stand-alone application to convert from 
standard .alist format to his 'C' header files.

NOTE: we have also updated Bertrand's code to run on an ARM NEON and it is 
quite fast (3 Mbps @ 1.2 GHz)

I am sorry that I cannot offer to make my code available to the community.

___
Eugene Grayver, Ph.D.
Aerospace Corp., Principal Eng.
Tel: 310.336.1274


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

[Discuss-gnuradio] Bug in fmdet_cf_imp.cc

[Eugene Grayver]

Hello,

There is a bug in the FM demod.  Unbelievably (almost), I reported a bug in the 
same line a couple of years ago.  At that time I also goofed (should have not 
retyped it).  The equation is STILL wrong!

Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);

Should be

Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);


[cid:image001.png@01D3FF1E.AB791FA0]

It is crazy that the basic FM demo works at all.


___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Eugene Grayver]

There is a major problem with the way tags are propagated in blocks with 
non-integer relative rate. If the ratio is not a power of two, the numerical 
accuracy of the floating point will cause the output tags to diverge from the 
input tags.  Consider the fractional resampler. It accumulates the timing 
offset in the range of 0 to 1. However tag propagation multiplies the ratio by 
the sample number. As the sample number grows the LSB accuracy of the ratio 
gets scaled by the ever larger value. For a ratio of 1.001 we saw divergence of 
1000s of samples over a few minutes at 10msps. I rewrote tag propagation for 
the resampler but did not rework the generic logic. I think the key point is to 
use the delta between read and written items to take out the large integer 
difference and then apply the scaling to a local delta within the current 
window.

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Windows install building oot modules

[Eugene Grayver]

First, kudos for getting Windows builds up and running.  I've been doing it 
manually myself for years and it has always been a pain.  Can I request two 
small changes:

1.   Please include enough extras to allow building oot modules

a.   Boost includes and .libs

b.  Swig.exe

c.   Zeromq includes and .libs (I think a few oot use this)

2.   I could not get 'pip' to work.  The pip-script.py works just fine, but 
pip.exe gives 'failed create process'  Not a big deal, but threw me for a loop.


___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Last call for abstracts for the IEEE Aerospace Conference!

[Eugene Grayver]

Hello fellow SDR developers.  I am still accepting abstracts for the SDR 
session at the Aerospace Conference to be held next March in Big Sky, MT.  Let 
me know if you are interested in submitting a paper (only abstracts are 
required right now), or just go to aeroconf.org.  Session 4.12.  Hope to see 
some of you there!

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Using two TwinRX in one x310

[Eugene Grayver]

Hello,

This may be an usrp-users question, but I can't seem to get approved for that 
list.  Is it possible to use two TwinRX boards (4 channels) in a X310?  As far 
as I can tell you need 4 DDCs, but only two are available by default.

A followup: why is it that TwinRX connection type is reported as 'Connection 
Type: II' for channel 0 QQ for channel 1.

Finally, I have a twinrx and a UBX board in one X310.  Trying to run all 3 RX 
at the same time I get:
UHD Warning:
[X300 Radio] Requesting invalid sampling rate from device: 100 MHz. Actual 
rate is: 200 MHz.
thread[thread-per-block[0]: ]: RuntimeError: 
Conflicting tick rates: One neighbouring block specifies 2e+08 MHz, another 
1e+08 MHz.


[cid:image001.png@01D2F424.CD93A110]

Thanks

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

Re: [Discuss-gnuradio] symbol already exists: cannot reuse! runtime error

[Eugene Grayver]

We figured out the cause of this error.  I had a block called 'vector_sink2' .  
I also have blocks called vector_sink. Turns out the block naming simply 
appends the block's index to it.  
The first vector_sink2 gets called vector_sink21
The first vector_sink gets called vector_sink1
So at some point we got an additional 20 vector_sink blocks.  So that created a 
'vector_sink21', which had a name conflict with the first vector_sink2.
The moral of the story is not to end the block name with a number.  An even 
better idea is to add a separator after the block name and its index for the 
complete name: e.g. vector_sink2(1)


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

[Discuss-gnuradio] symbol already exists: cannot reuse! runtime error

[Eugene Grayver]

I have a rather complicated GR application.  I create (Python, w/out grc) 
multiple top_blocks, each containing dozens of blocks.  To make things even 
more complicated, the flowgraphs are created in stages - using runtime 
reconfiguration to add more blocks.

Everything works fine until I reach some critical size (apparently).  Then I 
get an error: 'symbol already exists cannot reuse'  It has something to do with 
registering a block name in 'block_registry::register_symbolic_name'

I experience this error with both versions 3.7.9.2 and 3.7.11.

I am at a loss on how to debug this problem.  Reviewing the code seems OK - the 
thread locks look good.  I have no idea how a block with the same name can show 
up twice.  Is this due to multiple top_block instances?  Due to runtime 
reconfig?

Ideas?

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] 2018 IEEE Aerospace Conference

[Eugene Grayver]

Hello,

I am chairing the Software Defined and Cognitive Radio session at the upcoming 
IEEE Aerospace Conference (http://www.aeroconf.org<http://www.aeroconf.org/>).  
This large conference will take place March 4-11, 2018 in Big Sky, Montana.  
The conference is held at a ski resort and provides excellent opportunities for 
both networking and recreation (in addition to a world-class technical 
program).   This is one of the few conferences where SDR can be put in the 
context of a complete system and can be applied to new missions and concepts of 
operations.

Abstracts are due shortly, but I can take them a bit later as well, while the 
full paper is due end of October.  This session will focus on flexible radio 
architectures, including the use of DSPs and FPGAs.  Reports of existing 
systems and testbeds are of significant interest.  I am also very interested in 
programmable and flexible RF and analog architectures.

I have either met you at a conference in the past, or have referred to one of 
your works. I look forward to seeing many of you in Montana.

Please forward this to your colleagues working in the areas of SDR and 
cognitive radio.

Thanks,

Eugene.


___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] CMake error related to log4cpp in non-standard location

[Eugene Grayver]

The current GR CMakeFile(s) apparently do not add the include path 
LOG4CPP_INCLUDE_DIR to the compile.  Can't build w/ log4cpp in non-standard 
location.





Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Logging from hierarchical block

[Eugene Grayver]

Is there a reason that hier_block2 does not have a d_logger?  Seems like an 
oversight/bug.  Even though they don't have a work function, logging is useful 
from the constructor and member functions.  Comments?




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in annotator_raw_impl.cc

[Eugene Grayver]

There is a bug in annotator_raw_impl.cc:77


  if(tag.offset > nitems_read(0)) {

should be

  if(tag.offset < nitems_read(0)) {


Somebody please make a pull request.



Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

Re: [Discuss-gnuradio] set_max_output_buffer_size

[Eugene Grayver]

Sorry about the attached patch -- the fix for max buffer size was incorrect.  
The correct fix is (cant generate a patch now):


buffer.cc:173   return d_orig_bufsize - most_data - 1;

buffer.cc:115 d_orig_bufsize = nitems;

buffer.h:73  unsigned intd_orig_bufsize;


I tested it a little and it appears to work just fine.  Perhaps runtime experts 
want to comment?  For performance reasons, we may want to warn the user if the 
buffer is very small.  Anyone see other issues?



Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] set_max_output_buffer_size

[Eugene Grayver]

There are a two problems with the set_max_output_buffer_size command:


1. It is not exposed in Python

2. It cannot set the buffer size smaller than the system page size (typically 
4k).  This is a big problem for low-rate, low-latency applications.


I cannot provide a pull request, but am attaching a patch that should fix both 
problems.


The idea behind fixing (2) is simple: allow the system to allocate the full 4k, 
but keep a local variable with the 'real' buffer size.  Then, simply never 
report that you have more than 'real' buffer size items free.






Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274



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

[Discuss-gnuradio] Feature request: add max-length to vector_sink

[Eugene Grayver]

Adding a maximum length for a vector sink will make it easier to use for 
'realtime' QA code.  Minor change required.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in GPS time reported by the USRP

[Eugene Grayver]

This is being posted to both GR and Ettus forums because both groups should be 
aware.


The value returned by  USRP.get_mboard_sensor('gps_time') is incorrect.  It is 
NOT the GPS epoch, but is time relative to the UNIX epoch.  Only off by a 
decade or so...


'GPS epoch time: 1481073287 seconds'






Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] bug in digital.sd_psk_2_0x1

[Eugene Grayver]

Hello,

I found a bug in  digital.sd_psk_2_0x1.There should not be brackets around 
x_re = x.real.

Regards,
Eugene


def sd_psk_2_0x1(x, Es=1):
'''
1 | 0
'''
-x_re = [x.real,]
+x_re =[x.real
dist = Es*numpy.sqrt(2)
return -dist*x_re
---




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Viterbi encoder and decoder polynomial convention is different than Matlab/standard

[Eugene Grayver]

Hello,


I just found out that the polynomial definition convention used by the GR 
cc_encoder and decoder is bit reverse  of the 'standard' convention.  The 
standard convention (e.g. Matlab, Xilinx) pushes data bits from MSB to LSB, 
while the GR pushes LSB to MSB.  At the very least this should be called out 
LOUDLY in the documentation.


Eugene




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Tag propagaton bug in pack_k_bits_bb

[Eugene Grayver]

Hello,

I found a tag propagation bug in pack_k_bits_bb.  Example python file to 
demonstrate the bug is below.  This block takes every 2 bits and packs them 
into one output.  Thus, a tag on input 0 should come out on output 0, and tag 
on input 7 should come out on output 3.  However, as can be seen from this 
example, the second tag comes out on output 4.  This is probably due to the way 
sync_decimator does tag propagation: round(input_index / decimation).  However, 
that is NOT the correct approach for this block.

Eugene

---
from gnuradio import gr, blocks
import pmt
top = gr.top_block()
tag1 = gr.python_to_tag((0, pmt.intern('A'), pmt.PMT_NIL))
tag2 = gr.python_to_tag((7, pmt.intern('B'), pmt.PMT_NIL))
src = blocks.vector_source_b([0,]*10, tags=[tag1, tag2])
packer = blocks.pack_k_bits_bb(2)
dbg = blocks.tag_debug(gr.sizeof_char,'A')
top.connect(src, packer, dbg)
top.run()
--





Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in GR runtime related to lock/unlock and tag propagation

[Eugene Grayver]

Hello,


I came across a nasty bug in the runtime.  It has something to do with the tag 
pruning code after a flowgraph is reconfigured.  My guess is that some counter 
is not being reset, even though the output buffer is reset.  It is easy to 
demonstrate by hooking up a usrp_source to tag_debug.  usrp_source inserts tags 
but they are not seen by the tag_debug (after the first time).


Here's a full python example script.




from gnuradio import gr, blocks, uhd
import time
top = gr.top_block()
src = uhd.usrp_source('', uhd.stream_args('fc32'))
dbg = blocks.tag_debug(gr.sizeof_gr_complex,'A')
top.connect(src, dbg)
top.start()
for idx in range(10):
time.sleep(5)
top.lock()
top.disconnect(src, dbg)
# Tags are lost whether we reuse the same dbg or create a new one
#dbg = blocks.tag_debug(gr.sizeof_gr_complex,'A%d' % idx)
top.connect(src, dbg)
top.unlock()

top.stop()
top.wait()
---



Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in GR runtime: Messages do not restart after reconfiguration

[Eugene Grayver]

Hello,


I found a bug in the GR runtime.  Here's a simple script to demonstrate it.

#

from gnuradio import gr, blocks
import pmt
import time

class child(gr.hier_block2):
def __init__(self):
super(child, self).__init__('child',
gr.io_signature(0,0, gr.sizeof_char),
gr.io_signature(0,0, gr.sizeof_char))

src = blocks.message_strobe(pmt.intern('ABCD'), 1000)
snk = blocks.message_debug()
self.msg_connect(src, 'strobe', snk, 'print')

class parent(gr.top_block):
def __init__(self):
super(parent, self).__init__()

self.blank = child()
self.connect(self.blank)

def reconfig(self):
self.lock()
self.disconnect(self.blank)
self.dut = child()
self.connect(self.dut)
self.unlock()


print "Using GR version", gr.version()
dut = parent()
dut.start()
print "Created parent"
time.sleep(5)
print "About to reconfig"
dut.reconfig()
print "Reconfigured"
time.sleep(5)
print "Exiting"
dut.stop()
dut.wait()
#


Here's the output that shows that messages stop after reconfiguration.  I was 
relying on both features for my architecture...  Any suggestions/hot fix?


Using GR version v3.7.10-44-g124c641c

Created parent
*** MESSAGE DEBUG PRINT 
ABCD

*** MESSAGE DEBUG PRINT 
ABCD

*** MESSAGE DEBUG PRINT 
ABCD

*** MESSAGE DEBUG PRINT 
ABCD

*** MESSAGE DEBUG PRINT 
ABCD

About to reconfig
Reconfigured
Exiting





Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Can't use set_output_multiple from python

[Eugene Grayver]

Is there any reason why we can't set a blocks output_multiple outside its 
constructor?  I.e. why is set_output_multiple not swigged in the gateway block 
to be available from python?  I frequently have scenarios where the output 
multiple is not known in the constructor but only in the python script that 
creates the block.  This is usually for 'streaming' blocks that are operating 
on fixed-length (semi-packetized) data.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

Re: [Discuss-gnuradio] Bug in digital::glfsr_source_b

[Eugene Grayver]

Note: It is, of course, possible to trick the blocks into working by passing in 
negative values (n - 2**32), but it is not elegant.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274




From: Eugene Grayver
Sent: Monday, August 8, 2016 5:22 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Bug in digital::glfsr_source_b


Note: same issue with descrambler_bb and scrambler_bb.  The digital.lfsr block 
is correct.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274




From: Eugene Grayver
Sent: Monday, August 8, 2016 2:47 PM
To: discuss-gnuradio@gnu.org
Subject: Bug in digital::glfsr_source_b


I found a minor (?) bug in glfsr_source_b and _f, and in glfsr.h.  The input 
types for mask and seed should be 'unsigned int', not 'int'.  Currently it does 
not allow 32-bit values, only 31-bit values.  While somebody is fixing that, 
they should also make 'length' an optional input to have the LFSR restart after 
fewer than 2^degree outputs.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

Re: [Discuss-gnuradio] Bug in digital::glfsr_source_b

[Eugene Grayver]

Note: same issue with descrambler_bb and scrambler_bb.  The digital.lfsr block 
is correct.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274




From: Eugene Grayver
Sent: Monday, August 8, 2016 2:47 PM
To: discuss-gnuradio@gnu.org
Subject: Bug in digital::glfsr_source_b


I found a minor (?) bug in glfsr_source_b and _f, and in glfsr.h.  The input 
types for mask and seed should be 'unsigned int', not 'int'.  Currently it does 
not allow 32-bit values, only 31-bit values.  While somebody is fixing that, 
they should also make 'length' an optional input to have the LFSR restart after 
fewer than 2^degree outputs.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Bug in digital::glfsr_source_b

[Eugene Grayver]

I found a minor (?) bug in glfsr_source_b and _f, and in glfsr.h.  The input 
types for mask and seed should be 'unsigned int', not 'int'.  Currently it does 
not allow 32-bit values, only 31-bit values.  While somebody is fixing that, 
they should also make 'length' an optional input to have the LFSR restart after 
fewer than 2^degree outputs.




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Problem/bug with cmake config for gr-uhd using pybombs.

[Eugene Grayver]

There's a subtle problem with the FindUHD.cmake as used from PyBombs.  If the 
system has UHD installed in the 'standard' location (/usr/include/uhd, etc), 
this path will be used instead of the path set by pybombs prefix.  I.e. if I 
install gr into /etc/gr1: uhd is installed in /etc/gr1/src/uhd, but gr-uhd will 
use /usr/.../uhd.  This leads to very difficult to diagnose problems if the UHD 
versions are slightly different.  If they are very different, the build simply 
fails due to undefined symbols.


I am not familiar enough with the pybombs environment to suggest a fix.  
Perhaps pybombs should set the UHD_DIR env variable?




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in fmdet_cf_impl.cc

[Eugene Grayver]

There's an obvious bug in the very old fmdet_cf_impl.cc file.  I reported it 
before, but it has not been fixed.  Unfortunately I can't do a pull request, so 
somebody please fix it:


fmdet_cf_impl.cc:109


<<>>Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);


Note that the third term should be S2, not S1.  Otherwise, terms 2 and 3 just 
cancel each other.


________

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] set_max_output_buffer missing in block_gateway

[Eugene Grayver]

The functions to control output buffer size are not available to pure Python 
blocks.  I think that's because these functions are missing from 
block_gateway.h.  Is this an oversight or intentional?




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in tag processing

[Eugene Grayver]

I think there's a bug in tag processing.  Here's a simple script to demonstrate 
the problem.  If DELAY is set to a small value <6000,  we get the expected 
output. However, if DELAY is set to 8000, the tag never comes out.  The same 
problem can be observed using the blocks.vector_insert_b block, indicating that 
the bug is in the runtime.





DELAY = 8000
from gnuradio import gr, blocks
import pmt
print "Version", gr.version()
top = gr.top_block()
tag = gr.python_to_tag((0, pmt.to_pmt('A'), pmt.to_pmt(1), pmt.PMT_NIL))
src = blocks.vector_source_s(range(1), tags=[tag], repeat=False)
dly = blocks.delay(gr.sizeof_short, DELAY)
snk = blocks.tag_debug(gr.sizeof_short, 'A')
top.connect(src, dly, snk)

--
 expected output:


Version v3.7.9.1-97-gc0381e0e

--
Tag Debug: A
Input Stream: 00
  Offset: 6000  Source: n/a Key: A   Value: 1
--


____

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

Re: [Discuss-gnuradio] Crash on UHD import on a fresh build of 3.7.10 using PyBOMBS (Martin Braun)

[Eugene Grayver]

I thought about a library mismatch, but that does not seem to be the case.  The 
install folder is /home/gnuradio_latest (i.e. not /usr/...).  I verified the 
LD_LIBRARY_PATH.


Checking the swig library seems to return the correct path to uhd (i.e. not the 
system one):


 ldd 
/home/gnuradio_latest/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.so | 
grep uhd
libgnuradio-uhd-3.7.10git.so.0.0.0 => 
/home/gnuradio_latest/lib/libgnuradio-uhd-3.7.10git.so.0.0.0 
(0x7fb05c124000)
libuhd.so.003 => /home/gnuradio_latest/lib/libuhd.so.003 
(0x7fb05b7ed000)

Just in case, I removed the libuhd from /usr/lib but same crash.

I am out of ideas at this point ...



Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Crash on UHD import on a fresh build of 3.7.10 using PyBOMBS

[Eugene Grayver]

Just rebuilt GR using pybombs (went very smoothly).  However, encountered a 
very weird bug -- segfault on 'from gnuradio import uhd'.  The machine does not 
have any UHD devices attached (have not yet checked what happens if there's in 
fact a device).  Here's a backtrace from gdb.  Apparently something bad happens 
in high_res_timer.  I verified the system paths $LD_LIBRARY_PATH, $PYTHONPATH, 
$PATH and they all point to the latest pybombs install.


I've never seen this one before... (after the backtrace, there's some more info)




Core was generated by `python -c from gnuradio import uhd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0001e1a6 in ?? ()
(gdb) bt
#0  0x0001e1a6 in ?? ()
#1  0x7f95cf2066f0 in strstr (__needle=0x7f95cf290944 "swig_ptr: ",
__haystack=0x7f95cf27d210 "high_res_timer_now() -> 
gr::high_res_timer_type") at /usr/include/string.h:337
#2  SWIG_Python_FixMethods (methods=0x7f95cf4ba500 ,
const_table=0x7f95cf4c0880 ,
types=0x7f95cf4c08e0 ,
types_initial=0x7f95cf4b8b20 )
at 
/home/gnuradio_latest/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:45975
#3  init_uhd_swig ()
at 
/home/gnuradio_latest/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46096
#4  0x004268bc in _PyImport_LoadDynamicModule ()
#5  0x0046232a in ?? ()
#6  0x0052c6d5 in PyEval_EvalFrameEx ()
#7  0x0052cf32 in PyEval_EvalFrameEx ()
#8  0x0055c594 in PyEval_EvalCodeEx ()
#9  0x005b7392 in PyEval_EvalCode ()
#10 0x005b744a in PyImport_ExecCodeModuleEx ()
#11 0x00579f0f in ?? ()
#12 0x0055d3a3 in ?? ()
#13 0x0055d77c in ?? ()
---Type  to continue, or q  to quit---
#14 0x0055db37 in PyImport_ImportModuleLevel ()
#15 0x004755e7 in ?? ()
#16 0x004da20b in PyEval_CallObjectWithKeywords ()
#17 0x0052e6d7 in PyEval_EvalFrameEx ()
#18 0x0055c594 in PyEval_EvalCodeEx ()
#19 0x0052ca8d in PyEval_EvalFrameEx ()
#20 0x0055c594 in PyEval_EvalCodeEx ()
#21 0x005b7392 in PyEval_EvalCode ()
#22 0x005b744a in PyImport_ExecCodeModuleEx ()
#23 0x00579f0f in ?? ()
#24 0x0046b0e7 in ?? ()
#25 0x0055d3a3 in ?? ()
#26 0x004cd49e in ?? ()
#27 0x0055dbec in PyImport_ImportModuleLevel ()
#28 0x004755e7 in ?? ()
#29 0x004da20b in PyEval_CallObjectWithKeywords ()
#30 0x0052e6d7 in PyEval_EvalFrameEx ()
#31 0x0055c594 in PyEval_EvalCodeEx ()
#32 0x0052c05b in PyRun_StringFlags ()
#33 0x0042ef13 in PyRun_SimpleStringFlags ()
#34 0x0046a88c in Py_Main ()
#35 0x7f95d056aec5 in __libc_start_main (main=0x46ac3f , argc=3,
argv=0x7fff31ce2678, init=, fini=,
---Type  to continue, or q  to quit---
rtld_fini=, stack_end=0x7fff31ce2668) at libc-start.c:287
#36 0x0057497e in _start ()

A few relevant  files in the lib folder:
libgnuradio-audio.so libgnuradio-uhd-3.7.10git.so
libgnuradio-blocks-3.7.10git.so  libgnuradio-uhd-3.7.10git.so.0
libgnuradio-pager-3.7.10git.so.0 libuhd.so.003
libgnuradio-pager-3.7.10git.so.0.0.0 libuhd.so.003.010
libgnuradio-pager.so libvolk.so
libgnuradio-pmt-3.7.10git.so libvolk.so.1.2.1





____________

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Bug in block::declare_sample_delay

[Eugene Grayver]

Hello,
I think that the declare_sample_delay (and/or the way it is used) is 
implemented incorrectly for interpolator blocks.  Using GR 3.7.6.

The delay should be added **after** scaling the offset by the interpolation 
ratio, not before.  For example, using the 
filter.interp_fir_filter(4,[1,2,3,4]):
If a tag is on sample2, and the sample_delay is declared as one, the output tag 
should be on sample 2*4+1=9.  However, it falls on sample 12 = (2+1)*4.

Here's an example to demonstrate the error:


from gnuradio import gr, blocks, filter
import pmt

top = gr.top_block()
tag = gr.tag_utils.python_to_tag((2,
  pmt.to_pmt('A'),
  pmt.PMT_NIL,
  pmt.PMT_NIL))

src = blocks.vector_source_f(range(0, 50, 10), tags=[tag])
dut = filter.interp_fir_filter_fff(4, [1, 2, 3, 4])
dut.declare_sample_delay(1)
snk = blocks.vector_sink_f()

top.connect(src, dut, snk)
top.run()

result = snk.data()
tags = snk.tags()
print tags[0].offset

Regards.

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

[Discuss-gnuradio] Silly bug in gr_fmdet_cf.cc

[Eugene Grayver]

Just came across a typo in gr_fmdet_cf.cc (compare to previous version to 
see the correct code).  Line 87 currently reads:

Sdot = d_scl * (-S0+d_8*S1-d_8*S1+S4);

Note that the middle two terms are identical and therefore don't do 
anything.  The correct code should read:

Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);

I am no longer actively working with GR and don't recall how to submit a 
patch request, plus my version is very old.  I'd appreciate somebody 
putting the patch in for me.

Thanks,

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Messages, queues, and tags

[Eugene Grayver]

Hello,

I've been following the changes Josh is making to the GR messaging system. 
 I am not sure that a gr_tag is a good fit for a generic message.  For 
example, the 'offset' may not be relevant to many messages.

We've been using tags very extensively in our designs and they are great 
but serve a very different purpose than messages should.  Perhaps a better 
idea is to define a standard message header? 

Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Messages, queues, and tags

[Eugene Grayver]

Hello,

I've been following the changes Josh is making to the GR messaging system. 
 I am not sure that a gr_tag is a good fit for a generic message.  For 
example, the 'offset' may not be relevant to many messages.

We've been using tags very extensively in our designs and they are great 
but serve a very different purpose than messages should.  Perhaps a better 
idea is to define a standard message header? 

How about something like this:

A pmt_t tuple with 

1. First entry is a string indicating the packet type
2. A sequence of zero or more pairs with (key, value), where key is a 
string, and value is any pmt_t


Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cognitive Radio Implementation with, XML

[Eugene Grayver]

Hi Songsong,

This is not entirely on topic but you may be interested in my work on XML 
description for waveforms. See http://sdrphy.org 
I know some VT folks are using it for their cognitive radio research.  We 
implemented a really basic interpreter to configure a predefined GRC 
design based on the XML.  THe flow is:

GRC - XML description of the flowgraph

SDRPHY - interpreter  modify the GRC flowgraph using search/replace 

GRC - load modified flowgraph XML and generate the .py code

Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Thoughts on relative_rate

[Eugene Grayver]

Hi,

As GR is maturing, we get more support for complex blocks with nontrivial 
input/output relationships.  The option to 'produce' inside the ::work 
function is a major step in this direction.  Consider a block with two 
outputs: one at 1:1 rate, and one at N:1 rate.  It may be useful to allow 
set_relative_rate to take in a input/output port.  Of course, the 
scheduler would have to do something with the new information.

Eugene.

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Thoughts on stream tag propagation

[Eugene Grayver]

Hello,
I am starting to actively use stream tags and am finding them quite 
useful.  I have one suggestion:

Tags propagated through a block with a known delay (set_history) should be 
adjusted by that delay.  For example, an input to an FIR filter gets 
reflected in the output after a delay.  Since the GR executor has access 
to the delay info, there's no reason it should not use it.

Comments?

On a separate note, I have observed a _rare_ case where tags get lost. The 
scenario involves an output attached to two inputs.  The two inputs 
consume data in different (random) chunk blocks.  It appears that if one 
of the inputs consumes items with the tag well before the second input 
gets to the tagged item, the second input sometimes does not see the tag. 
I have not debugged this enough to confirm that there's no bug in my code.

Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Eugene Grayver is out of the office.

[Eugene Grayver]

I will be out of the office starting  05/22/2009 and will not return until
06/11/2009.

I will be checking my e-mail periodically.



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

[Discuss-gnuradio] Eugene Grayver is out of the office.

[Eugene Grayver]

I will be out of the office starting  10/27/2008 and will not return until 
10/31/2008.

I will be checking my voice mail and e-mail periodically.



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

[Discuss-gnuradio] Eugene Grayver is out of the office.

[Eugene Grayver]

I will be out of the office starting  08/29/2008 and will not return until 
09/14/2008.

I will be checking my voice mail and e-mail periodically.



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

Re: [Discuss-gnuradio] Multiple top-level blocks

[Eugene Grayver]

Thanks for the thorough response.  I am always impressed by the calibre of 
folks working on gr.  I absolutely appreciate the difficulty of thread 
synch.  I was thinking of restricting different top levels from talking to 
each other (i.e. they are _truly_ independent).  However, I can see how 
this restriction may be violated making the system unstable.

I'd like a bit more discussion of the second part of my question. Consider 
a simple receiver running at a low input rate (e.g. large decimation).  As 
far I can tell, the scheduler sits in an infinite loop, checking if the 
source has data.  If it does not, the loop goes back to the beginning. 
There's no blocking.  Perhaps the scheduler should relinquish the rest of 
the time slice if it find no block to 'work' in a given pass?  I don't 
know of a platform independent way to do that.

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274




Eric Blossom [EMAIL PROTECTED] 
02/28/2008 06:39 PM

To
Eugene Grayver [EMAIL PROTECTED]
cc
discuss-gnuradio@gnu.org
Subject
Re: [Discuss-gnuradio] Multiple top-level blocks






On Thu, Feb 28, 2008 at 06:12:33PM -0800, Eugene Grayver wrote:
 Hello,
 
 Is there any documentation of the new C++ only gnuradio framework?  I'd 
 like some insight into the philosophy behind it.  E.g. why can there 
only 
 be one top level block?  Consider an example:

The one top block constraint is an implementation detail (restriction)
that will be removed as part of the thread-per-block work.  If you've
every tried to robustly mix threads, signals, blocking system calls
and reliable shutdown, you may have some appreciation of the level of
effort required to make this work correctly.

 The gr_top_block appears to separate the flow graph into independent 
 subgraphs and runs each one in its own thread.  I wonder if this is 
always 
 the desired behavior.  Consider two threads with different computational 

 requirements.  One needs 90% the other 10% of the CPU.  The low rate 
 thread should relinquish control if it has nothing to do.  However, that 

 will not happen.  Instead, the scheduler will sit there and use up the 
 entire time to check if the graph has unblocked.  Any ideas?
 
 Thanks.

I think you misunderstand the details of what's going on.  The
low-rate thread will relinquish control.  No thread is spinning waiting
for another.  It'll be blocked waiting on something.  You are correct
in your assessment that we're not currently making good use of
multicore resources.  That will be fixed in as part of the
thread-per-block work.

Eric

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

Re: [Discuss-gnuradio] Multiple top-level blocks

[Eugene Grayver]

Thanks, got it.  I was using a custom source that did not block, just 
returned 0. 

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274




Eric Blossom [EMAIL PROTECTED] 
02/29/2008 12:03 PM

To
Eugene Grayver [EMAIL PROTECTED]
cc
discuss-gnuradio@gnu.org
Subject
Re: [Discuss-gnuradio] Multiple top-level blocks






On Fri, Feb 29, 2008 at 09:44:41AM -0800, Eugene Grayver wrote:
 Thanks for the thorough response.  I am always impressed by the calibre 
of 
 folks working on gr.  I absolutely appreciate the difficulty of thread 
 synch.  I was thinking of restricting different top levels from talking 
to 
 each other (i.e. they are _truly_ independent).  However, I can see how 
 this restriction may be violated making the system unstable.
 
 I'd like a bit more discussion of the second part of my question. 
Consider 
 a simple receiver running at a low input rate (e.g. large decimation). 
As 
 far I can tell, the scheduler sits in an infinite loop, checking if the 
 source has data.

The sources (or sinks) will block if there's nothing available (e.g., 
USRP).
It does not spin.  It does relinquish if there's nothing to do.

 If it does not, the loop goes back to the beginning. 
 There's no blocking.  Perhaps the scheduler should relinquish the rest 
of 
 the time slice if it find no block to 'work' in a given pass?  I don't 
 know of a platform independent way to do that.

If the code behaved as you think, we would always be consuming all cpu
cycles available.  We don't.

 
 Eugene Grayver, Ph.D.
 Aerospace Corp., Sr. Eng. Spec.
 Tel: 310.336.1274
 
 
 
 
 Eric Blossom [EMAIL PROTECTED] 
 02/28/2008 06:39 PM
 
 To
 Eugene Grayver [EMAIL PROTECTED]
 cc
 discuss-gnuradio@gnu.org
 Subject
 Re: [Discuss-gnuradio] Multiple top-level blocks
 
 On Thu, Feb 28, 2008 at 06:12:33PM -0800, Eugene Grayver wrote:
  Hello,
  
  Is there any documentation of the new C++ only gnuradio framework? I'd 

  like some insight into the philosophy behind it.  E.g. why can there 
 only 
  be one top level block?  Consider an example:
 
 The one top block constraint is an implementation detail (restriction)
 that will be removed as part of the thread-per-block work.  If you've
 every tried to robustly mix threads, signals, blocking system calls
 and reliable shutdown, you may have some appreciation of the level of
 effort required to make this work correctly.
 
  The gr_top_block appears to separate the flow graph into independent 
  subgraphs and runs each one in its own thread.  I wonder if this is 
 always 
  the desired behavior.  Consider two threads with different 
computational 
 
  requirements.  One needs 90% the other 10% of the CPU.  The low rate 
  thread should relinquish control if it has nothing to do.  However, 
that 
 
  will not happen.  Instead, the scheduler will sit there and use up the 

  entire time to check if the graph has unblocked.  Any ideas?
  
  Thanks.
 
 I think you misunderstand the details of what's going on.  The
 low-rate thread will relinquish control.  No thread is spinning waiting
 for another.  It'll be blocked waiting on something.  You are correct
 in your assessment that we're not currently making good use of
 multicore resources.  That will be fixed in as part of the
 thread-per-block work.
 
 Eric

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

[Discuss-gnuradio] Multiple top-level blocks

[Eugene Grayver]

Hello,

Is there any documentation of the new C++ only gnuradio framework?  I'd 
like some insight into the philosophy behind it.  E.g. why can there only 
be one top level block?  Consider an example:

I have a transmitter and a receiver.  The two are completely independent. 
Why can't each one be a gr_top_block?  I may want to stop one but not the 
other. 

The tx and rx may have been designed by different people.  Why do I need 
another top level to combine the two?

The gr_top_block appears to separate the flow graph into independent 
subgraphs and runs each one in its own thread.  I wonder if this is always 
the desired behavior.  Consider two threads with different computational 
requirements.  One needs 90% the other 10% of the CPU.  The low rate 
thread should relinquish control if it has nothing to do.  However, that 
will not happen.  Instead, the scheduler will sit there and use up the 
entire time to check if the graph has unblocked.  Any ideas?

Thanks.

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Frontend Hardware which is not USRP

[Eugene Grayver]

It's actually reasonably simple to design your own hardware interface. All 
you need are hw_source_c and hw_sink_c.  I designed one for the 
Nallatech/XtremeDSP from Xilinx.  As long as you already have functions to 
read and write to/from hardware, the blocks are actually very simple.

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Re-writing blocks using intel libraries

[Eugene Grayver]

Hello,

We are working on some systems that require high sampling rates.  I am 
already using the Intel C++ compiler at the highest optimization ratio, 
but a lot of the blocks are very slow still.  It appears that intel C++ 
does not properly vectorize complex data type. 

I have been replacing almost every low level block with a functionally 
equivalent using the intel performance libraries (IPP).  These libraries 
are not GPL, but are free for noncommercial use under Linux ($200 
otherwise).  At some point, I would like to contribute our work back to 
gnuradio.  Would this fit with the gr philosophy?  How should we structure 
the code?  (i.e. have a separate set of files, use #defines, or ...)?

Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

Re: [Discuss-gnuradio] Re-writing blocks using intel libraries

[Eugene Grayver]

Please see answers in-line.

Thanks!




Eric Blossom [EMAIL PROTECTED] 
12/11/2007 02:31 PM

To
Eugene Grayver [EMAIL PROTECTED]
cc
discuss-gnuradio@gnu.org
Subject
Re: [Discuss-gnuradio] Re-writing blocks using intel libraries






On Tue, Dec 11, 2007 at 10:13:32AM -0800, Eugene Grayver wrote:
 Hello,
 
 We are working on some systems that require high sampling rates.  I am 
 already using the Intel C++ compiler at the highest optimization ratio, 
 but a lot of the blocks are very slow still.  It appears that intel C++ 
 does not properly vectorize complex data type. 

General curiosity questions:

  Are you using oprofile to measure performance?

I am a bit of a maverick, and for various reasons am using a pure C++ 
environment.  I hacked my own 'connect_block' function (can;t wait for 
v3.2, where these will be part of native gr).  I am measuring the 
performance using a custom block (gr_throughput) that simply reports the 
average number of samples processed per second.

  What h/w platform are you running on / tuning for?

The platform is currently Intel Xeon or Core2 Duo.

  You're not trying to run your app on a cache-crippled machine like a
  Celeron, are you?  ;)

No, very high end.

  Which blocks are causing you the biggest problem?

I got a 2x improvement on all the filtering blocks.  About a 40% 
improvement for sine/cosine generation blocks.  This includes gr_expj, 
gr_rotate.

  Are your problems caused primarily by lack of CPU cycles, cache
  misses or mis-predicted branches?

I am not sure, since I am not at all a software expect (mostly dsp/comm). 
My guess is that the SSE instructions are not being used (or not used to a 
full extent).  Even the 'multiply' block is VERY slow compared to a vector 
x vector multiplication in the Intel library.  Some of the gr_blocks 
process each sample using a separate function call (e.g. 
for (n=0; nnoutput_samples; n++)
scale(in[n])

Replacing this with a single vectorized function call is much faster.

 I have been replacing almost every low level block with a functionally 
 equivalent using the intel performance libraries (IPP).  These libraries 

 are not GPL, but are free for noncommercial use under Linux ($200 
 otherwise).  At some point, I would like to contribute our work back to 
 gnuradio.  Would this fit with the gr philosophy?  How should we 
structure 
 the code?  (i.e. have a separate set of files, use #defines, or ...)?
 
 Eugene

We would not accept the changes.  Part of what we're up to is building
an ever expanding universe of free code.  Instead of using the
non-free IPP code, please consider using a free library such as ATLAS,
or help us find and fix performance challenges in a way that doesn't
require non-free code.  Also, are you sure that your performance
issues can't be better addressed with an algorithmic change?  If
you're using a lot of very low-level blocks (e.g., add, multiply,
etc.) you're probably better off writing a block that aggregates some
of the operations into a single block.

That's what I expected.  We'll try to contribute the more dsp-centric 
blocks such as demodulators. 



Eric

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