Seeking RF ML Demos for IEEE's new ICMLCN Conference in May 2024

[Tim O'Shea]

Dear Fellow GNU Radio Hackers,



If you’re working in the RF ML space and have a relatively recent demo of
applied work in this area (possibly even using GNU Radio!), please consider
submitting it to IEEE’s first ever flagship ComSoc conference focused on
the intersection of ML and communications systems (ICMLCN), where we’ve
extended our call for demo proposals below through Nov 30th!  Apologies if
you have already seen or received this, I wouldn't normally post CFP's to
this list, but this is potentially highly aligned with some folks building
cool things in the community!



Thanks & Cheers,

Tim






IEEE International Conference on Machine Learning for Communication and
Networking (ICMLCN) 2024 solicits proposals for demonstrations at the first
ever IEEE ComSoc flagship conference dedicated to machine learning and
communications networks, to be held in Stockholm, May 2024.



While ICMLCN will host a wide range of activities focusing on the
intersection of machine learning and communications networks from theory to
practice, there is no better place to demonstrate new data-driven methods
and ideas than in the real world. As such, we would like to invite the
submission of abstracts for proposed demonstrations from industry,
academia, and elsewhere, which bring concepts from machine learning
communications networks into live demonstrations, prototypes, and which can
be shown and measured.



The demo proposals will be reviewed based on its novelty; significance of
implementation; relevance to ICMLCN scope; potential impact on the
audience; quality of implementation.



Please submit an extended abstract (2 pages) on your proposed demonstration
to https://edas.info/N31472


Abstracts must be received by November 30th, 2023.


Please see additional details at
https://icmlcn2024.ieee-icmlcn.org/authors/call-demo-proposals if this is
of interest!

Re: Using Fractional or Rational resampler to simulate Doppler

[Tim Meehan]

Hi Jose,

I would take a look at gr_sattelite.  The work described here
https://destevez.net/2022/07/real-time-doppler-correction-with-gnu-radio/
 was integrated.  A true doppler correction would need to also
resample, but the time varying frequency correction may be enough for
your use case.

Tim

On Thu, Jul 27, 2023 at 1:19 PM Jose Ruvalcaba  wrote:
>
> Hello,
>
> I am trying to simulate an accurate representation of Doppler Shift in a 
> channel and I was told that to do this I would have to multiply a complex 
> signal with a cosine and implement a resampler block to simulate the signal 
> samples that are coming closer or farther away from each other.
>
> My question is this, can I use either the rational resampler or fractional 
> resampler block in GNU Radio to dynamically simulate samples moving closer or 
> farther than each other?  Or would I need to make my own OOT block to do this?
>
> I tried using a QT GUI Range block to change the resampling ratio of a 
> fractional resampler but my flowgraph froze.
>
> Any suggestions?
>
> Thanks,
> Jose

SPAWC21: ML for Multi-Domain Localization and Signal Recognition Data Competition Call for Participation!

[Tim O'Shea]

Call for IEEE SPAWC Data Competition Paper Submissions & Competitors!

===

IEEE Workshop on Signal Processing Advances in Wireless Communications (SPAWC) 
2021
September 27 – 30, 2021  --   Lucca, Italy (And Online Hybrid Event)

===

SPAWC is hosting two exciting data competition this year at the intersection of 
wireless communications and machine learning and soliciting competitors both 
through paper submissions on approaches to these problems and through direct 
participation in the competitions through submission of scored results.

We will accept the submission of full papers with proposed approaches and 
solutions to the data competition problem statements and datasets through July 
5th and will accept competition solution entries through the beginning of the 
conference on September 27th through the data competition sites hosted on 
Kaggle and eval.ai.

Full details for the data competition event may be found at the official 
conference website at https://www.spawc2021.com/data-competition/
Challenge #1 (Industrial Multi-Domain Localization) focuses on Industry 4.0 
centric robust and versatile positioning of robotic devices using a combination 
of Camera-based, IMU-Based and ultra-wideband (UWB) based data observations 
requiring the fusion of multiple domains of observation to maximize precision.  
As robust and precise radio emitter localization is a key component in future 
industry and factory applications, we are excited to launch this data-driven 
challenge as part of SPAWC 21.
https://www.kaggle.com/c/ieeespawc21localization/data

Challenge #2 (Wideband Signal Recognition) focuses on rapid spectrum awareness 
and signal recognition to enable radio spectrum access coordination, anomaly 
detection, spectrum sharing, spectrum analytics and spectrum monitoring 
applications.  As real-time spectrum awareness and spectrum aware decision 
making may be key components to beyond-5G and 6G communications systems, we are 
excited to launch this data-driven signal recognition competition as part of 
SPAWC this year to compare and contrast new promising approaches to the problem.
https://eval.ai/web/challenges/challenge-page/1057/overview

Both address key challenge areas where machine learning has demonstrated 
extremely promising initial results in related areas, but where we believe 
these datasets provide an exciting new step in expanding these results to 
multi-domain and to broad recognition challenges beyond what has been the 
principal focus in research publications thus far.   Thus, we hope by posing 
these two challenges we can excite new researchers to propose, compare and 
publish new approaches to these problems which can help accelerate and mature 
these domains at the intersection of communications systems and machine 
learning.

We’re soliciting full workshop papers via EDAS 
(https://edas.info/newPaper.php?c=28267) from competitors wishing to publish 
their approaches and ideas as well as competition submissions via Kaggle and 
eval.ai which may be submitted directly via the competition websites above 
until the beginning of the Conference event.

Best Regards,
Tim O’Shea
Data Competition Chair, SPAWC21

Re: How to set variable number of inputs/outputs in Python OOT modules

[Tim Huggins]

 I do not believe that you want to encapsulate the call with [ ], even so there 
may be an issue with that command. I am unsure what the issue is but when I 
make the call:

in_sig = gr.io_signature(3,3, gr.sizeof_gr_complex)
The error message is: Can't create an instance of your block: object of type 
'io_signature_sptr' has no len()

Instead try this:
    in_sig = 3*[np.complex64],
Where 3 will end up being your variable for number of inputs.
Tim

On Thursday, February 4, 2021, 1:23:35 PM EST, George Edwards 
 wrote:  
 
 Hi Tim,
Thanks for your suggestion! I just tried it and it does not work. The Python 
OOT def __init__(self, ) method requires that one fills in in_sig = xxx and 
out_sig = xxx.I tried your suggestion above for variable number of inputs and 
set:in_sig = [gr.io_signature(1, -1, gr.sizeof_gr_complex)] 
and I leave the yml file as is when I had the static number of inputs (in_sig = 
[complex64, complex64, complex64]) shown below inputs:-      domain:  stream    
   dtype:  complex       multiplicity:  '3'It gives a TypeError: data type not 
understoodI tried a bunch of combinations based on the above change you 
suggested, but GRC kept failing when I tried to run it.!
Thanks again for your suggestion!Regards,George


On Thu, Feb 4, 2021 at 8:01 AM Tim Huggins  wrote:

 George,
I would recommend taking a look at some of the existing blocks that have 
variable inputs to accomplish this (especially for the YML file). A YML example 
for a variable input can be found here:
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_multiply_xx.block.yml
I haven't run a test using this line in a python block yet, but two different 
examples are shown below that I believe should work (or should with some minor 
tweaks). The first doesn't limit the number of inputs while the second one does 
(at 8).
gr.io_signature(1, -1, gr.sizeof_gr_complex)) gr.io_signature(1, 8, 
gr.sizeof_float)I don't know if there is a complete python reference for 
GNURadio 3.8, but this should be helpful to get you close as well: 
https://www.gnuradio.org/doc/sphinx-v3.7.9.2/
Good luck,
Tim

On Thursday, February 4, 2021, 12:01:07 AM EST, George Edwards 
 wrote:  
 
 Hi Gavin,
Thanks for the information!
Does this mean that if I wanted 3 inputs and 5 outputs and all floating point 
values, then inside the Python code, I simply set  in_sig = [numpy.float32] 
out_sign = [numpy.float32]
And, in the yml file I set:inputs:-      domain:  stream       dtype:  float    
   multiplicity:  '3'
outputs: -        domain:  stream         dtype:  float         multiplicity:  
'5'
Would this be correct?Thanks again for your help!
Regards,George
On Wed, Feb 3, 2021 at 5:26 PM Gavin Jacobs  wrote:

In 3.7, you would use the  tag, but in 3.8 the trick to setting 
multiple ins/outs in the YML file, is the keyword "multiplicity". You can see 
the details of how to configure 
here:https://wiki.gnuradio.org/index.php/YAML_GRC


| YAML GRC - GNU RadioStarting with release 3.8, YAML replaces XML as the file 
format for GNU Radio Companion. This is triggered by switching from Cheetah to 
Mako as the templating engine, since Cheetah does not support Python 
3.wiki.gnuradio.org |



  
  

Re: Problem with Python OOT

[Tim Huggins]

 George,
That should be correct; I was more referring to keeping your coding clean so 
you don't accidentally make a mistake (I've been bit before :-). You could 
conceivably start consuming inputs at different rates but by then you are 
probably getting into some more complex signal processing. 

Tim

On Wednesday, January 20, 2021, 1:29:46 PM EST, George Edwards 
 wrote:  
 
 Hi Tim,
Thanks for your help and for sending the links. 
One final question, I was under the impression that length of data in each 
input was the same because the data to each input is streamed in in lock-step 
sample by sample.  Therefore, len(input_items[0] = len(input_items[1] = 
len(input_items[2], is this not correct?
Thanks again for your help and patience. I appreciate it very much!
Regards,George  
 , , use the appropriate length for each input 
On Wed, Jan 20, 2021 at 10:51 AM Tim Huggins  wrote:

 George,
I'm not completely certain exactly why that doesn't result in a 1 to 1 (you 
might be able to look at the code for the basic sync block to see if there is 
anything you could add: 
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/sync_block.cc
 (this would be an instance to use the sync block instead of a general block 
which forces the 1:1 relationship). That being said, take a look here: 
https://wiki.gnuradio.org/index.php/Types_of_Blocks
Mainly the implementation using a general block at the very bottom. You can see 
how the input is limited to be no bigger than the output buffer in the work 
implementation: 
in0 = input_items[0][:len(output_items[0])]

Also, be careful about your consumes - instead of using len(input_items[0]) for 
each, use the appropriate length for each input to get into good habits.
Tim

On Tuesday, January 19, 2021, 9:07:00 PM EST, George Edwards 
 wrote:  
 
 Hi Tim,
I thought I had it working. However, it is dropping the last output sample. In 
the QA file, there are 5 complex samples going into each of the 3-inputs to the 
module. When the general_work() method runs with the for loop, it throws an 
exception error stating that index 4 (meaning out[4]) is out of bounds. If I 
comment out the for loop and run the program with the line commented out below: 
output_items[0][:]= v2it results in 4 out of  5 samples going to the output. I 
am using the documented default approach in coding for a 1:1 input/output 
sample relationship as you can see in the forecast() and general_work() methods 
below, please let me know if you see something that is wrong.
    def forecast(self, noutput_items, ninput_items_required):

#setup size of input_items[i] for work call

for i in range(len(ninput_items_required)):

    ninput_items_required[i] = noutput_items

 

def general_work(self, input_items, output_items):

global v1, v2

if self.scale == True:

    v1 = self.v1

    v2 = self.v2

self.scale = False

 

    in0 = input_items[0]

    in1 = input_items[1]

    in2 = input_items[2]

    out = output_items[0]

 

    v2 = 1.0+1.0*1j

for ii in range(0,len(in0)):

    out[ii] = v2

# output_items[0][:] = v2

self.consume(0, len(input_items[0]))   

self.consume(1, len(input_items[0]))

self.consume(2, len(input_items[0]))
        return len(output_items])  

Thank you very much!George
On Tue, Jan 19, 2021 at 3:50 PM George Edwards  wrote:

Hi Tim,
Thank you very much for your help! 
The problem was with the QA file. I tried to input the 3 source streams as:src 
= blocks.vector_source_c(np.array([src0, src1, src2])) where each srcX was 
defined as a complex array. Based on the link into the github QA files that you 
sent me, it showed that each srcX must be connected individually to the 
processing block. Also, I overlooked the fact that when I ran the QA, it 
pointed to that line in the code as a problem.
I will now try to see if I can get the output to provide a stream of 8 samples 
(maybe do 3 as a start) based on one sample from each of the 3-input streams.
Thanks again for the help!
Regards,George  
On Tue, Jan 19, 2021 at 2:05 PM Tim Huggins  wrote:

 George,
Unfortunately I'll still not seeing anything wrong with what you have (and I 
realized that the QA code caused the issue so it is probably not in your yml 
file). I'd probably have too see your entire code to try to reproduce the error 
as all my tests to create the error didn't.
Regarding your other questions:1. There isn't really a correct/incorrect as the 
answer can depend on the work that you want the block to do but general will 
work. I mainly use general or sync.2. Yes, as you have a 1 to 1 stream.3. This 
doesn't look quite correct. Are you planning on working with vector inputs or 
steams to your block? if you are using streams then there is no need to change 
vlen in the yml file. Also it sounds like whatever computations are basically 
doing an interpolation

Re: Problem with Python OOT

[Tim Huggins]

 George,
I have made several OOT Python blocks with variable numbers of inputs and 
outputs and while I could very easily be overlooking something the error does 
not, at first glance, appear to be in the code that you have sent out. Can you 
send the rest of your yml file (and potentially the rest of the python)? I am 
curious if there is something missing in either the templates or parameters 
sections of your yml file.
Tim

On Friday, January 15, 2021, 2:56:48 PM EST, George Edwards 
 wrote:  
 
 Hello,

I am trying to make a Python OOT block which accepts a stream of 3 inputs 
complex valued data and for each single input sample (one on each input line) 
the block will output 8 complex samples. For my first cut, I am simply trying 
to get the module to work outputting one complex sample (rather than 8). Below 
are the essential parts of my program.
1. In the def __init__ (self.), I set the inner method 
gr.basic_block.__init__(self,       name="my_block_name_py_cc",       in_sig = 
[numpy.complex64,numpy.complex64, numpy.complex64  ],       out_sig = 
[numpy.complex64])       # with 3 inputs and one output
2. In the general_work() method for now I set the output to a constant complex 
value as follows      out_items[0][:] = 1.0+1.0*1j
3. In the *.yml file, the input is set as:        inputs:        - domain: 
stream           dtype: complex           multiplicity: '3'
The module compiles. However, when I run the QA file, it gives an error stating 
something is wrong in File "..blocks_swig1.py at line 8354.TypeError: 
in method 'vector_source_c_make', argument 2 of type 'bool'
I went to the file and the line stated, but I have not seen anything to help me 
make corrections. As far as a TypeError of 'bool', I do not see where I would 
have made such an error. I have an input parameter in the def __init__(self, 
start = True) method, 'start', which comes in as bool, but that is the only 
bool variable I am using. The documentation I read for the method states "This 
block produces a stream of samples based on an input vector" (which is my goal 
if I can get it to work).
I will appreciate any help to get me on the right track.
Regards,George
  

Embedded Python Block - Variable Input Vector

[Tim Huggins]

I created an embedded python block (using version 3.9 from git) successfully 
but I need the input vector to be variable size based on the parameters. For 
example:
in_sig=[(np.byte, a*b)],
out_sig=[(np.byte, a*b)]
However, the parameters have defaults and defaults appear to set the vector. I 
can't change the preceding stream to vector block or else the grc has an error, 
but when I run the grc there is an input error because I was not able to update 
the steam to vector block. A block that does this similarly is a Reed Solomon 
block whose yml file is:
https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/grc/dtv_dvbt_reed_solomon_enc.block.yml
However as far as I can tell there is no way to add a yml file for an embedded 
python block so I tried to create a python OOT module. However I must be making 
a mistake because when I go to build the block I error with:
make[2]: *** No rule to make target '../python/bindings/gnuradio-test', needed 
by 'python/bindings/extracted_docstrings.json'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:377: 
python/bindings/CMakeFiles/extracted_docstrings.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

I think I need to do something from this guide: 
https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
but I haven't figured out the right process. Can anyone help steer me in the 
right direction?
Thanks,
Tim

[Deadline Extended!] Re: Open Workshop on Machine Learning in Communications @ IEEE ICC 2020 (Call for Contributions)

[Tim O'Shea]

Dear GR Community,
This deadline has been extended until Feb 1!
Please consider contributing your work to this workshop!  Hoping to see GNU 
Radio making an appearance & impact here!
I apologize for the repeated announcement :-) 
Best,
Tim

> On Jan 25, 2020, at 10:20 AM, West, Nathan  
> wrote:
> 
> Hi all,
> 
> Please consider contributing your work or demonstration proposals to the 
> workshop at IEEE ICC if you are working at the intersection of communications 
> systems and machine learning. Please see the CFP below for details.
> 
> -Nathan
> 
> Call for Papers:
> 
> IEEE ICC 2020 Open Workshop on Machine Learning in Communications
> 
> 7-11 June 2020, Dublin, Ireland
> 
> ** Submission deadline: January 27, 2020 **
> 
> https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications/
>  
> <https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications/>
> 
> ===
> Call For Papers
> ===
> Machine Learning in Communications is a rapidly growing field within 
> networking and communications with the potential to substantially transform 
> wireless, optical, and other modes of networking and communications 
> engineering in a wide range of future systems by leveraging measurement, 
> data, feedback, domain knowledge, and learning to achieve optimality for a 
> wide range of performance metrics. By directly exploiting real data, 
> representation learning, end-to-end learning, reinforcement learning, 
> concurrent neuromorphic processing, and a wide range of concepts which have 
> advanced rapidly in the machine learning community in recent years, ML-Comms 
> holds the promise to discover alternative and superior ways for information 
> processing in practical application scenarios where deficient or inaccurate 
> models limit present development. `
> Openness and Reproducibility are two essential components in conducting 
> rigorous machine learning driven research, and this workshop seeks to 
> highlight and encourage both of these to help further increase the maturity 
> of communications as a data science.
> · Authors are strongly encouraged to utilize open tools such as 
> pre-publication (e.g. ArXiv), providing reference code, data, simulations, 
> GNU Radio modules, etc. openly (e.g. Github), and fully describe their 
> methodologies in an open and re-producible way such that others can easily 
> validate, leverage and build upon their work.
> · For accepted workshop papers meeting such criterion, IEEE ComSoc is willing 
> to provide as Open-Access publications at no additional fee to the authors!
> 
> MLC Dataset Challenge: In this year’s ICC 2020 Open Workshop, we are also 
> excited to announce an open-dataset challenge focused on the unique task of 
> Vision-Aided Beam Tracking for mmWave Systems. This challenge will adopt the 
> recently developed ViWi dataset. Additional details of the competition and 
> submission will be provided in early February 2020 via the workshop webpage: 
> https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications
>  
> <https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications>.
>  The workshop expects to announce results at the ICC’2020 on a hold-out test 
> set and invite competitors to share their approaches and experiences.
> 
> We invite submissions of unpublished works on the application and theory of 
> machine learning to communications. The workshop shall not restrict the type 
> of machine learning techniques and applications but does provide the 
> following list is a non-exhaustive list of suggested topics.
> · Machine learning driven design and optimization of modulation and coding 
> schemes
> · Machine learning techniques for channel estimation, channel modeling, and 
> channel prediction.
> · Machine learning based enhancements for difficult to model communications 
> channels such as molecular, biological, multi-scale, and other 
> non-traditional communications mediums
> · Transceiver design and channel decoding using deep learning
> · Machine learning driven techniques for radio environment awareness and 
> decision making
> · Machine learning for Internet of things (IoT) and massive connectivity.
> · Machine learning for ultra-reliable and low latency communications (URLLC).
> · Machine learning for Massive MIMO, active and passive Large Intelligent 
> Surfaces (LIS).
> · Distributed learning approaches for distributed communications problems
> · (Deep) Reinforcement Learning and Policy learning for resource management & 
> optimization
> · Reinforcement Learning for self-organized networks and AP/BTS optimization
> · Mach

Re: [Discuss-gnuradio] gr-eventstream OOT module

[Tim O'Shea]

On 04/17/2017 05:26 PM, Cinaed Simson wrote:

Hi - anyone using gr-eventstream?

If I recall correctly, gr-eventstream depends upon

   gr-mapper
   gr-framers
   gr-burst
   python-bitarray


it does not depend on any of these


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

Re: [Discuss-gnuradio] flow graph reconfiguration when using tagged streams

[Tim]

Use async message blocks, whatever you are doing is probably a bad idea

On 02/12/2017 04:29 PM, Damindra Bandara wrote:
> Hi,
>
> I am trying to reconfigure a flow graph that uses tagged streams. When
> I lock() and unlock() the flow graph(or stop()--> wait() and start())
> the blocks that uses tagged streams  produce 'Missing length tag key'
> error. The problem does not appear if I reinitiate all the blocks that
> use tagged streams. Is there a way to reconfigure a flow graph that
> uses tagged streams with out reinitiating all the blocks? I appreciate
> if you could help.
>
> Thank you,
> Damindra
>
> -- 
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
> ___
> 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] Keep M in N

[Tim]

I'd venture to say M>N is living in dangerous territory

On 10/06/2016 10:56 AM, Marcus Müller wrote:
>
> Hi Steve,
>
> The first M of each N. :) (I don't really understand 100% what "every
> N/M" would be in general for arbitrary N>=M, integers).
>
> If you dare to venture into the GNU Radio source code (which I'd
> encourage you to do, it's just that this isn't the most
> beautiful/interesting block), you'll find that the implementation [1]
> simply memcopys the first m items of every n-chunk from in- to output.
>
> Best regards,
>
> Marcus
>
> [1]
> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/keep_m_in_n_impl.cc#L111
>
> On 06.10.2016 16:22, Steve Gough wrote:
>> Hi mailing list,
>>
>> I have a question regarding the Keep M in N block, which keeps M out
>> of every N samples. Is this the first M samples in every N which it
>> retains (or) is it every N/M ?
>>
>> Thanks!
>> Steve
>>
>>
>> ___
>> 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] GNU Radio Conference 2016 Technical Proceedings Now Available!

[Tim]

The technical proceedings / papers from this year's GNU Radio Conference
are now available online!
This is the first year we have had a technical proceedings to accompany
the conference,
participation by speakers was optional but offered a chance to provide a
thorough long term reference for their work!

Proceedings are open-access and may be viewed at http://pubs.gnuradio.org

We are still working on getting google scholar to also index them ...

To Authors,
Thank you for taking the time to write a number of valuable
contributions for the community to refer to your work in depth, and for
making the proceedings a success this year!   Please don't hesitate to
send any updates or revisions you may wish to have included --

Regards,
Tim

http://pubs.gnuradio.org


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

Re: [Discuss-gnuradio] PSK31 (from audio to radio)

[Tim K]

Hey hey!

Glad to see someone using this. (And that it's apparently still working!
Goodness... I need to clean this up...)

I'm giving advice freehand right now, as I don't have my radios with me to
test this. There are definitely more elegant ways for this solution, this
is just the quickest I could think of without reverse engineering what I
wrote forever ago.

Since this is AM, I think you'll only need the Real port on your "Float to
Complex" block. You can attach the "Null Source" to the Imaginary port. Do
a quick check to make sure the real signal's not exceeding +/- 1... you
might want to attenuate it to +/- 0.7 for now, someone else should comment.

As far as the transmit side goes, I'd leave everything up to the "Multiply"
block untouched. Consider that your "audio input" to the radio. After
that...
 - Multiply Const (set to 0.7 for safety)
 - Polyphase Resampler (float/float) set to (1e6 / 48e3) - This gets your
sample rate up to radio speeds
 - Float to Complex (in the Real port, Null Source to the Imag port) - This
makes your signal "complex AM"
 - Send the Complex stream into your Osmocom Sink (set to 1e6 sps) - And
transmit!

If I remember correctly, some radios don't like working at non-integer
sample rates. (The hackRF may be ok though...)

Play gently with your TX gain until you can see it on another radio. (IIRC
the HackRF is simplex... perhaps an RTL?) Use AM to demodulate.

I've been meaning to do a write up on this for a while. If I ever get
around to it, I'll make sure to CC you.

- Tim


On Fri, Sep 2, 2016 at 11:55 PM, pen tester <testerofp...@gmail.com> wrote:

> Hi,
> I am trying to get a simple working example of PSk31 working (transmitting
> with a hackrf and receiving with a rtlsdr dongle). Here is what I have so
> far.
>
>
> Working PSK31 tx and rx with a sound card
> ==
> Transmit: https://github.com/tkuester/gr-psk31/ (examples/psk31_tx.grc)
> Receive: https://github.com/tkuester/gr-psk31/ (examples/psk31_rx.grc)
>
> These work great for sending a PSK31 message over audio card and receiving
> with the audio card.
>
> I just slightly modified them to take input from the "Audio Source" block
> instead of a "Wav File Source" to use the sound card directly:
>
> Transmit Graph: http://www.megafileupload.com/7sm9/psk31_tx.grc
> Transmit Image: http://pasteboard.co/giNm3kNzC.png or
> http://www.megafileupload.com/7smc/psk31_tx-audiocard.png
>
> Receive Graph: http://www.megafileupload.com/7sma/psk31_rx.grc
> Receive Image: http://pasteboard.co/giOlxtWUf.png or
> http://www.megafileupload.com/7smb/psk31_rx-audiocard.png
>
> Turning up the audio a little and tuning to 2003 approx on the rx graph
> results in reception of the sent message "Hello World!"
>
>
>
> Reference version for using hackrf instead of sound card
> ==
> Next, I wanted to modify these to audio versions to work over Radio using
> a HackRF and RTLSDR dongle.
>
> These graphs seems very useful but I couldn't get it working end to end
> for some reason.
>
> Transmit: https://github.com/argilo/sdr-examples (multi_tx.grc)
> Receive:  https://github.com/argilo/sdr-examples (tutorial/6_psk.grc)
>
> I made some changes to the freq to be in range for RTLSDR .e.g changed
> freq from 441e6 in ref graph, changed to 841e6.
>
>
>
> My merged attempt
> =
> The attempt I am currently trying to get working is based on the audio
> soundcard flies for the transmit:
>
> Transmit: Using  audio tx (psk31_tx_attempt2): where I just replaced the
> audio sink with the Osmocom sink (not sure what else is needed here for
> transmission over hackrf)
>
> Transmit Graph: http://www.megafileupload.com/7smi/psk31_tx-attempt2.grc
> Transmit Image: http://pasteboard.co/giOMGNqD9.png or
> http://www.megafileupload.com/7sme/psk31_tx-attempt2.png
>
> Receive Graph: http://www.megafileupload.com/7smh/6_psk-hackrf.grc
> Receive Image: http://pasteboard.co/giPflR4TI.png or
> http://www.megafileupload.com/7smf/6_psk_hackrf.png
>
> For the receive, I just left radio rx part in and replaced the decoder
> parts with decoding logic from https://github.com/tkuester/gr-psk31/
> (examples/psk31_rx.grc). I made other minor changes such as freq and sample
> rates.
>
>
>
> My question
> 
> So in summary, just looking for a little guidance on my merged attempt to
> get psk31 out over a hackrf and received using a RTLSDR. Any advice for a
> learner would be great :-)
>
>
>
> ___
> 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] gr-psk31

[Tim K]

Hey there!

Boy, it's been a long time since I touched that code. It's very "hacked
together", and needs some love!

I'd recommend trying psk31_rx.grc with this video[1]. If you have
youtube-dl, you can save it to a wav file.

For the TX side, I didn't really get that flushed out properly. The audio
sink doesn't like it when you stop sending samples to it, and I couldn't
figure out a tidy way to clean things up.

In the mean time, look at the vector source in psk31_tx.grc. \x80 is the
"preamble" byte, and everything else is just plain ASCII.

That should get you up and running! Maybe if I have some time later, I can
get a transmitter block up and running with the osmocom sink. It's just a
simple AM transmitter.

- Tim

[1] https://www.youtube.com/watch?v=qHNvp7FfP6E

On Sun, Jul 10, 2016 at 1:12 AM, Eoin 0w3n <eoin.0...@gmail.com> wrote:

> Hi,
>   I've been having some fun with gr-psk32 (
> https://github.com/tkuester/gr-psk31).
>
>   The aim is to be able to send ascii with a hackrf nd then receive with
> an rtlsdr.
>
>For now, I would just like to get the rx and tx examples working over
> audio/soundcard.
>
>I just added an audio source block to the "psk_rx.grc" and left the
> "psk_tx.grc" example as-is.
>
>When trying to tune on the right hand wide waterfall, I seem to get
> something close around 1850. I end up receiving "holmoewnrmg\n" which looks
> to be something related to the transmitted "hello world!\n" vector in the
> example.
>
>Has anyone got the tx and rx working for gr-psk32? Im sure its just a
> small setting somewhere.
>
>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

Re: [Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one

[Tim Castiglia]

I found a workaround that's not so pretty, but it works. Setting the
flowgraph to None does not work for me because it makes my other python
threads that are running throw errors. The problem turns out is more of a
low level hardware problem, or at least that's the case for when I use my
specific hardware driver.

The file descriptor my hardware was open on was closed, but an error
occurred when restarting the flowgraph in closing and reopening the file
descriptor. I cannot track down what exactly is causing the error, but
instead of fixing it, I just took out the close(fileDescriptor) line in my
code. This doesn't harm the system because the same file descriptor is use
anyway when the flowgraph is restarted.

I also realized that having a global flowgraph will be difficult to change
within python, so I made a wrapper class that holds the flowgraph as a
member variable, and made the class global instead. On top of this, when I
restart the flowgraph, I change the wrappers flowgraph, and then set a
member variable flowgraph in the socket class to be equal to the wrapper's
flowgraph. This might be overkill, but it works.

#I import that object into my server code
import flowgraphInit from flowgraph
#I can also import my other flowgraph
import newFlowgraphConstructor from flowgraph2

class wrapper():
__init__(self):
self.flowgraph = flowgraph

#At global level
flowgraph = flowgraphInit()
flowgraph.start()
wr = wrapper()

class ClientSocketConnection
__init__(self):
self.flowgraph = wr.flowgraph
#other functions
def onMessage(payload):
#Parse message
#If we need to change to a different flowgraph
wr.flowgraph.stop()
wr.flowgraph.wait()
time.sleep(5)
self.resetFlowgraph()

def resetFlowgraph(self):
wr.flowgraph = newFlowgraphConstructor()
wr.flowgraph.start()
self.flowgraph = wr.flowgraph

def main():
#create socket factory so we can allow many connections


On Fri, Jul 8, 2016 at 10:35 AM, Dave NotTelling <dmp250...@gmail.com>
wrote:

> Tim,
>
>  One thing I have found with the Python stuff is that you need to set
> the flow graph variable to None for resource to be released.  moo =
> myGraph(); moo.start(); time.sleep(10); moo.stop(); moo.wait(); moo = None;
> moo = myGraph(); moo.start() .
>
> -Dave
>
> On Thu, Jul 7, 2016 at 6:14 PM, Tim Castiglia <cas...@rpi.edu> wrote:
>
>> First I should give some context on my project. What we are trying to
>> build is a python server that utilizes gnuradio's blocks to get information
>> from hardware and send it outbound, as well as receiving requests from
>> clients to the server about configuration of flowgraph. More specifically,
>> right now, I have:
>>
>> Oscom Source -->Log Power FFT --> Vector Probe
>>
>> For simplicity, I am using the RTL-SDR for testing purposes. In the
>> future, we will be using our own device driver created within the SoapySDR
>> framework, hence why we are using the oscom block.
>>
>> The problem starts with the fact that this may not be the only flowgraph
>> we utilize. The hardware we are using may start pumping out FFT values
>> instead of IQ values. Which means we would need a flowgraph that looks more
>> like:
>>
>> Oscom Source --> Vector Probe
>> (Ignore the fact that this is not possible with the oscom block
>> currently, we will cross that bridge in the future)
>>
>> So I need to be able to stop my current running flowgraph, and start a
>> new one. This is where I run into trouble. I can stop my flowgraph
>> perfectly fine with:
>>
>> flowgraph.stop()
>> flowgraph.wait()
>> time.sleep(5)
>>
>> But I would like to keep the variable the same in my python code even
>> when I change the flowgraph. So I try:
>>
>> flowgraph = newFlowgraphConstructor()
>>
>> But this causes a python error at the flowgraph.stop() line: "variable
>> mentioned before instantiated"
>>
>> To get around this, I made a resetFlowgraph function:
>> def resetFlowgraph():
>> flowgraph = newFlowgraphConstructor()
>> flowgraph.start()
>>
>> and call things in this order:
>> flowgraph.stop()
>> flowgraph.wait()
>> time.sleep(5)
>> resetFlowgraph()
>>
>> The flowgraph starts successfully, but fails to "claim" the RTL-SDR from
>> the old flowgraph. I have also tried the same with only my device plugged
>> in, and a similar problem occurs. Is there a way to force the flowgraph to
>> relinquish its hold on the hardware? Our python server code needs to
>> continue running, so I need to be able to do this restart without ending
>> the program (The id

[Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one

[Tim Castiglia]

First I should give some context on my project. What we are trying to build
is a python server that utilizes gnuradio's blocks to get information from
hardware and send it outbound, as well as receiving requests from clients
to the server about configuration of flowgraph. More specifically, right
now, I have:

Oscom Source -->Log Power FFT --> Vector Probe

For simplicity, I am using the RTL-SDR for testing purposes. In the future,
we will be using our own device driver created within the SoapySDR
framework, hence why we are using the oscom block.

The problem starts with the fact that this may not be the only flowgraph we
utilize. The hardware we are using may start pumping out FFT values instead
of IQ values. Which means we would need a flowgraph that looks more like:

Oscom Source --> Vector Probe
(Ignore the fact that this is not possible with the oscom block currently,
we will cross that bridge in the future)

So I need to be able to stop my current running flowgraph, and start a new
one. This is where I run into trouble. I can stop my flowgraph perfectly
fine with:

flowgraph.stop()
flowgraph.wait()
time.sleep(5)

But I would like to keep the variable the same in my python code even when
I change the flowgraph. So I try:

flowgraph = newFlowgraphConstructor()

But this causes a python error at the flowgraph.stop() line: "variable
mentioned before instantiated"

To get around this, I made a resetFlowgraph function:
def resetFlowgraph():
flowgraph = newFlowgraphConstructor()
flowgraph.start()

and call things in this order:
flowgraph.stop()
flowgraph.wait()
time.sleep(5)
resetFlowgraph()

The flowgraph starts successfully, but fails to "claim" the RTL-SDR from
the old flowgraph. I have also tried the same with only my device plugged
in, and a similar problem occurs. Is there a way to force the flowgraph to
relinquish its hold on the hardware? Our python server code needs to
continue running, so I need to be able to do this restart without ending
the program (The idea is to have the server always be running and not be
manned most of the time).

Here's some pseudo code to give you an idea of how the code is structured:

#First I have a premade object generated from gnuradio-companion
#I import that object into my server code
import flowgraphInit from flowgraph
#I can also import my other flowgraph
import newFlowgraphConstructor from flowgraph2

#At global level
flowgraph = flowgraphInit()
flowgraph.start()

class ClientSocketConnection
...#init and other functions
def onMessage(payload):
#Parse message
#If we need to change to a different flowgraph
flowgraph.stop()
flowgraph.wait()
time.sleep(5)
resetFlowgraph()

def resetFlowgraph():
flowgraph = newFlowgraphConstructor()
flowgraph.start()

def main():
#create socket factory so we can allow many connections
#So there is only one flowgraph, but many people can see it and
potentially change it

(I have seen this question asked before here
https://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00411.html
but there was no solution in the thread)

Any help is appreciated!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Conference 2016 Technical Proceedings Call for Papers (extended date: now July 18)

[Tim]

We are excited to be including our first ever GNU Radio Conference
Technical Proceedings this year at GRCon16!

Proceedings provide a great format in which talks and ideas can be
documented and explained in great detail, easily found, referenced and
built upon by attendees and non-attendees in the future! 

So far we have had a very positive reception to this addition to GRCon,
and have received a number of excellent submissions. 

However, due to the extension of the talk abstract submission deadline,
generally busy summertime happenings, and the hope to give more people
time to participate, *we are extending the draft paper submission date
to July 18, 2016*.

We hope that everyone planning to give a talk at GRCon this year will
*strongly consider submitting a technical article* to accompany their
talk as well and to help leave a more lasting impact on the community!

As a reminder, information for authors along with our template can be
found at http://gnuradio.org/grcon-2016/call-for-submissions/

Regards,
Tim O'Shea
Chair, GRCon16 Technical Proceedings






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

Re: [Discuss-gnuradio] disabling UHD OOOOO... messages

[Tim K]

It may be nice to have this as an option to disable, in case the user wants
to reserve stderr for their own purposes.

On Wed, May 11, 2016 at 9:28 PM, Marcus D. Leech  wrote:

> On 05/11/2016 06:24 PM, Engin Karabulut wrote:
>
>> loosing samples isn't important for my application, my sample rate is 4
>> Msps but my CPU is weak(Intel N3150I). so I only want to disable these
>> annoying messages.
>>
>> If your application doesn't also use stderr, you can just:
>
> your-application  2>/dev/null
>
>
>
>
>
> ___
> 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] Tutorial on BPSK bursts

[Tim K]

It's not terrifically designed, but you might find my PSK31 repo helpful.
According to Balint though, the PLL is supposed to go after clock recovery,
not before.

https://github.com/tkuester/gr-psk31

- Tim

On Fri, Mar 4, 2016 at 8:56 PM, Jesse Reich <jrre...@gmail.com> wrote:

> So I've been playing with GNU Radio for about 2 months and trying to learn
> about signals and signal processing in general. Mostly out of curiosity
> that has sprung up from my profession. I am an Aerospace engineer by
> training and I work as a satellite ground systems engineer for the
> Cospas-Sarsat program.
>
> I've started with what I thought should be an easy task with aspirations
> of more complex tasks. The first task, decode a BPSK signal modulated on a
> 406 MHz carrier. The signals consist of a 160 ms carrier,  24 sync bits and
> then 120 data bits at 400 bits/sec. I'm just trying to decode and write the
> bits. Sounded to me to be an easy problem to tackle. Unfortunately I can't
> seem to even get off of the ground. Does anyone know of any tutorials that
> would be good.
>
> I've tried the gnuradio tutorials and honestly they don't really seem to
> help. Any help would be greatly appreciated.
>
> Thanks,
> Jesse
>
> ___
> 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] An End-to-End working example for GNU Radio on Zedboard

[Tim K]

Very cool. I'd be interested in looking into this further.

Am I correct in thinking that you didn't have the FPGA pass from QD to the
filters? That is to say, each block went into the FPGA, and back to the
computer?

- Tim

On Tue, Jan 26, 2016 at 2:08 PM, Alireza Khodamoradi <
ar.khodamor...@gmail.com> wrote:

> Hi everyone,
>
> I like to share our source code and some tutorials on how to implement and
> use GR on ZedBoard. You also can find custom blocks in GR designed to
> interact with XIllybus that you can use as drag and drop in GRC.
>
> https://bitbucket.org/maswes/gnuradio_on_fpga-cohort3/wiki/Home
>
> Cheers,
> Alireza
>
> ___
> 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] Asynchronous source with zeros in between

[Tim O'Shea]

You may want to look at gr-eventstream source block, this is exactly what
it is intended to do, precisely timed if desired


On Mon, Nov 30, 2015, 2:38 PM Francisco Albani 
wrote:

> Hi to all.
>
> (this email subject may be inaccurate)
>
> I need a block with the following characteristics:
>
> * Input port for messages.
> * Output port for complex/float/byte/etc. stream.
> * Forecast always answers 0.
> * Work function first check the message queue. If there are no messages,
> emits zeros; if there are, it emits the samples inside the message.
>
> I'm willing to write it, but first I want to hear from the people in the
> list in case this can be crafted using existing blocks or if this idea is
> deemed to fail for some reason I can't see.
>
> I need this in order to transmit N parallel burst radios using something
> like Polyphase Channel Synthesizer. The problem emerges when not all the
> transmitters have data to send and stop the other transmitters flows.
>
> Many thanks!
>
> Bye.
> ___
> 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] Working with Tags

[Tim K]

Hey all,

I just saw Tom has a patch for a similar bug I had relating to tags and
resampling. Just bringing this to the discussion in case it helps anyone
else!

http://gnuradio.org/redmine/issues/831#change-2511

- Tim

On Mon, Jan 4, 2016 at 8:55 AM, <mark.w.christian...@l-3com.com> wrote:

> My tag generator takes data packets that are time stamped for the first
> sample of each packet and needs to tag the stream produced in the work
> function. I tag starting m_tag_offset = 0 and then increment by the number
> of samples from my packets after each time I add_item_tag().
>
>
>
> I wouldn’t care so much about the tags stopping except that I sometimes
> have a dropped packet and the timing is off from then on.
>
>
>
> *From:* discuss-gnuradio-bounces+mark.w.christiansen=l-3com@gnu.org
> [mailto:discuss-gnuradio-bounces+mark.w.christiansen=l-3com@gnu.org] *On
> Behalf Of *Paul David
> *Sent:* Thursday, December 31, 2015 6:47 PM
> *To:* Tom Rondeau
>
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Working with Tags
>
>
>
> Weird. I don't see a problem between strobe_tags -> moving average ->
> vector sink with my test. How is m_tag_offset getting set?
>
>
>
> On Thu, Dec 31, 2015 at 7:43 PM, Paul David <pudda...@gmail.com> wrote:
>
> I'm gonna check this out. I may have fixed this according to the tests we
> were looking at, but introduced a bug elsewhere.
>
> A QA test involving the moving average blocks and stream tags might help
> clear things up.
>
>
>
> On Thu, Dec 31, 2015 at 10:38 AM, Tom Rondeau <t...@trondeau.com> wrote:
>
> On Wed, Dec 30, 2015 at 3:32 PM, <mark.w.christian...@l-3com.com> wrote:
>
> It’s a tag generator that goes through several other blocks before getting
> to the tag receiver.
>
>
>
> tag generator - mag^2 - moving average --- divide - add
> constant - tag receiver
>
>\- moving average -/
>
>
>
> Basically I’m computing the ration of a fast average to a slow average and
> sending that to a threshold detector sink (tag receiver) to watch for the
> signal to go above threshold. It then sends a message with the time stamp
> of that event to another block for other processing. I wrote the tag
> generator and tag receiver.
>
>
>
> Mark.
>
>
>
>
>
> I'd recommend plugging the tag generator directly into the tag receiver
> just to make sure both of those are handling the tags properly. If they
> are, then we can dive into the rest of the chain to see where things might
> be having problems. My guess is that it'll be related to the different
> delays of the moving average filters.
>
>
>
> This also might be related to a bug that we recently patched:
>
>
> https://github.com/gnuradio/gnuradio/commit/ae2e24f86b562a5bdcb9f5170e0abb1cd15838cf
>
>
>
> Tom
>
>
>
>
>
>
>
>
>
> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf
> Of *Tom Rondeau
> *Sent:* Wednesday, December 30, 2015 9:36 AM
> *To:* Christiansen, Mark W. @ CSG - CSW
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Working with Tags
>
>
>
> On Wed, Dec 30, 2015 at 11:15 AM, <mark.w.christian...@l-3com.com> wrote:
>
> I wrote a block that writes the rx_time tag and another block that reads
> it. After reading them for a 20 to thirty calls to the work function, it
> stops getting any. The amount it reads varies from run to run. Any ideas?
>
> This code snippet is from the work function my block that writes the tag.
> The cerr statement continues to print to the console until I stop execution.
>
>
>
> 
>
> VITA49_packet_info packet_info = p_packet->get_VITA49_packet_info();
>
> if (m_do_send_tags)
>
> {
>
>   double timestamp_in_seconds =
>
>   static_cast(p_packet->get_integer_seconds()) +
>
>   static_cast(p_packet->get_fraction_seconds()) * 1e-12;
>
>   const pmt::pmt_t timestamp = pmt::make_tuple(
>
>   pmt::from_uint64(static_cast long>(floor(timestamp_in_seconds))),
>
>   pmt::from_double(timestamp_in_seconds -
> floor(timestamp_in_seconds)));
>
>   std::cerr << "SEND (" << d_id << ") "
>
> << " tag_offset=" << m_tag_offset
>
> << std::setprecision(std::numeric_limits::digits10
> + 1)
>
> << " timesamp_in_seconds=" << timestamp_in_seconds <<
> std::endl;
>
>   add_item_tag(0, m_tag_offset, TIME_KEY, timestamp, d_id);
>
&g

Re: [Discuss-gnuradio] Message inputs and hierachical block: incompatibility introduced in GNU Radio 3.7.9

[Tim O'Shea]

Hi Piotr,

Hier message ports were actually not working at all prior to this fix -
- since the logic had been changed from the originally functioning pub/sub
based message connection data structures into the more traditional digraph
flattening structure incorrectly
please see:  http://gnuradio.org/redmine/issues/862#change-2460

This change was needed to correct the hier port flattening logic
and was the originally intended API that got reversed somewhere along the
way -
GRC was updated to correspond --
Have you tested your hier message ports actually function with 3.7.8
successfully prior to this?  I would be kind of surprised -
Perhaps if you are writing python code, some kind of conditional check work
around might be in order, or just dropping support for old versions as they
did not function correctly

-Tim



On Sat, Jan 2, 2016 at 4:12 AM Piotr Krysik <per...@o2.pl> wrote:

> Hi all,
>
> In GNU Radio version 3.7.8 message inputs of hierarchical blocks were
> created from python level with:
>self.message_port_register_hier_out("msg_in")
>
> Starting (most probably) from GNU Radio 3.7.9 message inputs are created
> with:
>self.message_port_register_hier_in("msg_in")
>
> This leads to incompatibility. I can't now distribute to the users
> python code of hierarchical blocks generated with GRC because for some
> of them it won't work (if they don't use the same GNU Radio version as I
> do). Compilation of GRC files to python with grcc during building is not
> an option as it doesn't work reliably yet and it will lead to higher
> level of problems.
>
> Currently I manually added this code to my hierarchical blocks in order
> to make them work on with GNU Radio earlier than 3.7.9:
>
>   from distutils.version import LooseVersion as version
>
>   if version(gr.version()) >= version('3.7.9'):
> self.message_port_register_hier_in("msg_in")
>   else:
> self.message_port_register_hier_out("msg_in")
>
> Is it possible to fix this problem for example on the level GRC - so it
> generate code that is compatible with GNU Radio versions < 3.7.9 and
> >=3.7.9?
>
> Best Regards,
> Piotr Krysik
>
> ___
> 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] OOT module authors, please update your cmake

[Tim K]

Could there be perhaps a `gr_modtool update_cfiles`?

On Tue, Dec 29, 2015 at 8:55 PM, Michael Dickens 
wrote:

> On Tue, Dec 29, 2015, at 08:30 PM, Johnathan Corgan wrote:
>
> On Tue, Dec 29, 2015 at 5:08 PM, Philip Balister 
> wrote:
>
> Dunno, but gr-newmod (or whatever it is called) in gnuradio has a copy
> of the files. I had to fix the issue twice.
>
>
> This is good opportunity then to see what we can now remove from gr-newmod.
>
>
> Yes! Or, whatever the name ends up being. +1 from me!
>
> ___
> 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] Help decoding Bell 202

[Tim K]

En,

Ah! Sitting and playing with it greatly helped my understanding of the
problem.

1. Your capture seems to have some distortion on it. Fortunately, this
doesn't affect FM too bad, but you may want to crank your gain back.
2. Remember, Bell 202 uses 1200 Hz and 2200 Hz. You probably don't want
1200 Hz as the corner for your LPF. FSK Demod already has one as well, I
just removed it.
3. I listened to the transmissions, and looked at the data. It does sound
like Bell 202, and appears to have HDLC frames... but it doesn't sound like
APRS. May I ask where you got this?

What I got after removing the LPF: http://i.imgur.com/Z3EbIgU.png

- Tim

On Mon, Dec 28, 2015 at 12:07 AM, En Shih <seanstone5...@gmail.com> wrote:

> Thanks, Tim. That really clarified a lot of confusion that I had!
>
> I have uploaded the files here:
>
> https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing
> <
> https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing
> >
> -"bell202new.grc" is the current flow graph.
> -"dump" is how the input signal I'm trying to decode looks like.
> -"decoded" is the bytes of a successfully decoded signal, which was decoded
> previously using some hardware equipment. (some parts of the data may be
> corrupted)
> -"imet.pdf" explains the data packet.
> -"tcp.py" explains the data packet.
>
> As far as I know, at the physical layer the data is modulated using Bell
> 202. The data framing is not AX.25, but conforms to UART, although I'm
> unsure about the parity and stop bits. I tried looking for the data frames
> by looking for start/stop bits, the header. I've also tried flipping the
> bits. However, it still doesn't look quite right.
>
> Correct me if I'm wrong: your FSK demod block uses tone detection to
> demodulate, which is passing the signal through two band pass filters in
> parallel, and determine which comes through (as in p.9 of
> http://edge.rit.edu/edge/P09141/public/FSK.pdf)
>
> Regards,
> En Shih
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57503.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help decoding Bell 202

[Tim K]

Just some obsesrvations...

 - Why do WBFM to Audio? Shouldn't that be NBFM?
 - Your post NBFM receive looks good.
 - Your QD output looks a little strange. Perhaps look at the FFT of your
signal before the QD?
 - In my experience the MM Clock Recovery block likes using ~4 sps. Perhaps
use the Rational Resampler to decimate by 10 first?
 - 2 MHz / 40 = 50 kbps... did you mean to be working with 1200 baud?

I've done my own "1200 baud AFSK" receiver, you may be interested in it.

https://github.com/tkuester/gr-bruninga

- Tim

On Sun, Dec 27, 2015 at 7:52 AM, En Shih <seanstone5...@gmail.com> wrote:

> Hi all,
>
> I am trying to decode a Bell 202 signal from a RTL dongle source using GNU
> Radio Companion 3.7.8.1.
> I am new to GNU Radio and signal processing, and constructed this flow
> graph
> by searching previous topics on AFSK:
>
> <http://gnuradio.4.n7.nabble.com/file/n57483/2015-12-27_20-51-40.png>
> first by passing through a NBFM and then a quadrature demod, but I can't
> recover the expected signal, which should have bytes 01 04 or 01 01 at the
> start of a packet.
>
> This is how the signal looks like:
>
> 1. RTL-SDR source
> <http://gnuradio.4.n7.nabble.com/file/n57483/signal1.png>
>
> 2. After NBFM receive
> <http://gnuradio.4.n7.nabble.com/file/n57483/3.png>
>
> 3. After quadrature demod
> <http://gnuradio.4.n7.nabble.com/file/n57483/5.png>
>
> 4. Final
> <http://gnuradio.4.n7.nabble.com/file/n57483/6.png>
>
> Does it look like I am on the right track?
>
> The grc file, a dump of the original signal, and a decoded file is stored
> here:
>
> https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing
> <
> https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing
> >
> The decoded file was done using a physical modem, and its contents does not
> match the dump but is in the same format.
>
> I have also tried using  multimon-ng
> <https://github.com/EliasOenal/multimon-ng>   with the following command:
> rtl_fm -f 40200 -s 22050 | multimon-ng -a AFSK1200 -t raw /dev/stdin
> but to no avail.
>
> Thanks.
>
> Regards,
> En Shih
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help decoding Bell 202

[Tim K]

En,

It's hard to judge exactly from your screen shots... if I had your .grc
files and sample inputs, I might be able to do a little better! You may
find the APRS test CD [1] useful, if you haven't used it already.

Here's what I get using the test CD, and aprs-wav.grc. I happened to take
the screenshot just at a good moment! You can consider the bottom graph to
be the output of the QD block, though in this implementation it's measuring
the difference in amplitude of the 1200 and 2200 Hz tones.

First, I should note, people use Bell 202, AFSK, AX.25, and APRS
interchangeably... but they are not!

 - Bell 202 is the physical layer spec, which sends data 1200 baud with
2FSK. The "tones" used are 1200 Hz and 2200 Hz.
 - AFSK is a term I don't like very much... audio frequency shift keying?
It often refers to Bell 202, although wouldn't P.25 C4FM be audio frequency
shift keying as well? Either way, I digress!
 - AX.25 is a protocol which specifies a packet format and communication
standard. Interestingly enough, it does not specify the physical layer at
all.
 - APRS is an application of AX.25 which almost exclusively uses Bell 202
and NBFM VHF radios to send packets with position reports. (Much to the
designer's chagrin, I might add... but when you only have UDP style frames,
ensuring receipt is rather difficult...)

Most of what I'm writing focuses on a generic APRS application. Anyways,
with that out of the way! I'll start my discussion at the end of the
receiver, and work my way back to the "audio waveform" itself.

http://i.imgur.com/KOBLLDz.png

The top graph shows the recovered "bits". Note how there is nice separation
between the 1's and 0's, and how the waveform is nicely centered around 0.
This should lead to good data recovery.

The bottom graph (although not aligned with the top graph) shows the data
waveform just before clock recovery. You can see the distinctive "HDLC
frame sync byte" of 0x7e (ASCII ~) being repeated over and over again. This
is in contrast to other radios that use (0x55) and a sync word. You can
read more about it here:
https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

http://i.imgur.com/HV3EjTE.png

In the bottom graph, you can see the original audio signal. If you look
very closely, you might even be able to see the sync byte being repeated
(0x7e, or 0110).

Unlike your application which uses the QD block to demodulate the FSK, I'm
doing a receiver more like the one you can find here on page 9. (
http://edge.rit.edu/edge/P09141/public/FSK.pdf) That's why there's a red
and blue waveform that are near compliments of each other.

You may find this paper interesting as well, as it explains many of the
troublesome points of APRS.

http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=2449=theses

- Tim

On Sun, Dec 27, 2015 at 10:00 AM, En Shih <seanstone5...@gmail.com> wrote:

> Thanks for the reply, Tim.
>
> - The WBFM is a remnant I've never corrected. I now have the audio from
> NBFM.
> - The baudrate is 1200.
>
> This is the Fourier after Hilbert before QD:
> <http://gnuradio.4.n7.nabble.com/file/n57488/13.png>
> <http://gnuradio.4.n7.nabble.com/file/n57488/11.png>
> and the corresponding time plot:
> <http://gnuradio.4.n7.nabble.com/file/n57488/10.png>
> <http://gnuradio.4.n7.nabble.com/file/n57488/12.png>
> I am unsure if that looks right or not.
>
> Is it so that the signal after QD should look something like this?
> <http://gnuradio.4.n7.nabble.com/file/n57488/demod_timedomain.png>
> (image taken from
>
> http://www.indigresso.com/wiki/lib/exe/fetch.php?media=opentag:radios:demod_timedomain.png
> )
>
> I have tried your FSK demodulator block, and the initial result looks nice.
> <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-35-40.png>
> <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-40-37.png>
> <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-38-51.png>
> However, I haven't been able to identify the characteristic preamble for
> each data packet. Am I using the block correctly, or is there some
> tweaking/synchronization that I should do?
>
> Regards,
> En Shih
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57488.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] asynchronous messaging frameworks

[Tim]

For most applications,
I would suggest building a python native GNU Radio message block to
interact with a graph --
and *not* jumping to thrift or zmq without a reason --
bridging messages and streams over zmq IPC is doable but more work -- in
this case PMT serialization and JSON are the most used message formats -
valid reasons might be if gnu radio is secondary to your app and you
want a large layer of separation, process separation, or remote message
passing
-Tim

On 12/27/2015 11:42 AM, Marcus Müller wrote:
> Hi Daniel,
>
> On 12/27/2015 03:10 PM, Daniel Pocock wrote:
>> Is there any generic documentation about the use of GNU Radio with
>> asynchronous messaging and integration frameworks or would it be useful
>> to build up a wiki page about the topic?
> There's internal asynq messaging in GR (the "light grey" connections
> between blocks); message passing is relatively well-documented in the
> doxygen [1], and there's a bit on it in the guided tutorials[2].
> As everything, it could be better documented :) Documentation patches
> for the doxygen are always as welcome as wiki extensions.
> For the RPC beneath the controlport interface[3] we use Apache Thrift.
> There's also the XMLRPC, but I'm not experienced with that. I hear you
> can develop web-style applications with it easily.
>
> For network and IPC, we basically support zeroMQ, UDP, and of course
> simple Unix mechanisms like FIFOs and everything that can get a file
> descriptor.
>> I came across some pages referring to ZeroMQ support[1], I was also
>> curious about support for Qpid Proton[2] and other AMQP[3] systems.
>> There were some comments elsewhere about people using OpenMAMA[4]
>> (designed for low-latency financial messaging) to transport radar data,
>> among other things.
>>
>> Another possibility that comes to mind is D-Bus[5] support, either at a
>> low-level (other desktop applications controlling the radio or receiving
>> data from the radio) or high level (e.g. a Telepathy Connection
>> Manager[6] implementing one of the various digital messaging
>> solutions[7] or even Morse code)
> I personally don't know of any implementation of adapters for any of
> these; however, writing e.g. a dbus to message passing adapter won't be
> too hard. In fact, it should be but a couple of lines of python, unless
> things get overly involved with business logic etc.
>
> For your App-to-GNU Radio adaption, ZeroMQ pretty much sounds like a
> perfect match. It's leightweight, multi-language, easy to learn.
>> This could be a good way to further empower people familiar with other
>> systems, e.g. there was some question a while ago about how gpredict
>> could integrate with GNU Radio for real-time doppler shift
>> correction[8].  Doing such things over an asynchronous message bus leads
>> to looser coupling, so it is easier to swap components for
>> test/simulation or add more components to the architecture.
> I really cannot stress enough how right you are: GNU Radio definitely
> needs to get as "usable" from an application developer's perspective.
> Easy solutions for sending information to and from applications are most
> of the times sufficient; ZeroMQ definitely has become my tool of choice
> for that. However, at some level of complexity, you start to implement
> remote procedure calling.
> RPC, however, isn't easy. You might really want to stick with
> controlport, which is deeply integrated in GNU Radio, and its thrift
> foundation, if you have the choice.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/doc/doxygen/page_msg_passing.html
> [2]
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Programming_Topics#53-Message-Passing
> [3] http://gnuradio.org/doc/doxygen/page_ctrlport.html
>
> ___
> 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] ham/amateur getting started

[Tim K]

Hey Dan, you may be interested in this app!

https://github.com/madengr/ham2mon

- Tim

On Wed, Dec 23, 2015 at 3:47 PM, Daniel Pocock <dan...@pocock.pro> wrote:

>
>
> Hi all,
>
> I did a quick search for resources for ham/amateur operators getting
> started with GNU Radio, I came across these:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/HamRadio
> http://www.oz9aec.net/index.php/grc-examples
>
> Both of them refer to receivers, the latter has an SSB transmitter as well.
>
> Is there any more getting started documentation about full transmit and
> receive solutions for popular amateur bands like 2m and 70cm narrow band
> FM?
>
> Regards,
>
> Daniel
>
> ___
> 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] Renaming PyBOMBS

[Tim O'Shea]

Most new users should be installing gnu radio binaries via their os package
manager repos or ppa.   Pybombs should be used for 1. Helping get up to
date oot modules set up and deployed ( like pip ) and 2. Helping developers
set up their development environment.
So I'm not sure installer is the right idea to impart on new users at all

On Wed, Dec 23, 2015, 1:23 PM Richard Bell  wrote:

> I'd like to throw in another point from an entry level perspective. Those
> people who might need pybombs most, are those who need names that tell them
> what it's for the most. Even if it is incorrect to call pybombs an
> installer, it would really help the entry level folks (which I would claim
> without support is the largest population of the community at any given
> time) understand what it's for and how they should use it. I think we all
> have the experience of learning new tools and running into tool names,
> which even though the description is spot on for what its for, at the time
> carried zero value for the new guy using it (thinking mostly about Xilinx
> tool names here).
>
> With that said, I think it would be good for the community to use the word
> installer in the tool that makes gnuradio and uhd really easy to install,
> and is what the vast majority of people I'm guessing would use it for.
>
> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun 
> wrote:
>
>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well and
>> > you can think of the associated sentences ;)
>>
>> 'grab' is also a very common english verb, so I think people would be
>> able to distinguish. It also sounds like 'crab' if you like :)
>>
>> M
>>
>> >
>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>> >> GRAB = Gnu RAdio Basic installer
>> >>
>> >> Then we can say things like "Go GRAB it" when referring to a needed
>> module
>> >>
>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun > >
>> >> wrote:
>> >>
>> >>> There's been some demand to rename PyBOMBS, and now that we're
>> >>> re-releasing it, this is a good time to think about it. Complaints
>> about
>> >>> the name include:
>> >>>
>> >>> - It may or may not be true that people have been detained by TSA for
>> >>> working on PyBOMBS at the airport[1]
>> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>> >>> rather than a GNU Radio-related tool
>> >>> - People can't agree on a capitalization
>> >>> - No one can remember what the acronym stands for
>> >>>
>> >>> Sure, this is not a critical thing, but now's a good chance to bring
>> it
>> >>> up and also, this is not a joke :)
>> >>>
>> >>> Here's how we're going to do this:
>> >>>
>> >>> - Please suggest new names in this thread.
>> >>> - I will choose from those names based on 'can I live with this name',
>> >>> 100% subjectively.
>> >>> - New names will be put up for a vote. This will include an option to
>> >>> keep the old name.
>> >>> - Finally, the result of the vote will be used as a strong suggestion
>> on
>> >>> what the new name will be.
>> >>>
>> >>> There already have been some suggestions:
>> >>>
>> >>> - gromit -- the GNU Radio out-of-tree module installation tool
>> >>> - the groot
>> >>> - grpm -- the GNU Radio package manager
>> >>>
>> >>>
>> >>> OK guys, bring up the ideas!
>> >>>
>> >>> Cheers,
>> >>> Martin
>> >>>
>> >>> [1] It's not.
>> >>>
>> >>> ___
>> >>> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim O'Shea]

Ubuntu packages uhd
Assuming other oses do too
I'm sure there are up to date ppas somewhere too

On Wed, Dec 23, 2015, 1:34 PM Richard Bell <richard.be...@gmail.com> wrote:

> Is there a way for a new user to get uhd installed from the package
> manager though? A lot of people want to dive right into gnu radio with
> hardware, doing simple things like spectrum analysis. I'm not aware of a
> way of getting the uhd + gnuradio setup running that's easier then pybombs.
> I very well could be wrong here.
>
> On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com>
> wrote:
>
>> Most new users should be installing gnu radio binaries via their os
>> package manager repos or ppa.   Pybombs should be used for 1. Helping get
>> up to date oot modules set up and deployed ( like pip ) and 2. Helping
>> developers set up their development environment.
>> So I'm not sure installer is the right idea to impart on new users at all
>>
>>
>> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> I'd like to throw in another point from an entry level perspective.
>>> Those people who might need pybombs most, are those who need names that
>>> tell them what it's for the most. Even if it is incorrect to call pybombs
>>> an installer, it would really help the entry level folks (which I would
>>> claim without support is the largest population of the community at any
>>> given time) understand what it's for and how they should use it. I think we
>>> all have the experience of learning new tools and running into tool names,
>>> which even though the description is spot on for what its for, at the time
>>> carried zero value for the new guy using it (thinking mostly about Xilinx
>>> tool names here).
>>>
>>> With that said, I think it would be good for the community to use the
>>> word installer in the tool that makes gnuradio and uhd really easy to
>>> install, and is what the vast majority of people I'm guessing would use it
>>> for.
>>>
>>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com>
>>> wrote:
>>>
>>>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well
>>>> and
>>>> > you can think of the associated sentences ;)
>>>>
>>>> 'grab' is also a very common english verb, so I think people would be
>>>> able to distinguish. It also sounds like 'crab' if you like :)
>>>>
>>>> M
>>>>
>>>> >
>>>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>>>> >> GRAB = Gnu RAdio Basic installer
>>>> >>
>>>> >> Then we can say things like "Go GRAB it" when referring to a needed
>>>> module
>>>> >>
>>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <
>>>> martin.br...@ettus.com>
>>>> >> wrote:
>>>> >>
>>>> >>> There's been some demand to rename PyBOMBS, and now that we're
>>>> >>> re-releasing it, this is a good time to think about it. Complaints
>>>> about
>>>> >>> the name include:
>>>> >>>
>>>> >>> - It may or may not be true that people have been detained by TSA
>>>> for
>>>> >>> working on PyBOMBS at the airport[1]
>>>> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>>>> >>> rather than a GNU Radio-related tool
>>>> >>> - People can't agree on a capitalization
>>>> >>> - No one can remember what the acronym stands for
>>>> >>>
>>>> >>> Sure, this is not a critical thing, but now's a good chance to
>>>> bring it
>>>> >>> up and also, this is not a joke :)
>>>> >>>
>>>> >>> Here's how we're going to do this:
>>>> >>>
>>>> >>> - Please suggest new names in this thread.
>>>> >>> - I will choose from those names based on 'can I live with this
>>>> name',
>>>> >>> 100% subjectively.
>>>> >>> - New names will be put up for a vote. This will include an option
>>>> to
>>>> >>> keep the old name.
>>>> >>> - Finally, the result of the vote will be used as a strong
>>>> 

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim O'Shea]

IMO it is generally nice to have a unique googleable name for an
application which doesn't result in five trillion unrelated Google
results.  While short acronyms will have false positives, names like "grab"
or any standard English words are generally bad choices from this point of
view
Grpm and the like seem fairly unique - pybombs was a win by this measure

On Wed, Dec 23, 2015, 1:02 PM Martin Braun  wrote:

> On 23.12.2015 09:28, Stefan Wunsch wrote:
> > I don't want to destroy your idea, but GRAB sounds like CRAP as well and
> > you can think of the associated sentences ;)
>
> 'grab' is also a very common english verb, so I think people would be
> able to distinguish. It also sounds like 'crab' if you like :)
>
> M
>
> >
> > On 12/22/2015 09:31 PM, Richard Bell wrote:
> >> GRAB = Gnu RAdio Basic installer
> >>
> >> Then we can say things like "Go GRAB it" when referring to a needed
> module
> >>
> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun 
> >> wrote:
> >>
> >>> There's been some demand to rename PyBOMBS, and now that we're
> >>> re-releasing it, this is a good time to think about it. Complaints
> about
> >>> the name include:
> >>>
> >>> - It may or may not be true that people have been detained by TSA for
> >>> working on PyBOMBS at the airport[1]
> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
> >>> rather than a GNU Radio-related tool
> >>> - People can't agree on a capitalization
> >>> - No one can remember what the acronym stands for
> >>>
> >>> Sure, this is not a critical thing, but now's a good chance to bring it
> >>> up and also, this is not a joke :)
> >>>
> >>> Here's how we're going to do this:
> >>>
> >>> - Please suggest new names in this thread.
> >>> - I will choose from those names based on 'can I live with this name',
> >>> 100% subjectively.
> >>> - New names will be put up for a vote. This will include an option to
> >>> keep the old name.
> >>> - Finally, the result of the vote will be used as a strong suggestion
> on
> >>> what the new name will be.
> >>>
> >>> There already have been some suggestions:
> >>>
> >>> - gromit -- the GNU Radio out-of-tree module installation tool
> >>> - the groot
> >>> - grpm -- the GNU Radio package manager
> >>>
> >>>
> >>> OK guys, bring up the ideas!
> >>>
> >>> Cheers,
> >>> Martin
> >>>
> >>> [1] It's not.
> >>>
> >>> ___
> >>> 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] Renaming PyBOMBS

[Tim Newman]

I agree with Tim, the tool is not gnuradio specific, and I personally dont
think it needs to be locked to gnuradio and have a "gr" in the name
anywhere and uniquely searchable is a must.  I'm a big fan of the original
name. Otherwise:

PySIS - Pybombs Software Installer System.

On Wed, Dec 23, 2015 at 1:43 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> Yeah I should have clarified that. I tried the full package manager route
> of install about 2 years ago for gnuradio and uhd. It didn't work. I
> installed uhd through apt-get and gnuradio through apt-get with no success.
>
> I'm just bringing that up so we don't assume that is an easy possibility
> for someone to do. As far as I know from my stab at it two years ago, it's
> not viable. Someone should try that route now to see if it is before we
> assume anything.
>
> On Wed, Dec 23, 2015 at 10:38 AM, Tim O'Shea <tim.oshea...@gmail.com>
> wrote:
>
>> Ubuntu packages uhd
>> Assuming other oses do too
>> I'm sure there are up to date ppas somewhere too
>>
>>
>> On Wed, Dec 23, 2015, 1:34 PM Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> Is there a way for a new user to get uhd installed from the package
>>> manager though? A lot of people want to dive right into gnu radio with
>>> hardware, doing simple things like spectrum analysis. I'm not aware of a
>>> way of getting the uhd + gnuradio setup running that's easier then pybombs.
>>> I very well could be wrong here.
>>>
>>> On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com>
>>> wrote:
>>>
>>>> Most new users should be installing gnu radio binaries via their os
>>>> package manager repos or ppa.   Pybombs should be used for 1. Helping get
>>>> up to date oot modules set up and deployed ( like pip ) and 2. Helping
>>>> developers set up their development environment.
>>>> So I'm not sure installer is the right idea to impart on new users at
>>>> all
>>>>
>>>>
>>>> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'd like to throw in another point from an entry level perspective.
>>>>> Those people who might need pybombs most, are those who need names that
>>>>> tell them what it's for the most. Even if it is incorrect to call pybombs
>>>>> an installer, it would really help the entry level folks (which I would
>>>>> claim without support is the largest population of the community at any
>>>>> given time) understand what it's for and how they should use it. I think 
>>>>> we
>>>>> all have the experience of learning new tools and running into tool names,
>>>>> which even though the description is spot on for what its for, at the time
>>>>> carried zero value for the new guy using it (thinking mostly about Xilinx
>>>>> tool names here).
>>>>>
>>>>> With that said, I think it would be good for the community to use the
>>>>> word installer in the tool that makes gnuradio and uhd really easy to
>>>>> install, and is what the vast majority of people I'm guessing would use it
>>>>> for.
>>>>>
>>>>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com
>>>>> > wrote:
>>>>>
>>>>>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>>>>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as
>>>>>> well and
>>>>>> > you can think of the associated sentences ;)
>>>>>>
>>>>>> 'grab' is also a very common english verb, so I think people would be
>>>>>> able to distinguish. It also sounds like 'crab' if you like :)
>>>>>>
>>>>>> M
>>>>>>
>>>>>> >
>>>>>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>>>>>> >> GRAB = Gnu RAdio Basic installer
>>>>>> >>
>>>>>> >> Then we can say things like "Go GRAB it" when referring to a
>>>>>> needed module
>>>>>> >>
>>>>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <
>>>>>> martin.br...@ettus.com>
>>>>>> >> wrote:
>>>>>> >>
>>>>>> >>> There's been some demand to rename PyBOMBS, and now t

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim]

Martin,
Excited to see pybombs2 emerging as stable !
A few thoughts on the naming below --
-Tim

On 12/22/2015 03:10 PM, Martin Braun wrote:
> There's been some demand to rename PyBOMBS, and now that we're
> re-releasing it, this is a good time to think about it. Complaints about
> the name include:
>
> - It may or may not be true that people have been detained by TSA for
> working on PyBOMBS at the airport[1]
> - The name suggests a Python-related packages (like Pylint, PyPI...)
> rather than a GNU Radio-related tool
it doesn’t really need to be gnu radio specific --
it was written to work with any such light weight recipes that follow
standard git/cmake or other common or custom format

> - People can't agree on a capitalization
> - No one can remember what the acronym stands for
>
> Sure, this is not a critical thing, but now's a good chance to bring it
> up and also, this is not a joke :)
>
> Here's how we're going to do this:
>
> - Please suggest new names in this thread.
> - I will choose from those names based on 'can I live with this name',
> 100% subjectively.
> - New names will be put up for a vote. This will include an option to
> keep the old name.
> - Finally, the result of the vote will be used as a strong suggestion on
> what the new name will be.
>
> There already have been some suggestions:
>
> - gromit -- the GNU Radio out-of-tree module installation tool
this name makes me cringe horribly
"installation tool" isn't really a fair characterization since it is
setting up a development environment
apt-get or standard binary installs are more "installation tool"

> - the groot
also - horrible cringe factor,

> - grpm -- the GNU Radio package manager
I like grpm --
other similar possibilities:

rmm - radio module manager
grmm - gnu radio module manager
gmm - gnuradio module manager
spm - SDR Packager Manager
spm - spm package manager

personally in favour of something short and functional vs cutesy and
contrived (we already have one of those names)
three letter package managers seem to be relatively common practice in FOSS

examples:apt, rpm, pip, gpm, npm, ...

>
>
> OK guys, bring up the ideas!
>
> Cheers,
> Martin
>
> [1] It's not.
>
> ___
> 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] Renaming PyBOMBS

[Tim O'Shea]

Python build overlay managed bundle system


On Tue, Dec 22, 2015, 4:47 PM Donald Pupecki  wrote:

> I like GRPM - GnuRadio Package Manager.
>
> Can never remember what pybombs stands for anyway.
> On Dec 22, 2015 3:10 PM, "Martin Braun"  wrote:
>
>> There's been some demand to rename PyBOMBS, and now that we're
>> re-releasing it, this is a good time to think about it. Complaints about
>> the name include:
>>
>> - It may or may not be true that people have been detained by TSA for
>> working on PyBOMBS at the airport[1]
>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>> rather than a GNU Radio-related tool
>> - People can't agree on a capitalization
>> - No one can remember what the acronym stands for
>>
>> Sure, this is not a critical thing, but now's a good chance to bring it
>> up and also, this is not a joke :)
>>
>> Here's how we're going to do this:
>>
>> - Please suggest new names in this thread.
>> - I will choose from those names based on 'can I live with this name',
>> 100% subjectively.
>> - New names will be put up for a vote. This will include an option to
>> keep the old name.
>> - Finally, the result of the vote will be used as a strong suggestion on
>> what the new name will be.
>>
>> There already have been some suggestions:
>>
>> - gromit -- the GNU Radio out-of-tree module installation tool
>> - the groot
>> - grpm -- the GNU Radio package manager
>>
>>
>> OK guys, bring up the ideas!
>>
>> Cheers,
>> Martin
>>
>> [1] It's not.
>>
>> ___
>> 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] Renaming PyBOMBS

[Tim O'Shea]

Cutesy acronym grumblings aside on this one, If all you wanted to do was
install gnu radio, apt, rpm, our emerge would do.   IMO pybombs seems more
about indexing, installing, setting up development environments, and
updating out of tree modules - "grin" implied scope is a small subset
thereof

On Tue, Dec 22, 2015, 10:02 PM Neel Pandeya <neel.pand...@ettus.com> wrote:

> Also perhaps:
>
> GRIN = Gnu Radio INstaller
>
>
>
> On 22 December 2015 at 15:37, Martin Braun <martin.br...@ettus.com> wrote:
>
>> Another suggestion from #gnuradio was 'grapple'.
>>
>> M
>> On 22 Dec 2015 15:12, "Neel Pandeya" <neel.pand...@ettus.com> wrote:
>>
>>> My vote would be for one of these:
>>>
>>> GRPM = GnuRadio Package Manager
>>>
>>> GRAB = Gnu RAdio Basic installer
>>>
>>> GRBI =
>>> ​​
>>> Gnu Radio Basic Installer
>>>
>>> I agree with Tim O'Shea, the name should be something short and
>>> functional, and give an idea of what it does, instead of being cutesy and
>>> contrived.
>>>
>>> --Neel
>>>
>>>
>>>
>>>
>>> On 22 December 2015 at 12:10, Martin Braun <martin.br...@ettus.com>
>>> wrote:
>>>
>>>> There's been some demand to rename PyBOMBS, and now that we're
>>>> re-releasing it, this is a good time to think about it. Complaints about
>>>> the name include:
>>>>
>>>> - It may or may not be true that people have been detained by TSA for
>>>> working on PyBOMBS at the airport[1]
>>>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>>>> rather than a GNU Radio-related tool
>>>> - People can't agree on a capitalization
>>>> - No one can remember what the acronym stands for
>>>>
>>>> Sure, this is not a critical thing, but now's a good chance to bring it
>>>> up and also, this is not a joke :)
>>>>
>>>> Here's how we're going to do this:
>>>>
>>>> - Please suggest new names in this thread.
>>>> - I will choose from those names based on 'can I live with this name',
>>>> 100% subjectively.
>>>> - New names will be put up for a vote. This will include an option to
>>>> keep the old name.
>>>> - Finally, the result of the vote will be used as a strong suggestion on
>>>> what the new name will be.
>>>>
>>>> There already have been some suggestions:
>>>>
>>>> - gromit -- the GNU Radio out-of-tree module installation tool
>>>> - the groot
>>>> - grpm -- the GNU Radio package manager
>>>>
>>>>
>>>> OK guys, bring up the ideas!
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> [1] It's not.
>>>>
>>>> ___
>>>> 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] SSB/CW/FM tranceiver

[Tim Rand]

Hi folks,

I've just spent a couple days reading a lot in here. Finding this thread, a
recent one, talking ham radio gives me an excellent opportunity to join in -
my first post here.

I'm in the process of putting together receive & transmit capability based
on gnuradio. Not a transceiver exactly, but a full station from soup to
nuts. Currently I'm receive-only using a Ham-It-Up converter, an rtlsdr
dongle, Gqrx and a newly constructed mag loop antenna. My plans include
generating SSB via gnuradio and bringing the I & Q signals out to homebrew
balanced modulators, a DDS and a QRP linear.

I was a ham back in 1955-60, let my license lapse & was inactive for several
decades, then just last summer went & got my General. Returning to the hobby
now I find radio just as magical & exciting as when I was a kid. Since I
prefer homebrewing & gadgeteering more than operating on air, I'm building
stuff on the cheap like I did back then but now it's $20 rtl dongles instead
of WWII surplus ARC-5 command sets. Still chewing gum & rubber bands tho.

Actually I may get involved with grc/gnuradio before I tackle making a
transmitter. What brought me to this list was pursuing articles on folks
using two or more rtlsdr dongles for phasing applications. My interests
aren't so much in passive radar or beamforming. I'm sticking with HF bands
for now (mainly 40 meters). I've been researching two-antenna phase
cancellation techniques for RFI noise reduction. Hams have been doing this
with antenna-level RF signals for years. A currently available product is
the MFJ-1026. But I got to thinking about doing the nulling at the IQ signal
level via twin receivers, i.e. dual dongles. Coherent clocking. Much
discussion I've read involves precision measurements but my use case is, I
believe, much more modest. All I'm looking for is letting a 2nd noise
antenna reduce the receive noise floor on an HF ham band. Anyway, I'm
interested in giving this a try.

One more thing: I'm already helping to spread the word about gnuradio. The
graphic art at the top of my YouTube channel has a grc flowgraph along with
other radio items both old & new. I'm working on telling my story about
building up my station via YouTube videos (only a couple up there right
now). If the "diversity" noise cancellation scheme works out that'll be
another video.

Tim  KK6VQQ
YouTube channel:  www.youtube.com/channel/UCCRh9a5sQKd5h8VAfZ_OtWA




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/SSB-CW-FM-tranceiver-tp56800p57121.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Frequency discriminator using a frequency to voltage converter

[Tim K]

Per chance, are you looking for the quadrature demodulator?

- Tim

On Wed, Nov 4, 2015 at 7:15 AM, larry ho <larryhorui...@hotmail.com> wrote:

> Hi
>
>
> I am new to linux and GNU Radio, I am trying to create a frequency to
> voltage converter, I tried looking into the source code of QT GUI Frequency
> Sink to get an idea how it detects frequency. However, it seems a little
> complicated, is there any particular function i should look out for in the
> coding? Or are there any alternative in creating a frequency to voltage
> converter. Greatly appreciative if any advise can be provided. Thank you.
>
>
> Regards
>
>
> Larry
>
> ___
> 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] MMCR Filters

[Tim K]

Hey all,

Just threw this together and thought you'd be interested. It's a comparison
of filters for the MMCR block on (raw data + noise).

http://pastebin.com/nbq4HwQ1

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

Re: [Discuss-gnuradio] bidirectional with Socket PDU

[Tim]

You should be fine connecting both input and output ports at the same
time for exactly this purpose!
-Tim

On 08/13/2015 03:29 PM, Jason Matusiak wrote:
 This will probably show my networking ignorance, but is there a way to
 use the socket PDU for bi-directional purposes?  I see that it has a PDU
 in and out, but I cant' seem to get it to work.

 What I am doing is connection netcat to it with the PDU in UDP Server
 mode with nc -u localhost 52001 and I can transmit to it.  But I know
 that I cannot open a listening port with nc -ul localhost 52001 since
 the port is bound.

 Is there a way to write and listen on the same port, or am I totally
 screwing how networking works (the only reason I would think there might
 be a way is because the GRC script allows me to connect the PDU in and
 out at the same time without throwing an error)?

 ___
 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] Processing expectations

[Tim O'Shea]

You may also want to have a look at
http://stats.gnuradio.org/
To get a feel for how fast different sdr kernels run on different
processing platforms

Tim

On Fri, Aug 7, 2015, 11:47 AM Tom Cook tom.k.c...@gmail.com wrote:

 I'm brand new to SDR and I'm just trying to calibrate my expectations of
 what will be possible in real time.  I'm hoping someone here can give me a
 pointer or two.

 I'm running GNU Radio 3.7.2 on Ubuntu 14.04, having installed from the
 Ubuntu repositories.  The machine I'm using has an Intel Core i5-2520M
 running at 2500MHz.

 I'm constructing flowgraphs in GRC and using an RTL-2832U-based USB dongle
 as a receiver.

 I've built a fairly simple broadcast FM stereo receiver as an example.  It
 has the following components:
 * RTL-SDR source (768k sample rate).
 * Low pass filter (768k sample rate, 96k cutoff, 4k transition)
 * Rational resampler (4x decimation)
 * WBFM receiver (quadrature rate 192k)
 * Low pass filter (1x decimation, 192k sample rate, 15k cutoff, 2k
 transition)
 * 2x Band pass filter (1x decimation, 192k sample rate, differing cutoff
 and transition)
 * Multiply
 * Low pass filter (192k sample rate, 15k cutoff, 2k transition)
 * Add, subtract
 * 2 x rational resampler (4x decimation)
 * Audio sink (sample rate 48k)

 My system is not able to run this in realtime, producing regular underruns
 (about two per second).  Decreasing the receiver sample rate to 384k and
 decreasing the decimation factor in the first resampler to 2 allows it to
 run in without underruns, from which I deduce that the CPU is right on the
 edge of being able to process the flowchart in realtime.

 Are my expectations of what I'll be able to do in realtime unreasonably
 high?  Is there something I'm missing, that I can do to make this run much
 faster?

 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] isolate channels from wideband

[Tim K]

Just as a heads up, someone mailed this into the mailing list the other
day. I think it accomplishes exactly what you all want -- although it
doesn't use PFBs as I recall.

https://github.com/madengr/ham2mon

- Tim

On Sun, Aug 2, 2015 at 2:18 PM, John Ackermann N8UR j...@febo.com wrote:

 Hi Chris --

 Using the variables, I now have the program working in general.

 The channel mapping gave me some nightmares, though.  I finally decided
 that you need two maps -- one for the channelizer block, where you do the
 4,5,6,7,0,1,2,3 translation, and another for the GUI that is a simple 0..7.

 With that, it seems to be working well although my WBX front end seems to
 have been fried as it is more deaf than it used to be.  Time to switch to
 hardware troubleshooting mode...

 Thanks, again!

 John
 


 On 08/02/2015 12:10 AM, Chris Kuethe wrote:

 Thanks for pointing out the paste-o. I'll fix that.

 I'm using gnuradio 3.7.8rc1, which has helper blocks for computing
 filter taps. You can replace them with variables:

 pfb_taps = firdes.low_pass(2.0, oversampled_width, noaa_fm_dev * 2,
 2500, firdes.WIN_HAMMING, 6.76)
 lpf_taps = firdes.low_pass(1.0, hardware_rate, noaa_band_width / 2,
 noaa_chan_width, firdes.WIN_HAMMING, 6.76)

 On Sat, Aug 1, 2015 at 5:00 PM, John Ackermann   N8UR j...@febo.com
 wrote:

 Thanks much for this, Chris!  I look forward to playing with it, but...

 When I load the flowgraph on my GRC 3.7.6.1 system, I get a Missing
 Block
 error for each of lpf_taps and pbf_taps, triggering errors in the xfft
 and
 channelizer blocks.

 I also had an error in the Multiply Const block coming out of channel
 7.
 but that was caused by a missing space before else in the evaluation.

 Help?

 But thanks so much for taking this on.  It's the perfect starting point
 for
 some projects I've been wanting to work on!

 John
 

 On 08/01/2015 03:26 PM, Chris Kuethe wrote:


 OK, Here it is... at least, a beta version.  I have yet to come up with
 a concise explanation of the channel map and why you'd want to
 oversample, but it is functional.

 This flowgraph would work equally well by directly connecting all the
 ports together, but I'm a big fan of using virtual sources and sinks to
 make the design somewhat self-documenting..



 On Sat, Aug 1, 2015 at 4:55 AM, Markus Heller hel...@relix.de
 mailto:hel...@relix.de wrote:

  Great! Thanks! I'm very curious!

  br/vy73
  markus
  dl8rds

  Am Freitag, den 31.07.2015, 14:34 -0700 schrieb Chris Kuethe:
OK, I have a mostly working flowgraph and am now adding comment
  to all
the blocks explaining why I'm doing this or that. Will publish
  tonight
or tomorrow.
   
On Tue, Jul 21, 2015 at 11:56 AM, Chris Kuethe
  chris.kue...@gmail.com mailto:chris.kue...@gmail.com wrote:
 Maybe I'll do up an illustrated example on this using NOAA
 weather
 radio, or the pager band

 On Tue, Jul 21, 2015 at 11:42 AM,  mle...@ripnet.com
  mailto:mle...@ripnet.com wrote:
 I just use the built-in firdes stuff, rather than using an
  external
 designer.







 On 2015-07-21 14:38, Marcus Müller wrote:

 Hi Rich, hello Markus,

 On 21.07.2015 19 tel:21.07.2015%2019:51, Richard Bell
 wrote:

 GNU Radio has channelizers built-in, but I've not used them
  yet, so I don't
 know how far they take you into this kind of task.

 the Polyphase channelizer is actually an implementation
  derived from that
 school of thought, and it works amazingly well.
 In fact, in preparation of a presentation at a certain ham
  conference, I
 tried using it to get 20 PMR/LPD channels out of a 1MS/s
  signal in real
 time, and then just shuffle them around, before feeding them
  back into the
 inverse synthesizer PFB.

 It's pretty easy:
 Design a single low pass filter, as if you just wanted to
  filter out the
 channel which is centered exactly at your RF center
 frequency,
  i.e. 0Hz,
 with the full sampling rate [2], using the gr_filter_design
  tool. Play
 around with the different window types[1], and bear in mind
  that the
 suppression outside your desired passband needs to be high
  enough so that
 the sum of the energy in all other channels don't hurt your
  channel too
 much, but don't overdo it (60dB suppression should be
 enough).
 Now you get a long filter. Copy and paste the filter
  coefficients from
 gr_filter_design to your PFB filter taps property.
 Set your channelizers number of channels according to your
  plans -- 40, if
 you want to get all the 40 25kHz channels in 2MHz. You get a
  block with 40
 outputs

Re: [Discuss-gnuradio] ham2mon GR based scanner

[Tim K]

Nicely done!

On Wed, Jul 22, 2015 at 9:11 PM, madengr rfeng...@me.com wrote:

 Throught I'd share my GR based scanner with curses GUI.  Locks on and
 demodulates N number of NBFM channels and logs audio to disk.  Uses
 gr-osmosdr source so should work with a variety of devices.

 https://github.com/madengr/ham2mon

 https://www.youtube.com/watch?v=BXptQFSV8E4







 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/ham2mon-GR-based-scanner-tp54975.html
 Sent from the GnuRadio mailing list archive at Nabble.com.

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

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

Re: [Discuss-gnuradio] Is there a project which implements half-duplex communications?

[Tim]

Jeon,
Also check out
http://wp.me/p55sJw-2v
software based half duplex burst PSK modem which can operate using a
single USRP, file loopback, or other SDR
-Tim

On 06/30/2015 09:30 AM, Jeon wrote:
 Hello, GNU Radio users,

 Very long time ago, USRP 1 was not suitable for half-duplex
 communications because USB 2.0 interface is too slow to achieve it.
 But now, there are USRP embedded and gigabit ethernet supporting USRP
 series.
 In my opinion, thus, half-duplex communications might be achievable
 nowadays.

 I am curious that there is a project which implements half-duplex
 communications.
 If there is, how many USRPs, daughterboards and antennas are used for
 each node?
 Can I find such a project in pybombs?

 In my guess, a half-duplex communication application can be built from
 both USRP sink and source being placed in one flow graph.
 But I have no idea of the rest of the flow graph. Should the flow
 graph open loop or closed loop?
 Is there a special configuration or tweak on USRP or GNU Radio
 required to achieve half-duplex communications?

 I apologize if my question sounds quite vague.

 Regards,
 Jeon.


 ___
 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] Adding OOT Modules from Github

[Tim K]

How did you go about installing GNU Radio, and what version are you using?
(Check gnuradio-companion's version).

On Tue, Jun 23, 2015 at 4:21 PM, Washbourne, Logan 
lwas...@ostatemail.okstate.edu wrote:

 Hello,

 I am trying to use the Burst PSK project that Tim O'Shea and Kiran Karra
 developed and I am having trouble figuring out how to add the projects'
 blocks into my version of Gnuradaio. Is there an easy way to add multiple
 blocks at a time or is it necessary to add them one at a time (using the
 method described in the OOT tutorial)?

 I haven't tried much in the way of solving this problem because I would
 consider myself a novice when it comes to Linux but a hint in the right
 direction would definitely be welcomed.

 I appreciate your time,

 Logan Washbourne
 Electrical Engineering Graduate Student
 (Electromagnetics)


 ___
 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] HermesNB with Pybombs

[Tim]

Check again, recipe added
./pybombs sync should update recipes to the latest for you

On 05/04/2015 11:53 PM, Tom McDermott wrote:
 Hi Greg - there is no Pybombs recipe for gr-hpsdr. I do not have
 Pybombs installed, so can't test a recipe.

 My development system pushes to github, so it's always up to date and
 the most accurate mirror. I endeavor to keep
 TAPR SVN accurate, but it is manually copied from github...

 I recommend getting gr-hpsdr from github which has the latest, and
 doing the source build.

 https://github.com/Tom-McDermott/gr-hpsdr

 -- Tom, N5EG


 On Mon, May 4, 2015 at 6:58 PM, Gregory W. Ratcliff n...@att.net
 mailto:n...@att.net wrote:

 Tom,

 Heard your talk on this work.   Went digging around  in the new
 Pybombs list but didn't notice anything that looked HPSDR-like.

 Before I go to TAPR subversion could you give us a pointer to the
 latest version for the
 Everyone wants to brag about their progress before Dayton weekend.


 Greg
 nz8r






 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto: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] Release Announcement: GNU Radio 4.1

[Monahan-Mitchell, Tim]

In the interest of saving the GR support team costly web hosting fees, may I 
send a self-addressed package with my blank 3.5 floppies to get the release?
How many blank floppies should I send? I think I can get them in bulk on eBay.
I'm in no hurry, so return  by pre-paid surface mail is fine for me (it will 
take me time to convert my C++ GR blocks to C#).

- Tim

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

Re: [Discuss-gnuradio] pybombs

[Tim]

This issue should now be fixed in the latest version
-Tim

On 02/20/2015 06:33 AM, Marcus Müller wrote:
 Hi,

 you seem to be running pybombs and/or the app_store.py as root,
 although the prefix they use seems to be your home directory, making
 root privileges unnecessary.
 Using sudo therefore most likely messes up your paths, and thus things
 go wrong.
 Don't use sudo when you're using a home-directory prefix.

 Greetings,
 Marcus


 On 02/20/2015 11:32 AM, FredomFighter099 . wrote:

 Hello list

  Has anyone else has experienced any problems with pybombs: failing
 to load recipes


 This is happening when I try to install through ./app_store.py


 I am getting this output


 I have tried several prefixes all with the same result.

 test@test-virtual-machine:~$ cd pybombs

 test@test-virtual-machine:~/pybombs$ sudo ./app_store.py

 [sudo] password for test:

 Settled on prefix: /home/test

 Initializing environmental variables...

 no existing inventory found, creating an empty one...

 Loading recipes ...

 Failed to load recipe gr-zmqblocks

 Failed to load recipe numpy

 Failed to load recipe gflags

 Failed to load recipe gr-osmosdr

 Failed to load recipe pyqt4-dev-tools

 Failed to load recipe glib

 Failed to load recipe gr-baz

 Failed to load recipe pocsag-mrt

 Failed to load recipe gr-gsm

 Failed to load recipe gr-tagutils

 Failed to load recipe gr-compat

 Failed to load recipe libbzip

 Failed to load recipe fftw

 Failed to load recipe pango

 Failed to load recipe wireshark

 Failed to load recipe gr-smithchart

 Failed to load recipe gr-dvbs2

 Failed to load recipe libpng

 Failed to load recipe gr-ettus

 Failed to load recipe gr-packetradio

 Failed to load recipe git

 Failed to load recipe gnuradio

 Failed to load recipe uhd

 Failed to load recipe gr-multimon

 Failed to load recipe freetype

 Failed to load recipe cairo

 Failed to load recipe libbtbb

 Failed to load recipe libpcap

 Failed to load recipe gr-mediatools

 Failed to load recipe boost

 Failed to load recipe libsndfile

 Failed to load recipe gr-mtb

 Failed to load recipe wxpython

 Failed to load recipe gr-iqbal

 Failed to load recipe gr-dvbt2

 Failed to load recipe libpolarssl

 Failed to load recipe expat

 Failed to load recipe pyqt4

 Failed to load recipe glog

 Failed to load recipe pycairo

  

 Thanks in advanced



 ___
 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] Updating GNU Radio, UHD or PyBOMBS

[Tim O'Shea]

Try running
Pybombs clean gnuradio
Pybombs clean uhd
And then installing

-Tim
On Oct 31, 2014 11:53 AM, Richard Bell richard.be...@gmail.com wrote:

 I'm still asking for help with this maintenance process. I tried the
 './pybombs remove' command to get rid of uhd and gnuradio as a test. I
 didn't get any error or warnings and it completed. When I looked in the
 pybombs/src folder, both gnuradio and uhd folders still existed there. I
 deleted them by hand. I then tried the './pybombs install uhd' command to
 reinstall uhd, but pybombs seems to think it's installed.

 I'm really at a loss as to how I'm supposed to do things here. I think in
 theory, pybombs would make all of this painless, but I've either done
 something terribly wrong and screwed pybombs up at this point, or it's not
 working as intended.

 What should I do at this point to fresh install with pybombs? I checked
 the packages I have installed on my ubuntu and I don't see gnuradio or uhd
 in the list, which is good. If I deleted the pybombs folder and start over
 from there, would you expect a clean installation at that point? Is that
 what Martin meant by Just reinstall it?

 Thanks,
 Rich

 On Wed, Oct 29, 2014 at 4:06 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Just reinstall it. No hassle :)

 M

 On 10/29/2014 11:07 PM, Richard Bell wrote:
  Well, I can tell you that I deleted the gnuradio build directory and
  then executed ./pybombs update to see if it would start the build
  process. It did not. As of now I'm not really sure what ./pybombs update
  does. The wiki leads me to believe it's supposed to do the pull and
  build process, link below to explanation of ./pybombs update.
 
  http://gnuradio.org/redmine/projects/pybombs/wiki/Using
 
  Unfortunately, the wiki also recommends that we don't update each recipe
  manually, because we could break a dependency. So at this point, I'm
  still not sure what I'm supposed to do to update my install when new
  versions of gnuradio or uhd come out. Can someone with experience in
  this flow chime in for me. Much appreciated.
 
  Rich
 
  On Wed, Oct 29, 2014 at 2:46 PM, Martin Braun martin.br...@ettus.com
  mailto:martin.br...@ettus.com wrote:
 
  On 10/29/2014 09:32 PM, Richard Bell wrote:
   Thanks Martin, but I'm still unsure of this process.
  
   1) I tried using ./pybombs update, but it doesn't look like it
 initiated
   a build process on anything. Did you mean to imply it would do
 that, or
   just the git pull process for gnuradio and uhd?
 
  Hm, I thought that's what it would do. Maybe it just git pulls.
 
   2) There is no build directory in uhd, like there was in
 gnuradio. From
   the pybombs/src/uhd directory where do I need to be to execute
 make and
   sudo make install?
 
  You sure? Maybe pybombs/src/uhd/host/build ?
 
   3) There is also no build directory in pybombs, where should I
 execute
   make and sudo make install?
 
  That you just git pull. It's pure Python, and doesn't get
 installed, so
  it just needs a build process.
 
  M
  
   Thanks,
   Rich
  
  
   On Wed, Oct 29, 2014 at 1:18 PM, Martin Braun 
 martin.br...@ettus.com mailto:martin.br...@ettus.com
   mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com
  wrote:
  
   Sometimes it's safer to clear the build dir, usually it's OK
  to leave
   in. If you have any cmake variables set, you'll need to reset
  them if
   you clear the dir.
  
   UHD is updated the same way. In all cases, it depends where
 you
   installed your stuff.
  
   pybombs can do all this for you, by the way: ./pybombs update
  
   ...although I don't think this will update pybombs itself.
  
   M
  
   On 10/29/2014 08:53 PM, Richard Bell wrote:
Hi all,
   
I am new to all of this, so I'm looking for some guidance. I
  recently
setup UHD and GNURadio using PyBOMBS on Ubuntu 14.04. I now
  want to do a
git pull and update my stuff. I'm not sure what commands to
  execute
after I do the git pull for each.
   
For example, I found two different recommendations for
  updating gnuradio
after a git pull
   
First way:
   
*git pull
*
*rm -Rf build
*
*mkdir build
*
*cd build
*
*cmake ../
*
*make
*
*sudo make install*
   
Second way:
   
*git pull
*
*cd build
*
*make
*
*sudo make install*
   
Is the removal of the existing build directory and cmake
  command necessary?
   
After

Re: [Discuss-gnuradio] PyBombs install maint branch from fresh

[Tim O'Shea]

Martin,
You are probably right we should track maint by default at this point.I
think it's worth adding a Pybombs environment question about which branch
to track during initial setup for those that prefer to track master
however.
Tim
 On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote:


 On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com
 wrote:

 On 07/23/2014 07:14 AM, Activecat wrote:
  Dear Sirs,
 
  I am performing fresh gnuradio installation using pybombs.
  Pybombs install master branch by default.
  How to make pybombs install 'maint' instead?
 
  Act@rsLAPTOP: ~/download/pybombs $ git checkout maint
  error: pathspec 'maint' did not match any file(s) known to git.

 This is not how you use git; you need to give it a remote branch to
 track first. Also, if you checked out 'maint' on pybombs, it wouldn't
 necessarily check out 'maint' on any SW package it's trying to install.

 I assume you're trying to install GNU Radio maint, right? I guess one
 way would be to modify the gnuradio.lwr recipe, change the default
 branch to maint.

 M



 Thanks.
 yes, I am trying to install GNU Radio maintenance branch.
 I will change the gitbranch of gnuradio.lwr recipe to 'maint'.
 Does this means the uhd.lwr also need to be 'maint', or can just be
 'master' as default?

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


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

Re: [Discuss-gnuradio] PyBombs install maint branch from fresh

[Tim]

One of the problems with allowing this kind of customization is that a 
single set of pybombs recipes is generally intended to represent a fixed 
set of versions / branches as far as configuration management.
Supporting additional branch combinations is kind of explosive in terms 
of new combinations of supported packages/versions.That said, master 
is kind of a moving target.   The hope was to have a set of recipes that 
tracks master everywhere for the most part (for developers that want 
this), and then have numbered known good sets of recipes that track for 
instance 3.7.3 or 3.7.4 with known good OOT modules at the time (for 
more stable OOT development or pure users).   However this is a lot of 
time/work to set up and constantly test / release so thus far we haven't 
really been doing that half - The versioned releases are to some extent 
already covered by binary packages -
That said, we can always throw this feature in with a *danger untested 
version combination* caveat ...


-Tim


On 07/23/2014 07:28 AM, Marcus Müller wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tim,

idea:
pybombs install package
gets the default branch as in the recipe,
pybombs install package%awesomefeatures
gets the awesomefeatures branch.

That would allow people to specify they want UHD maint, GNU Radio
v3.7.4, and gqrx master, if they really want to.

Greetings,
Marcus

On 23.07.2014 13:18, Tim O'Shea wrote:

Martin, You are probably right we should track maint by default at
this point.I think it's worth adding a Pybombs environment
question about which branch to track during initial setup for those
that prefer to track master however. Tim On Jul 23, 2014 7:10 AM,
Activecat active...@gmail.com wrote:


On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun
martin.br...@ettus.com wrote:


On 07/23/2014 07:14 AM, Activecat wrote:

Dear Sirs,

I am performing fresh gnuradio installation using pybombs.
Pybombs install master branch by default. How to make pybombs
install 'maint' instead?

Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error:
pathspec 'maint' did not match any file(s) known to git.

This is not how you use git; you need to give it a remote
branch to track first. Also, if you checked out 'maint' on
pybombs, it wouldn't necessarily check out 'maint' on any SW
package it's trying to install.

I assume you're trying to install GNU Radio maint, right? I
guess one way would be to modify the gnuradio.lwr recipe,
change the default branch to maint.

M



Thanks. yes, I am trying to install GNU Radio maintenance
branch. I will change the gitbranch of gnuradio.lwr recipe to
'maint'. Does this means the uhd.lwr also need to be 'maint', or
can just be 'master' as default?

___ 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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTz5xzAAoJEBQ6EdjyzlHt2oYIAJYYair2p3bJqiYwIMVhtX21
O5DUUVV06LQpEXUbxs99JBeGtA4KoY1KddVW2OPx26yUhP49xBAYO8dbNHth4ft8
PHNjS2vWroGK/8otLM8kkdzr+2+YmCw9zMKW/q/nl/afxsdUmu8N+gY9hZYsBkv8
jF8A4UPk7b8d4r79WxHmiiYHN6FLnW9glfGXDbigJMXyERzNaKJVPoy/o9Z7o5Q7
MLjsWBOkikn6mlNFjXD2VrHRBOJwQrp6gRLtirDhMqaeKepD1QBZddWYv5I5vYB0
5U/DFTN7j3Ar/BXWYiFIGFeUPqFunIw4YO6m/e9z4Le5VuJ0H36d3OptieuS/dE=
=twiT
-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

Re: [Discuss-gnuradio] How to start with stream tags

[Tim Newman]

Try:

http://gnuradio.org/doc/doxygen-3.7/page_stream_tags.html

or

http://gnuradio.org/redmine/attachments/download/252/06-rondeau-stream_tags.pdf

or even

http://bit.ly/1kWXdCl



On Tue, Apr 22, 2014 at 6:29 AM, Hoang Ngo Khac khachoang1...@gmail.comwrote:

 Dear List,

 I want to make time synchronization for implementation of two-way relaying
 network. Each node contain both RX chain and TX chain but they should not
 run simultaneously (half-duplex mode). Therefore, the TX chain is on when
 it is needed to transmit, and off when the transmission is over. I found
 that *stream tags* is the key solution to perform that.

 My question is, how should I start to learn about* stream tags*, where
 can I find tutorial of *stream tags*?

 Thank you so much.

 Best Regards,
 Hoang

 --
 Ngo Khac Hoang
 Faculty of Electronics and Telecommunications -
 University of Engineering and Technology (UET) - Vietnam National
 University, Hanoi (VNU)
 Vice-president of Student Association of UET
 Alternative email:  hoangnk...@vnu.edu.vn
 Mobilephone:  +84.163.682.7874

 ___
 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] Best way to output decoded data to user

[Tim]

check out gr-pyqt - this might be roughly what you are looking for
I've added some very simple python blocks which can send and receiver 
pdus with strings stored in pmt u8vectors and can be easily dropped into 
a Qt Gui for user interaction


https://github.com/osh/gr-pyqt/commit/7b12b79bc029d483ce71878960b24871ddbfd954

-Tim

On 04/15/2014 04:35 AM, Martin Braun wrote:

On 04/15/2014 06:14 AM, Francois Gervais wrote:

I'm trying to figure out the best way to print the decoded data
information of packets (received through gnuradio) to the user. File
outputs are not really user friendly so I'm thinking of using a message
queue out of my decoding block connected to the WX GUI Terminal Sink.

Generally: Don't use a message queue. Also, I recommend not adding any
WX widgets, unless you hate QT, because we're trying to move away from them.

The message passing interface might be a better choice, but the idea in
general is very good.


Is this a good approach? I'm thinking it might not since I can't find
any design using the terminal sink on the net.

If this is the right path could someone point me to an easy example of
using the message queue. I'd like to do a quick proof of concept and
output something like hello world on the terminal sink.

Have a look at the message_debug code. It does most of what you want,
but not in a widget, just on the console.

Martin

___
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] Solution for SegFault with Lock / Unlock in 3.7 C++

[Tim Newman]

What version of boost are you using?

Tim


On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote:

 I was wondering if there has been any progress or work arounds for Bug 598
 in 3.7?

 http://gnuradio.org/redmine/issues/598

 The issue is the GnuRadio will segfault if there are too many Lock /
 Unlocks.
 I am having it happen after 6 - 10 lock/unlocks.

 My program is a C++ program that records trunked radio calls and I need to
 be able to dynamically connect / disconnect recording flowgraphs as new
 calls are started. The program works fine under 3.6.

 I was wondering if there are any work arounds I should try. I have tried
 using tb-stop,  tb-wait, tb-start, but it still crashes. Is there some
 other way to dynmically connect  disconnect blocks that doesn't require
 lock / unlock?

 Is there an ETA when this would be fixed? Anything I can help on? I am
 going to have to go back to 3.6 if I can't figure out a solution.

 Thanks!

  - Luke




 ___
 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] Solution for SegFault with Lock / Unlock in 3.7 C++

[Tim Newman]

I was thinking the older version of boost had a bug in the boost thread
stuff that was causing this, but boost 1.53 should be fine.


On Fri, Mar 28, 2014 at 1:09 PM, Luke Berndt luk...@gmail.com wrote:

 I am using Boost 1.53, on Ubuntu 13.10 via apt-get. When I was running it
 under GnuRadio 3.6, I think I was running Boost 1.49, but it got upgrade
 because I think it is not compatible with GR 3.7?

 Would it be worth it to try build from source for Boost 1.48 or 1.55?


 On Fri, Mar 28, 2014 at 12:54 PM, Tim Newman tim.new...@gmail.com wrote:

 What version of boost are you using?

 Tim


 On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote:

 I was wondering if there has been any progress or work arounds for Bug
 598 in 3.7?

 http://gnuradio.org/redmine/issues/598

 The issue is the GnuRadio will segfault if there are too many Lock /
 Unlocks.
 I am having it happen after 6 - 10 lock/unlocks.

 My program is a C++ program that records trunked radio calls and I need
 to be able to dynamically connect / disconnect recording flowgraphs as new
 calls are started. The program works fine under 3.6.

 I was wondering if there are any work arounds I should try. I have tried
 using tb-stop,  tb-wait, tb-start, but it still crashes. Is there some
 other way to dynmically connect  disconnect blocks that doesn't require
 lock / unlock?

 Is there an ETA when this would be fixed? Anything I can help on? I am
 going to have to go back to 3.6 if I can't figure out a solution.

 Thanks!

  - Luke




 ___
 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] Controlport error in GRC

[Tim]

If you built GNU Radio under pybombs, you can also run
./pybombs rb gnuradio
this alias (rebuild) will blow away the build dir and re-run 
cmake/make/install for you with the proper environment set up
don't forget to rebuild everything that links against gnuradio 
afterwards (any OOT modules you may have)

-Tim

On 03/12/2014 09:05 AM, Tom Rondeau wrote:

On Wed, Mar 12, 2014 at 1:12 PM, sarankumar saran...@gmail.com wrote:

hi,
I removed version Ice3.5.1 and built Ice 3.5.0. But now GRC cannot detect
Ice:

from gnuradio.ctrlport.monitor import *
   File
/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/__init__.py, line
23, in module
 import Ice, IcePy
ImportError: No module named Ice

do I need to build PyBombs again for gnuradio to detect Ice?

regards,
Saran

Remove CMakeCache.txt from your build directory and rerun cmake with
the ICE_MANUAL_INSTALL_PATH set. Also make sure PYTHONPATH and
LD_LIBRARY_PATH are set properly to the location of the ICE 3.5.0
installation.

Tom







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

Re: [Discuss-gnuradio] Include guard bug

[Tim]

good find, this was probably my fault - sorry
We should consider changing headers to use #pragma once which is 
simpler and less error prone
do people still use gcc older than 3.4 ?  I think this is pretty widely 
supported now

not sure if that would cause swig issues as well -
-Tim

On 02/21/2014 10:51 AM, Marcus Müller wrote:

Ruecan:
I got carried away. This is indeed a bugfix for the header file not 
being processed in some cases, but since the error appeared although 
actually processing the fixed header file, I've run out of ideas, still.


On 02/21/2014 04:37 PM, Marcus Müller wrote:

Should be :)
Just as side info:
http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html

Sorry, totally running low on clues here...
This is twice as strange since boost::random is missing mt19937; if 
it was std:: I'd guess on a non-C++11 standard library, but like it is...
If cleaning and rebuilding doesn't help, make sure that 
libstdc++-devel is correctly installed


Basically, it should be right here:
http://www.boost.org/doc/libs/1_54_0/boost/random/mersenne_twister.hpp
and is included.


AAAND bam.
Found the bug. header include protection by #ifdef at the very 
beginning of the file.
you might pull my bugfix from 
https://github.com/marcusmueller/gnuradio.git;


git pull https://github.com/marcusmueller/gnuradio.git 
master_fix_message_strobe_random_ifndef


Greetings,
Marcus

On 02/21/2014 04:00 PM, Ruecan wrote:

Thanks Marcus,

Actually the boost version I have is 1.54.0.

Is this ok ?



--
View this message in 
context:http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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




___
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] Control Port, Perf Mon for GRC - errors

[Tim Newman]

Are you installing Ice after you build gnuradio?  If so, then gnuradio
won't enable the controlport modules during the gnuradio build because it
doesnt detect Ice.

Tim


On Fri, Feb 7, 2014 at 11:10 PM, Tom McDermott tom.mcdermo...@yahoo.comwrote:


 Having some issues with Control Port and Perf Mon in GRC.

 1. Built Latest Gnuradio 3.7.2 from git.
 enabled performance counters in the cmake command line
 cmake ../ -DENABLE_PERFORMANCE_COUNTERS=On
 then successful make, install, ldconfig, and gnuradio runs fine.

 2. Edited the  gnuradio-runtime-conf file to enable PerfCounters and
   ControlPort, Edges.

 3. Installed zeroc-ice (ver 3.4).

 If I add both a ControlPort Complex Probe and a CtrlPort Monitor, get the
 following error:

 Traceback (most recent call last):
   File home/tom//mod_phasing_test.py, line 17, in module
 from gnuradio.ctrlport.monitor import *
 ImportError: No module named ctrlport.monitor

 If I delete the CtrlPort Monitor, leaving only the probe, I get the
 following error:
 Traceback (most recent call last):
   File /home/tom/mod_phasing_test.py, line 231, in module
 tb = mod_phasing_test()
   File /home/tom/mod_phasing_test.py, line 144, in __init__
 self.blocks_ctrlport_probe_c_0 =
 blocks.ctrlport_probe_c(constellation, Constellation Points)
 AttributeError: 'module' object has no attribute 'ctrlport_probe_c'

 Are there other configuration steps needed? Does zeroc-ice need to be
 configured in some manner?

 -- Tom, N5EG



 ___
 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 stream tagging

[Tim]

You can also do precisely timed burst to stream conversion in 
pure-software which is a bit more portable
For one example of how to do this using gr-eventstream tools see the 
transmitter in

https://github.com/osh/gr-bitcoin
-Tim

On 02/08/2014 02:37 PM, Price, Nathan D. (ST-Student) wrote:

Hello,

I'm working on project in gnuradio, in which I'm trying to toggle on and off the transmission from the USRP.  After much 
research, I learned this was done by tagging the first sample of a transmission with tx_sob and the last 
sample with tx_eob (there was also a tx_time tag, but I found the former option more convenient). 
 I wrote a custom block that periodically tags segments out of continuous stream of data as a proof of concept; however, 
the transmission remains continuous as if there were no tag.  I've checked with the tag debugging block to ensure my 
block acutally generates tags. My flow graph is simply: file source(repeat)-custom tagging block-psk 
mod-multiply const-uhd sink.

Reading in the archive, I haven't found reference to success much success with 
the streaming API. I would love the community's input on this problem.

Thanks,
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] PyBOMBS issue using recipe with hierarchical git branch.

[Tim]

Andrew,

Try again with the latest version - this should be fixed now

-Tim

On 01/29/2014 12:21 PM, Andrew Back wrote:

Hello,

I tried adding a recipe to PyBOMBS for UHD-Fairwaves, setting
gitbranch to fairwaves/umtrx. However, when I run install,
fairwaves is stripped from the branch hierarchy and so it fails
since there is no branch called simply umtrx.

Guessing there may be a bug in the way in which PyBOMBS parses the
recipe gitbranch value?

Cheers,

Andrew

[1] https://github.com/fairwaves/UHD-Fairwaves




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

Re: [Discuss-gnuradio] more pybombs

[Tim]

Generally $gituser is not used for anything
you can if you want put a repository address like 
ssh://$gitu...@yourserver.com:gr-foo.git in a recipe

I guess it is just intended to provide a standard easy way of doing this -
we could probably remove it if it really upsets people, but it seems 
fairly harmless as is
our list of configuration variables is getting longer and longer, I'm 
not sure what the right balance is between prompting the user for all of 
them, and trying to hide ones that a user may not understand or care 
about -

perhaps simply a more verbose explanation of it would help

-Tim

On 01/22/2014 11:55 AM, ikjtel wrote:
We're starting to get a few more folks who have used pybombs 
(successfully) to install gnuradio and/or gr-op25.


Below is one comment - I have to admit, I had the same 
question/uncertainty myself, re: the gituser (Username for git 
access) prompt.  For me, concurrent make threads was obvious and 
the penalty for wrong answers was perfectly clear; whereas this is not 
at all the case for gituser.  In fact I seem to recall trying 
different answers for gituser without actually seeing that it had any 
effect [???]...


Best

Max
~~
[start paste, 1 minor edit]
I was pointed to the Ettus Research builds of GNURadio, which 
apparently they regularly update for Windows. It's something I may try 
at some point. I was going to start IT tonight until the other Scott 
(the one that has his  together far more than me for this project) 
dropped in with his info. I may still.


EDIT: Might be nice to include the link, eh? 
http://code.ettus.com/redmine/ettus/...URadio_Windows 
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows


Right now it's bombs awayor pybombs. The install is running 
merrily away...so far.


I would note that at the outset in the step after ./pybombs install 
gnuradio I was prompted for numerous options, with a default for 
each. Because I don't have any clue as to what the hell I'm doing, I 
chose the defaults. __

Scott - Scan New England Webmaster
http://www.scan-ne.net http://www.scannewengland.net/
Radio Reference MA, RI,  CT Database Admin


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


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

Re: [Discuss-gnuradio] Pybombs issue

[Tim]

It should now prompt for a value if makewidth is undefined w
an open -j argument was never the intended behavior - as it is not 
particularly safe


Also the boost recipe has been converted to do $makewidth wide builds 
with bjam now


-Tim


On 01/09/2014 11:26 AM, Tom Rondeau wrote:

On Thu, Jan 9, 2014 at 11:15 AM, Robert McGwier rwmcgw...@gmail.com wrote:

I did an update to pybombs two days ago, and immediately gnuradio got to
around 57% completion and just hung my Ubuntu 13.10 computer so hard, I
couldn't get it to respond to ctrl-alt-del for over half and hour.

I tried again after doing a force rebuild on gnuradio and it was worse.  I
long-hit the power button to do a reset.

I checked the pybombs defaults and it is makewidth = 4, but it certainly
acts like it is ignoring this and doing

make -j

.  Further symptoms include a nonstop, hard green LED on disk writes on a 8
GB system.  I have never seen it actually go to a major use of virtual
memory (if that is what is happening) until now.

I went into src/gnuradio/build and did a manual make -j4 and it worked
perfectly, thus my diagnosis.

Bob

Yep, making with an unnumerated -j is really dangerous, even on very
high-end systems.

There was another report about issues with makewidth, so that needs
looking into.

Tom



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

Re: [Discuss-gnuradio] GNURadio 3.7.2.1 Installation Problem

[Monahan-Mitchell, Tim]

Hi, Nathan,

 I think this is a known bug we're currently trying to squash 
 (http://gnuradio.org/redmine/issues/582).

 I think this is the first report of a problem on x86 hardware; if we can't 
 duplicate it on our machines would you mind if we bug you about testing out 
 code in the following couple of days?

FYI, I cited x86 in addition to ARM in my original report of #582.

For my x86, gnuradio-config-info -v reports 3.7.1 (The GR tree is on maint 
branch, at the 3.7.1 release commit).

My hardware is a 12.04 Ubuntu on top of VMWare:

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping: 7
microcode   : 0x25
cpu MHz : 3392.340
cache size  : 8192 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts mmx fxsr sse sse2 ss nx rdtscp lm constant_tsc up 
arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf pni 
pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor 
lahf_lm ida arat xsaveopt pln pts dtherm
bogomips: 6784.68
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Let me know if I can send anything else to characterize my x86 machine.

Regards,
Tim

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

Re: [Discuss-gnuradio] [VOLK] Summary of call

[Tim]

On 12/12/2013 04:01 PM, Douglas Geiger wrote:
 On Thu, Dec 12, 2013 at 3:11 PM, West, Nathan
 n...@ostatemail.okstate.edu mailto:n...@ostatemail.okstate.edu wrote:

 The VOLK working group had a call earlier today. Agenda and summary
 are here:
 http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131212

 We'll likely have our next call late January or February time-frame.

 There's a semi-open question about what kind of stats we should
 collect. Tim added support for taking CFLAGS at build time and
 /proc/version and /proc/cpuinfo at runtime. While we're at it are
 there any other machine features that would be useful to collect?


 Toolchain name/version info please!
 (http://gnuradio.org/redmine/issues/620)

 Unless, of course, Tim's support for CFLAGS already includes that info
 and/or patch...


Yep, already working on including compiler name / version as well

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7

[Monahan-Mitchell, Tim]

 I am wondering if the QA failure is relates, to the use of the hard float 
 ABI.
 For me, whenever I have tried to specify hard or soft float ABI, cmake 
 fails. If I don't specify it, it just works...

 I'm switching my OE builds to armthf now so I can compare my results with 
 Tom's.

 I'm working on a real fix for the qa code (not just symlinking until 
  it works) Hopefully, I can confirm hard float status tomorrow.

 Philip

Seems like Philip was able to replicate these VOLK bugs using the hard float 
build.
 I just tried it myself using his hard float OE, but I'm still getting 
 everything to pass ok on my system.
 Tom

OK, good to hear. Does that mean bugs 582 and 583 should be re-opened?

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7

[Monahan-Mitchell, Tim]

 The volk test is failing on my gnuradio build on a Beaglebone Black
 (armv7h) running Arch Linux Arm.

 # make test
 start   1: qa_volk_test_all
 *** 2 failures detected in test suite Master Test Suite1/177 Test   #1:
 qa_volk_test_all .***Failed9.88 sec

 Full output of ctest -V _R qa_volk_test_all is attatched.

 which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a 
 part of the 3.7.2.1 release.
 See bugs #582 and #583 on our Issues page.
 Tom

 After pulling the latest GR code (as of Dec 1) and doing a fresh build, my 
 ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached 
 in the first message of this thread. So there is something still going on 
 here. Is it possible some external component needs to be updated, that is 
 outside of what's in the GR git tree?

 The output I originally logged in Bug #583 differs from our latest results, 
 but the behavior is the same (in1/in2 values appear to match).
 The output I originally logged in Bug #582 (for ARM target) remains the 
 same (in1/in2 values differ by 1).
 I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
 from the latest git checkout (was testing Balister's new OE manifest
 and SDK) and everything is working great here.
 
 When you say you did a fresh build, what does that really mean? One
 of the quirks of volk is that cmake /has/ to be rerun when these kinds
 of changes are made. Best really to clean up everything to make sure
 you're doing everything from a clean checkout. git reset --hard; git
 pull origin master; git clean -dxf;. Then rerun cmake and make from a
 clean build directory.
 
 The above might be overkill, so if you want a quicker test, start with
 the clean git pull of the latest head and just make sure to rerun
 cmake and make, not necessarily from an empty directory.

Hi, Tom,
I tried these steps:
- Uninstalled gnuradio (make uninstall).
- apt-get update + apt-get upgrade for my ARM7 target (Ubuntu 13.04),
  which updated quite a bit of stuff.
- Deleted my gnuradio tree and re-cloned it.
- Checkout maint branch.
- Built as I have been doing.
- Same problem :(

Hi, Philip,
 Building gnuradio on an arm is silly :)
I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86 
prowess. :)

 I am wondering if the QA failure is relates, to the use of the hard float ABI.
For me, whenever I have tried to specify hard or soft float ABI, cmake fails. 
If I don't specify it, it just works...

 I'm switching my OE builds to armthf now so I can compare my results with 
 Tom's.
Thanks!

Tim 

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

Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7

[Monahan-Mitchell, Tim]

 The volk test is failing on my gnuradio build on a Beaglebone Black 
 (armv7h) running Arch Linux Arm.

 # make test
 start   1: qa_volk_test_all
 *** 2 failures detected in test suite Master Test Suite1/177 Test   #1:
 qa_volk_test_all .***Failed9.88 sec

 Full output of ctest -V _R qa_volk_test_all is attatched.

 which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a 
 part of the 3.7.2.1 release.
 See bugs #582 and #583 on our Issues page.
 Tom

After pulling the latest GR code (as of Dec 1) and doing a fresh build, my 
ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached in 
the first message of this thread. So there is something still going on here. Is 
it possible some external component needs to be updated, that is outside of 
what's in the GR git tree?

The output I originally logged in Bug #583 differs from our latest results, but 
the behavior is the same (in1/in2 values appear to match). 

The output I originally logged in Bug #582 (for ARM target) remains the same 
(in1/in2 values differ by 1).

Regards,
Tim

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

Re: [Discuss-gnuradio] Go-back is possible?

[Tim]

gzip - base64 encode the grc file into some comments in the python file
perhaps?
a smallish grc file appears to be on the order of 1000 chars with such
an encoding

On 12/02/2013 05:11 PM, Dan CaJacob wrote:
 I have an interesting (to me anyway) idea:

 What if we added a default option to the GRC-XML-to-python converter
 to add the contents of the original GRC file as a big, delineated
 comment blob.  Then, a simple tool could pull the GRC back out of the
 python file anytime and you could go back and forth.  An option when
 building would disable the verbose output for those publishing code or
 who just don't want the extra cruft.

 It's a little lame, but it solves the problem.  I know I've had to
 hand-craft many old GRCs from python files when the original GRC was
 lost or the originator was other than myself.  The problem has often
 crept up with GRCs not properly updated for new versions of code,
 where the blocks go missing in the GRC representation (I think there
 was talk of fixing this - graying them out or something).

 Very Respectfully,

 Dan CaJacob


 On Mon, Dec 2, 2013 at 4:48 PM, Marcus Leech mle...@ripnet.com
 mailto:mle...@ripnet.com wrote:

 Think of the Python that gets emitted by GRC as object code.  What
 you're asking is to convert said object code back into reasonable
 source code.

 Such things exist for *actual* machine object-code, but, they
 produce damned-ugly results.
  
 on Dec 02, 2013, *Raydel Abreu (CM2ESP)* cm2...@gmail.com
 mailto:cm2...@gmail.com wrote:

 Oh, that's bad, I guess I should use instead the old
 code-reading method

 Raydel


 2013/12/2 Marcus Leech mle...@ripnet.com
 mailto:mle...@ripnet.com

 There's no automatic mechanism for doing that.

  
 on Dec 02, 2013, *Raydel Abreu (CM2ESP)* cm2...@gmail.com
 mailto:cm2...@gmail.com wrote:

 Hello,

 Is it possible to go back and convert a Python GNU
 Radio code back into the GRC Flow Graph from which it
 was generated?

 Cheers,

 Raydel, CM2ESP

 
 

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

  

  

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto: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] trying to use gdb

[Tim]

you should be able to run 'gdb python --core=corefilename'
you may want to make sure you have compiled gnuradio with
-DCMAKE_BUILD_TYPE=RelWithDebInfo for useful symbol tables

On 11/26/2013 04:31 PM, Matt D wrote:
 Hi,
 I am using GRC3.6.3 and my program is dying with no verbose.  so now i
 have my core file in my home folder and i cant find the path to the
 executable.  Can someone please tell me the path?
 Thanks!



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

Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception

[Tim Newman]

I've seen ICE do this before, but usually its because my flowgraph dies,
via segfault or something.  When the flowgraph dies, the ice endpoints
aren't available anymore so the controlport monitor timesout when
attempting to query them.  Are you sure your flowgraph isn't crapping out
for some reason or another?

Tim


On Wed, Nov 13, 2013 at 11:10 AM, Nowlan, Sean
sean.now...@gtri.gatech.eduwrote:

  

 *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:* Monday, November 11, 2013 4:10 PM
 *To:* discuss-gnuradio@gnu.org
 *Subject:* [Discuss-gnuradio] gr-ctrlport-monitor timeout exception

 

 I’m using ControlPort to monitor transmissions through a USRP. I have a
 flowgraph responsible for generating burst traffic and streaming to a
 uhd_sink. Then I have a uhd_source tuned to the same frequency as the
 uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I
 have ControlPort support compiled-in and enabled from a config file. I’m
 able to connect to a remotely running flowgraph using gr-ctrlport-monitor
 and plot the PSD of the “samples” vector pulled from the probe2 block every
 100 milliseconds. The problem is that after (what seems to be) a
 nondeterministic time, the ICE port stops responding and
 gr-ctrlport-monitor reports an error:

 

 ctrlport-monitor: radio.get threw exception (exception
 ::Ice::ConnectTimeoutException

 {

 }).

 

 When I close and restart, gr-ctrlport-monitor times out and segfaults:

 

 2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error:
 Traceback (most recent call last):

   File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main

 status = self.doMain(args, initData)

   File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain

 return self.run(args)

   File
 /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
 line 97, in run

 radio = self.getRadio(host, port)

   File
 /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
 line 36, in getRadio

 radio = GNURadio.ControlPortPrx.checkedCast(base)

   File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line
 1257, in checkedCast

 return
 _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
 '::GNURadio::ControlPort', facetOrCtx, _ctx)

 ConnectTimeoutException: exception ::Ice::ConnectTimeoutException

 {

 }

 

 Segmentation fault (core dumped)

 

 So there are two issues to note here:

 -Something in the ICE instance is breaking on the GNU Radio
 flowgraph side. The port is still open; it just times out. Trying to
 instantiate gr-ctrlport-monitor to an incorrect port just says “connection
 refused,” as expected.

 -gr-ctrlport-monitor is not robust to connection-related errors
 like timeouts or refused connections.

 

 Is there any advice of what I can turn on or enable in GNU Radio or my
 flowgraph to debug the first problem? I can live with the second problem as
 long as I can make sure ICE doesn’t break on me.

 

 Thanks,

 Sean



 Sorry for getting antsy about this, but I’m really not sure how to go
 about debugging ICE server stuff. It seems like it’s buried pretty deeply
 in gnuradio-runtime. Where’s the best place to start looking to find out
 why the ICE server stops responding?



 Sean

 ___
 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] Sampling with multiple USRP N210s with one host computer

[Tim Newman]

There are lots of different ways.  One example would be to simply connect
them all to a switch, along with your host.  Assuming the aggregate
bandwidth doesn't exceed what the host's network card or switch can handle
you'll be fine.  You could also, as you mentioned, have a single host with
8 network interfaces, this is completely possible.

Tim



On Thu, Oct 31, 2013 at 4:54 PM, rmsrms1987 rmsrms1...@gmail.com wrote:

 Hi Everyone,

 I recently discovered that Ettus offer a way of synchronizing up the eight
 USRPs with the following clock distribution system:

 https://www.ettus.com/product/details/OctoClock-G
 https://www.ettus.com/product/details/OctoClock-G

 Out of curiosity, how would one be able to connect and sample with eight
 separate USRPs with one host computer.  Would you need eight separate
 ethernet ports?  That seems like more than what a typical motherboard would
 be able to handle.

 Or can the USRPs all be connected to a server, which can be individually
 accessed through the host computer?

 Understanding how to do this will be extremely beneficial in order to
 gather
 some ideas for a project.

 Thank you very much in advance,
 Rob



 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Sampling-with-multiple-USRP-N210s-with-one-host-computer-tp44502.html
 Sent from the GnuRadio mailing list archive at Nabble.com.

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

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

Re: [Discuss-gnuradio] What conditions will cause block destructor to be skipped?

[Monahan-Mitchell, Tim]

 you're entering a minefield there...

Thanks for helping me navigate :)

 First of all, destructors of python objects are called whenever the python 
 runtime feels like it - this often happens when you do something like 
 object_name = None but it doesn't necessarily has to happen right away.
 The Garbage Collector can choose when to do it, and sometimes, it decides not 
 to do it at all - if your program terminates first, this might be the case.
 Furthermore, if it decides that at the end of runtime, it should destruct its 
 output stream file handles before destructing your block, your printf output 
 might be lost.

So I know it isn't just dropping printf output, as other clean-up code does 
not execute.

 So these are the pitfalls I could think of. Maybe the situation is a lot 
 easier, though :) Post some code, maybe a github gist or a pastebin!

All excellent ideas, especially the GC that rightfully  turns up its nose at 
any destructor complaints.

So it is good to know that it is a bit out of my hands, but I can certainly 
move my clean-up code to the point where the work() method signals WORK_DONE. 
Sorry, I can't possibly air my dirty laundry on a pastebin :(.

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

[Discuss-gnuradio] What conditions will cause block destructor to be skipped?

[Monahan-Mitchell, Tim]

Rarely, I'm seeing evidence that my custom source block destructor is not being 
called.

My flowgraph was built with No GUI and Prompt for Exit options (GR 3.7.1+)

The condition is that my source block's work function has moved to a state 
returning WORK_DONE, and will stay in that state.

When I press Enter to end the flowgraph, I sometimes don't see the usual ending 
printf() outputs. Fortunately, it does not happen often.

This article cites such a case: 
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00055.html, but 
my flowgraph only has my custom source block and a File Sink block.

Regards,
Tim

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

Re: [Discuss-gnuradio] timestamp tags and set_min_output_buffer

[Tim]

On 10/09/2013 02:59 PM, Juha Vierinen wrote:
 Hi,

 I'm writing a block that always outputs the same number of items as it
 gets in. 

 The block is doing FFT on a fixed length vector, so I always need nfft
 samples in and nfft samples out. I've achieved this (I think) by
 using: set_min_noutput_items(nfft) and set_max_noutput_items(nfft).
 However, when I increase nfft to 8192, I get a message about not
 enough buffer space. I tested various things and ended up calling  
 set_min_output_buffer(2*nfft)  as just nfft wasn't enough. It all
 seems to work nicely, except that the rx_time tags are screwed up -- I
 get a nearly random offset in the beginning, even though there are no
 dropped packets on the USRP. 

 Is this a bug or a feature? What is the correct way to increase the
 value of noutput_items without breaking rx_time tags?

 juha


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

An easier way to achieve this is, is calling set_output_multiple(nfft)
in the block constructor - which assures noutput_items = n*nfft where n = 1
then if its a sync block without the relative rate or forecast being
change, it will also assume it also needs nfft items each work call
set_min_noutput_nitems and set_min_output_buffer are bigger hammers that
probably shouldn't be used in this case unless you have really big
vectors - I think by default there should be no problems with an output
multiple = 8k
are you consuming nfft each time in your current  block?  If it is
providing you nfft+extra samples each time through work you would get
strange offsets if you simply consumed noutput_items each time.

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

Re: [Discuss-gnuradio] Activating/Deactivating Blocks in real time

[Monahan-Mitchell, Tim]

Can you do this with a 2:1 mux block? Input 2 = constant 0, control input is 
s(t)?

From: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org 
[mailto:discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] On Behalf 
Of Achilleas Anastasopoulos
Sent: Wednesday, October 02, 2013 3:48 PM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Activating/Deactivating Blocks in real time

I have the following problem that I would like your opinion on how to solve 
elegantly:
I have a block A (say a standard sync block with some memory--eg an fir filter) 
which
has input x(t) and output y(t) and is pretty computationally intensive.
I would like to add the following functionality to it:

Add a new input s(t) to A which can be 0 or 1.
When s(t)=1 the block operates as before ie, it processes x(t) to generate y(t).
If s(t)=0 I would like it to output y(t)=0 and consume the appropriate x(t)'s 
from the input.
This way when s(t)=0 block A essentially does not work.

This is pretty straightforward to code if I modify the work function of block A.

However, block A for me is a pretty complicated hierarchical block, so I don't 
have access to its work function.
One way to do this is to rewrite the whole hierarchical block A as a flat block 
and then do as suggested above.

Is there a better way?

Thanks
Achilleas

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

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Monahan-Mitchell, Tim]

 On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
 The solution I found was to set the Fixed Frame Length parameter to 1 
 on the OFDM Frame Equalizer block of the Header Stream.

 1 is the correct setting. I'm currently adding a tx into the example so it 
 runs as-is (like benchmark).

It would be interesting to keep the original diagram, and then also show a 
replacement diagram that instead uses the OFDM Demod block and any other newer 
ones that consolidate the equivalent function.

 The reason: The headers have constant length, therefore it is not necessary 
 to propagate them as tagged streams. The way the header/paylod demux work, it 
 splits off the header and passes that regularly. There's no need to generate 
 a length tag.

Maybe that explains why my earlier issue about the Length Tag Key value for 
that same block does not matter (see GR issue # 593), since 1 implies it is 
not needed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Monahan-Mitchell, Tim]

 The solution I found was to set the Fixed Frame Length parameter to 1 
 on the OFDM Frame Equalizer block of the Header Stream.

 1 is the correct setting.

With this fix, now I see a new error:

INFO: Detected an invalid packet at item 0
INFO: Parser returned #f
thread[thread-per-block[18]: block header_payload_demux (24)]: Buffer too 
small for min_noutput_items

I'll look into this, but just in case this is familiar to anyone...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.

[Tim]

Docs can take a long time to build, so when doing multiple builds a day
during testing you really don't want to have this turned on.   Likewise
if you are building on slow machine or an older machine without
sufficient doxygen.   But obviously they are valuable for users doing
their primary build who want to use the docs.

I'm thinking it might make sense to just prompt the user when pybombs
sets up its environment and asks for things like the prefix directory -
for it to also ask the user whether they want to build documentation in
general for all the recipes they will be building.   

The main issues with this are,
1. there are not currently recipes for doxygen and it's dependencies -
those would need to be written and would pull in a bunch of latex, perl,
ghostscript, etc --
2. the dependencies for gnuradio need to change based on
enabling/disabling this feature - we don't have a good mechanism yet in
pybombs for turning deps on or off based on recipe options, but we
could add something like this fairly easily

At the end of the day we do have a choice now between trying to keep
build configurations fairly static and simple (defined only by their
recipe set and guaranteed for repeatability - which is great for
performing repeatable testing, versioning, and packaging) or allowing it
to become a monolithic thing that has lots of different user prompted
states and options.   It's not clear that we can't achieve both - but we
would sacrifice a bit of conciseness and recipe simplicity to get there

-Tim


On 09/19/2013 09:59 AM, Tom Rondeau wrote:
 On Wed, Sep 18, 2013 at 3:48 PM, M Dammer i...@mdammer.net wrote:
 May I then suggest to enable the docs in the pybombs recipe by default
 as well ?
 You may suggest.

 Sorry for being glib. I also think it's a good idea to enable the
 documentation by default. If Tim agrees and there wasn't a technical
 reason why it was turned off in the first place, I think we can change
 it.


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

Re: [Discuss-gnuradio] Proper way to update pybombs

[Tim]

On 09/14/2013 06:01 AM, M Dammer wrote:
 How can I update pybombs (to get the latest version and update the
 recipes) without loosing the information about my gnuradio build? 
in your pybombs directory or pybombs recipe directory run

git remote update
git pull

this should pull down any pybombs updates that may be available
you may want to 'git stash' before pulling and 'git stash pop' after if
you have any local changes.
or merge with a local branch with local modifications if you know what
you are doing

 I want
 to continue to update gnuradio without the need to do a complete rebuild
 after a pybombs update.
The 'safe' way to rebuild updated modules is to run
./pybombs update
this will
1. find any out of date packages - and all packages that depend on these
2. uninstall all of these packages for you
3. perform a fresh install of all of these packages

this may seem like overkill - but it is the only truly safe way to ensure
you can try the shortcut approach - which is to run

cd pybombs/src/gnuadio/
git remote update
git pull
cd build
make install

this is much much faster to do, it may not even need to run cmake if
changes were very minor
however - if you don't rebuild everything that links against gnuradio
there is a danger that you will break linkage or some API/ABI contract
with the dependent library, and there is always a danger that cmake
won't automatically re-generate some file that is is supposed to when
running this (like swig sources) - so when you do this you are rolling
the dice.
You may be able to get away with this a few times, but invariably one
day you will start running into strange seg-faults which seem
nonsensical, and which would completely go away in a fresh build.
The other safe thing is to just do a fresh pybombs build in a separate
directory so you don't lose your old working build while testing against
the latest versions of code from various repos.

-Tim

 tnx, Mark




 ___
 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] Questions on rx_ofdm example in GR 3.7.1

[Monahan-Mitchell, Tim]

GR 3.7.1
gr-digital/examples/ofdm/rx_ofdm.grc

1. The OFDM Frame Equalizer block that is downstream from the Header Stream 
Virtual Source block has the Length Tag Key field set to length_tag_name, yet 
all other blocks on the diagram with that field are set to length_tag_key 
(which is the ID of a Variable block at the top of the diagram). Is that a 
mistake? If someone will confirm, I can file the bug.

2. When I try to run this flowgraph, modified for my target's custom source 
block, I get this error:
FATAL: Missing a required length tag on port 0 at item #0
thread[thread-per-block[21]: block ofdm_frame_equalizer_vcvc (22)]: Missing 
length tag.

Which led me to question (1) above. However, changing that block to match the 
others does not correct the runtime error.

I found a couple of instances of the same error listed in (2) above in the 
mailing list, but no one replied to them.

TIA,
Tim



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

[Discuss-gnuradio] Enabling cpu #1 causes math error on ARM target

[Monahan-Mitchell, Tim]

I wanted to post this observation to the group to see if I get a hit.

I updated Bug #569 today with an additional observation:
http://gnuradio.org/redmine/issues/569 

Basically, on my ARM target, if I enable cpu core #1 (two cores total), the 
qa_mpsk_receiver test fails about 1/3rd of the time, when it compares 0.5 to 
sometimes -.492 or sometimes -.503 (i.e., the sign in the real part of a 
complex result flipped). If I keep cpu #1 disabled, the test passes every time. 
Keeping the CPUs limited to their minimum speed does not help.

I'm compiling with gcc 4.7.3, and -mcpu=cortex-a15 -mfpu=neon 
-mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations

I'll be varying the build flags to see if that makes a difference in the 
meantime.

Regards,
Tim



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

Re: [Discuss-gnuradio] Off-line signal processing (GR in slow motion)

[Monahan-Mitchell, Tim]

 Off-line example (3 separate flowgraphs, run one at a time):
 
 1. USRP -- File
 2. File -- AM Radio Demodulation, produces audio data -- File
 3. File -- Throttle @ audio rate -- Audio Sink

As Tim O pointed out, #3 would just be File -- Audio Sink, since the Audio 
Sink consumes at a fixed rate.

 
 Note that #2 can take as long as needed to complete, no issues with loss of 
 data.
 
 If so, how would I set up flowgraph #2 above?

 Hm, I'm not quite sure if I understand your problem. You can simply connect a 
 file source to the am demod and then to a file sink.

Yes, #2 was meant to depict whatever processing blocks are needed to go from RF 
samples to audio samples.

 This flowgraph will then run unlimited ('cause no throttle). But that's OK 
 if the input file is limited in size. Your CPU will be running full power 
 until there's nothing left to process.

Yes, I understand that part. What I was not sure about was whether the real 
time rate of data passing through the system was required to be able to do 
proper signal processing? Or whether some of the processing blocks are simply 
told what the rate is?

Here is another example: suppose I have a file of audio samples. To determine 
the spectrum of the data , isn't the sampling rate of the data a factor? Or 
must a scalar be applied somewhere (related to the sampling rate) to convert 
relative values to energy per Hz?

If the latter is true, then I'm still unclear on whether something like the 
rx_ofdm example under gr-digital can work, just given a file of samples and no 
throttle block (CPU limitations aside)?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Off-line signal processing (GR in slow motion)

[Monahan-Mitchell, Tim]

I know that a source block of live IQ samples set to a certain sampling rate is 
equivalent to a File source of IQ samples followed by a Throttle block set to 
that same sampling rate. So far so good.

But suppose the system cannot keep up with a live IQ stream, or the equivalent 
File + Throttle and do all the desired signal processing. Is there another way 
to process a file of captured samples without a throttle block, yet produce 
equivalent results output to another file?

Here is an example to illustrate the question:

Live example:
USRP - AM Radio Demodulation, produces audio data - Audio Sink

Off-line example (3 separate flowgraphs, run one at a time):

1. USRP -- File
2. File -- AM Radio Demodulation, produces audio data -- File
3. File -- Throttle @ audio rate -- Audio Sink 

Note that #2 can take as long as needed to complete, no issues with loss of 
data.

If so, how would I set up flowgraph #2 above?

Regards,
Tim


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

Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Monahan-Mitchell, Tim]

Just for the record.

 If the selected floating-point hardware includes the NEON extension (e.g. 
 -mfpu='neon'), note that floating-point operations are not generated by 
 GCC's auto-vectorization pass unless -funsafe-math-optimizations is also 
 specified. This is because NEON hardware does not fully implement the IEEE 
 754 standard for floating-point arithmetic (in particular denormal values 
 are treated as zero), so the use of NEON instructions may lead to a loss of 
 precision.
 
Regarding loss of precision: my target is able to use '-mfpu=neon-vfpv4' which 
selects floating point  fused operations instead of chained. I tried it, but a 
new test error surfaces due to accuracy (v3.7.0):

/src/gnuradio/build # ctest -V -R qa_ofdm_frame_equalizer_vcvc
UpdateCTestConfiguration  from :/src/gnuradio/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :/src/gnuradio/build/DartConfiguration.tcl
Test project /src/gnuradio/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 142
Start 142: qa_ofdm_frame_equalizer_vcvc

142: Test command: /bin/sh 
/src/gnuradio/build/gr-digital/python/digital/qa_ofdm_frame_equalizer_vcvc_test.sh
142: Test timeout computed to be: 9.99988e+06
142: .F.
142: ==
142: FAIL: test_002_static (__main__.qa_ofdm_frame_equalizer_vcvc)
142: --
142: Traceback (most recent call last):
142:   File 
/src/gnuradio/gr-digital/python/digital/qa_ofdm_frame_equalizer_vcvc.py, line 
244, in test_002_static
142: self.assertEqual(tag_dict, expected_dict)
142: AssertionError: {'frame_len': 4L, 'ofdm_sync_chan_taps': [0j, 0j, 
(-2.2037331959268158e-08+1j),  [truncated]... != {'frame_len': 4, 
'ofdm_sync_chan_taps': [0, 0, 1j, 1j, 0, 1j, 1j, 0]}
142: + {'frame_len': 4, 'ofdm_sync_chan_taps': [0, 0, 1j, 1j, 0, 1j, 1j, 0]}
142: - {'frame_len': 4L,
142: -  'ofdm_sync_chan_taps': [0j,
142: -  0j,
142: -  (-2.2037331959268158e-08+1j),
142: -  (-2.2037331959268158e-08+1j),
142: -  0j,
142: -  (2.2037331959268158e-08+1j),
142: -  (-2.2037331959268158e-08+1j),
142: -  0j]}

So I went back to just '-mfpu=neon'.

I didn't log this as a GR bug, since it feels like the Doctor, it hurts when I 
do this variety of problems.

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

Re: [Discuss-gnuradio] gnuradio recipe in pybombs requires mcpp

[Tim Newman]

Yeah, I think your right, mcpp isn't needed in the gnuradio pybombs recipe.

Tim


On Thu, Aug 8, 2013 at 9:05 AM, Alexandru Csete oz9...@gmail.com wrote:

 On Thu, Aug 8, 2013 at 2:16 PM, Tom Rondeau t...@trondeau.com wrote:
  On Thu, Aug 8, 2013 at 7:37 AM, Alexandru Csete oz9...@gmail.com
 wrote:
  Greetings,
 
  I just noticed that executing ./pybombs install gnuradio on a system
  that already has all the necessary dependencies starts by installing a
  package called mcpp. Searching the web I found out that it is a C/C++
  preprocessor from 2008...
 
  Since gnuradio builds just fine with the standard preprocessor in gcc,
  I hope we can get rid of it get rid of this dependency.
 
  Alex
 
  It's an ICE dependency... the rest of GNU Radio doesn't use it. It's
  just needed to build ICE.

 Tom,

 Thanks for the info. If it is is an ICE build dependency then we can
 remove it from the gnuradio recipe, yes?
 Or is it also necessary for parsing and converting the gnuradio.ice files?

 Alex

 ___
 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] Xlate FIR filter broken in gr 3.7

[Monahan-Mitchell, Tim]

rant

I would vote for making copious use of the doc section in every block's XML 
file.

For example, as a beginner, I spent a lot of time fiddling with Stream to 
Vector to figure out the parameters were opposite from what I thought they 
were. It is frustrating to open up a block's sheet and find it empty.

/rant

 On 08/08/2013 05:01 PM, Andrew Davis wrote:
 Also, this change breaks a very important and very used part of hundreds of 
 projects over the last ten years to make a variable name make slightly more 
 since, when you could just change the variable name to 'frequency_shift' and 
 leave the functionality the way it was.

 Andrew

  I have to agree.  It's one thing to muck with the API semantics of a block 
 that is new and hardly anyone has used.  It's quite another to
  make a change like this on a block that has been in use for many years, with 
folks having figured out the semantics, despite the odd naming.



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

Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Monahan-Mitchell, Tim]

Hi, Marcus.

Thanks for your help. Tom seems to have given a pretty definitive reply, but 
this is just to completely answer your reply.

 On 08/07/2013 02:44 AM, Marcus Müller wrote:


 [1] note: in kernel terms of auxvec.h this stands for AT_HWCAP, see 
 http://lxr.free-electrons.com/source/include/uapi/linux/auxvec.h?a=arm#L24
 How Volk handles it looks like AT_HWCAP can only start on a 4-byte-aligned 
 address within auxv;
 I'm absolutely not sure whether this is correct; on my x86_64 machine, there 
 is no AT_HWCAP in that case.
decided to have a look into this instead of sleeping; man proc(5) and volk are 
right: AT_HWCAP can only occur every 64 bit in /proc/PID/auxv. Sorry for the 
confusion.

Your earlier reply said:

snip ... however, as it seems, detection of Neon fails.

But the cmake output I included said:

-- Performing Test have_mfpu_neon - Success
-- Performing Test have_funsafe_math_optimizations - Success

So I think the neon detection works?

You also asked: does executing
   hexdump /proc/self/auxv|sed ' 0010'
show anything?

Yes, an error :) ... Maybe you meant grep? The first line of auxv matches to 
your string:

$ hexdump /proc/self/auxv
000 0010  b0d7 0001 0006  1000 
010 0011  0064  0003  8034 
020 0004  0020  0005  0009 
030 0007  c000 4002 0008   
040 0009  8f35  000b   
050 000c    000d   
060 000e    0017   
070 0019  dc07 bed4 001f  dfeb bed4
080 000f  dc17 bed4    
090

And if I run the basic cmake ../ command, I still get the same output for 
Volk.

You asked for the CFLAGS in CMakeCache.txt in that s case, here you go: 

// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_C_FLAGS:STRING=
CMAKE_C_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
//ADVANCED property for variable: CMAKE_C_FLAGS
CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1

Just to compare, running my original cmake command yields the CFLAGS I manually 
specified:

grep C_FLAGS CMakeCache.txt
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_C_FLAGS:STRING=-I/usr/include/arm-linux-gnueabihf -mcpu=cortex-a15 
-mfpu=neon -mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations
CMAKE_C_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
//ADVANCED property for variable: CMAKE_C_FLAGS
CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1

Thanks again and all the best,
Tim

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

Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Monahan-Mitchell, Tim]

Hi, Marcus,

 I was just a little confused, because I read the volk/gen/archs.xml template, 
 and figured if
 has_neon() returned true, -mfloat_abi=soft and -nfpu=neon would have been 
 added to the C_FLAGS...
 and cmake's output contained Performing Test have_mfloat_abi_softfp - 
 Failed, so I guessed that (since I was quite sure that your machine 
 supports softfp) it was disabled by lack of compiler flags...

Actually, I compared my VMware x86 gnuradio cmake output to my ARM target, and 
it also failed the same abi_softfp test (but of course volk is much more 
exciting on the x86 target).

But I also fiddled with that flag for a while: if I add -mfloat_abi=soft to my 
CFLAGS in the cmake command, it fails early as it can't find crti.o and crt1.o. 
But I was smart enough to find those on may target, and set LIBRARY_PATH to 
help. But then I get an error telling me there is a mismatch between the ABI of 
my toolchain and the ABI of the compiler output. So the soft flag came back out.

Because of the 'abi_softfp' test failing on my x86, I decided I did not need to 
re-build the ARM tool chain to support soft ABI to try and help Volk. Is that 
still correct? (I have been able to build and run gnuradio without the soft 
flag just fine).

Thanks,
Tim

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

Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Monahan-Mitchell, Tim]

Hi, Marcus

 On 08/07/2013 09:48 PM, Monahan-Mitchell, Tim wrote:
 Because of the 'abi_softfp' test failing on my x86, I decided I did not need 
 to re-build the ARM tool chain to support soft ABI to try and help Volk. Is 
 that still correct? (I have been able to build and run gnuradio without the 
 soft flag just fine).
 I don't think -mfloat_abi=softfp (or even =soft) applies to x86; I think I 
 remember the equivalent flag being something along the ways of 
 -msoft-float... Or am I misunderstanding you and you talk about 
 cross-compiling on x86 for arm?

In my volk travels to answer this email thread's question, I was comparing what 
cmake did on my x86 (where there is more volk support) to what cmake does on my 
ARM target. I noted that both had -- Performing Test have_mfloat_abi_softfp - 
Failed, hence my conclusion that softfp was not a requirement for volk.

snip

 If the selected floating-point hardware includes the NEON extension (e.g. 
 -mfpu='neon'), note that floating-point operations are not generated by GCC's 
 auto-vectorization pass unless -funsafe-math-optimizations is also specified. 
 This is because NEON hardware does not fully implement the IEEE 754 standard 
 for floating-point arithmetic (in particular denormal values are treated as 
 zero), so the use of NEON instructions may lead to a loss of precision.

 So it might make sense to include -funsafe-math-optimizations, if 
 vectorize-with-neon-quad does not do that implicitly.

Yes, I have -funsafe-math-optimizations and the cmake test for it passes:  
Performing Test have_funsafe_math_optimizations - Success

Thanks,
Tim

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

[Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Monahan-Mitchell, Tim]

Volk only gives me 'generic'.

Is there some component available that I can to add to my system to get more 
out of it?

Neon is detected, so I think that is why I see the 'generic_orc' machine listed.

The gory details:

gnuradio v3.7.0

Ubuntu 13.04 LTS (ARM distribution, ubuntu-core-13.04-core-armhf.tar.gz)

Part of my cmake config :
cmake -DCMAKE_C_FLAGS:STRING=-I/usr/include/arm-linux-gnueabihf 
-mcpu=cortex-a15 \
-mfpu=neon -mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations \

Parts of the cmake output:

-- The CXX compiler identification is GNU 4.7.3
-- The C compiler identification is GNU 4.7.3

snip

-- Configuring volk support...
--   Enabling volk support.
--   Override with -DENABLE_VOLK=ON/OFF
-- Found PythonInterp: /usr/bin/python2 (found suitable version 2.7.4)
--
-- Python checking for python = 2.5
-- Python checking for python = 2.5 - found
--
-- Python checking for Cheetah = 2.0.0
-- Python checking for Cheetah = 2.0.0 - found
-- Boost version: 1.53.0
-- Found the following Boost libraries:
--   filesystem
--   system
--   unit_test_framework
-- checking for module 'orc-0.4  0.4.11'
--   found orc-0.4  0.4.11, version 0.4.17
-- Found ORC: /usr/lib/arm-linux-gnueabihf/liborc-0.4.so
-- Looking for cpuid.h
-- Looking for cpuid.h - not found
-- Looking for intrin.h
-- Looking for intrin.h - not found
-- Looking for fenv.h
-- Looking for fenv.h - found
-- Looking for dlfcn.h
-- Looking for dlfcn.h - found
-- Compiler name: GNU
-- Performing Test HAVE_WERROR_UNUSED_CMD_LINE_ARG
-- Performing Test HAVE_WERROR_UNUSED_CMD_LINE_ARG - Failed
-- Performing Test have_maltivec
-- Performing Test have_maltivec - Failed
-- Performing Test have_mfpu_neon
-- Performing Test have_mfpu_neon - Success
-- Performing Test have_mfloat_abi_softfp
-- Performing Test have_mfloat_abi_softfp - Failed
-- Performing Test have_funsafe_math_optimizations
-- Performing Test have_funsafe_math_optimizations - Success
-- Performing Test have_m32
-- Performing Test have_m32 - Failed
-- Performing Test have_m64
-- Performing Test have_m64 - Failed
-- Performing Test have_m3dnow
-- Performing Test have_m3dnow - Failed
-- Performing Test have_msse4_2
-- Performing Test have_msse4_2 - Failed
-- Performing Test have_mpopcnt
-- Performing Test have_mpopcnt - Failed
-- Performing Test have_mmmx
-- Performing Test have_mmmx - Failed
-- Performing Test have_msse
-- Performing Test have_msse - Failed
-- Performing Test have_msse2
-- Performing Test have_msse2 - Failed
-- Performing Test have_msse3
-- Performing Test have_msse3 - Failed
-- Performing Test have_mssse3
-- Performing Test have_mssse3 - Failed
-- Performing Test have_msse4a
-- Performing Test have_msse4a - Failed
-- Performing Test have_msse4_1
-- Performing Test have_msse4_1 - Failed
-- Performing Test have_mavx
-- Performing Test have_mavx - Failed
-- Available arch: generic;orc;norc
-- Available machines: generic_orc

My /proc/cpuinfo :
Processor   : ARMv7 Processor rev 2 (v7l)
processor   : 0
BogoMIPS: 13.53
Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x1
CPU part: 0x04d
CPU revision: 2

Thanks in advance,
Tim


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

Re: [Discuss-gnuradio] Help Pybombs

[Tim Newman]

When you run pybombs for the first time, it should ask you what prefix you
want it to install into.  For example, i think it defaults to /usr/local/.
 This then passes that prefix directory to the configurare parameter
--prefix for autotools based projects or the cmake parameter
-DCMAKE_INSTALL_PREFIX for cmake based projects, and the projects install
into that prefix.  Pybombs is simply running the configure/make/make
install for the project you want to install and all it's dependencies.
 There's no magic about where it installs things.

Tim


On Fri, Aug 2, 2013 at 9:37 AM, tom sutherland alphatoz...@yahoo.comwrote:

 I have in stalled pybombs. I looked at all the projects in the recipe
 directory and have run ./pybombs install gr-ham and a few others but
 can't figure out what it is installing and WHERE did it put it. I thought
 it was installing some examples but I can't find anything.
 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] Boost recipe in pybombs

[Tim]

Alex,

This is set because of the unfortunate way some version of
FindBoost.cmake are written
the order it searches for libs can look something like

1. check for libboostfoo-mt.so in $BOOST_ROOT
2. check for libboostfoo-mt.so in /usr/lib/
3. check for libboostfoo.so in $BOOST_ROOT
4. check for libboostfoo.so in /usr/lib/

A result of this is that if you build without the -mt tag, and you are
on a distro that has an older version of boost installed into /usr/lib/
system paths - $BOOST_ROOT will be ignored because it checks all the
search directories for each library naming case in an unfortunate order.
So building with -mt every time to ensures FindBoost.cmake picks up the
right prefixed boost library (if built from source) every time when
building other recipes that use boost  cmake.

-Tim

On 08/01/2013 02:16 PM, Alexandru Csete wrote:
 The boost recipe in pybombs builds using the --layout=tagged option
 which will  generate libraries with the -mt suffix. The 'mt' stands
 for multi threaded and is only available for historical reasons,I
 suppose.

 Is there any particular reason for using this optionin pybombs? There
 are some linux distributions that have abandoned the -mt suffix and
 gnuradio builds just fine on those. Ubuntu still uses the -mt suffix
 but also creates softlinks  without the suffix, so it is safe for an
 application to only link to libboost-xyz without the suffix.

 Alex

 ___
 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] Gnuradio3.7 make error

[tim . newman]

Its finding 1.40 headers somewhere on your system.

Tim
Sent on the Sprint® Now Network from my BlackBerry®

-Original Message-
From: Harry Zhang zhang...@gmail.com
Sender: discuss-gnuradio-bounces+tim.newman=gmail.com@gnu.orgDate: Tue, 30 Jul 
2013 19:23:47 
To: Nathan Westnathan.w...@okstate.edu
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Gnuradio3.7 make error

Dear Nathan,
 Thank you for your reply.
 I have changed the boost to 1.48 but the error remains. According 
to the error information, it seems to require libboost1.40,which puzzles me.

2013/7/30 12:12, Nathan West wrote:
 On Mon, Jul 29, 2013 at 11:55 PM, Gong Zhang zhang...@gmail.com wrote:
 Dear Nathan,
  I have tried the method in the URL but it does not work. The error
 remains.

   2013/7/30 10:58, Nathan West wrote:
 On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang zhang...@gmail.com wrote:
 Hi,
   I'm using Ubuntu 12.04 and libboost1.46. I got the following errors
 when
 I make the project.

 libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04
 should have libboost1.48 available in the repos. Here's some more
 info:
 http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html

 What do you mean you tried the method in the URL? The cmake flag? The
 point of sending that link is the version of boost you have is known
 to cause problems with GNU Radio and unless you have a very good
 reason for using it you should use another version. If you're having
 trouble installing GNU Radio for the first time you might give pybombs
 a shot. It's pretty easy to get an installation going for the first
 time, especially if you're having a problem with dependencies like
 boost.

 Here's info on pybombs: http://gnuradio.org/redmine/projects/pybombs/wiki

 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] pybombs building 3.6.5.1 - swapping and out of virtual memory

[Tim Newman]

By default pybombs runs make with the -j4 option, allowing it to compile
things in parallel.  This typically helps the compile go quicker.  I
certainly wouldnt expect the gnuradio compile to have issues like this, but
you could edit the gnuradio recipe to force it not to use the -j4 option
by adding:

make {
make
}

This basically overwrites the template pybombs uses for the make
stage, which uses the -j4 by default. It will result in a longer
compile time, and again I wouldnt expect a machine with 4GB of RAM to
have any problems, even with that option, but its something to try.

Tim




On Mon, Jul 29, 2013 at 12:40 PM, M Dammer i...@mdammer.net wrote:

 Not sure if this is a Pybombs or Gnuradio build issue: When building
 version 3.6.5.1 via pybombs the system starts swapping after about 70%
 of the build have completed and even sometimes bails out with out of
 virtual memory. I can complete the build by restarting pybombs install
 - sometimes several times.
 I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM.
 I notice that top shows several cc1plus processes running in parallel
 each consuming over 1Gb of memory.



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

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

Re: [Discuss-gnuradio] PYBOMBS Build Failure

[Tim Newman]

It appears that your error is not with pybombs but with building gnuradio.
 Can you post a bit more of the compile log?

Tim


On Thu, Jul 25, 2013 at 12:36 PM, Dan CaJacob dan.caja...@gmail.com wrote:

 Hi,

 I've been trying out pybombs for building the latest gnuradio.  I had a
 successful build at home last week, but I am having repeated failures in a
 test environment VM (virtualbox, ubuntu 12.04 x64).

 I am running the build like this: sudo ./pybombs install gnuradio

 Here's the relevant part of the make output:

 [ 68%] Built target gnuradio-blocks
 Linking CXX shared module _vocoder_swig.so
 [ 68%] Built target _vocoder_swig
 make: *** [all] Error 2
 bash return val = 2
 Traceback (most recent call last):
   File ./pybombs, line 91, in module
 install(p,True);
   File /home/spacequest/pybombs/mod_pybombs/pybombs_ops.py, line 49, in
 install
 global_recipes[pkg].install();
   File /home/spacequest/pybombs/mod_pybombs/recipe.py, line 512, in
 install
 st = self.install_src();
   File /home/spacequest/pybombs/mod_pybombs/recipe.py, line 582, in
 install_src
 self.install_order[step][1]();
   File /home/spacequest/pybombs/mod_pybombs/recipe.py, line 612, in make
 assert(st == 0);
 AssertionError

 ___
 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] Gnuradio 3.6.x recipe for pybombs ?

[Tim Newman]

On 07/20/2013 12:38 PM, M Dammer wrote:
 thanks for the suggestion. I already solved the problem here, by putting
 this configure section in the recipe:
 configure {
 git checkout tags/v3.6.5.1
 cmake .. -DCMAKE_BUILD_TYPE=$cmakebuildtype
 -DCMAKE_INSTALL_PREFIX=$prefix $config_opt
 }


 On 20/07/13 17:04, Nathan West wrote:
 On Sat, Jul 20, 2013 at 10:26 AM, M Dammer i...@mdammer.net wrote:
 This does not work. I am getting a branch not found, building HEAD
 instead like error and then it builds 3.7. It looks as the gitbranch
 part of the recipe really only works with branches while the version
 numbers are tags. Does pybombs has a similar command than gitbranch to
 define a tag in a recipe ?

 On 19/07/13 20:00, Tom Rondeau wrote:
 On Fri, Jul 19, 2013 at 12:31 PM, M Dammer i...@mdammer.net wrote:
 Has anyone a recipe for installing the 3.6-branch via pybombs ? I need a
 3.6 parallel installation on my system, because many old projects are
 not working out of the box in 3.7.x. Even many of the projects
 referenced by recipes that currently come with pybombs do not compile.
 tnx, Mark
 Mark,

 You can edit the recipe file to change the branch you want to check
 out. In pybombs/recipes/gnuradio.lwr look for the 'gitbranch' line.
 Change this from 'master' to the tag of the version you want, such as
 'v3.6.5.1' for the latest in the 3.6 version.

 Tom
 Leave the branch as whatever you want (master, maint...) but add a
 line for gitrev:
 gitrev: tags/v3.6.5.1

 Of course this could be whatever rev you want.

 Nathan



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Nathan's correct, the proper way would be by using the gitrev: line,
you should be table to specify either a tag or a specific git revision.

Tim

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

Re: [Discuss-gnuradio] git check out fails

[Monahan-Mitchell, Tim]

 ===  THIS MAY TAKE QUITE SOME TIME= Fetching Gnu Radio 
 via GIT...Could not find gnuradio/gnuradio-{core,runtime} after GIT 
 checkout GIT checkout of Gnu Radio failed!

 omg.  what do i have to do here?

 Well, you could run it using --verbose to see if there's anything extra going 
 wrong.

It looks like the build_gnuradio script is being used.

Just try the git command that is in the script by itself like this I think:

git clone --verbose http://gnuradio.org/git/gnuradio.git

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

Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)

[Monahan-Mitchell, Tim]

 One of my OOT blocks is a function that takes in shorts and outputs shorts 
 (a 1-to-2 interpolator).

 I have a simple flowgraph created in GRC:   File Source - My block - File 
 sync .

 GRC is happy until I run the flowgraph, and I get this:

 Executing:  /top_block.py

 Traceback (most recent call last):
   File  /top_block.py, line 54, in module
 tb = top_block()
   File  /top_block.py, line 39, in __init__
 self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0))
   File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, 
 line 130, in connect
 self._connect(points[i-1], points[i])
   File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, 
 line 141, in _connect
 self._tb.primitive_connect(src_block.to_basic_block(), src_port,
 AttributeError: 'function' object has no attribute 'to_basic_block'

I have found the error (or at least I am closer): The Python code that GRC 
generates is slightly different between v3.6.4.2 and v3.7.0 for the same test 
flowgraph. Namely, the newer version omits an empty set of parens, thusly:

From v3.6.4.2 :

##
# Blocks
##
self.my_oot_my_block_0 = my_oot.my_block()

From v3.7.0 :

##
# Blocks
##
self.my_oot_my_block_0 = my_oot.my_block

My block has no parameters (thus the empty parens).

If I manually edit the v3.7.0 generated py code to add the missing parens, it 
all works fine as with v3.6.4.2.

Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module? 
As far as I can tell, I converted it according to the 3.6 - 3.7 recipe.

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

Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)

[Monahan-Mitchell, Tim]

 One of my OOT blocks is a function that takes in shorts and outputs shorts 
 (a 1-to-2 interpolator).

 I have a simple flowgraph created in GRC:   File Source - My block - File 
 sync .

 GRC is happy until I run the flowgraph, and I get this:

 Executing:  /top_block.py

 Traceback (most recent call last):
   File  /top_block.py, line 54, in module
 tb = top_block()
   File  /top_block.py, line 39, in __init__
 self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0))
   File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, 
 line 130, in connect
 self._connect(points[i-1], points[i])
   File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, 
 line 141, in _connect
 self._tb.primitive_connect(src_block.to_basic_block(), src_port,
 AttributeError: 'function' object has no attribute 'to_basic_block'

 I have found the error (or at least I am closer): The Python code that GRC 
 generates is slightly different between v3.6.4.2 and v3.7.0 for the same test 
 flowgraph. Namely, the newer version omits an empty set of parens, thusly:

 From v3.6.4.2 :

   ##
   # Blocks
   ##
   self.my_oot_my_block_0 = my_oot.my_block()

 From v3.7.0 :

   ##
   # Blocks
   ##
   self.my_oot_my_block_0 = my_oot.my_block

 My block has no parameters (thus the empty parens).

 If I manually edit the v3.7.0 generated py code to add the missing parens, it 
 all works fine as with v3.6.4.2.

 Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module? 
 As far as I can tell, I converted it according to the 3.6 - 3.7 recipe.

Answer: This was my subtle coding error. I left the empty parens out of the XML 
file's 'make' entry (last line below).

File: my_oot_my_block.xml

block
  namemy_block/name
  keymy_oot_my_block/key
  categorymy_oot/category
  importimport my_oot/import
  makemy_oot.my_block/make  - Forgot () after the name.  Case closed.

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

Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)

[Monahan-Mitchell, Tim]

 I've stepped up to GR 3.7.0, re-used gr_modtool to freshly re-create my OOT 
 module, everything builds, tests, installs OK. GRC has my OOT blocks listed 
 and I can put them on my flowgraph.

 One of my OOT blocks is a function that takes in shorts and outputs shorts (a 
 1-to-2 interpolator).

 I have a simple flowgraph created in GRC:   File Source - My block - File 
 sync .

 GRC is happy until I run the flowgraph, and I get this:

 Executing:  /top_block.py

 Traceback (most recent call last):
   File  /top_block.py, line 54, in module
 tb = top_block()
   File  /top_block.py, line 39, in __init__
 self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0))
   File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, 
 line 130, in connect
 self._connect(points[i-1], points[i])
   File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, 
 line 141, in _connect
 self._tb.primitive_connect(src_block.to_basic_block(), src_port,
 AttributeError: 'function' object has no attribute 'to_basic_block'

An update.

First, I believe I exhaustively eradicated older installed versions of GR by 
searching and deleting for anything named '*gnuradio*' under /usr, re-built GR 
and re-installed. But, same results.

Using the pdb single step debugger and also just looking at the code, I have a 
question about top_block.py (under 
/usr/local/lib/python2.7/dist-packages/gnuradio/gr):

def _connect(self, src, dst):
(src_block, src_port) = self._coerce_endpoint(src)
(dst_block, dst_port) = self._coerce_endpoint(dst)
self._tb.primitive_connect(src_block.to_basic_block(), src_port,
   dst_block.to_basic_block(), dst_port)

def _coerce_endpoint(self, endp):
if hasattr(endp, 'to_basic_block'):
return (endp, 0)
else:
if hasattr(endp, __getitem__) and len(endp) == 2:
return endp # Assume user put (block, port)
else:
raise ValueError(unable to coerce endpoint)

I'm not a python expert, but _coerce_endpoint is checking if the attribute 
'to_basic_block' exists... But then the _connect function goes right ahead 
and tries to use it as it prepares to call primitive_connect, which is what 
the error is about... And single stepping through the python code seems to 
verify that...  (in my case, the test for __getitem__ and len(endp) == 2 is the 
path the code takes).

I also don't understand why _coerce_endpoint in that path returns ony endp, 
but in its other leg, returns (endp, 0)? Seems like the caller wants to 
assign 2 values (src_block, src_port)...

This part of the top_block.py code is the same between 3.6.4.2 and 3.7.0...

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