Re: [Discuss-gnuradio] pybombs error

[Mostafa Alizadeh]

Hi Nathan,

I think the package is going to be installed isn't "python-qwt5-qt4". The
folder location of the package is going to be installed by pubombs is: "
/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5". I tried to find an
installation help for this package and I found it (in the attachment).
The installation configuration is returned with an error which doesn't lead
to produce a "make" file for the installation!
I wonder why? Please help me. I stranding on it for a while! :(

Best,
Mostafa



On Fri, Oct 17, 2014 at 12:43 PM, West, Nathan 
wrote:

> I'm not sure what's wrong here, but it should be trying to install a
> deb called python-qwt5-qt4, not pyqwt5. Perhaps run an apt-get update
> and try again. The optimal solution is to find out if this is a bug in
> pybombs or your setup and send a patch if it applies to others.
> Otherwise you can get around this by installing python-qwt5-qt4
> yourself and then use pybombs config to tell pybombs you already have
> pyqwt5 installed.
>
> On Fri, Oct 17, 2014 at 1:37 AM, Mostafa Alizadeh
>  wrote:
> > Hello guys,
> >
> > I still trying to install GNURadio on debian 7.6 i86, but there is a
> problem
> > with installing 'pyqwt5' package with pybombs! The following error is
> > appeared:
> >
> > packages to install: ['pyqwt5', 'mcpp', 'db48', 'ice', 'gnuradio']
> > install called (pyqwt5)
> > install type priority: ['deb', 'src']
> > install deb called (pyqwt5)
> > deb is not available locally
> > check remote repositories...
> > install src called (pyqwt5)
> > state = configure
> > Current step: (pyqwt5 :: make)
> > make
> > ('\nmake -j4\n', '\nmake -j$makewidth\n')
> > ('\nmake -j4\n', '\nmake -j4\n')
> > bash exec (/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5/configure)::
> > make -j4
> >
> > make: *** No targets specified and no makefile found.  Stop.
> > ERROR:root:PyBOMBS Make step failed for package (pyqwt5) please see bash
> > output above for a reason (hint: look for the word Error)
> >
> > What I should do? Please help me :(
> >
> > Best,
> > Mostafa
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>



-- 
***
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
***
Title: Installation — PyQwt v5.2.0 documentation



  
  

  Navigation
  

  index

  modules |

  next |

  previous |
PyQwt v5.2.0 documentation » 
  
  


  

  

  
Installation¶

Source Code Installation¶

Build Prerequisites¶
Recommended build prerequisites for PyQwt-5.2.0 are:

Python, version 2.6.x and 2.5.x are
supported.
Qt, version 4.5.x, 4.4.x,
4.3.x, and 3.3.x  are supported.
SIP,
version 4.8.x and 4.7.x (x > 3) are supported.
PyQt
for Mac OS X, Windows, and/or X11, version 4.5.x, 4.4.x, 4.3.x,
3.18.x, and 3.17.x are supported.
optionally NumPy, version 1.3.x,
1.2.x, and 1.1.x are supported.
optionally Qwt, version 5.2.x,
5.1.x, and 5.0.x are supported.

The source package
PyQwt-5.2.0.tar.gz
contains a snapshot of the Qwt-5.2 subversion bug fix branch which may
fix some bugs in Qwt-5.2.0.
I recommend to compile and link the bug fix branch statically into PyQwt.
To exploit the full power of PyQwt, you should install at least one of
the numerical Python extensions:

NumPy
numarray
Numeric

and built PyQwt with support for the numerical Python extension(s) of
your choice.  However, only NumPy is actively developed and numarray and
Numeric are deprecated.
PyQwt-5.2.0 and recent versions of the numerical Python extensions support
the N-D array interface
protocol.  Therefore, PyQwt supports those extensions, even if they have not
been installed when PyQwt has been built. In this case, the functionality is
somewhat reduced, since conversion from an QImage to a Numerical
Python array is not supported.


Installation¶
The installation procedure consists of three steps:

Unpack PyQwt-5.2.0.tar.gz.

Invoke the following commands to build PyQwt-5.2.0 for Qt-4:
cd PyQwt-5.2.0
cd configure
python configure.py -Q ../qwt-5.2
make
make install

or invoke the commands to build PyQwt-5.2.0 for Qt-3:
cd PyQwt-5.2.0
cd configure
python configure.py -3 -Q ../qwt-5.2
make
make install

This assumes that the correct Python interpreter is on your path. Replace
make by nmake, if you use Microsoft Visual C++.
The commands build PyQwt against the included Qwt subversion snapshot and
install PyQwt.
Test the installation by playing with the example programs.

Fine tune (optional):

to use a Qwt library already installed on your system invoke

[Discuss-gnuradio] [coproc] Next WG Call Time

[Douglas Geiger]

I'd like to setup another Co-Processors WG call in the next couple of weeks
- any one interested in attending should vote on the date/time at:
http://whenisgood.net/pinanwe

Somewhere in the Oct. 27 - 31 date range will work best for me. Note that
you need to select your local timezone (e.g. I'll be in the US Eastern TZ).

Also - if there are items you'd like to discuss during the call please drop
me a note.

 Doug

-- 
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gettin data out from GRC to C++ or java?

[Ernest Szczepaniak]

Thanks for those tips.

Matlab can handle 20M samples due to receiver object, which is buffering
data, and than sending it to Matlab. My receiver is able to demodulate
around 5x802.11 frames per second but i want something more faster.

So i can use UHD driver in C++ enviroment directly right? Sorry for newbie
question, but im quite new to sdr platform :D

Best



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Gettin-data-out-from-GRC-to-C-or-java-tp50824p50898.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] Works with GR 3.6, breaks with 3.7

[John Malsbury]

The good news is.  the GFSK block doesn't do anything specific to Gaussian
FSK.  So I guess tha tall works out =)

You're outputs might be more illustrative if you rebuild it in from the
blocks actually inside the GFSK demod block:

quad demod > clock recovery -> slicer

On Fri, Oct 17, 2014 at 12:33 PM, Luke Berndt  wrote:

> It actually looks like the control channel for Motorola SmartNet is FSK: "On
> the control (data) channel the base station transmits 84 bits frames at
> 3600 bit/s with direct frequency modulation of the carrier using Frequency
> Shift Keying (FSK). "
>
> I will at least see if I can get something that looks right out the other
> side. Would it be best to use one of the GFSK examples in gr-digital?
>
> On Fri, Oct 17, 2014 at 10:37 AM, John Malsbury <
> jmalsbury.perso...@gmail.com> wrote:
>
>> Also, my understanding for the PLL blocks were that they were ideal for
>> "strong carrier" signals like AM.  When I say strong carrier i mean a
>> signal that has an obvious carrier which isn't "hidden" under modulation..
>>
>> Anyway, the GMSK block might be a good place to start.
>>
>> -John
>>
>> On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury <
>> jmalsbury.perso...@gmail.com> wrote:
>>
>>> It doesn't have frequency correction - I can probably follow up with
>>> some ideas on how to implement that part.  But the GMSK demod might do OK
>>> for you initially.  It doesn't do anything intelligent to deal with the
>>> data shaping - its just a non-coherent slicer.
>>>
>>> If you want to design in GRC but keep your top-level application as is,
>>> you can use a hier block.  You can also use a command line parameter or
>>> other mechanism to select your demodulator at start-time for easy
>>> comparisons.
>>>
>>> [typed one handed.. my daughter has my other and]
>>>
>>> -John
>>>
>>> On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt 
>>> wrote:
>>>
 Thanks for looking into it! To be honest, I am not really good at RF. I
 based my code off the python code in gr-smartnet. The fsk-demod python file
 is here:
 https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py

 It is quite possible that it just happened to work because of an error
 that got patched in Gr 3.7.

 Are there some good examples for GMSK/FSK demodulation that I could
 borrow from instead?

 Recreating this in GRC sounds like a great idea so I can scope along
 the way. I will give that a try next.

 Thanks again for the pointers, fresh eyes are really helpful when you
 have been staring at it for so long.

  - Luke

 On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun 
 wrote:

> On 10/17/2014 08:28 AM, John Malsbury wrote:
> > Also also, is the Band-Edge FLL ideal for GMSK?  My possibly,
> incorrect
> > understanding of that block is that it was more ideal for PAM with
> > common RRC.
>
> For the record: It might work coincidentally because of the rolloff-y
> shape of GMSK, but it's derived for and designed for common PAM/RRC, as
> John says and I wouldn't recommend it for anything else.
> To look up the math, I suggest Harris' works.
>
>
>

 ___
 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] Works with GR 3.6, breaks with 3.7

[Luke Berndt]

It actually looks like the control channel for Motorola SmartNet is FSK: "On
the control (data) channel the base station transmits 84 bits frames at
3600 bit/s with direct frequency modulation of the carrier using Frequency
Shift Keying (FSK). "

I will at least see if I can get something that looks right out the other
side. Would it be best to use one of the GFSK examples in gr-digital?

On Fri, Oct 17, 2014 at 10:37 AM, John Malsbury <
jmalsbury.perso...@gmail.com> wrote:

> Also, my understanding for the PLL blocks were that they were ideal for
> "strong carrier" signals like AM.  When I say strong carrier i mean a
> signal that has an obvious carrier which isn't "hidden" under modulation..
>
> Anyway, the GMSK block might be a good place to start.
>
> -John
>
> On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury <
> jmalsbury.perso...@gmail.com> wrote:
>
>> It doesn't have frequency correction - I can probably follow up with some
>> ideas on how to implement that part.  But the GMSK demod might do OK for
>> you initially.  It doesn't do anything intelligent to deal with the data
>> shaping - its just a non-coherent slicer.
>>
>> If you want to design in GRC but keep your top-level application as is,
>> you can use a hier block.  You can also use a command line parameter or
>> other mechanism to select your demodulator at start-time for easy
>> comparisons.
>>
>> [typed one handed.. my daughter has my other and]
>>
>> -John
>>
>> On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt  wrote:
>>
>>> Thanks for looking into it! To be honest, I am not really good at RF. I
>>> based my code off the python code in gr-smartnet. The fsk-demod python file
>>> is here:
>>> https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py
>>>
>>> It is quite possible that it just happened to work because of an error
>>> that got patched in Gr 3.7.
>>>
>>> Are there some good examples for GMSK/FSK demodulation that I could
>>> borrow from instead?
>>>
>>> Recreating this in GRC sounds like a great idea so I can scope along the
>>> way. I will give that a try next.
>>>
>>> Thanks again for the pointers, fresh eyes are really helpful when you
>>> have been staring at it for so long.
>>>
>>>  - Luke
>>>
>>> On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun 
>>> wrote:
>>>
 On 10/17/2014 08:28 AM, John Malsbury wrote:
 > Also also, is the Band-Edge FLL ideal for GMSK?  My possibly,
 incorrect
 > understanding of that block is that it was more ideal for PAM with
 > common RRC.

 For the record: It might work coincidentally because of the rolloff-y
 shape of GMSK, but it's derived for and designed for common PAM/RRC, as
 John says and I wouldn't recommend it for anything else.
 To look up the math, I suggest Harris' works.



>>>
>>> ___
>>> 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] Source Block - Flow Control

[Matt Ettus]

You'll probably want to make a block to do the padding, or mux in zeros.

Matt

On Thu, Oct 16, 2014 at 3:00 PM, David Halls 
wrote:

>  Thanks Matt. is this likely to be the cause of the Us at the beginning?
> How can I pad simply in GNU radio? can i add padding to every burst? if so
> that seems straightforward. I can just mux some zeros in.
>
>  Also should the padding be included in the burst length?
>
>
>  Original message 
> From: Matt Ettus
> Date:2014/10/16 22:54 (GMT+00:00)
> To: David Halls
> Cc: John Malsbury ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> On TX, if you need your first sample to be valid and everything settled in
> the radio, you should zero pad ahead of it.  If you need your last sample
> to go out clean, you should zero pad after it.  In both cases, a few
> microseconds worth is usually fine.  This flushes buffers and filters, but
> also gives physical devices like antenna switches to settle.
>
>  Matt
>
> On Thu, Oct 16, 2014 at 2:46 PM, David Halls  > wrote:
>
>>
>>
>>   Original message 
>> From: Matt Ettus
>>  Date:2014/10/16 22:42 (GMT+00:00)
>> To: John Malsbury
>> Cc: David Halls ,GNURadio
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>>  On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury <
>> jmalsbury.perso...@gmail.com> wrote:
>>
>>>  I'm happy this is working for you, David.  So do I understand
>>> correctly, that the adding tx_time finally made the MIMO case work?
>>>
>>>  I'd never done burst transmission with multiple USRP outputs.  I'm not
>>> totally surprised but I wasn't sure what would happen.
>>>
>>> Maybe someone from Ettus can comment on this?  Since UHD is trying to do
>>> time alignment in the multi_usrp class, what happens to time alignemt in
>>> the non-continuous-streaming case if you *don't* include a tx_time tag?
>>>
>>
>>
>>  Noncontinuous streaming means there is some amount of down time.  If
>> you don't include tx_time tags, the device doesn't know when to start back
>> up again, so each antenna is going to start at a different time.
>>
>>  Matt
>>
>>
>>   That seemed exactly the kind of behaviour I saw where sync between the
>> two streams was lost. Matt, can you comment on whether I need to put dummy
>> padding items before the first burst? to flush buffers and is there a
>> delicate way to do this?
>>
>>
>> --
>>
>> NOTE: The information in this email and any attachments may be
>> confidential and/or legally privileged. This message may be read, copied
>> and used only by the intended recipient. If you are not the intended
>> recipient, please destroy this message, delete any copies held on your
>> system and notify the sender immediately.
>>
>> Toshiba Research Europe Limited, registered in England and Wales
>> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
>> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>>
>>
>>
>>  --
>> This email has been scanned for email related threats and delivered
>> safely by Mimecast.
>> For more information please visit http://www.mimecast.com
>> --
>>
>
>
> --
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] NC-OFDM and Cross sub-carrier Interference

[Vahid Behzadan]

Hi,

I'm currently developing a testbed for spectrum aggregation and
fragmentation using GNURadio and USRPs (B200s and B210s). My approach is to
emulate aggregation and fragmentation using Non-Contiguous OFDM:
Theoretically, each node should be able to transmit in any subset of the
sub-carriers available.

Everything seems to be fine when tested in a loop back(the GRC OFDM Tx
example in gr_digital was used). And connected to USRPs, a single pair
transmission and reception is fine while transmitting in any subset of
subcarriers. The problem arises when I have more than one node transmitting
in the same OFDM configuration. No matter how wide the OFDM span is (I
began from 64 and increased it to 1024), and no matter how far apart the
two transmitting channels are, the cross-interference is enough to corrupt
both transmissions. I have played with the transmission power of both
transmitters to see if lowering it makes any difference, to no avail.

I have also thought of applying a bandpass filter before feeding OFDM
signals to USRPs to limit their out of band emissions, but as the system is
supposed to handle fragmentation and requires complete spectrum agility, a
single filter would not solve the problem.

I would greatly appreciate any advice on the matter.

Many Thanks,

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

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Matt Ettus]

Yes, there were multiple issues in the thread, and what I said only applies
to TX.  Certainly on the receive side there should be no latency issues, as
every block should do all computations they can on whatever data they
receive, since that is exactly what is tripping up the TX guys :)

Matt

On Fri, Oct 17, 2014 at 10:25 AM, John Malsbury <
jmalsbury.perso...@gmail.com> wrote:

> Matt,
>
> BTW - in this particular case, this was *all* in the receive direction -
> its a lowrate demodulator.  So I was a bit surprised to see the issue at
> all - 'cause I've never seen such high latency on a receive flowgraph.  We
> have a "closed" loop approach to managing transmit latency through the USRP
> without timestamps or relying on a source stream for throttling.  But I do
> think the advice you provide is useful for other's who are trying to solve 
> *transmitter
> latency by shrinking buffers.*
>
> Per the email above - it turned out that buffer sizes were not an issue.
> Something else was weird was happening - see (2) on my prev email if you're
> interested.
>
> Thanks for following up on this thread.
>
> -John
>
> On Fri, Oct 17, 2014 at 10:16 AM, Matt Ettus  wrote:
>
>>
>> We see this issue a lot with applications that only transmit, and which
>> transmit continuously.  The problem is that you end up generating samples
>> far in advance of when you really know what you want to transmit, because
>> there is no rate-limiting on the production side.
>>
>> Some general principles -- Large buffers *allow* you to deal with high
>> latency.  Large buffers do not *create* high latency unless the application
>> is not designed properly.  A properly designed application will work with
>> infinitely large buffers as well as it does with minimally sized ones.
>>
>> Shrinking buffers may allow your application to work, but that isn't
>> really the best way to solve this problem.  The best way to solve the
>> problem is to modify your head-end source block to understand wall-clock
>> time.  The easiest way to do that if you are using a USRP is to instantiate
>> a UHD source (i.e. a receiver) at a relatively low sample rate and feed it
>> into the source you have created.
>>
>> Your source block should then look at timestamps on the incoming samples
>> (it can throw the samples themselves away).  It should generate only enough
>> samples to cover the maximum latency you want, and it should timestamp
>> those transmit samples.  For example, if it receives samples timestamped
>> with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2,
>> where L1 is the worst-case flowgraph and device latency, and L2 is the
>> worst case reaction time you are looking for.  Thus, if you suddenly get a
>> message from your operator to send a message, you know that you will never
>> need to wait for more than L2 seconds.  Thus, you can bound your worst case
>> reaction time.
>>
>> It should be noted that in two-way application like GSM or LTE, you would
>> never run into these problems and they are naturally avoided because you
>> won't generate samples until you've seen what you receive.  It only is an
>> issue in TX-only apps.
>>
>> I think we should generate an example app to do this, because the issue
>> comes up periodically, especially among the space communications crowd.  It
>> is a design pattern we really should document.
>>
>> Matt
>>
>>
>> On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani  wrote:
>>
>>> I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
>>> only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
>>> flat_flowgraph.cc.
>>> This is regarded as a dodgy hack by all the GR developers here, but it
>>> worked for me (and I read the article on latency). I believe the guy
>>> who wrote GMSKSpacecraftGroundstation had the same problem, and found
>>> it in one of his old threads.
>>>
>>> On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob 
>>> wrote:
>>> > Hey John,
>>> >
>>> > I am way out of my depth here, but while working on a custom python
>>> block
>>> > the other day, I saw some weird behavior in 3.7.5 that was similar.
>>> Setting
>>> > the global max output had no effect, but setting the just-upstream
>>> block(s)
>>> > min/max output buffer size(s) low fixed my apparent slowliness.
>>> >
>>> > Very Respectfully,
>>> >
>>> > Dan CaJacob
>>> >
>>> > On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury
>>> >  wrote:
>>> >>
>>> >> Default scheduler.
>>> >>
>>> >> tb.start(1024), with different values, etc, etc.
>>> >>
>>> >> Most of the downstream blocks are stock GNU Radio blocks - a delay
>>> block
>>> >> (max delay is 1 sample), logical operators, etc.  I guess I'll add
>>> some
>>> >> printf debugging?
>>> >>
>>> >> -John
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller <
>>> marcus.muel...@ettus.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi John,
>>> >>> On 10.10.2014 19:33, John Malsbury wrote:
>>> >>>
>>> >>> Toward the end of the receive chain, there are

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[John Malsbury]

Matt,

BTW - in this particular case, this was *all* in the receive direction -
its a lowrate demodulator.  So I was a bit surprised to see the issue at
all - 'cause I've never seen such high latency on a receive flowgraph.  We
have a "closed" loop approach to managing transmit latency through the USRP
without timestamps or relying on a source stream for throttling.  But I do
think the advice you provide is useful for other's who are trying to
solve *transmitter
latency by shrinking buffers.*

Per the email above - it turned out that buffer sizes were not an issue.
Something else was weird was happening - see (2) on my prev email if you're
interested.

Thanks for following up on this thread.

-John

On Fri, Oct 17, 2014 at 10:16 AM, Matt Ettus  wrote:

>
> We see this issue a lot with applications that only transmit, and which
> transmit continuously.  The problem is that you end up generating samples
> far in advance of when you really know what you want to transmit, because
> there is no rate-limiting on the production side.
>
> Some general principles -- Large buffers *allow* you to deal with high
> latency.  Large buffers do not *create* high latency unless the application
> is not designed properly.  A properly designed application will work with
> infinitely large buffers as well as it does with minimally sized ones.
>
> Shrinking buffers may allow your application to work, but that isn't
> really the best way to solve this problem.  The best way to solve the
> problem is to modify your head-end source block to understand wall-clock
> time.  The easiest way to do that if you are using a USRP is to instantiate
> a UHD source (i.e. a receiver) at a relatively low sample rate and feed it
> into the source you have created.
>
> Your source block should then look at timestamps on the incoming samples
> (it can throw the samples themselves away).  It should generate only enough
> samples to cover the maximum latency you want, and it should timestamp
> those transmit samples.  For example, if it receives samples timestamped
> with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2,
> where L1 is the worst-case flowgraph and device latency, and L2 is the
> worst case reaction time you are looking for.  Thus, if you suddenly get a
> message from your operator to send a message, you know that you will never
> need to wait for more than L2 seconds.  Thus, you can bound your worst case
> reaction time.
>
> It should be noted that in two-way application like GSM or LTE, you would
> never run into these problems and they are naturally avoided because you
> won't generate samples until you've seen what you receive.  It only is an
> issue in TX-only apps.
>
> I think we should generate an example app to do this, because the issue
> comes up periodically, especially among the space communications crowd.  It
> is a design pattern we really should document.
>
> Matt
>
>
> On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani  wrote:
>
>> I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
>> only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
>> flat_flowgraph.cc.
>> This is regarded as a dodgy hack by all the GR developers here, but it
>> worked for me (and I read the article on latency). I believe the guy
>> who wrote GMSKSpacecraftGroundstation had the same problem, and found
>> it in one of his old threads.
>>
>> On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob 
>> wrote:
>> > Hey John,
>> >
>> > I am way out of my depth here, but while working on a custom python
>> block
>> > the other day, I saw some weird behavior in 3.7.5 that was similar.
>> Setting
>> > the global max output had no effect, but setting the just-upstream
>> block(s)
>> > min/max output buffer size(s) low fixed my apparent slowliness.
>> >
>> > Very Respectfully,
>> >
>> > Dan CaJacob
>> >
>> > On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury
>> >  wrote:
>> >>
>> >> Default scheduler.
>> >>
>> >> tb.start(1024), with different values, etc, etc.
>> >>
>> >> Most of the downstream blocks are stock GNU Radio blocks - a delay
>> block
>> >> (max delay is 1 sample), logical operators, etc.  I guess I'll add some
>> >> printf debugging?
>> >>
>> >> -John
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller <
>> marcus.muel...@ettus.com>
>> >> wrote:
>> >>>
>> >>> Hi John,
>> >>> On 10.10.2014 19:33, John Malsbury wrote:
>> >>>
>> >>> Toward the end of the receive chain, there are a multitude of blocks
>> that
>> >>> are used for Viterbi node synchronization. I've found that the number
>> of
>> >>> blocks in series (3-5), combined with the low datarates at this point
>> in
>> >>> the flowgraph, lead to latencies on the order of 1-2 minutes.  That
>> is to
>> >>> say, once the node synchronization is accomplished, it takes 1-2
>> minutes
>> >>> to
>> >>> flush these blocks and get the fresh, good data through.  This is
>> >>> measured
>> >>> with function probes on the state of the sync 

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Matt Ettus]

We see this issue a lot with applications that only transmit, and which
transmit continuously.  The problem is that you end up generating samples
far in advance of when you really know what you want to transmit, because
there is no rate-limiting on the production side.

Some general principles -- Large buffers *allow* you to deal with high
latency.  Large buffers do not *create* high latency unless the application
is not designed properly.  A properly designed application will work with
infinitely large buffers as well as it does with minimally sized ones.

Shrinking buffers may allow your application to work, but that isn't really
the best way to solve this problem.  The best way to solve the problem is
to modify your head-end source block to understand wall-clock time.  The
easiest way to do that if you are using a USRP is to instantiate a UHD
source (i.e. a receiver) at a relatively low sample rate and feed it into
the source you have created.

Your source block should then look at timestamps on the incoming samples
(it can throw the samples themselves away).  It should generate only enough
samples to cover the maximum latency you want, and it should timestamp
those transmit samples.  For example, if it receives samples timestamped
with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2,
where L1 is the worst-case flowgraph and device latency, and L2 is the
worst case reaction time you are looking for.  Thus, if you suddenly get a
message from your operator to send a message, you know that you will never
need to wait for more than L2 seconds.  Thus, you can bound your worst case
reaction time.

It should be noted that in two-way application like GSM or LTE, you would
never run into these problems and they are naturally avoided because you
won't generate samples until you've seen what you receive.  It only is an
issue in TX-only apps.

I think we should generate an example app to do this, because the issue
comes up periodically, especially among the space communications crowd.  It
is a design pattern we really should document.

Matt


On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani  wrote:

> I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
> only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
> flat_flowgraph.cc.
> This is regarded as a dodgy hack by all the GR developers here, but it
> worked for me (and I read the article on latency). I believe the guy
> who wrote GMSKSpacecraftGroundstation had the same problem, and found
> it in one of his old threads.
>
> On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob 
> wrote:
> > Hey John,
> >
> > I am way out of my depth here, but while working on a custom python block
> > the other day, I saw some weird behavior in 3.7.5 that was similar.
> Setting
> > the global max output had no effect, but setting the just-upstream
> block(s)
> > min/max output buffer size(s) low fixed my apparent slowliness.
> >
> > Very Respectfully,
> >
> > Dan CaJacob
> >
> > On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury
> >  wrote:
> >>
> >> Default scheduler.
> >>
> >> tb.start(1024), with different values, etc, etc.
> >>
> >> Most of the downstream blocks are stock GNU Radio blocks - a delay block
> >> (max delay is 1 sample), logical operators, etc.  I guess I'll add some
> >> printf debugging?
> >>
> >> -John
> >>
> >>
> >>
> >>
> >> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller <
> marcus.muel...@ettus.com>
> >> wrote:
> >>>
> >>> Hi John,
> >>> On 10.10.2014 19:33, John Malsbury wrote:
> >>>
> >>> Toward the end of the receive chain, there are a multitude of blocks
> that
> >>> are used for Viterbi node synchronization. I've found that the number
> of
> >>> blocks in series (3-5), combined with the low datarates at this point
> in
> >>> the flowgraph, lead to latencies on the order of 1-2 minutes.  That is
> to
> >>> say, once the node synchronization is accomplished, it takes 1-2
> minutes
> >>> to
> >>> flush these blocks and get the fresh, good data through.  This is
> >>> measured
> >>> with function probes on the state of the sync process, and BERT
> analysis
> >>> of
> >>> the demodulator output [through TCP/IP socket].
> >>>
> >>> I see you found the hidden interplanetary signal delay simulator.
> >>> Congrats! Watch out for the red shift in downstream samples.
> >>>
> >>> No, seriously, that sounds like a lot.
> >>> You are using 3.6.4.1 with the default scheduler, tpb?
> >>>
> >>>- I've tried messing around with the output buffer size option in
> the
> >>>flowgraph, but this seems l to have a negligible impact.
> >>>
> >>> That surprises me. How did you mess around? top_block->run(1024)?
> >>>  Do your blocks really get called with smaller input item sizes? (do a
> >>> little printf-debugging)
> >>>
> >>>- I can write some custom blocks to reduce the overall block count,
> >>> but
> >>>I have demonstrated that this provides a linear improvement, rather
> >>> than
> >>>the two-order-magnitude impr

Re: [Discuss-gnuradio] help accessing fft bins in python script

[madengr]

k1gto wrote
> Is there any way to access the fft bins from python without writing a
> custom block? 

See this:
http://ha5kfu.sch.bme.hu/fft_test

Lou
KD4HSO



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/help-accessing-fft-bins-in-python-script-tp50854p50891.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] High Flowgraph Latency in 3.6.4.1

[John Malsbury]

So...  there were actually several contributors to this long latency.  Some
of it was related to GNU Radio's inner workings, some were external.  With
all of the "external" things removed, there was still 1+ minute of latency
at low bitrates.

I thought I would share my findings, for the sake of getting this
experience publicly archived.  (and maybe someone can build on these
insights?)

First, a little background on the application.  The use case-here is that
there is some moderately complex that isn't data-specific per-se.  But the
quality of the demodulated data is evaluated on a periodic basis to
determine alignment through multiple, parallel FEC decoding chains.  After
alignment is detected, an appropriate chain is selected, and downstream
delays are adjusted.   Here are specific things that were observed:

   1. We gave up on the stock selector block early on.  It was misaligning
   samples, which effected a down-stream interleaving process. What are the
   general thoughts/feelings on how the selector block is currently
   implmeneted.

   2. We tried several "clever" (ha) methods to select the desired stream.
   Most of them revolved around the concept of summering/xoring streams after
   multiplying or and'ing the streams according to which stream we wanted
   (operand = 1 if we wanted the stream, 0 if not).  Through various methods
   we found that anything with a constant source, and const, etc, create this
   very long latencies.  The behavior was this:

   After the streams were selected and the long latency expired the data
   would be valid, and latency would be quite good for such a low data rate.
   This seemed to indicate that somehting in the blocks used to select the
   stream was causing a delay - ie. inserting a lot of samples with the
   previous evaluated results where things would be misaligned.  Either that,
   or the callbacks to set the new operands for stream selection were not
   "executing" right away.  The specific offenders seem to be 1) constant
   source   2) and constant   3) mult_const.  I haven't figured out why yet...

The end solution was to do a dumb selector block that just copied the
specified input to the output.  Derp...
-John

On Fri, Oct 10, 2014 at 7:09 PM, John Malsbury  wrote:

> Is there something i can force on a per block basis in 3.6?  Is there some
> trickery in the forecast function I might use?
> On Oct 10, 2014 6:40 PM, "Ed Criscuolo" 
> wrote:
>
>> On 10/10/14 9:15 PM, John Malsbury wrote:
>>
>>> Sounds dangerous if you also happen to have very high throughput
>>> applications to run?  Am I wrong?
>>>
>>>
>> Yes, it was a fine line between getting it small enough for acceptable
>> latency while still maintaining enough throughput to not overrun.
>> Fortunately for our application we were able to strike that balance.
>>
>> Your mileage may vary.
>>
>> @(^.^)@  Ed
>>
>>
>> ___
>> 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 error

[West, Nathan]

I'm not sure what's wrong here, but it should be trying to install a
deb called python-qwt5-qt4, not pyqwt5. Perhaps run an apt-get update
and try again. The optimal solution is to find out if this is a bug in
pybombs or your setup and send a patch if it applies to others.
Otherwise you can get around this by installing python-qwt5-qt4
yourself and then use pybombs config to tell pybombs you already have
pyqwt5 installed.

On Fri, Oct 17, 2014 at 1:37 AM, Mostafa Alizadeh
 wrote:
> Hello guys,
>
> I still trying to install GNURadio on debian 7.6 i86, but there is a problem
> with installing 'pyqwt5' package with pybombs! The following error is
> appeared:
>
> packages to install: ['pyqwt5', 'mcpp', 'db48', 'ice', 'gnuradio']
> install called (pyqwt5)
> install type priority: ['deb', 'src']
> install deb called (pyqwt5)
> deb is not available locally
> check remote repositories...
> install src called (pyqwt5)
> state = configure
> Current step: (pyqwt5 :: make)
> make
> ('\nmake -j4\n', '\nmake -j$makewidth\n')
> ('\nmake -j4\n', '\nmake -j4\n')
> bash exec (/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5/configure)::
> make -j4
>
> make: *** No targets specified and no makefile found.  Stop.
> ERROR:root:PyBOMBS Make step failed for package (pyqwt5) please see bash
> output above for a reason (hint: look for the word Error)
>
> What I should do? Please help me :(
>
> Best,
> Mostafa
>
>
> ___
> 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 accessing fft bins in python script

[mleech]

 

Again, if one uses the vector-probe block, one can call the appropriate
function from a function-probe, at that point, you have a variable with
the contents of the FFT output vector in it, which can be used in a call
to your 

own Python code. 

On 2014-10-17 12:01, Brad Hein wrote: 

> This sounds interesting - do you have any sample code? 
> 
> Can anybody explain the concept of "size" of an fft (Arg 1 of fft.fft_vcc) 
> comes into play if the output of that FFT generates as many samples as it 
> receives? 
> 
> -
> 
> FROM: "John Malsbury" 
> TO: "Brad Hein" 
> CC: "Martin Braun" , discuss-gnuradio@gnu.org
> SENT: Friday, October 17, 2014 1:50:31 AM
> SUBJECT: Re: [Discuss-gnuradio] help accessing fft bins in python script
> 
> Sometimes when I want to grab samples and perform some periodic operation 
> like CNR estimation, or fine-frequency estimation I sometimes use a 
> vector_sink, and then two function probe blocks - one to read the data and 
> one to reset it (yes I call the reset function from the function probe). This 
> seems to work wonderfully for certain corner cases where a vector sink 
> doesn't work well. And I mostly use this technique when I want to prototyping 
> something quickly before writing a block. But am I asking for trouble with 
> memory allocation issues???
> 
> ALSO, I WAS THINKING, IT WOULD BE GOOD TO HAVE THE OPTION, EITHER A BLOCK 
> PARAMETER OR AN OVERLOADED FUNCTION) TO RESET THE VECTOR_SINK, EACH TIME 
> .DATA() IS CALLED... I CAN CODE THIS UP UNLESS ANYONE THINKS THIS 
> FUNCTIONALITY WOULD LEAD TO REGRESSIONS. 
> 
> But I agree the vector sink block is much more convenient for FFTs... -John 
> 
> On Thu, Oct 16, 2014 at 5:37 PM, Brad Hein  wrote:
> 
>> Is there any way to access the fft bins from python without writing a custom 
>> block? 
>> 
>> -
>> 
>> FROM: "Martin Braun" 
>> TO: discuss-gnuradio@gnu.org
>> SENT: Thursday, October 16, 2014 2:02:03 PM
>> SUBJECT: Re: [Discuss-gnuradio] help accessing fft bins in python script 
>> 
>> A very simple way would just be to write your block downstream of the
>> FFT in Python. You can then operate on the vectors in the work function.
>> 
>> M
>> 
>> On 10/16/2014 07:44 PM, mle...@ripnet.com wrote:
>>> The vector sink is for debugging only. Don't use it in production code,
>>> because there's no convenient way to
>>> 
>>> vacuum it out, so it grows without bound.
>>> 
>>> 
>>> 
>>> When I've had this problem, I use a vector-probe block, and have a
>>> function probe running at a couple of Hz,
>>> 
>>> and then leverage the dependency-tree evaluator to have my own
>>> function called with the result of the
>>> 
>>> function probe. There are other ways, that's the one I personally
>>> find most convenient. But there are message
>>> 
>>> queues and sundry other methods as well.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 2014-10-16 13:36, Brad Hein wrote:
>>> 
 
 Using qa_fft.py for inspiration[1], I'm trying to feed a raw capture
 file into an fft of size 32 and then review the 32 fft bins at an
 instantaneous point in time[2]. I must be doing something wrong
 however because when I review the vector sink's data() method, it
 returns a rather large array (compared to the 32-element array I am
 expecting). data() seems to return an array with the same number of
 elements as samples fed into the fft. I just want an array of the 32
 fft bins so I can calculate the relative power in the given band.
 
 Any help/pointers appreciated! 
 Thanks
 
 
 [1]
 http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py
  [1]
 
 [2]
 https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py
  [2]
 
 
 [Brad Hein]
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
>>> 
>>> 
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
>>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
 

Links:
--
[1]
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py
[2]
https://github

Re: [Discuss-gnuradio] help accessing fft bins in python script

[Brad Hein]

This sounds interesting - do you have any sample code? 

Can anybody explain the concept of "size" of an fft (Arg 1 of fft . fft_vcc ) 
comes into play if the output of that FFT generates as many samples as it 
receives? 



- Original Message -

From: "John Malsbury"  
To: "Brad Hein"  
Cc: "Martin Braun" , discuss-gnuradio@gnu.org 
Sent: Friday, October 17, 2014 1:50:31 AM 
Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script 

Sometimes when I want to grab samples and perform some periodic operation like 
CNR estimation, or fine-frequency estimation I sometimes use a vector_sink, and 
then two function probe blocks - one to read the data and one to reset it (yes 
I call the reset function from the function probe). This seems to work 
wonderfully for certain corner cases where a vector sink doesn't work well. And 
I mostly use this technique when I want to prototyping something quickly before 
writing a block. But am I asking for trouble with memory allocation issues??? 

Also, I was thinking, it would be good to have the option, either a block 
parameter or an overloaded function) to reset the vector_sink, each time 
.data() is called... I can code this up unless anyone thinks this functionality 
would lead to regressions. 

But I agree the vector sink block is much more convenient for FFTs... 

-John 

On Thu, Oct 16, 2014 at 5:37 PM, Brad Hein < k1...@comcast.net > wrote: 




Is there any way to access the fft bins from python without writing a custom 
block? 



From: "Martin Braun" < martin.br...@ettus.com > 
To: discuss-gnuradio@gnu.org 
Sent: Thursday, October 16, 2014 2:02:03 PM 
Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script 


A very simple way would just be to write your block downstream of the 
FFT in Python. You can then operate on the vectors in the work function. 

M 

On 10/16/2014 07:44 PM, mle...@ripnet.com wrote: 
> The vector sink is for debugging only. Don't use it in production code, 
> because there's no convenient way to 
> 
> vacuum it out, so it grows without bound. 
> 
> 
> 
> When I've had this problem, I use a vector-probe block, and have a 
> function probe running at a couple of Hz, 
> 
> and then leverage the dependency-tree evaluator to have my own 
> function called with the result of the 
> 
> function probe. There are other ways, that's the one I personally 
> find most convenient. But there are message 
> 
> queues and sundry other methods as well. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 2014-10-16 13:36, Brad Hein wrote: 
> 
>> 
>> Using qa_fft.py for inspiration[1], I'm trying to feed a raw capture 
>> file into an fft of size 32 and then review the 32 fft bins at an 
>> instantaneous point in time[2]. I must be doing something wrong 
>> however because when I review the vector sink's data() method, it 
>> returns a rather large array (compared to the 32-element array I am 
>> expecting). data() seems to return an array with the same number of 
>> elements as samples fed into the fft. I just want an array of the 32 
>> fft bins so I can calculate the relative power in the given band. 
>> 
>> Any help/pointers appreciated! 
>> Thanks 
>> 
>> 
>> [1] 
>> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py
>>  
>> 
>> [2] 
>> https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py
>>  
>> 
>> 
>> [Brad Hein] 
>> 
>> ___ 
>> 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] Gettin data out from GRC to C++ or java?

[John Malsbury]

Ernest - here's an example of how to connect other stuff to GNU Radio via
pipes - granted at much lower sample rates.  Higher sample rates shouldn't
effect the pipe, but Matlab may not keep up with a typical 802.11 sample
rate.

http://youtu.be/GBmli8Vflig?t=2m33s

If you *could* get this 3k sample snapshot, how do you make sure a useful
signal will be present?

If you're doing processing in another framework, why don't you just use UHD
directly w/out GNU Radio?  There are finite acquisition calls in UHD IIRC...

-John


On Fri, Oct 17, 2014 at 5:15 AM, Martin Braun 
wrote:

> On 10/17/2014 12:40 PM, Ernest Szczepaniak wrote:
> > So i if would like to create a simple flow graph, with USRP source and
> file
> > sink only, is there any way to control file buffer size (i.e i want that
> any
> > file consist of 3k 32complex samples every write)?
>
> You can't control how many samples the USRP source will produce per run.
> And I'm not sure that's really what you want.
>
> > Any 3.7 compatibile pipe pack? tried gr-pipe but typical "gnuradio-core"
> > error :(
>
> I was suggesting you create a named pipe instead of a regular file. If
> you don't know what that means, I suggest looking it up, it's a basic
> concept of most OSes, and Google will have all the info you need.
>
> You don't need any addons for that.
>
> M
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[John Malsbury]

Also, my understanding for the PLL blocks were that they were ideal for
"strong carrier" signals like AM.  When I say strong carrier i mean a
signal that has an obvious carrier which isn't "hidden" under modulation..

Anyway, the GMSK block might be a good place to start.

-John

On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury  wrote:

> It doesn't have frequency correction - I can probably follow up with some
> ideas on how to implement that part.  But the GMSK demod might do OK for
> you initially.  It doesn't do anything intelligent to deal with the data
> shaping - its just a non-coherent slicer.
>
> If you want to design in GRC but keep your top-level application as is,
> you can use a hier block.  You can also use a command line parameter or
> other mechanism to select your demodulator at start-time for easy
> comparisons.
>
> [typed one handed.. my daughter has my other and]
>
> -John
>
> On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt  wrote:
>
>> Thanks for looking into it! To be honest, I am not really good at RF. I
>> based my code off the python code in gr-smartnet. The fsk-demod python file
>> is here:
>> https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py
>>
>> It is quite possible that it just happened to work because of an error
>> that got patched in Gr 3.7.
>>
>> Are there some good examples for GMSK/FSK demodulation that I could
>> borrow from instead?
>>
>> Recreating this in GRC sounds like a great idea so I can scope along the
>> way. I will give that a try next.
>>
>> Thanks again for the pointers, fresh eyes are really helpful when you
>> have been staring at it for so long.
>>
>>  - Luke
>>
>> On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun 
>> wrote:
>>
>>> On 10/17/2014 08:28 AM, John Malsbury wrote:
>>> > Also also, is the Band-Edge FLL ideal for GMSK?  My possibly, incorrect
>>> > understanding of that block is that it was more ideal for PAM with
>>> > common RRC.
>>>
>>> For the record: It might work coincidentally because of the rolloff-y
>>> shape of GMSK, but it's derived for and designed for common PAM/RRC, as
>>> John says and I wouldn't recommend it for anything else.
>>> To look up the math, I suggest Harris' works.
>>>
>>>
>>>
>>
>> ___
>> 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] Works with GR 3.6, breaks with 3.7

[John Malsbury]

It doesn't have frequency correction - I can probably follow up with some
ideas on how to implement that part.  But the GMSK demod might do OK for
you initially.  It doesn't do anything intelligent to deal with the data
shaping - its just a non-coherent slicer.

If you want to design in GRC but keep your top-level application as is, you
can use a hier block.  You can also use a command line parameter or other
mechanism to select your demodulator at start-time for easy comparisons.

[typed one handed.. my daughter has my other and]

-John

On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt  wrote:

> Thanks for looking into it! To be honest, I am not really good at RF. I
> based my code off the python code in gr-smartnet. The fsk-demod python file
> is here:
> https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py
>
> It is quite possible that it just happened to work because of an error
> that got patched in Gr 3.7.
>
> Are there some good examples for GMSK/FSK demodulation that I could borrow
> from instead?
>
> Recreating this in GRC sounds like a great idea so I can scope along the
> way. I will give that a try next.
>
> Thanks again for the pointers, fresh eyes are really helpful when you have
> been staring at it for so long.
>
>  - Luke
>
> On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun 
> wrote:
>
>> On 10/17/2014 08:28 AM, John Malsbury wrote:
>> > Also also, is the Band-Edge FLL ideal for GMSK?  My possibly, incorrect
>> > understanding of that block is that it was more ideal for PAM with
>> > common RRC.
>>
>> For the record: It might work coincidentally because of the rolloff-y
>> shape of GMSK, but it's derived for and designed for common PAM/RRC, as
>> John says and I wouldn't recommend it for anything else.
>> To look up the math, I suggest Harris' works.
>>
>>
>>
>
> ___
> 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] Works with GR 3.6, breaks with 3.7

[Luke Berndt]

Thanks for looking into it! To be honest, I am not really good at RF. I
based my code off the python code in gr-smartnet. The fsk-demod python file
is here:
https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py

It is quite possible that it just happened to work because of an error that
got patched in Gr 3.7.

Are there some good examples for GMSK/FSK demodulation that I could borrow
from instead?

Recreating this in GRC sounds like a great idea so I can scope along the
way. I will give that a try next.

Thanks again for the pointers, fresh eyes are really helpful when you have
been staring at it for so long.

 - Luke

On Fri, Oct 17, 2014 at 8:18 AM, Martin Braun 
wrote:

> On 10/17/2014 08:28 AM, John Malsbury wrote:
> > Also also, is the Band-Edge FLL ideal for GMSK?  My possibly, incorrect
> > understanding of that block is that it was more ideal for PAM with
> > common RRC.
>
> For the record: It might work coincidentally because of the rolloff-y
> shape of GMSK, but it's derived for and designed for common PAM/RRC, as
> John says and I wouldn't recommend it for anything else.
> To look up the math, I suggest Harris' works.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio

[Ruben.Merz]

Make sure you put an attenuator before going back into the N200 so that you do 
not damage the RF input.
Ruben

From: discuss-gnuradio-bounces+ruben.merz=swisscom@gnu.org 
[mailto:discuss-gnuradio-bounces+ruben.merz=swisscom@gnu.org] On Behalf Of 
Carlos Alberto Ruiz Naranjo
Sent: Friday, October 17, 2014 3:35 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] TX/RX with USRPN200 and GNURadio

[cid:image001.png@01CFEA20.8ED2B3A0]
​Hello,

I want to transmit and receive at the same time with WBX board and USRPN200. I 
have this flowgraph.

I connected the input and output with a RF cable (a loop).

Is it possible? Is there any problem?
Thank you.


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

[Discuss-gnuradio] TX/RX with USRPN200 and GNURadio

[Carlos Alberto Ruiz Naranjo]

​Hello,

I want to transmit and receive at the same time with WBX board and USRPN200.
I have this flowgraph.

I connected the input and output with a RF cable (a loop).

Is it possible? Is there any problem?

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

Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[Martin Braun]

On 10/17/2014 08:28 AM, John Malsbury wrote:
> Also also, is the Band-Edge FLL ideal for GMSK?  My possibly, incorrect
> understanding of that block is that it was more ideal for PAM with
> common RRC.

For the record: It might work coincidentally because of the rolloff-y
shape of GMSK, but it's derived for and designed for common PAM/RRC, as
John says and I wouldn't recommend it for anything else.
To look up the math, I suggest Harris' works.

Cheers,
M


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

Re: [Discuss-gnuradio] Gettin data out from GRC to C++ or java?

[Martin Braun]

On 10/17/2014 12:40 PM, Ernest Szczepaniak wrote:
> So i if would like to create a simple flow graph, with USRP source and file
> sink only, is there any way to control file buffer size (i.e i want that any
> file consist of 3k 32complex samples every write)?

You can't control how many samples the USRP source will produce per run.
And I'm not sure that's really what you want.

> Any 3.7 compatibile pipe pack? tried gr-pipe but typical "gnuradio-core"
> error :(

I was suggesting you create a named pipe instead of a regular file. If
you don't know what that means, I suggest looking it up, it's a basic
concept of most OSes, and Google will have all the info you need.

You don't need any addons for that.

M


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

Re: [Discuss-gnuradio] Gettin data out from GRC to C++ or java?

[Ernest Szczepaniak]

So i if would like to create a simple flow graph, with USRP source and file
sink only, is there any way to control file buffer size (i.e i want that any
file consist of 3k 32complex samples every write)?

Any 3.7 compatibile pipe pack? tried gr-pipe but typical "gnuradio-core"
error :(



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Gettin-data-out-from-GRC-to-C-or-java-tp50824p50875.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] Works with GR 3.6, breaks with 3.7

[Dan CaJacob]

John,

I use the BE FLL for auto-doppler correction in the rare case where I am
not actively correcting for doppler.  But, the correction is *really*
slow.  I'm probably not using it correctly, but it works OK in that rare
case when it's all I've got.

Very Respectfully,

Dan CaJacob

On Fri, Oct 17, 2014 at 2:28 AM, John Malsbury  wrote:

> Luke,
>
> I researched this for a bit  (OK, maybe it was more like staring
> blankly)... unfortunately on a windows machine w/out git.  Nothing stands
> out at the momentt.  I'll give it another try tomorrow! =)
>
> Also, I've never used the PLL blocks for freq demod before. Can you set
> something up with a graphical sink and send some snapshots showing what the
> output of that looks like?
>
> Also also, is the Band-Edge FLL ideal for GMSK?  My possibly, incorrect
> understanding of that block is that it was more ideal for PAM with common
> RRC.
>
> -John
>
> On Thu, Oct 16, 2014 at 7:19 AM, Luke Berndt  wrote:
>
>> I just tried doing a complete PyBombs reinstall and that didn't seem the
>> help. I checked and simple GRC files run fine. I can also see the signal
>> where I expect it to be in GQRX, so I think my tuning parameters are
>> correct.
>>
>> Are there some other things I should try?
>>
>> Sent from my iPhone
>>
>> On Oct 13, 2014, at 1:38 PM, Luke Berndt  wrote:
>>
>> I have a GnuRadio C++ program that decodes and records a SmartNet Trunked
>> radio system. It is running great under GnuRadio 3.6.5.1, but it doesn’t
>> seem to be working under 3.7.6.
>>
>> 3.6 is installed in /usr/local and 3.7.6 was installed in my home
>> directory using PyBombs. My updated program compiles against 3.7 with no
>> problem and runs. It will pick up a few of the trunking commands, so it is
>> working, but the ratios is about 1 to 100 compared to 3.6. I also tried
>> running it in a Ubuntu VM with 3.7 installed at /usr/local and had the same
>> results.
>>
>> I corrected for the change with XlatingFirFilter in 3.7, so it is the
>> opposite offset of 3.6. It looks like it could be a tuning error though,
>> the flow graph seems to be failing mostly at the CRC check. Did anything
>> else change with Blocks in 3.7? I looked at gr-osmosdr but I didn’t notice
>> huge discrepancies between the 3.6 and 3.7 branches.
>>
>> Are there some obvious things I could be missing? I feel like this is
>> something small and stupid that I missing.
>>
>> The diff between the two versions is here, smartness.cc is the main file
>> that decodes the control channel. As you can see, there is not that much
>> different:
>>
>>
>> https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40
>>
>> Here is the central code block that does it. Anything obviously dumb here?
>>
>> * float samples_per_second = samp_rate;*
>> * float syms_per_sec = 3600;*
>> * float gain_mu = 0.01;*
>> * float mu=0.5;*
>> * float omega_relative_limit = 0.3;*
>> * float offset = chan_freq - center_freq;  // have to reverse it for 3.7
>> because it swapped in the switch.*
>> * float clockrec_oversample = 3;*
>> * int decim = int(samples_per_second / (syms_per_sec *
>> clockrec_oversample));*
>> * float sps = samples_per_second/decim/syms_per_sec;*
>> * const double pi = boost::math::constants::pi();*
>>
>> * cout << "Control channel offset: " << offset << endl;*
>> * cout << "Decim: " << decim << endl;*
>> * cout << "Samples per symbol: " << sps << endl;*
>>
>> *  std::vector lpf_taps;*
>>
>> *  init_loggers(max_loggers, center_freq, samp_rate);*
>>
>> *  gr::msg_queue::sptr queue = gr::msg_queue::make();*
>>
>> * lpf_taps =  gr::filter::firdes::low_pass(1, samp_rate, 1, 12000);*
>>
>> * gr::filter::freq_xlating_fir_filter_ccf::sptr prefilter =
>> gr::filter::freq_xlating_fir_filter_ccf::make(decim,*
>> *   lpf_taps,*
>> *   offset,*
>> *   samp_rate);*
>>
>> * gr::digital::fll_band_edge_cc::sptr carriertrack =
>> gr::digital::fll_band_edge_cc::make(sps, 0.6, 64, 0.35);*
>>
>> *  gr::analog::pll_freqdet_cf::sptr pll_demod =
>> gr::analog::pll_freqdet_cf::make(2.0 / clockrec_oversample,
>> 2*pi/clockrec_oversample, -2*pi/clockrec_oversample);*
>>
>> * gr::digital::clock_recovery_mm_ff::sptr softbits =
>> gr::digital::clock_recovery_mm_ff::make(sps, 0.25 * gain_mu * gain_mu, mu,
>> gain_mu, omega_relative_limit);*
>>
>> * gr::digital::binary_slicer_fb::sptr slicer =
>>  gr::digital::binary_slicer_fb::make();*
>>
>> * gr::digital::correlate_access_code_tag_bb::sptr start_correlator =
>> gr::digital::correlate_access_code_tag_bb::make("10101100",0,"smartnet_preamble");*
>>
>> * smartnet_deinterleave_sptr deinterleave = smartnet_make_deinterleave();*
>>
>> * smartnet_crc_sptr crc = smartnet_make_crc(queue);*
>>
>> * tb->connect(src,0,prefilter,0);*
>> * tb->connect(prefilter,0,carriertrack,0);*
>> * tb->connect(carriertrack, 0, pll_demod, 0);*
>> * tb->connect(pll_demod, 0, softbits, 0);*
>> * tb->connect(softbits, 0, slicer, 0);*
>> * tb->connect(slicer, 0, start_c