[Discuss-gnuradio] variable noutput_items

[Amirhosein naseri]

HiI code my own block that produce complex sample and I set max and min output 
buffer of my block to 256, but if I use a RRC filter after my block , depend on 
number of tabs , noutput_items of my block change randomly during running of 
flowgraph, why?___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building gnuradio master fails

[li...@lazygranch.com]

Full cmake output at 
https://pastebin.com/4uwwZbcW

Here is the relevant portion of the cmake output. Everything is found.
Now I suppose I could downgrade the libraries if that helps.

-- Checking for module 'gsl >= 1.10'
--   Found gsl , version 2.3
-- Found GSL: gsl;gslcblas;m  
--
-- Configuring gr-fec support...
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Enabling gr-fec support.
--   Override with -DENABLE_GR_FEC=ON/OFF



On Mon, 22 May 2017 23:03:15 -0700
Cinaed Simson  wrote:

> On 05/21/2017 08:02 PM, li...@lazygranch.com wrote:
> > It seems opensuse runs an old rev of gsl. Here are the relevant file
> > names and revs:
> > 
> > gsl 1.16-74
> > gsl-devel 2.3-9.1
> > libgsl19 2.3-9.1
> > libgslblas0 2.3-9.1
> > python-pygsl 0.9.5-2.30
> > python-pygsl-devel 0.9.5-2.30  
> 
> I'm running release version 3.7.11 with gsl-1.16.
> 
> Actually, now that I think about it, I would be suprised if it built
> gr-fec without gsl.
> 
> It may not a be gsl problem - your mileage may vary depending upon the
> version of gnuradio you're running.
> 
> Create a new build directory and run cmake - it will tell you if
> there's a problem with gsl.
> 
> -- Cinaed
> 
> > 
> > Using the science repo, I can upgrade gsl to rev 2.3. Yast will
> > have to deinstall a number of programs such as krita and more
> > significant, inkscape. I can build what breaks from source if the
> > rev of gsl is the problem.
> > 
> > 
> > On Sun, 21 May 2017 18:08:36 -0700
> > li...@lazygranch.com wrote:
> >   
> >>
> >> "Latest commit 0e32fca 4 days ago." That comes right off of github.
> >> https://github.com/gnuradio/gnuradio
> >>
> >> When I'm on that machine, I will research what I have for the gnu
> >> scientific library. I have it, but don't know if it is up to date.
> >>
> >>
> >>   Original Message  
> >> From: Cinaed Simson
> >> Sent: Sunday, May 21, 2017 5:52 PM
> >> To: discuss-gnuradio@gnu.org
> >> Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> >>
> >> On 05/21/2017 01:27 AM, li...@lazygranch.com wrote:  
> >>> FWIW, I just compiled 0e32fca on opensuse. It builds just fine,
> >>> but I'm failing all the polar tests. Yeah I have scipy installed.
> >>> I'll start a new thread on that when I've totally given up
> >>> debugging. But the code on that rev is buildable on my PC.  
> >>
> >> I have no idea what 0e32fca is - looks like an arbitrary hex tag -
> >> but if the tests in gr-fec are failing it's most likely because
> >> development version of gsl wasn't installed - or it's the wrong
> >> version.
> >>
> >> Can you simply install gsl and be on your merry way? Unlikely.
> >>
> >> -- Cinaed
> >>
> >>  
> >>>
> >>>
> >>> On Sun, 21 May 2017 08:13:28 +0200
> >>> "Ralph A. Schmid, dk5ras"  wrote:
> >>>  
>  This is also my experience, I made exactly this, deleting the
>  build dir, make a new one, fresh cmake, and so on.
> 
>  Ralph.
> 
>   
> > -Original Message-
> > From: li...@lazygranch.com [mailto:li...@lazygranch.com]
> > Sent: Saturday, 20 May, 2017 20:50
> > To: Ralph A. Schmid, dk5ras; 'Kostis Triantafyllakis';
> > discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio]
> > Building gnuradio master fails
> >
> > Be that as it may, I have noticed that the first "cmake../",
> > that is a fresh directory, produces different output than a
> > "make clean" followed by "cmake ../". ‎ I've made it a point to
> > do a "rm -r build".
> >
> > By output, I means whatever is written to standard output. I
> > don't know if a fresh directly effects the actual build or not.
> >
> > Original Message
> > From: Ralph A. Schmid, dk5ras
> > Sent: Saturday, May 20, 2017 11:32 AM
> > To: 'Kostis Triantafyllakis'; discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> >
> > Hi,
> >
> > Forgot to mention that of course I already did so - with no
> > success...
> >
> > Ralph.
> >  
> >> -Original Message-
> >> From: Kostis Triantafyllakis [mailto:ctri...@csd.uoc.gr]
> >> Sent: Saturday, 20 May, 2017 18:19
> >> To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
> >> Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> >>
> >> Hello,
> >>
> >> Cleaning (or even deleting the whole build directory) before
> >> rebuilding, had helped me in similar cases.
> >> Maybe you could give it a try
> >>
> >> Best,
> >> Kostis
> >>
> >>
> >> On 05/20/2017 06:58 PM, Ralph A. Schmid, dk5ras wrote:   
> >>> Hi,
> >>>
> >>> on a Kubuntu 16.04 system building gnuradio from source fails.
> >>> Branch is master, downloaded right now.
> >>>
> >>> UHD is also the latest version from right now.
> >>>
> >>> Any ideas what it could be? Here the outpu

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p transreceiver module - Number of symbols per frame?

[Bastian Bloessl]

Hi,

On 05/21/2017 11:45 PM, Qurat-Ul-Ann Akbar wrote:

Hi,

I want to look at the number of symbols copied for *each frame received 
*in wifi_rx flow graph. I have been trying to understand how the start 
of each frame is calculated and by looking at the code it seems like its 
being done in the wifi sync_short block where the auto correlation 
coefficient is being checked against a threshold and then the d_plateau 
is being updated until it reaches MIN_PLATEAU.


However, for the number of symbols per frame, there is a MAX_SAMPLES 
which is set to 540*80 where 80 is the number of samples per symbol but 
I don't understand why is the total number of symbols per frame set to 540?


IIRC, that corresponds to a 1500 byte BPSK 1/2 frame. It just pipes in 
the maximum number of samples, since this block doesn't know the actual 
size of the frame.





Whats the role of MIN_GAP? Why is it being used to detect a shorter frame?



The autcorrelation has a plateau at the beginning of the frame. To avoid 
triggering multiple times, the receiver waits at least MIN_GAP samples.


But even if the receiver still copies samples, it can already 
resynchronize after MIN_GAP samples, i.e., if it's not one large frame, 
but short ones with low interarrival time.





Moreover, does it mean that the number of symbols per frame can be 
either MAX_SAMPLES or MIN_GAP because in both cases it starts searching 
for new frames. What if one frame has less number of symbols than 
MIN_GAP and MAX_SAMPLES?


It will receive frames with __up to__ MAX_SAMPLES and short frames 
back-to-back, if they are spaced __at least__ MIN_GAP samples.


Best,
Bastian


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

[Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver

[Ayan Chatterjee]

Hi,

In IEEE 802.11 a/g/p Receiver (https://github.com/bastibl/gr-ieee802-11),
when a packet gets dropped, does the transmitter resend another packet with
the same sequence number ?

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

Re: [Discuss-gnuradio] IEEE 802.15.4_OQPSK PHY Constellation issues

[Bastian Bloessl]

Hi,

On 05/23/2017 02:45 AM, Tellrell White wrote:

Hi All,
I'm currently using the the IEEE 802.15.4 testbed developed by Bastian 
Bloessl, and company, specifically the offset-qpsk PHY. The only changes 
I've made to the flow-graph developed by Bastian is adding  a vector 
source consisting of 0's and 1's as my input source and adding a 
constellation sink. I've attached the flow-graph for reference. When 
running the flow-graph, the output of the constellation doesn't look 
quite correct. For instance I'm not quite sure why there are 
constellation points at 0 + j and 0 - j as well as at 1 + 0j  and 1- 0j. 
A picture of the constellation plot is also attached.


I'm not sure what you are irritated about. With OQPSK you don't change 
abruptly, but transition from one constellation point to the other on a 
circle. Depending on the sample rate, there are multiple points 
in-between the final constellation at +-0.707 +- 0.707i. (in that case 
it is just one).



Best,
Bastian

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

[Discuss-gnuradio] How to do synchronization in gnuradio and remove preamble after peak of correlation

[Huzaifa niazi]

Hi, I want to correlate my data frame with known preamble , i am using
CORRELATION ESTIMATOR BLOCK . it has two output ports one is for
correlation and one is shown as output port . I want to Know How to Proceed
further for synchronization ,Which block i will use next to it ,which
should remove preamble by estimating the peak of correlation and extracting
data out of it. Kindly check my flowgraph , Your help will highly
appreciated ,Thanx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver

[Bastian Bloessl]

Hi,

On 05/23/2017 12:54 PM, Ayan Chatterjee wrote:

Hi,

In IEEE 802.11 a/g/p Receiver 
(https://github.com/bastibl/gr-ieee802-11), when a packet gets dropped, 
does the transmitter resend another packet with the same sequence number ?




No.

Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver

[Ayan Chatterjee]

Hi,

Is there any buffer on the receiver side which stores received packets
before decoding ?

Regards,
Ayan

On Tue, May 23, 2017 at 4:36 PM, Bastian Bloessl  wrote:

> Hi,
>
> On 05/23/2017 12:54 PM, Ayan Chatterjee wrote:
>
>> Hi,
>>
>> In IEEE 802.11 a/g/p Receiver (https://github.com/bastibl/gr-ieee802-11),
>> when a packet gets dropped, does the transmitter resend another packet with
>> the same sequence number ?
>>
>>
> No.
>
> Best,
> Bastian
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver

[Bastian Bloessl]

Hi,

On 05/23/2017 01:12 PM, Ayan Chatterjee wrote:

Hi,

Is there any buffer on the receiver side which stores received packets 
before decoding ?


Yes, there are many. GNU Radio uses shared buffers to exchange data 
(samples) between blocks. See here:


https://www.gnuradio.org/blog/buffers/

Best,
Bastian

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

[Discuss-gnuradio] Warning::How can i calibrate HackRF one for frequency correction in DVB-T receiving?(Bad Receiving HackRF one reasons shared...)

[Stack Programer]

Steps to reproduce

1.I had a HackRF one TX DVB-T,and a RX-DVBT with hackRF one, in receive it
sucks .
2.with rtl-sdr and vlc it can received DVB-T signalbut with hackrf
one sucks
Expected behaviour

after some research i guess that oscillator hackrf one is not accurate .it
can should be calibrate?
how we can calibrate hackrf one for different modulation
Actual behaviour

in real world i guess it can not calibrated in frequency.
Version information

*Operating system*:
debian os , gnuradio 3.7.12,linux
why hackrf one not can received ? it has weakness in receiving? weak
receiving can be related to ppm ?
please help, any idea??? it can be related ADC?HackRFone has poor receiving
why?
i will soon share result.
best regards stackprogramer
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Warning::How can i calibrate HackRF one for frequency correction in DVB-T receiving?(Bad Receiving HackRF one reasons shared...)

[Marcus Müller]

Hi Stack Programer,

seriously, your mail is sub-standard: Please explain your statements and
ask well-defined questions. I'll try to point out what's wrong here

On 23.05.2017 16:20, Stack Programer wrote:
>
>
>   Steps to reproduce
>
> 1.I had a HackRF one TX DVB-T,and a RX-DVBT with hackRF one, in
> receive it sucks .
>
What does "it sucks" mean? For all I know (and it's not even a product
of the company that pays me), it's a fine device. Chances are your
receiving software isn't configured optimally.
>
> 2.with rtl-sdr and vlc it can received DVB-T signalbut with
> hackrf one sucks
>
Same as above. Also, note that a lot of people put a lot of work into
that hardware, and those are potentially the people that you want to
help you. Choice of words.
>
>
>   Expected behaviour
>
> after some research i guess that oscillator hackrf one is not accurate
> .it can should be calibrate?
>
Well. Not much research, then. I'm pretty sure that a HackRF's
oscillator should be just as good as the one of an RTL-dongle. But an
RTL dongle in TV reception mode does automatic frequency correction.
Again, you're probably not configuring the receiving software accordingly
>
> how we can calibrate hackrf one for different
> modulation
>
This question makes no sense. Also, more dots don't add sense.
>
>
>   Actual behaviour
>
> in real world i guess it can not calibrated in frequency.
>
Heading and content don't align. Anyway, real-world receivers always
continously adjust frequency, because in this world, no two oscillators
are the same, physically.
>
>
>   Version information
>
> *Operating system*:
> debian os , gnuradio 3.7.12,linux
>

> why hackrf one not can received ? it has weakness in receiving? weak
> receiving can be related to ppm ?
>
> please help, any idea??? it can be related ADC?HackRFone has poor
> receiving why?
>
Yeah, come on, describe the problems you're having, and what you tried
to solve them.

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

[Discuss-gnuradio] usrp_spectrum_sense.py

[MuratCA77]

The current outputs produced by the usrp_spectrum_sense.py code do not
provide the bin metrics that are required for my application.  The metrics
are detection time, true detection power, the center frequency of the
transmission, the centroid, and transmission bandwidth. It was recommended
to create a second signal processing block chain in a new class similar to
the existing "top_block" which performs the sample rate reduction and bin
metrics computation. This chain would only be called for detections that
pass the threshold test. 

The main idea is that Spectrum Monitoring System sweeps through the full
frequency range at a coarse FFT resolution, picks out frequencies where
something is present, and goes back and does higher-resolution scans of
these regions until a candidate frequency is selected for bin metrics. It
does not have to be in real time. We are using HackRF One. 

I was wondering if I can receive guidance on implementing the main idea in
python.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994.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] usrp_spectrum_sense.py

[Marcus Müller]

Hi Murat,

a few quick comments:

On 23.05.2017 20:24, MuratCA77 wrote:
> The current outputs produced by the usrp_spectrum_sense.py code do not
> provide the bin metrics that are required for my application.
Yeah, usrp_spectrum_sense hasn't aged all that well. I think if I were
to implement that today, it would look totally different internally.
> The metrics are 
> detection time,
that might actually be pretty interesting to implement; as far as I
know, the HackRF currently doesn't support time-stamping (don't know,
though – this might have changed or will be changing).
>  true detection power, 
That's a hard one! You'll need to calibrate your receiver first; none of
the "popular" SDR devices, including USRPs and HackRF, are calibrated
power measurement devices. Thus, you'll need to generate a signal of
interest for a few known powers at every frequency that you want to step
to, or else you won't get a physical power, just digital numbers (which
might or might not, in general the latter, be comparable between
different frequencies!).

> the center frequency of the
> transmission, the centroid,
Good news: for all practical single-carrier systems, transmission
centroid and center frequency usually are the same. If you think about
it, that makes sense: you have finite energy to spend on transmitting,
so you'll use your bandwidth to the fullest extent. From an
information-theoretical point of view: Anything that makes the spectrum
look skewed means there's redundant info that shouldn't be transmitted.
>  and transmission bandwidth. 
You'd first have to define what "bandwidth" is – a definition of
bandwidth that works well for e.g. a given GMSK signal (e.g. 2G) might
be totally inappropriate e.g. for a CDMA signal (3G, WiFi) and might not
be overly helpful in understanding multicarrier waveforms (as OFDM, eg.
4G, WiFi). Also, when you observe an FM audio station for a short time
while the audio source is relatively quiet, you'll see a smaller
bandwidth than midst-song when everything is loud and the frequency
deviation gets large!
So, you'd first have to restrict the types of signals you're looking
for; later, you can implement more cases, but what you want to build is
a fully-fledged signal classificator, and well, those things are a lot
of work, and you'll have to define a reasonable observation time vs.
speed tradeoff to ensure proper detection of the signal you're looking
at whilst keeping the likelihood of simply missing transmissions (by not
scanning over them at all while they're active).

I think you might want to look at https://github.com/gnuradio/gr-inspector

Best regards,
Marcus


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

[Discuss-gnuradio] Making Sure Usrp Sink Center Frequency Changed Before Data Arrives

[Sean Horton]

I have a flowgraph that is supposed to be set up so that the tx frequency
can be changed on the fly. It was originally changed by changing variables,
but I've switched to publishing pmt_t destined for the usrp sink (it didn't
seem to work on the rx side very well, something was buggy). Testing seems
to indicate that the center frequency isn't always changed before the data
is transmitted (in the test I should be sending 20 chunks of data, and I
should be alternating between two frequencies). Is there a way to query the
usrp sink to determine when it has changed it's center frequency? It
doesn't publish a message, or it doesn't look that way after looking at
source.

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

Re: [Discuss-gnuradio] Mixing multiple streams to audio

[Kevin Reid]

On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR  wrote:

> I'm continuing to work on a multi-channel NBFM receiver using the
> polyphase filter.  I have the basic system working, but am hung up on how
> to get audio out of the system; most of my attempts end up either with
> audio underruns, or stalls that result in overruns.
>

You're using only one RF source hardware device, correct?

Even then, *some* amount of overrun/underrun is inevitable because the RF
receiver and the audio output are not using the same clock oscillator, so
the resampling rate you've implemented is not the resampling rate you would
ideally need (which there is no way in GR to actually detect or implement).


> The relevant portion of the flowgraph is attached.  Each channel ends up
> at a 15ksps rate and is fed into a power squelch, then a mult block that's
> used to mute or unmute the audio, then NBFM demod.  The demodulated outputs
> are at 7.5ksps (though I get the same results with 15ksps) and the seven
> channels are added.  Then a rational resample to 48ksps, volume control,
> and audio sink at 48ksps.
>
> I've tried the "gate" param of the power squelch block both off and on,
> and the "OK to block" option of the audio sink in various combinations, but
> I'm not able to get clean audio.
>

"Gate" should be off. What that option does is drop samples. The problem is
that the Add block requires samples from every input to produce an output,
so if any one of the inputs drops samples then eventually your flowgraph
will not be able to make progress because some buffers are overfull and
some are empty.

Any flowgraph that has paths that split (here, polyphase channelizer) and
rejoin (here, add) MUST have exactly the same
input-samples-to-output-samples ratio on all of the paths, or it will
eventually lock up.

"OK to block" does not do very much, but in this type of application it
should be off. This means that if there is an overrun, the audio sink will
discard samples rather than the internal buffers filling up and causing the
RF source block to have to discard them instead; while this is very similar
in principle, it means a higher input-to-output latency. The time to use
"OK to block" is when your source has no clock (e.g. it is a file or an
internal signal source of some sort) so the audio sink has to be
responsible for deciding when it's time to take more samples.


> I'd appreciate any suggestions.  One thing I wonder about is the placement
> of the blocks in the stream; would a different order work better?
>

The ordering should not matter (as long as it is not incorrect in some
other way, of course).


When you have "Gate" off, which type of misbehavior do you get?

Have you confirmed that your sound card/driver actually supports 48 kHz?
What happens if you try a different sample rate?

Have you tried resampling to a rate slightly under or over 48 kHz, as
appropriate? That will help if you actually have a severe clock skew
problem.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Mixing multiple streams to audio

[Marcus Müller]

Hi JOhn,

you mustn't gate=yes in the squelch! The "add" block needs an input
sample on every input to generate one sum sample, and thus, every
squelch that's currently gating (i.e. not generating any samples) will
simply stop the complete flow graph.

The rest looks ok (if you really feed in 15 kHz channels); I'd recommend
doing a few things for debugging:

* replace the receiver block with a null source. You should be getting
silence. If that doesn't work, post whole flow graph.

* Replace the receiver block with a NBFM transmitter (followed by, if
necessary, a "rotator"), so that your generated FM signal ends up in one
of the channels, while the rest should see silence.

* Look at the output of the "add" block with a Qt Time sink or so; you
might be generating amplitudes that clip in the sound card

* Try 44.1 kS/s instead of 48 kS/s

* observe buffer fillage with the control port perf monitor


Cheers,

Marcus


On 23.05.2017 20:31, John Ackermann N8UR wrote:
> Hi --
>
> I'm continuing to work on a multi-channel NBFM receiver using the
> polyphase filter.  I have the basic system working, but am hung up on
> how to get audio out of the system; most of my attempts end up either
> with audio underruns, or stalls that result in overruns.
>
> The relevant portion of the flowgraph is attached.  Each channel ends
> up at a 15ksps rate and is fed into a power squelch, then a mult block
> that's used to mute or unmute the audio, then NBFM demod.  The
> demodulated outputs are at 7.5ksps (though I get the same results with
> 15ksps) and the seven channels are added.  Then a rational resample to
> 48ksps, volume control, and audio sink at 48ksps.
>
> I've tried the "gate" param of the power squelch block both off and
> on, and the "OK to block" option of the audio sink in various
> combinations, but I'm not able to get clean audio.
>
> I'd appreciate any suggestions.  One thing I wonder about is the
> placement of the blocks in the stream; would a different order work
> better?
>
> Thanks for any assistance.
>
> John
>
>
> ___
> 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] Making Sure Usrp Sink Center Frequency Changed Before Data Arrives

[Marcus Müller]

Hi Sean,

with "post", do you mean "send a message to the USRP Sink", or do you
mean "attached a tag to a sample"? You should probably do the latter.

Best regards,

Marcus


On 23.05.2017 20:45, Sean Horton wrote:
> I have a flowgraph that is supposed to be set up so that the tx
> frequency can be changed on the fly. It was originally changed by
> changing variables, but I've switched to publishing pmt_t destined for
> the usrp sink (it didn't seem to work on the rx side very well,
> something was buggy). Testing seems to indicate that the center
> frequency isn't always changed before the data is transmitted (in the
> test I should be sending 20 chunks of data, and I should be
> alternating between two frequencies). Is there a way to query the usrp
> sink to determine when it has changed it's center frequency? It
> doesn't publish a message, or it doesn't look that way after looking
> at source.
>
> -- 
> Sean Horton
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[MuratCA77]

Hello Marcus,

Thank you so much for your guidance. When I tried to close gr-inspector, it
said the following:

"CMake 3.1 or higher is required. You are running version 2.8.12.2"

I was wondering what seems to be the issue. I am running Ubuntu 14.04.

Best,
Murat





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64001.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] Mixing multiple streams to audio

[John Ackermann N8UR]

Hi Marcus and Kevin, and thanks for the info.

I've set all squelch gates off.  In that case, I get good audio if "OK 
to block" in the audio sink is set to "yes" but the latency is awful -- 
3 to 5 seconds!  If "OK to block" is "no", then I get lots of aU and 
unusable audio.


If setting the squelch gates off means that samples are continuously 
sent through the adder to the sink, I don't understand why blocking 
makes the difference, or why the latency builds up so fast.  I'd try 
using 44.1ksps on the sink, but the dropdown doesn't allow that choice.


John

On 05/23/2017 02:51 PM, Kevin Reid wrote:

On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR mailto:j...@febo.com>> wrote:

I'm continuing to work on a multi-channel NBFM receiver using the
polyphase filter.  I have the basic system working, but am hung up
on how to get audio out of the system; most of my attempts end up
either with audio underruns, or stalls that result in overruns.


You're using only one RF source hardware device, correct?

Even then, /some/ amount of overrun/underrun is inevitable because the
RF receiver and the audio output are not using the same clock
oscillator, so the resampling rate you've implemented is not the
resampling rate you would ideally need (which there is no way in GR to
actually detect or implement).


The relevant portion of the flowgraph is attached.  Each channel
ends up at a 15ksps rate and is fed into a power squelch, then a
mult block that's used to mute or unmute the audio, then NBFM
demod.  The demodulated outputs are at 7.5ksps (though I get the
same results with 15ksps) and the seven channels are added.  Then a
rational resample to 48ksps, volume control, and audio sink at 48ksps.

I've tried the "gate" param of the power squelch block both off and
on, and the "OK to block" option of the audio sink in various
combinations, but I'm not able to get clean audio.


"Gate" should be off. What that option does is drop samples. The problem
is that the Add block requires samples from every input to produce an
output, so if any one of the inputs drops samples then eventually your
flowgraph will not be able to make progress because some buffers are
overfull and some are empty.

Any flowgraph that has paths that split (here, polyphase channelizer)
and rejoin (here, add) MUST have exactly the same
input-samples-to-output-samples ratio on all of the paths, or it will
eventually lock up.

"OK to block" does not do very much, but in this type of application it
should be off. This means that if there is an overrun, the audio sink
will discard samples rather than the internal buffers filling up and
causing the RF source block to have to discard them instead; while this
is very similar in principle, it means a higher input-to-output latency.
The time to use "OK to block" is when your source has no clock (e.g. it
is a file or an internal signal source of some sort) so the audio sink
has to be responsible for deciding when it's time to take more samples.


I'd appreciate any suggestions.  One thing I wonder about is the
placement of the blocks in the stream; would a different order work
better?


The ordering should not matter (as long as it is not incorrect in some
other way, of course).


When you have "Gate" off, which type of misbehavior do you get?

Have you confirmed that your sound card/driver actually supports 48 kHz?
What happens if you try a different sample rate?

Have you tried resampling to a rate slightly under or over 48 kHz, as
appropriate? That will help if you actually have a severe clock skew
problem.


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

Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[Kyeong Su Shin]

Hello MuratCA77:

What do you mean by "close gr-inspector"? If you meant building &
installing it, yes, you may have to update your cmake package. Ubuntu 14.04
does come with cmake 2.8.12, which is older than what gr-inspector asks for
(CMakeLists.txt says: cmake_minimum_required(VERSION 3.1) ).

See: https://askubuntu.com/questions/610291/how-to-
install-cmake-3-2-on-ubuntu-14-04 (or alternatively, you can switch to a
newer version of Ubuntu).

Regards,
Kyeong Su Shin

On Tue, May 23, 2017 at 12:24 PM, MuratCA77  wrote:

> Hello Marcus,
>
> Thank you so much for your guidance. When I tried to close gr-inspector, it
> said the following:
>
> "CMake 3.1 or higher is required. You are running version 2.8.12.2"
>
> I was wondering what seems to be the issue. I am running Ubuntu 14.04.
>
> Best,
> Murat
>
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.co
> m/usrp-spectrum-sense-py-tp63994p64001.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] usrp_spectrum_sense.py

[Marcus Müller]

Get a newer Ubuntu.


On 23.05.2017 21:24, MuratCA77 wrote:
> Hello Marcus,
>
> Thank you so much for your guidance. When I tried to close gr-inspector, it
> said the following:
>
> "CMake 3.1 or higher is required. You are running version 2.8.12.2"
>
> I was wondering what seems to be the issue. I am running Ubuntu 14.04.
>
> Best,
> Murat
>
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64001.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] Mixing multiple streams to audio

[Marcus Müller]

Hi John,

3 to 5 seconds doesn't sound all that much considering that you're doing
stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B), that's
2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
buffers between NBFM demod and add, and between add and resampler. In
fact, NBFM demod internally is a hier block (might have more low-rate
buffers); so, that's half a second for these two buffers alone...

In your very specific use case, using a higher sampling rate might make
the problem more manageable. If you'd share the first half of your flow
graph, we could discuss options for that!

Best regards,

Marcus

[1] http://gnuradio.org/blog/buffers


On 23.05.2017 22:04, John Ackermann N8UR wrote:
> Hi Marcus and Kevin, and thanks for the info.
>
> I've set all squelch gates off.  In that case, I get good audio if "OK
> to block" in the audio sink is set to "yes" but the latency is awful
> -- 3 to 5 seconds!  If "OK to block" is "no", then I get lots of aU
> and unusable audio.
>
> If setting the squelch gates off means that samples are continuously
> sent through the adder to the sink, I don't understand why blocking
> makes the difference, or why the latency builds up so fast.  I'd try
> using 44.1ksps on the sink, but the dropdown doesn't allow that choice.
>
> John
> 
> On 05/23/2017 02:51 PM, Kevin Reid wrote:
>> On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR > > wrote:
>>
>> I'm continuing to work on a multi-channel NBFM receiver using the
>> polyphase filter.  I have the basic system working, but am hung up
>> on how to get audio out of the system; most of my attempts end up
>> either with audio underruns, or stalls that result in overruns.
>>
>>
>> You're using only one RF source hardware device, correct?
>>
>> Even then, /some/ amount of overrun/underrun is inevitable because the
>> RF receiver and the audio output are not using the same clock
>> oscillator, so the resampling rate you've implemented is not the
>> resampling rate you would ideally need (which there is no way in GR to
>> actually detect or implement).
>>
>>
>> The relevant portion of the flowgraph is attached.  Each channel
>> ends up at a 15ksps rate and is fed into a power squelch, then a
>> mult block that's used to mute or unmute the audio, then NBFM
>> demod.  The demodulated outputs are at 7.5ksps (though I get the
>> same results with 15ksps) and the seven channels are added.  Then a
>> rational resample to 48ksps, volume control, and audio sink at
>> 48ksps.
>>
>> I've tried the "gate" param of the power squelch block both off and
>> on, and the "OK to block" option of the audio sink in various
>> combinations, but I'm not able to get clean audio.
>>
>>
>> "Gate" should be off. What that option does is drop samples. The problem
>> is that the Add block requires samples from every input to produce an
>> output, so if any one of the inputs drops samples then eventually your
>> flowgraph will not be able to make progress because some buffers are
>> overfull and some are empty.
>>
>> Any flowgraph that has paths that split (here, polyphase channelizer)
>> and rejoin (here, add) MUST have exactly the same
>> input-samples-to-output-samples ratio on all of the paths, or it will
>> eventually lock up.
>>
>> "OK to block" does not do very much, but in this type of application it
>> should be off. This means that if there is an overrun, the audio sink
>> will discard samples rather than the internal buffers filling up and
>> causing the RF source block to have to discard them instead; while this
>> is very similar in principle, it means a higher input-to-output latency.
>> The time to use "OK to block" is when your source has no clock (e.g. it
>> is a file or an internal signal source of some sort) so the audio sink
>> has to be responsible for deciding when it's time to take more samples.
>>
>>
>> I'd appreciate any suggestions.  One thing I wonder about is the
>> placement of the blocks in the stream; would a different order work
>> better?
>>
>>
>> The ordering should not matter (as long as it is not incorrect in some
>> other way, of course).
>>
>>
>> When you have "Gate" off, which type of misbehavior do you get?
>>
>> Have you confirmed that your sound card/driver actually supports 48 kHz?
>> What happens if you try a different sample rate?
>>
>> Have you tried resampling to a rate slightly under or over 48 kHz, as
>> appropriate? That will help if you actually have a severe clock skew
>> problem.
>
> ___
> 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] Mixing multiple streams to audio

[John Ackermann N8UR]

Interesting point, Marcus.  I'll post the complete flowgraph tomorrow when I am 
at my development machine.  I did revert the audio rate out of the demod to 
15ksps and that helped somewhat.  So maybe that can go further.

On May 23, 2017, 7:18 PM, at 7:18 PM, "Marcus Müller" 
 wrote:
>Hi John,
>
>3 to 5 seconds doesn't sound all that much considering that you're
>doing
>stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
>between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B), that's
>2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
>buffers between NBFM demod and add, and between add and resampler. In
>fact, NBFM demod internally is a hier block (might have more low-rate
>buffers); so, that's half a second for these two buffers alone...
>
>In your very specific use case, using a higher sampling rate might make
>the problem more manageable. If you'd share the first half of your flow
>graph, we could discuss options for that!
>
>Best regards,
>
>Marcus
>
>[1] http://gnuradio.org/blog/buffers
>
>
>On 23.05.2017 22:04, John Ackermann N8UR wrote:
>> Hi Marcus and Kevin, and thanks for the info.
>>
>> I've set all squelch gates off.  In that case, I get good audio if
>"OK
>> to block" in the audio sink is set to "yes" but the latency is awful
>> -- 3 to 5 seconds!  If "OK to block" is "no", then I get lots of aU
>> and unusable audio.
>>
>> If setting the squelch gates off means that samples are continuously
>> sent through the adder to the sink, I don't understand why blocking
>> makes the difference, or why the latency builds up so fast.  I'd try
>> using 44.1ksps on the sink, but the dropdown doesn't allow that
>choice.
>>
>> John
>> 
>> On 05/23/2017 02:51 PM, Kevin Reid wrote:
>>> On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR >> > wrote:
>>>
>>> I'm continuing to work on a multi-channel NBFM receiver using
>the
>>> polyphase filter.  I have the basic system working, but am hung
>up
>>> on how to get audio out of the system; most of my attempts end
>up
>>> either with audio underruns, or stalls that result in overruns.
>>>
>>>
>>> You're using only one RF source hardware device, correct?
>>>
>>> Even then, /some/ amount of overrun/underrun is inevitable because
>the
>>> RF receiver and the audio output are not using the same clock
>>> oscillator, so the resampling rate you've implemented is not the
>>> resampling rate you would ideally need (which there is no way in GR
>to
>>> actually detect or implement).
>>>
>>>
>>> The relevant portion of the flowgraph is attached.  Each channel
>>> ends up at a 15ksps rate and is fed into a power squelch, then a
>>> mult block that's used to mute or unmute the audio, then NBFM
>>> demod.  The demodulated outputs are at 7.5ksps (though I get the
>>> same results with 15ksps) and the seven channels are added.
>Then a
>>> rational resample to 48ksps, volume control, and audio sink at
>>> 48ksps.
>>>
>>> I've tried the "gate" param of the power squelch block both off
>and
>>> on, and the "OK to block" option of the audio sink in various
>>> combinations, but I'm not able to get clean audio.
>>>
>>>
>>> "Gate" should be off. What that option does is drop samples. The
>problem
>>> is that the Add block requires samples from every input to produce
>an
>>> output, so if any one of the inputs drops samples then eventually
>your
>>> flowgraph will not be able to make progress because some buffers are
>>> overfull and some are empty.
>>>
>>> Any flowgraph that has paths that split (here, polyphase
>channelizer)
>>> and rejoin (here, add) MUST have exactly the same
>>> input-samples-to-output-samples ratio on all of the paths, or it
>will
>>> eventually lock up.
>>>
>>> "OK to block" does not do very much, but in this type of application
>it
>>> should be off. This means that if there is an overrun, the audio
>sink
>>> will discard samples rather than the internal buffers filling up and
>>> causing the RF source block to have to discard them instead; while
>this
>>> is very similar in principle, it means a higher input-to-output
>latency.
>>> The time to use "OK to block" is when your source has no clock (e.g.
>it
>>> is a file or an internal signal source of some sort) so the audio
>sink
>>> has to be responsible for deciding when it's time to take more
>samples.
>>>
>>>
>>> I'd appreciate any suggestions.  One thing I wonder about is the
>>> placement of the blocks in the stream; would a different order
>work
>>> better?
>>>
>>>
>>> The ordering should not matter (as long as it is not incorrect in
>some
>>> other way, of course).
>>>
>>>
>>> When you have "Gate" off, which type of misbehavior do you get?
>>>
>>> Have you confirmed that your sound card/driver actually supports 48
>kHz?
>>> What happens if you try a different sample rate?
>>>
>>> Have you tried resampling to a rate slightly under or over 48 kHz,
>as
>>> appropriate? That will he

[Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

[Pavan Yedavalli]

Hi,

I successfully followed the instructions on github to install pybombs,
cloning the directory and then running

sudo python setup.py install

Everything successfully finished:

PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
installing binary packages:
Install tree:
|
\- gnuradio
   |
   +- uhd
   |
   \- apache-thrift
PyBOMBS.install_manager - INFO - Phase 2: Recursively installing
source packages to prefix:
PyBOMBS.install_manager - INFO - Installing package: apache-thrift
Cloning: (100%)
[===]
Cloning: (100%)
[===]
Configuring: (100%)
[===]
Building:(100%)
[===]
Installing:  (100%)
[===]
PyBOMBS.install_manager - INFO - Installation successful.
PyBOMBS.install_manager - INFO - Installing package: uhd
Cloning: (100%)
[===]
Configuring: (100%)
[===]
Building:(100%)
[===]
Installing:  (100%)
[===]
PyBOMBS.install_manager - INFO - Installation successful.
PyBOMBS.install_manager - INFO - Installing package: gnuradio
Cloning: (100%)
[===]
Configuring: (100%)
[===]
Building:(100%)
[===]
Installing:  (100%)
[===]
PyBOMBS.install_manager - INFO - Installation successful.
pavan@pavan-ThinkPad-T430:~/pybombs$ source ~/prefix/setup_env.sh

But then when I run gnuradio-companion, it gives me the following error:

pavan@pavan-ThinkPad-T430:~/pybombs$ gnuradio-companion
Traceback (most recent call last):
  File "/home/pavan/prefix/bin/gnuradio-companion", line 99, in 
run_main()
  File "/home/pavan/prefix/bin/gnuradio-companion", line 87, in run_main
from gnuradio.grc.main import main
ImportError: No module named main

Why is it not able to find the "main" module? It seemed like
everything was installed correctly. I did this install multiple times
after removing the pybombs directory and doing it again, but it
continues to give this same error. I don't really know where to go
from here.

I saw that Mike Willis had a similar problem a bit ago and he said he
found random files in

/usr/lib/python2.7/dist-packages/gnuradio/

Is there a way I can clean up/uninstall everything and just start from
scratch with the correct steps also (I'm using Ubuntu 14.04)? I was
hoping that all the steps in the pybombs installation would make
everything work correctly. Please let me know.
Thanks so much for the help.


--

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

Re: [Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

[Kyeong Su Shin]

Hello Pavan Yedavalli:

I don't use PyBOMBS so maybe I am wrong, but that sounds like that path
variables (for bash) are not correctly updated to include the path to the
GNU Radio libraries OR you have already installed an another version of GNU
Radio (using manual build or apt-get) and is conflicting with your PyBomBs
installations.

A few things to check:

1.Did you make sure that your computer does not have an older version of
GNU Radio?
2.Did you try *pybombs run gnuradio-companion* instead?
3.Did you try printing out path variables (PYTHONPATH, PATH,
LD_LIBRARY_PATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH ) after running "source
~/prefix/setup_env.sh"? Does it look correct? (Note: you have to run "source
~/prefix/setup_env.sh" every time you open your terminal.)

If you don't want to build it using PyBOMBS, you can just install one that
is on the official Ubuntu repo (sudo apt-get install gnuradio-dev). The one
that comes with Ubuntu 14.04 is pretty outdated, though. (Maybe you can
dist-upgrade to Ubuntu 16.04 or later, which comes with a more recent
vintage of GNU Radio).

Alternatively, you can do a full manual build by downloading dependencies
and do a full manual build following instructions at
https://github.com/gnuradio/gnuradio . Note that this can be a somewhat
annoying process, and that is what PyBOMBS is attempting to solve.
(Somewhat outdated list of dependencies:
https://wiki.gnuradio.org/index.php/UbuntuInstall . Also, please note that
you may have to do "git clone --recursive
https://github.com/gnuradio/gnuradio.git"; instead of "git clone
https://github.com/gnuradio/gnuradio.git"; since the latter command may not
clone source codes for Volks.)

Finally, you can simply use GNU Radio live image.

Regards,
Kyeong Su Shin

On Tue, May 23, 2017 at 6:22 PM, Pavan Yedavalli 
wrote:

> Hi,
>
> I successfully followed the instructions on github to install pybombs,
> cloning the directory and then running
>
> sudo python setup.py install
>
> Everything successfully finished:
>
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and 
> installing binary packages:
> Install tree:
> |
> \- gnuradio
>|
>+- uhd
>|
>\- apache-thrift
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source 
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: apache-thrift
> Cloning: (100%) 
> [===]
> Cloning: (100%) 
> [===]
> Configuring: (100%) 
> [===]
> Building:(100%) 
> [===]
> Installing:  (100%) 
> [===]
> PyBOMBS.install_manager - INFO - Installation successful.
> PyBOMBS.install_manager - INFO - Installing package: uhd
> Cloning: (100%) 
> [===]
> Configuring: (100%) 
> [===]
> Building:(100%) 
> [===]
> Installing:  (100%) 
> [===]
> PyBOMBS.install_manager - INFO - Installation successful.
> PyBOMBS.install_manager - INFO - Installing package: gnuradio
> Cloning: (100%) 
> [===]
> Configuring: (100%) 
> [===]
> Building:(100%) 
> [===]
> Installing:  (100%) 
> [===]
> PyBOMBS.install_manager - INFO - Installation successful.
> pavan@pavan-ThinkPad-T430:~/pybombs$ source ~/prefix/setup_env.sh
>
> But then when I run gnuradio-companion, it gives me the following error:
>
> pavan@pav

[Discuss-gnuradio] Handling custom blocks in GRC

[vipinsharma]

Hello,

My application is written in Matlab. I have converted the Matlab code to C++ 
code using Matlab Coder. The original Matlab code has top level function, say 
A_Func which calls multiple other functions, say B_Func and C_Func. Matlab 
Coder dumps out three C++ functions; one each for A_Func, B_Func and C_Func. 

I used gr_modtool utility to bring these C++ functions into GRC gui. I am able 
see these custom blocks in the GRC gui and instantiate them as well. 

The question I have is this: A_Func calls B_Func and C_Func. I don’t think I 
can instantiate the three custom blocks directly in one GRC flow-graph. What 
will happen to the function call made in A_Func for B_Func when A_Func custom 
block is kicked off for execution by the GRC scheduler? Is there any way in GRC 
to define hierarchical custom blocks? 

One way to solve this issue is the have Matlab Coder dump all code in one C++ 
file and then simply create one giant custom block to instantiate in GRC gui. 
Problem is that I won’t be able to debug in GRC gui very well (granularity of 
probe points would be severally limited). 

What is the best way to go about this?

Vipin

Sent from Mail for Windows 10

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

[Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

[Pavan Yedavalli]

It looks like it was a permission problem to open gnuradio-companion. If I
run "sudo gnuradio-companion," it will open correctly.

Having said that, I am seeing another problem of "No module named tutorial"
when running python grc flowgraphs.

On a previous computer that successfully ran the same program, I noticed
that /usr/local/lib/python2.7/dist-packages contained:

pavan@pavanlabdesktop:/usr/local/lib/python2.7/dist-packages$ ls
easy-install.pthPyYAML-3.11-py2.7-linux-x86_64.egg
future-0.15.2-py2.7.egg setuptools.pth
gnuradiothrift
grc_gnuradiothrift-0.9.3-py2.7.egg-info
osmosdr tutorial
pmt volk_modtool
PyBOMBS-2.1.0rc1-py2.7.egg

The one that I am currently using sees the module problem, and only
contains the following in /usr/local/lib/python2.7/dist-packages:

pavan@pavan-ThinkPad-T430:/usr/local/lib/python2.7/dist-packages$ ls
easy-install.pth  future-0.16.0-py2.7.egg  PyBOMBS-2.3.1a0-py2.7.egg
PyYAML-3.12-py2.7-linux-x86_64.egg  setuptools.pth

I don't know what was the difference in installations or how to make it
work like the previous one and contain all of the proper libraries. Please
let me know. Thank you so much.


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

Re: [Discuss-gnuradio] Trouble with gnuradio-companion after pybombs installation

[Cinaed Simson]

On 05/23/2017 10:38 PM, Pavan Yedavalli wrote:
> It looks like it was a permission problem to open gnuradio-companion. If
> I run "sudo gnuradio-companion," it will open correctly.
> 
> Having said that, I am seeing another problem of "No module named
> tutorial" when running python grc flowgraphs.
> 
> On a previous computer that successfully ran the same program, I noticed
> that /usr/local/lib/python2.7/dist-packages contained:
> 
> pavan@pavanlabdesktop:/usr/local/lib/python2.7/dist-packages$ ls
> easy-install.pthPyYAML-3.11-py2.7-linux-x86_64.egg
> future-0.15.2-py2.7.egg setuptools.pth
> gnuradiothrift
> grc_gnuradiothrift-0.9.3-py2.7.egg-info
> osmosdr tutorial
> pmt volk_modtool
> PyBOMBS-2.1.0rc1-py2.7.egg
> 
> The one that I am currently using sees the module problem, and only
> contains the following in /usr/local/lib/python2.7/dist-packages:
> 
> pavan@pavan-ThinkPad-T430:/usr/local/lib/python2.7/dist-packages$ ls
> easy-install.pth  future-0.16.0-py2.7.egg  PyBOMBS-2.3.1a0-py2.7.egg 
> PyYAML-3.12-py2.7-linux-x86_64.egg  setuptools.pth
> 
> I don't know what was the difference in installations or how to make it
> work like the previous one and contain all of the proper libraries.
> Please let me know. Thank you so much.

Didn't you install gnuradio in ~/prefix?

If true, then that's were you should be looking:

  ~/prefix/lib/python2.7/dist-package

Also, the osmosdr and tutorial are OOT (Out Of Tree) modules so I think
you need to install those with pybombs too if you didn't do it when you
installed gnuradio.

-- Cinaed

> 
> 
> -- 
> Pavan
> 
> 
> ___
> 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] Building gnuradio master fails

[Cinaed Simson]

On 05/23/2017 02:03 AM, li...@lazygranch.com wrote:
> Full cmake output at 
> https://pastebin.com/4uwwZbcW
> 
> Here is the relevant portion of the cmake output. Everything is found.
> Now I suppose I could downgrade the libraries if that helps.
> 
> -- Checking for module 'gsl >= 1.10'
> --   Found gsl , version 2.3
> -- Found GSL: gsl;gslcblas;m  

gsl-2.3 might not be supported. I would start a new thread "suse and
gsl-2.3". See if anyone else is using gsl-2.3

-- Cinaed

> --
> -- Configuring gr-fec support...
> --   Dependency ENABLE_VOLK = ON
> --   Dependency Boost_FOUND = 1
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Enabling gr-fec support.
> --   Override with -DENABLE_GR_FEC=ON/OFF
> 
> 
> 
> On Mon, 22 May 2017 23:03:15 -0700
> Cinaed Simson  wrote:
> 
>> On 05/21/2017 08:02 PM, li...@lazygranch.com wrote:
>>> It seems opensuse runs an old rev of gsl. Here are the relevant file
>>> names and revs:
>>>
>>> gsl 1.16-74
>>> gsl-devel 2.3-9.1
>>> libgsl19 2.3-9.1
>>> libgslblas0 2.3-9.1
>>> python-pygsl 0.9.5-2.30
>>> python-pygsl-devel 0.9.5-2.30  
>>
>> I'm running release version 3.7.11 with gsl-1.16.
>>
>> Actually, now that I think about it, I would be suprised if it built
>> gr-fec without gsl.
>>
>> It may not a be gsl problem - your mileage may vary depending upon the
>> version of gnuradio you're running.
>>
>> Create a new build directory and run cmake - it will tell you if
>> there's a problem with gsl.
>>
>> -- Cinaed
>>
>>>
>>> Using the science repo, I can upgrade gsl to rev 2.3. Yast will
>>> have to deinstall a number of programs such as krita and more
>>> significant, inkscape. I can build what breaks from source if the
>>> rev of gsl is the problem.
>>>
>>>
>>> On Sun, 21 May 2017 18:08:36 -0700
>>> li...@lazygranch.com wrote:
>>>   

 "Latest commit 0e32fca 4 days ago." That comes right off of github.
 https://github.com/gnuradio/gnuradio

 When I'm on that machine, I will research what I have for the gnu
 scientific library. I have it, but don't know if it is up to date.


   Original Message  
 From: Cinaed Simson
 Sent: Sunday, May 21, 2017 5:52 PM
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Building gnuradio master fails

 On 05/21/2017 01:27 AM, li...@lazygranch.com wrote:  
> FWIW, I just compiled 0e32fca on opensuse. It builds just fine,
> but I'm failing all the polar tests. Yeah I have scipy installed.
> I'll start a new thread on that when I've totally given up
> debugging. But the code on that rev is buildable on my PC.  

 I have no idea what 0e32fca is - looks like an arbitrary hex tag -
 but if the tests in gr-fec are failing it's most likely because
 development version of gsl wasn't installed - or it's the wrong
 version.

 Can you simply install gsl and be on your merry way? Unlikely.

 -- Cinaed

  
>
>
> On Sun, 21 May 2017 08:13:28 +0200
> "Ralph A. Schmid, dk5ras"  wrote:
>  
>> This is also my experience, I made exactly this, deleting the
>> build dir, make a new one, fresh cmake, and so on.
>>
>> Ralph.
>>
>>  
>>> -Original Message-
>>> From: li...@lazygranch.com [mailto:li...@lazygranch.com]
>>> Sent: Saturday, 20 May, 2017 20:50
>>> To: Ralph A. Schmid, dk5ras; 'Kostis Triantafyllakis';
>>> discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio]
>>> Building gnuradio master fails
>>>
>>> Be that as it may, I have noticed that the first "cmake../",
>>> that is a fresh directory, produces different output than a
>>> "make clean" followed by "cmake ../". ‎ I've made it a point to
>>> do a "rm -r build".
>>>
>>> By output, I means whatever is written to standard output. I
>>> don't know if a fresh directly effects the actual build or not.
>>>
>>> Original Message
>>> From: Ralph A. Schmid, dk5ras
>>> Sent: Saturday, May 20, 2017 11:32 AM
>>> To: 'Kostis Triantafyllakis'; discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
>>>
>>> Hi,
>>>
>>> Forgot to mention that of course I already did so - with no
>>> success...
>>>
>>> Ralph.
>>>  
 -Original Message-
 From: Kostis Triantafyllakis [mailto:ctri...@csd.uoc.gr]
 Sent: Saturday, 20 May, 2017 18:19
 To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Building gnuradio master fails

 Hello,

 Cleaning (or even deleting the whole build directory) before
 rebuilding, had helped me in similar cases.
 Maybe you could give it a try

 Best,
 Kostis


 On 05/20/2017 06:58 PM, Ralph A. Schmid, dk5ras wrote:   
> Hi,
>
> on a Kubunt

[Discuss-gnuradio] CC Decoder with punctured code = errors

[Justin Hamilton]

Hi everyone,

Is it possible to modify the *traceback depth* of the built-in *CC Decoder
Definition*? It appears unable to recover errors I have introduced during
puncturing/depuncturing, returning values with bit errors still present.

I am trying to decode a PDU I originally convolutionally encoded using the *FEC
Async Encoder* block with the default 1/2 rate, K=7, 79/109 *CC Encoder
Definition* in 'terminated mode'. I then perform async puncturing using a
custom block I wrote to achieve 2/3 and 3/4 code rates, followed by the
corresponding async depuncturing block, which inserts zeroes in previously
punctured positions. I then attempt to decode the depunctured code using
the *FEC Async Decoder *block with the default 1/2 rate, K=7, 79/109 *CC
Decoder Definition* in 'terminated mode'.

Without puncturing (rate = 1/2) decoding works perfectly. I have confirmed
the puncture/depuncture behaviour is correct, so it appears that the
decoder just isn't looking back far enough when performing Viterbi
decoding. I haven't been able to find an obvious way to modify the
decoder's traceback depth... *SSE2 Viterbi* decoding methods like that used
in *DVB-T* and *802.11* actually already modify their traceback depth to
accommodate puncturing.

Anyone have any advice? Ideally I'd make the default cc encoders/decoders
work since they perform the necessary flushing of bits for fixed length
packets, rather than modifying the SSE2 versions to do the same.

Big thanks in advance for any help!

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

Re: [Discuss-gnuradio] Handling custom blocks in GRC

[Moritz Luca Schmid]

Hi Vipin,

The question I have is this: A_Func calls B_Func and C_Func. I don’t 
think I can instantiate the three custom blocks directly in one GRC 
flow-graph. What will happen to the function call made in A_Func for 
B_Func when A_Func custom block is kicked off for execution by the GRC 
scheduler? Is there any way in GRC to define hierarchical custom blocks?


There are hierarchical blocks in GNU Radio, but only for python. If your 
A_Func logic is relatively straight forward calling the other functions, 
you can try create a python hier block (you can do this with gr_modtool 
as well). But if the function calls don't relate to the data flow, it 
makes no sense to create different blocks for each function in my 
opinion. Remember that a GR block should fulfill one logical signal 
processing step. If your functions separately don't do that, defining 
multiple methods in your class of the block is better way to do it.


One way to solve this issue is the have Matlab Coder dump all code in 
one C++ file and then simply create one giant custom block to 
instantiate in GRC gui. Problem is that I won’t be able to debug in 
GRC gui very well (granularity of probe points would be severally 
limited).


Anyway, I think it depends on the structure and purpose of your 
different functions. Are they each executing a signal processing step 
themselves or is only the ensemble of the three functions one logical 
signal processing. In the latter case I would implement the three 
functions in one block.



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