Re: [Discuss-gnuradio] measuring RSSI - N210 with RFX2400

2013-07-16 Thread Sam mite 
With respect to following post:

http://lists.gnu.org/archive/html/discuss-gnuradio/2011-06/msg00066.html

>>There is an "rssi" 
>>sensor:>>http://www.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series 
>>

>>from the uhd api:
>>usrp->get_rx_sensor("rssi")

>>or in python w/ gr-uhd
>>usrp.get_dboard_sensor("rssi")


>>-josh


I get following eror while using usrp.get_dboard_sensor("rssi") with
USRPN210 and RFX2400

return _uhd_swig.uhd_usrp_source_sptr_get_dboard_sensor(self, *args, **kwargs)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/dboards/A/rx_frontends/0/sensors/rssi

What could be the issue ?

-- 

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

Re: [Discuss-gnuradio] Measuring RSS during packet reception

2013-07-16 Thread Nemanja Savic 
Any suggestions on this topic, opinions?

Best
Nemanja


On Tue, Jul 9, 2013 at 4:23 PM, Nemanja Savic  wrote:

> Hi again gnuradioers,
>
> as always, I would like to ask for your opinion before starting to write
> my own block.
> Basically, I would like to add a feature to my receiver to be able to
> calculate average signal strength during signal reception. When I receive a
> valid packet I would like to have a RSS value. My question is what is the
> best way to accomplish this in GNURADIO? Using tags or messages, ...? IS
> there anything similar already provided so that I can take a look?
>
> Thank you and best
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] Measuring RSS during packet reception

2013-07-16 Thread Nemanja Savic 
The only way that is on my mind is to detect burst and store it in a file,
and then to send a message to the block that will read that file, and in
case of successfull demodulation and decoding to calcualte signal power,
but it looks pretty robust and non elegant.

Cheers,
Nemanja


On Tue, Jul 16, 2013 at 2:26 PM, Nemanja Savic  wrote:

> Any suggestions on this topic, opinions?
>
> Best
> Nemanja
>
>
> On Tue, Jul 9, 2013 at 4:23 PM, Nemanja Savic  wrote:
>
>> Hi again gnuradioers,
>>
>> as always, I would like to ask for your opinion before starting to write
>> my own block.
>> Basically, I would like to add a feature to my receiver to be able to
>> calculate average signal strength during signal reception. When I receive a
>> valid packet I would like to have a RSS value. My question is what is
>> the best way to accomplish this in GNURADIO? Using tags or messages,
>> ...? IS there anything similar already provided so that I can take a look?
>>
>> Thank you and best
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] SRIF workshop at SIGCOMM

2013-07-16 Thread Tom Rondeau 
Hi everyone,

I want to remind everyone about the Software Radio Implementation
Forum (SRIF) workshop at the ACM SIGCOMM conference in August in Hong
Kong. I'm on the steering committee of the workshop, and we've been
working to build a space for publishing work that takes theory and
simulation into actual radio systems. We have a really good lineup of
talks, and I hope many of you can make it, especially if you were
already going to be at SIGCOMM.

http://conferences.sigcomm.org/sigcomm/2013/srif.php

Tom

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

Re: [Discuss-gnuradio] Bug in volk on armv6

2013-07-16 Thread Tom Rondeau 
On Thu, Jul 4, 2013 at 4:13 AM, Alexey Bazhin  wrote:
> Confirming that this fix works.
>
> But now volk test fails in another place.
>
> (gdb) run
> Starting program: /root/gnuradio-3.6.5.1/build/volk/lib/test_all
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/arm-linux-gnueabihf/libthread_db.so.1". Running 92 test cases...
> Using Volk machine: generic_orc
> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
> no architectures to test
> RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a
> generic completed in 0s
> orc completed in 0.01s
> Best arch: generic
> RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a
> generic completed in 0s
> orc completed in 0s
> Best arch: generic
> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a
> generic completed in 0.01s
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb6f96428 in ?? () from /usr/lib/arm-linux-gnueabihf/libvolk.so.0.0.0
> (gdb) bt
> #0  0xb6f96428 in ?? ()
> #from /usr/lib/arm-linux-gnueabihf/libvolk.so.0.0.0
> Cannot access memory at address 0x0
> #1  0xb6db3da0 in pthread_mutex_unlock ()
> #from /lib/arm-linux-gnueabihf/libc.so.6 2  0x0020 in ?? ()
> #3  0x0020 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
>
> P.S. I'm trying to compile gnuradio on raspbian on Raspberry Pi board.
> All other tests passed ok, so some broken volk function shouldn't be a
> problem for me since I only want to use network sink on it.

Hi Alexey,

Yeah, you shouldn't care too much about Volk on the Raspberry Pi since
there's nothing optimized for that platform. You just need to make
sure all call to Volk work using the 'generic' proto-kernels (in other
words, you need Volk because we use functions from the library in GNU
Radio, but you won't access any of the SIMD-optimized versions of the
code).

To learn more about the QA failure above, it'd be better to build with
debug symbols on (-DCMAKE_BUILD_TYPE="Debug") to get more information
out of that back trace.

Tom



> On Wed, 3 Jul 2013 10:55:06 -0400
> Tom Rondeau  wrote:
>
>> On Mon, Jul 1, 2013 at 4:08 AM, Alexey Bazhin  wrote:
>> > Hi!
>> >
>> > I would like to report a bug in volk on armv6.
>> >
>> > There is infinite "while" cycle in volk/tmpl/volk_cpu.tmpl.c
>> > function "has_neon" (line 111).
>> >
>> > Code "while(!found_neon && auxvec_f) {" will loop infinitely if
>> > there is no neon in platform. found_neon will never be true and file
>> > descriptor auxvec_f will always be true.
>> >
>> > --
>> > Alexey Bazhin 
>>
>> Ok, I see your point. Looks like we should be testing the return value
>> from fread, instead of auxvec_f. Can you confirm if this patch works?
>>
>> diff --git a/volk/tmpl/volk_cpu.tmpl.c b/volk/tmpl/volk_cpu.tmpl.c
>> index 81fc679..b1a0a4a 100644
>> --- a/volk/tmpl/volk_cpu.tmpl.c
>> +++ b/volk/tmpl/volk_cpu.tmpl.c
>> @@ -116,10 +116,11 @@ static int has_neon(void){
>>  auxvec_f = fopen("/proc/self/auxv", "rb");
>>  if(!auxvec_f) return 0;
>>
>> +size_t r = 1;
>>  //so auxv is basically 32b of ID and 32b of value
>>  //so it goes like this
>> -while(!found_neon && auxvec_f) {
>> -  fread(auxvec, sizeof(unsigned long), 2, auxvec_f);
>> +while(!found_neon && r) {
>> +  r = fread(auxvec, sizeof(unsigned long), 2, auxvec_f);
>>if((auxvec[0] == AT_HWCAP) && (auxvec[1] & HWCAP_NEON))
>>  found_neon = 1;
>>  }
>>
>> Or might be better to test 'if(r < 2)' after the fread line and break
>> in case an error occurs and we only get 1 character out and not try to
>> read from it again. Probably not a bit deal since we're only reading
>> in two chars at a time.
>>
>> Tom
>
>
> --
> Alexey Bazhin 

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

Re: [Discuss-gnuradio] Simple QAM project

2013-07-16 Thread Tom Rondeau 
On Sun, Jul 7, 2013 at 5:50 PM, tom sutherland  wrote:
> I am new to linux and GNURadio.  I don'g follow where the 1 bit/byte is
> coming from. Does the audio source not deliver 8bit/sample or how do you
> figure that out? I don't see anything such as
> "gnuradio>digital>generic_mod_demod.py " in my directories. Thanks for the
> help.
> Tom

Tom,
The audio source will produce single-precision floating-point samples
between -1 and 1. You'll need to think about how you want to convert
these to digital samples that the QAM modulation can handle. So first
convert it into some quantized representation (i.e., as fixed point).
Then, you should have a stream of 'packet' bits that can be directly
inputted into the modulator.

There are blocks called packed_to_unpacked / unpacked_to_packed as
well as a unpack_k_bits / pack_k_bits that you can use to go from
unpacked to packed representation.

Tom



> --
> Tom,
>
> There are few changes required in ur FG
>   1: PSK/QAM Modulator takes packed byte input (8 bits per byte) instead of
> 1 bit per byte
>see gnuradio>digital>generic_mod_demod.py
>   2: Constellation sink work only for PSK modulation M=2,4,8.
>
> To see output constellation of QAM-16 u will have to first downsample it to
> 1 sample_per_symbol and then use wx-scope-sink in XY-Mode
> Down-sampling can be done using symbol-timing blocks or manually
> (delay+keep1inN combination) as in attached FG
>
> -Adeel
>
> 
> From: Adeel Anwar 
> To: tom sutherland ; discuss-gnuradio@gnu.org
> Sent: Friday, July 5, 2013 10:25 PM
> Subject: Re: [Discuss-gnuradio] Simple QAM project
>
>
> Can u attach ur GRC file?
>
> -Adeel
>
>
> On Fri, Jul 5, 2013 at 5:48 AM, tom sutherland 
> wrote:
>
> I am trying to get data through a QAM-16 Modulator and just display the data
> stream on a Constellation Sink. I have 8khz sampled 8-bit data(char) going
> into the QAM Mod block. I have the output of the QAMmod block going directly
> into the Const Sink. I am not seeing anything on the Constellation Sink. I
> put a throttle block in but that didn't help.
> Any thoughts on what could be wrong? I have followed the GNUradio tutorial:
> Part 4 by balint256 but didn't help.
> Thanks...DT
>
>
> ___
> 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] Channel Model omits first 3 samples

2013-07-16 Thread Tom Rondeau 
On Wed, Jul 10, 2013 at 8:42 AM, Gregory Warnes  wrote:
>
>
> On Jul 10, 2013, at 4:47 AM, Tom Rondeau  wrote:
>
>> On Tue, Jul 9, 2013 at 8:38 PM, Gregory Warnes  wrote:
>>> Hi All,
>>>
>>> I've been working on calculating BER for simulated transmitter/recieved pair
>>> and have noticed that the channel_model eats the first 3 samples.  Thus to
>>> correctly align the data input and output from channel_model (e.g. for
>>> calculating BER), it is necessary to account for the 3-sample offset.
>>>
>>> Perhaps it would be worth adding a note to this effect to the channel_model
>>> documentation.
>>>
>>> -Greg
>>
>> It's not that the channel model 'eat's 3 samples. This is group delay
>> of your filters that you're seeing. The transmitter, receiver, and
>> channel model may all have filters in them and each has a group delay.
>> You always have to adjust for this. Not sure we can put it into the
>> documentation except to say that you need to calculate the total group
>> delay of your system if you want to align the data.
>
> Thanks Tom,
>
> Is there a straightforward way to calculate group delay for a flow graph?
>
> Alternatively, would it be straightforward to create a block that annotates 
> the data stream with a time index and another block that uses this 
> information to align streams?
>
> -Greg


Greg,

Symmetric FIR filters have a known group delay of (N-1)/2. So what you
need to do is a) make sure all of your filters are symmetric FIRs (and
they probably are; firdes and optfir produce these types of filters)
and b) know all of the filters in the path, which includes the
transmit and receive pulse shaping filters and any filter in the
channel model (used to simulate multipath). You should be able to add
up the group delays of all filters to get your answer.

Tom

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

[Discuss-gnuradio] GR Developers' Call, July 18

2013-07-16 Thread Tom Rondeau 
Hi everyone,

Our July conference call is happening this Thursday, July 18 at 5pm
UTC. Details can be found here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20130718

Talk to you then!

Tom

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

Re: [Discuss-gnuradio] Measuring RSS during packet reception

2013-07-16 Thread Nemanja Savic 
This looks a bit silly cause I am speaking with myself. Anyway, maybe I can
do something with probe_avg_mag_sqr, but maybe somebody can tell me how can
I access that block's values from another block?

Best,
Nemanja


On Tue, Jul 16, 2013 at 3:16 PM, Nemanja Savic  wrote:

> The only way that is on my mind is to detect burst and store it in a file,
> and then to send a message to the block that will read that file, and in
> case of successfull demodulation and decoding to calcualte signal power,
> but it looks pretty robust and non elegant.
>
> Cheers,
> Nemanja
>
>
> On Tue, Jul 16, 2013 at 2:26 PM, Nemanja Savic  wrote:
>
>> Any suggestions on this topic, opinions?
>>
>> Best
>> Nemanja
>>
>>
>> On Tue, Jul 9, 2013 at 4:23 PM, Nemanja Savic  wrote:
>>
>>> Hi again gnuradioers,
>>>
>>> as always, I would like to ask for your opinion before starting to write
>>> my own block.
>>> Basically, I would like to add a feature to my receiver to be able to
>>> calculate average signal strength during signal reception. When I receive a
>>> valid packet I would like to have a RSS value. My question is what is
>>> the best way to accomplish this in GNURADIO? Using tags or messages,
>>> ...? IS there anything similar already provided so that I can take a look?
>>>
>>> Thank you and best
>>>
>>> --
>>> Nemanja Savić
>>>
>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>



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

[Discuss-gnuradio] Loss of synchronization while creating new file

2013-07-16 Thread rmsrms1987 


Hi Everyone,

I am having some issues with figuring out the cause of a loss of
synchronization using the USRP N210. I will be using the USRP as a
receiver for a radar system, but I am still in the calibration phase.
For calibration testing, I am interested in seeing the stability of the
baseband IQ data when applying a known pulsed RF signal with RF
frequency
matched to the frequency of the DDC.  The data collection program
developed through GNURadio libraries is to continuously run while
creating a new file after a specified amount of time, to avoid having
one massive file. Typically each file is set to 5 minutes, but for this
issue the number has been altered several times. The baseband IQ data
from a single inter pulse period is plotted every 5 seconds. To
synchronize the pulsed RF with the USRP, we are using an external 10 MHz
clock in addition to a PPS signal.

During testing, at first everything seemed to be working as it should,
because the baseband IQ plots were the same every 5 seconds a new plot
was  displayed.  The problem occurred after the completion of a file,
and the start of a new file.  The start of the new file caused the IQ
values to change, and these values remained until completion of the
file, where the problem will continue to the next file. I have tried
many different tests to understand this problem, but I have run out of
ideas. I was wondering, is something on the NCO is not being reset
during the closing and opening of a new file. Or, is there always going
to be some loss of synchronization during this change?  For a
visualization of the problem I have attached a couple pictures of the
phase for subsequent files. If anyone has any suggestions to solve this
problem it would be greatly appreciated.  Also if there is any other
information you need, please let me know.

Thank you very much,
Robert

 
 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Loss-of-synchronization-while-creating-new-file-tp42517.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] SIP, PyQt, PyQWT API Conflicts

2013-07-16 Thread Michael Dickens 
Joe and I had a discussion off-list.  Here's the end-result, confirmed via both 
internet search as well as local testing:

The error generated by the Python command:

{{{
> import PyQt4.Qwt5 as Qwt
 File 
"/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/Qwt5/__init__.py",
 line 32, in 
   from Qwt import *
RuntimeError: the sip module implements API v10.0 but the PyQt4.Qwt5.Qwt module 
requires API v8.1
}}}

is the result of PyQwt being compiled using SIP API 8.1 (SIP version 4.13.3), 
while the currently installed SIP API is 10.0 (SIP version 4.14.7).  Depending 
on what one is trying to do with SIP, the above might actually work; and SIP 
provides a means to allow it to work by using a special import command (or, at 
least that's my reading of the code).

I do not see this issue within MacPorts because the MacPorts maintainers been 
diligent about updating SIP dependencies whenever SIP is updated.  I had 
thought MacPorts would catch SIP updates and force reinstallation of 
dependencies (via a new binary or from source), but in my testing it does not 
automatically do so.  Hence, that task now falls back onto the maintainer of 
SIP in MacPorts, who happens to be me; lucky me!) . - MLD


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

Re: [Discuss-gnuradio] Loss of synchronization while creating new file

2013-07-16 Thread Marcus D. Leech 

On 07/16/2013 04:31 PM, rmsrms1987 wrote:


Hi Everyone,

I am having some issues with figuring out the cause of a loss of
synchronization using the USRP N210. I will be using the USRP as a
receiver for a radar system, but I am still in the calibration phase.
For calibration testing, I am interested in seeing the stability of the
baseband IQ data when applying a known pulsed RF signal with RF
frequency
matched to the frequency of the DDC.  The data collection program
developed through GNURadio libraries is to continuously run while
creating a new file after a specified amount of time, to avoid having
one massive file. Typically each file is set to 5 minutes, but for this
issue the number has been altered several times. The baseband IQ data
from a single inter pulse period is plotted every 5 seconds. To
synchronize the pulsed RF with the USRP, we are using an external 10 MHz
clock in addition to a PPS signal.

During testing, at first everything seemed to be working as it should,
because the baseband IQ plots were the same every 5 seconds a new plot
was  displayed.  The problem occurred after the completion of a file,
and the start of a new file.  The start of the new file caused the IQ
values to change, and these values remained until completion of the
file, where the problem will continue to the next file. I have tried
many different tests to understand this problem, but I have run out of
ideas. I was wondering, is something on the NCO is not being reset
during the closing and opening of a new file. Or, is there always going
to be some loss of synchronization during this change?  For a
visualization of the problem I have attached a couple pictures of the
phase for subsequent files. If anyone has any suggestions to solve this
problem it would be greatly appreciated.  Also if there is any other
information you need, please let me know.

Thank you very much,
Robert






--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Loss-of-synchronization-while-creating-new-file-tp42517.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


You haven't described your flow-graph, nor how you "flip to a new file".

The USRP has *zero* idea about what you're doing with the samples once 
they leave the USRP.  It doesn't care.  So any anomalies with things like
  file recording are utterly independent of the USRP (modulo any 
overruns that might be caused by your flow-graph, in which case, you'll see

  phase-hits).



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing

2013-07-16 Thread Tom Rondeau 
On Thu, Jul 11, 2013 at 7:17 PM, LD Zhang  wrote:
> Great, these discussions actually help a lot, I am going to initially design
> it to be a factor of 10 less than the theoretical limit.
>
> There is another question: in the case of no floating point operations at
> all, there must be a limit of how fast the data can stream through the
> Gnuradio environment. So is the limit like 10 Msps, or like 50 Msps? A 1
> Msps data stream fed through 10 parallel ports is like 10 Msps data stream,
> correct?
>
> Thanks,
>
> LD


Being able to calculate the cost of an SDR application running on a
GPP would be fantastic, but it would only ever be an approximation.

Instead, we've introduced the Performance Counters and a Performance
Monitor application with GNU Radio 3.7.0 that simply measures the
amount of time a block takes during a call to work. The paper that
I'll be presenting at the SRIF workshop in August introduces this
concept. I've also just written some documentation that will go into
the manual soon that describes them better.

The point of this tool is to see how well your application is running
and to identify which blocks might be using too much CPU time to be
singled out for optimization. It could also potentially be used to
develop an understanding of how each block might work on your machine,
which you could then use to extrapolate how much your system could
process.

Tom



> -Original Message-
> From: Nathan West [mailto:nathan.w...@okstate.edu]
> Sent: Thursday, July 11, 2013 3:35 PM
> To: LD Zhang
> Cc: Nathan West; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming
> processing
>
> On Thu, Jul 11, 2013 at 6:13 PM, LD Zhang  wrote:
>> Hi, Please my comment below:
>>
>> You can probably get a rough estimate of the lower limit of your
>> processors ability to do something like an FIR filter with some simple
>> calculations:
>> A 10-point FIR filter needs to do 10 multiplies and 9 additions.
>> Blissfully ignoring branching that's 19 instructions for each output.
>> So let's say we've got a simple FIR filter that outputs the same
>> sample rate as it inputs.
>>
>> Using the table in here:
>> http://en.wikipedia.org/wiki/Instructions_per_second it looks like
>> modern CPUs clocked around 1GHz should expect between 2-5 IPS / (1/clock
> speed).
>> Pick your favorite (I'm guessing you're on older hardware so let's go
>> with 2). 2 * 1GHz = 2000 MIPs. So you can process 1M samples through a
>> very poorly implemented 10-tap FIR filter. That in itself is also a
>> pretty poor estimate. I see Marcus just replied as well and as he
>> said, the best way to
>> *know* is just to try it out on your hardware; there's no substitute
>> for that.
>>
>>
> I am confused: 10-tap FIR according to the above is 19 IPs, so 1M
>> samples correspond to 19 MIPS, much below the 2000 MIPS limit?
>> Am I missing something?
>>
>> LD
>>
>
> Hmm, I guess you're right. It's not too important because the actual
> estimate wouldn't be close to anything close to what you would see.
> The point is there is no easy answer (other than just running something to
> see if it works), but you might be able to come up with a rough estimate if
> you really need to and your application is really simple. You should
> probably ignore my lousy attempt :-P. I came up with it on the fly...
> There's also the issue of how long it takes those instructions to execute.
>
> -Nathan
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing

2013-07-16 Thread LD Zhang 
Fantastic! Let us know if there are docs/links and code examples now. Or
maybe we will wait till the August presentation?

-Original Message-
From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: Tuesday, July 16, 2013 2:30 PM
To: LD Zhang
Cc: Nathan West; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming
processing

On Thu, Jul 11, 2013 at 7:17 PM, LD Zhang  wrote:
> Great, these discussions actually help a lot, I am going to initially 
> design it to be a factor of 10 less than the theoretical limit.
>
> There is another question: in the case of no floating point operations 
> at all, there must be a limit of how fast the data can stream through 
> the Gnuradio environment. So is the limit like 10 Msps, or like 50 
> Msps? A 1 Msps data stream fed through 10 parallel ports is like 10 
> Msps data stream, correct?
>
> Thanks,
>
> LD


Being able to calculate the cost of an SDR application running on a GPP
would be fantastic, but it would only ever be an approximation.

Instead, we've introduced the Performance Counters and a Performance Monitor
application with GNU Radio 3.7.0 that simply measures the amount of time a
block takes during a call to work. The paper that I'll be presenting at the
SRIF workshop in August introduces this concept. I've also just written some
documentation that will go into the manual soon that describes them better.

The point of this tool is to see how well your application is running and to
identify which blocks might be using too much CPU time to be singled out for
optimization. It could also potentially be used to develop an understanding
of how each block might work on your machine, which you could then use to
extrapolate how much your system could process.

Tom



> -Original Message-
> From: Nathan West [mailto:nathan.w...@okstate.edu]
> Sent: Thursday, July 11, 2013 3:35 PM
> To: LD Zhang
> Cc: Nathan West; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for 
> streaming processing
>
> On Thu, Jul 11, 2013 at 6:13 PM, LD Zhang  wrote:
>> Hi, Please my comment below:
>>
>> You can probably get a rough estimate of the lower limit of your 
>> processors ability to do something like an FIR filter with some 
>> simple
>> calculations:
>> A 10-point FIR filter needs to do 10 multiplies and 9 additions.
>> Blissfully ignoring branching that's 19 instructions for each output.
>> So let's say we've got a simple FIR filter that outputs the same 
>> sample rate as it inputs.
>>
>> Using the table in here:
>> http://en.wikipedia.org/wiki/Instructions_per_second it looks like 
>> modern CPUs clocked around 1GHz should expect between 2-5 IPS / 
>> (1/clock
> speed).
>> Pick your favorite (I'm guessing you're on older hardware so let's go 
>> with 2). 2 * 1GHz = 2000 MIPs. So you can process 1M samples through 
>> a very poorly implemented 10-tap FIR filter. That in itself is also a 
>> pretty poor estimate. I see Marcus just replied as well and as he 
>> said, the best way to
>> *know* is just to try it out on your hardware; there's no substitute 
>> for that.
>>
>>
> I am confused: 10-tap FIR according to the above is 19 IPs, so 1M
>> samples correspond to 19 MIPS, much below the 2000 MIPS limit?
>> Am I missing something?
>>
>> LD
>>
>
> Hmm, I guess you're right. It's not too important because the actual 
> estimate wouldn't be close to anything close to what you would see.
> The point is there is no easy answer (other than just running 
> something to see if it works), but you might be able to come up with a 
> rough estimate if you really need to and your application is really 
> simple. You should probably ignore my lousy attempt :-P. I came up with it
on the fly...
> There's also the issue of how long it takes those instructions to execute.
>
> -Nathan
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] Loss of synchronization while creating new file

2013-07-16 Thread rmsrms1987 
Hi Marcus, 

Thank you for the prompt reply.  I have attached the two python programs
that have been written to do this type of acquisition.  From Snafoo.py the
only section of importance is the Rupdate.  Before any file is written, the
program checks the hard drive to make sure there is enough space to complete
the file.  If there is enough space, then the program initiates the data
collection program (rx.py).  The inputs to this class include the directory
to save to (self.indir), FIR filter coefficients (self.fr), and the file
size in seconds (self.fs).  Then the method 'run' is executed, which is a
function from the gr.top_block class. 
After writing this, it seems like the problem can potentially be the
commands that are executed between files.  These command will take a brief
amount of time, but enough to cause a slight phase difference between files. 
Do you think this may be the cause as well? If so, do you possibly have a
solution?

Thanks,
Robert








snafoo.py    rx.py
  



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Loss-of-synchronization-while-creating-new-file-tp42517p42522.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] Loss of synchronization while creating new file

2013-07-16 Thread Marcus D. Leech 

On 07/16/2013 06:34 PM, rmsrms1987 wrote:

Hi Marcus,

Thank you for the prompt reply.  I have attached the two python programs
that have been written to do this type of acquisition.  From Snafoo.py the
only section of importance is the Rupdate.  Before any file is written, the
program checks the hard drive to make sure there is enough space to complete
the file.  If there is enough space, then the program initiates the data
collection program (rx.py).  The inputs to this class include the directory
to save to (self.indir), FIR filter coefficients (self.fr), and the file
size in seconds (self.fs).  Then the method 'run' is executed, which is a
function from the gr.top_block class.
After writing this, it seems like the problem can potentially be the
commands that are executed between files.  These command will take a brief
amount of time, but enough to cause a slight phase difference between files.
Do you think this may be the cause as well? If so, do you possibly have a
solution?

Thanks,
Robert

You're basically doing a complete "session reset" between each 
file--there's no way you can maintain phase coherence across that

  "singularity".

A *MUCH* better approach is to use GRC, with a file sink, perhaps to a 
FIFO, and then an external program that cuts your stream up

  into individual files.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

[Discuss-gnuradio] help QAM16 Encoding / Transmission

2013-07-16 Thread tom sutherland 
I want to QAM16 encode a band limited (0-3khz) signal on one computer. I want 
to connect this computer to another computer running a QAM16 Decoder program. 
The QAM16 encoded signal needs to be able to be sent over the audio 
channel(single channel) of the computer. How can take the complex output of the 
QAM16 module and "mix" it so that it can be sent over a single audio channel? 
Need also to demodulate it on the other side.

Thanks...Tom 

Mixer_QAM DecodeOnly.grc
Description: Binary data


Mixer_QAM EncodeOnly.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FPGA code for N210

2013-07-16 Thread Sam mite 
Hi list,

I want to compile USRP N210 FPGA code. From where I can get the latest fpga
code for USRP N210 ? Please provide the link. Any help will be appreciated.

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

Re: [Discuss-gnuradio] FPGA code for N210

2013-07-16 Thread Ian Buckley 
https://github.com/EttusResearch/uhd

Under fpga/usrp2/top/N2x0

-Ian

On Jul 16, 2013, at 10:10 PM, Sam mite  wrote:

> Hi list,
> 
> I want to compile USRP N210 FPGA code. From where I can get the latest fpga 
> code for USRP N210 ? Please provide the link. Any help will be appreciated. 
> 
> -- 
> Sam
> ___
> 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] Specifying parameter type in .xml where parameter is a class defined in python

2013-07-16 Thread Manu T S 
Hello,

I have a block "ldpc_encoder", which takes as parameter an object of the
class "ldpc_parity".The block "ldpc_encoder" and the class "ldpc_parity"
are defined in python. The parameter is passed as a variable LDPC_Parity
into the __init__() method. I have successfully installed this block using
cmake tools.

Now I want to edit .xml file corresponding to this block. The automatically
generated(using mod_tool) .xml file is given below.
--


  ldpc_encoder
  ldpc_ldpc_encoder
  ldpc
  import ldpc
  ldpc.ldpc_encoder($LDPC_Parity)
  
  
...
...
...
  

  
  
in

  

  
  
out

  

-
>From what I understand,  I have to edit the parameter declaration to define
$LDPC_Parity as a parameter.
How do I specify the type in this case? Can I use import statements?

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

Re: [Discuss-gnuradio] Specifying parameter type in .xml where parameter is a class defined in python

2013-07-16 Thread Manu T S 
On Wed, Jul 17, 2013 at 12:03 PM, Manu T S  wrote:

> Hello,
>
> I have a block "ldpc_encoder", which takes as parameter an object of the
> class "ldpc_parity".The block "ldpc_encoder" and the class "ldpc_parity"
> are defined in python. The parameter is passed as a variable LDPC_Parity
> into the __init__() method. I have successfully installed this block using
> cmake tools.
>
> Now I want to edit .xml file corresponding to this block. The
> automatically generated(using mod_tool) .xml file is given below.
>
> --
> 
> 
>   ldpc_encoder
>   ldpc_ldpc_encoder
>   ldpc
>   import ldpc
>   ldpc.ldpc_encoder($LDPC_Parity)
>   
>   
> ...
> ...
> ...
>   
>
>   
>   
> in
> 
>   
>
>   
>   
> out
> 
>   
> 
>
> -
> From what I understand,  I have to edit the parameter declaration to
> define $LDPC_Parity as a parameter.
> How do I specify the type in this case? Can I use import statements?
>
> --
> Manu T S
>


Another question with reference to the earlier mail.
The input/output vector length are variables K and N respectively which are
computed inside the __init__() method. So how can I specify vlen tag under
sink/source tags?

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