Re: [Discuss-gnuradio] RFNoc and data rates

2015-09-24 Thread Marcus D. Leech

On 09/24/2015 06:37 PM, Simon Olvhammar wrote:
Yes, in my current Python Gnuradio application I have implemented 
Dicke-switching by syncing it with external signals that indicate S/R 
as well as transition state of RF. I have not seen any issues with 
overlapping fft:s. The switch frequency is 1 Hz and the transition 
state signal has an interval of perhaps 100us where no storing of ffts 
is done.


I'm still very new to signal processing and I'm having trouble to 
understand the relation between alpha and how much is averaged, I just 
see a scale factor in the transfer function? 0.01 seconds seems quite 
alot and to reduce this to 0.001 seconds I could perhaps choose 
alpha=0.1 and N=10 if I'm understanding you right? Are we talking same 
delay times if I were to implement this is my current non FPGA 
gnuradio app?


I have attached a flowgraph and it would be greatly appreciated if you 
could check if it looks right for the purpose of just storing averaged 
FFT:s.
Just looked at your flow-graph.  Looks OK to me, but at 100Msps, I 
imagine that your computer is working very, very hard.


Also, Gnu Radio doesn't have predictable latency, so trying to 
synchronize to your external Dicke-switching hardware will be a significant

  challenge.

Another approach, that Ken Tapping and I have used successfully, is what 
we call a differential radiometer:


http://www.sbrac.org/files/DTP_RX.pdf

This happens to use RTLSDR dongles, but the same approach of identical 
SDR RX chains providing full-time "sky" in one channel and
  "reference" in another eliminates the switching hardware, and the 
need to synchronize yourself with it



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


Re: [Discuss-gnuradio] RFNoc and data rates

2015-09-24 Thread Marcus D. Leech

On 09/24/2015 06:37 PM, Simon Olvhammar wrote:
Yes, in my current Python Gnuradio application I have implemented 
Dicke-switching by syncing it with external signals that indicate S/R 
as well as transition state of RF. I have not seen any issues with 
overlapping fft:s. The switch frequency is 1 Hz and the transition 
state signal has an interval of perhaps 100us where no storing of ffts 
is done.


I'm still very new to signal processing and I'm having trouble to 
understand the relation between alpha and how much is averaged, I just 
see a scale factor in the transfer function? 0.01 seconds seems quite 
alot and to reduce this to 0.001 seconds I could perhaps choose 
alpha=0.1 and N=10 if I'm understanding you right? Are we talking same 
delay times if I were to implement this is my current non FPGA 
gnuradio app?
You can chose the latency tradeoffs yourself.  If you want data 
delivered to the host faster, you'd likely choose a shorter integration

  time, by playing with alpha values.

But if your Dicke-switching time is on the order of 1s, then you could 
discard several FFT frames and still have very-high-quality data.


There's also a technique called "oblivious synchronous detection" 
developed by Ken Tapping at DRAO, and I did an implementation of it in
  my gr-ra_blocks package.  If the difference between "sky" and 
"reference" is more than a few dB, then you can just take buffers of data
  and "sort them into their houses"  (ref or sky) by "slicing" based on 
the distinct populations of samples, without having to worry about
  strict synchronization with your (external) switching source--the 
samples themselves tell you what "house" they belong in.






I have attached a flowgraph and it would be greatly appreciated if you 
could check if it looks right for the purpose of just storing averaged 
FFT:s.


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


Re: [Discuss-gnuradio] Questions about burst communication

2015-09-24 Thread lwashbo
Julian and Martin,

Typically 2 U's appear then a stream of O's. Ya, I don't have any sort of 
correlation block on the receiver side so that is definitely a problem. Next 
week I'll work on implementing a correlation block with a barker code preamble.

Do you have any suggestions for quick testing and validation? What I've been 
doing to check the bytes, if my acknowledgment fails, is to save the bytes to a 
file and use MATLAB to inspect them. Is there an easier way to quickly look at 
individual bytes?

I appreciate the help,

Logan

Sent from my Cyanogen phone

On Sep 24, 2015 4:12 PM, julian.arn...@ettus.com wrote:

Hi Logan,


The problem is that the USRP does not know where your burst of data starts and 
how long it is and therefore it will respond with Us as soon as no new data is 
coming in. In order to tell the USRP how long a packet of data is the USRP sink 
in GNURadio offers the 'length tag name' property. If you set this to something 
not empty the USRP sink will work like a tagged stream block and can therefore 
handle tagged streams properly. 


However, you are reporting to see Os and not Us. That is a little strange. 
Normally it indicates that your PC is not able to keep up with the processing 
of the incoming data. This should be more or less independent on weather or not 
you are transmitting bursty data. 

Are you not seeing any Us and only Os?


Cheers,

Julian



Am 24.09.2015 um 17:20 schrieb Washbourne, Logan 
:

Hello all,

I've been trying to modify the chat app tutorial into a system that can utilize 
USRPs and an acknowledgement system. The acknowledgement system works so far, 
the RX just sends a pdu back to the TX side saying that it received the 
message. I am now trying to implement the USRPs to have an over the air system, 
instead of just using one computer and simulating the channel. 

My grc files are on github, https://github.com/loganwashbourne/Logan.git. The 
modified Chat Receiver and Chat Sanitizer blocks are on the github as well.

My question is, do I need to treat a burst communication system different than 
a continuous system? My problem is that on each side I am getting O's whenever 
I start the program, I have tried increasing and decreasing the sampling rate, 
and I didn't see any change to the output. 

I am using the USRP1's, with the RFX2400 daughter boards. 

If anyone has any ideas or avenues for me to look into it would be much 
appreciated.

Logan Washbourne

Electrical Engineering Graduate Student

(Electromagnetics)


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

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


Re: [Discuss-gnuradio] RFNoc and data rates

2015-09-24 Thread Simon Olvhammar
Yes, in my current Python Gnuradio application I have implemented 
Dicke-switching by syncing it with external signals that indicate S/R as 
well as transition state of RF. I have not seen any issues with 
overlapping fft:s. The switch frequency is 1 Hz and the transition state 
signal has an interval of perhaps 100us where no storing of ffts is done.


I'm still very new to signal processing and I'm having trouble to 
understand the relation between alpha and how much is averaged, I just 
see a scale factor in the transfer function? 0.01 seconds seems quite 
alot and to reduce this to 0.001 seconds I could perhaps choose 
alpha=0.1 and N=10 if I'm understanding you right? Are we talking same 
delay times if I were to implement this is my current non FPGA gnuradio 
app?


I have attached a flowgraph and it would be greatly appreciated if you 
could check if it looks right for the purpose of just storing averaged 
FFT:s.


Den 2015-09-24 kl. 16:24, skrev mle...@ripnet.com:


Since you'd be decimating on the FPGA, your latency would be dominated 
by the rate at which you send FFTs to the host.  In the scenario 
descibed, that would be about 0.01second, plus the inherent group 
delay of the filters in the radio, which if you're running at full ADC 
bandwidth won't be much.


Define "instantaneous".  Are you switching between "sky" and 
"reference", and want to be sure that you have no cross-contamination 
between the two virtual "channels"?  You'll always have *some*.  When 
I've done similar things, I always discard some samples during the 
switching interval, because both analog and digital bits and pieces 
make samples delivered during that time ambiguous.


On 2015-09-24 03:48, Simon Olvhammar wrote:


Thanks!
One concern that I have however is how the iir filter will affect delays in the 
flow graph. In the current (non RFNoC) application; when I switch the input RF 
to another source I would like to to see an almost instantaneous change in the 
samples of the file sink. Which I pretty much do right now with all averaging 
done in python. Could the iir filter affect this aspect? What delay time could 
I expect from  the x310:s A/D converter down to file sink?

Simon

On 09/24/2015 02:14 AM, Marcus D. Leech wrote:

On 09/23/2015 06:13 PM, Simon Olvhammar wrote:
What would be a good choice for N in this case? However, this seems 
very promising and I thank you for your help! Cheers Simon
Whatever rate you're comfortable receiving integrated FFTs at. You'd 
adjust the 'alpha' value for the IIR filter and N appropriately. 
Let's say you're running the FFT input at full bandwidth--200Msps, 
and you have an FFT size of 2048. That's 97.7e3 FFTs/second being 
produced in the FFT machinery in RFNoC, including the complex-to-mag 
part. Run that through a single-pole-IIR filter with an alpha value 
of, let's say, 0.01 (or the integer/fixed-point equivalent). Then 
set your 'N' in keep-one-in-N to be about 100. You'll get roughly 
97.7e1 FFTs/second into your host instead of 97.7e3 FFTs/second. At 
those low rates, even a purely-Python-based secondary long-term 
integrator should be able to keep up just fine.

On 09/23/2015 11:40 PM, Marcus D. Leech wrote:

On 09/23/2015 04:19 PM, Simon Olvhammar wrote:
Hi Marcus, No, we also have some spectrometers for atmospheric 
measurements. Regarding the keep 1 in N. It occurs to me then 
that by using this I would loose (N-1)/N percent of the FFT data 
for a given amount of observation time? Or am I missing 
something? Simon
Since you're integrating prior to decimation here, there should be 
no loss of information.

Den 2015-09-23 kl. 21:40, skrev Marcus D. Leech:

On 09/23/2015 03:06 PM, Marcus D. Leech wrote:

On 09/23/2015 02:49 PM, Simon Olvhammar wrote:
Hello, Thank you for your answers. Yes we do alot of averaging 
to expose the signal, in some applications we even average 
over several months.
Are these astronomical spectral features? They usually aren't 
that wide, even with doppler spreading. 
___ 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] Fwd: Re: Transmission error

2015-09-24 Thread Rama V
Hi all,
I have tried to send packets to the receiver from /digital/narrowband
folder and it has mostly succeeded. The output I was able to get when I
sent the following commands were

Sender: ./benchmark_tx.py -p 4 -M 2 -f 2.43561G --tx-gain=28 -r 25
Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25

ok =  True  pktno = 1323  n_rcvd = 1303  n_right = 1294
ok =  True  pktno = 1324  n_rcvd = 1304  n_right = 1295
ok =  True  pktno = 1325  n_rcvd = 1305  n_right = 1296
ok =  True  pktno = 1326  n_rcvd = 1306  n_right = 1297
ok =  True  pktno = 1327  n_rcvd = 1307  n_right = 1298
ok =  True  pktno = 1328  n_rcvd = 1308  n_right = 1299
ok =  True  pktno = 1329  n_rcvd = 1309  n_right = 1300
ok =  True  pktno = 1330  n_rcvd = 1310  n_right = 1301
ok = False  pktno = 1331  n_rcvd = 1311  n_right = 1301

But there were a few packets where I have not received them correctly. I
guess only 95% of them were efficient in transmitting.  I have tried
changing the gain settings and what I observed was that if I decrease the
gain from its normal value, the reception of packets are somewhat less
efficient. Can I kindly know what I might be able to do in order to receive
those packets in a more efficient way or is that what generally happens in
a real world transmission? Thanks

Regards,
Dave

On Tue, Sep 22, 2015 at 1:02 PM, Marcus Müller 
wrote:

> Ok,
>
> This is because I have changed my folder to /digital/ofdm, I have started
> to receive packets.
>
> this means that you're using something *completely* different than before.
> It's simply a completely different transceiver system.
>
> kindly advise if I need to figure out the combination settings till most
> of them receive properly?
>
> Yes. You will need to figure out the optimum settings. Increase gain on
> the RX end, see if things get better or worse. Find an optimum for that. Do
> the same with the TX gain.
>
> Because even though I did not set any sample rate, the transmitter sent
> the information.
>
> As mentioned before multiple times: run the programs with "--help". They
> will show you what default settings they have.
>
> Please help. Please excuse me if I am being naive in asking these.
>
> It's alright to ask questions, but please remember to apply the things we
> tell you.
>
> Best regards,
> Marucs
>
>
> On 22.09.2015 00:59, Rama V wrote:
>
> Hi,
> As advised, the problem has been solved to a little extent where I have
> got the below results by giving the commands as
>
> Sender : ./benchmark_tx.py -f 2.435G --tx-gain=25
> Receiver: ./benchmark_rx.py -f 2.435G --rx-gain 50
>
> ok: True  pktno: 1971  n_rcvd: 1687  n_right: 358
> ok: False  pktno: 1972  n_rcvd: 1688  n_right: 358
> ok: False  pktno: 1973  n_rcvd: 1689  n_right: 358
> ok: False  pktno: 1974  n_rcvd: 1690  n_right: 358
> ok: True  pktno: 1975  n_rcvd: 1691  n_right: 359
> ok: False  pktno: 1976  n_rcvd: 1692  n_right: 359
> ok: True  pktno: 1977  n_rcvd: 1693  n_right: 360
> ok: False  pktno: 1978  n_rcvd: 1694  n_right: 360
> ok: True  pktno: 1979  n_rcvd: 1695  n_right: 361
> ok: True  pktno: 1980  n_rcvd: 1696  n_right: 362
> ok: False  pktno: 1981  n_rcvd: 1697  n_right: 362
> ok: True  pktno: 1982  n_rcvd: 1698  n_right: 363
> ok: False  pktno: 1983  n_rcvd: 1699  n_right: 363
> ok: True  pktno: 1984  n_rcvd: 1700  n_right: 364
> ok: False  pktno: 1985  n_rcvd: 1701  n_right: 364
> ok: True  pktno: 1986  n_rcvd: 1702  n_right: 365
> ok: False  pktno: 1987  n_rcvd: 1703  n_right: 365
> ok: True  pktno: 1988  n_rcvd: 1704  n_right: 366
>
> This is because I have changed my folder to /digital/ofdm, I have started
> to receive packets. But I guess this is only 50% efficient in receiving
> packets. Not all of them have been receiving properly. kindly advise if I
> need to figure out the combination settings till most of them receive
> properly? Because even though I did not set any sample rate, the
> transmitter sent the information. Please help. Please excuse me if I am
> being naive in asking these.
>
> Regards,
> Dave
>
> On Mon, Sep 21, 2015 at 11:00 AM, Rama V  wrote:
>
>> Hi,
>> Thanks Marcus. I will do as you have advised and approach if any
>> uncertainties.
>>
>> Regards,
>> Dave
>>
>> On Mon, Sep 21, 2015 at 10:16 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Hi Dave,
>>>
>>> you shouldn't be modifying the python files before you understand what
>>> they do exactly. Please revert your edits, because it will be impossible to
>>> help you if you don't use the same scripts as we do, obviously. We've
>>> talked about this[1].
>>>
>>> So:
>>>
>>> Sender : benchmark_tx.py -f 2.435G -r 250k
>>> Receiver : benchmark_rx.py -f 2.435G
>>>
>>> That's wrong! Now, your transmitter sends 250,000 bits per second, but
>>> your receiver expec

Re: [Discuss-gnuradio] Function Probe and OOT Blocks

2015-09-24 Thread Patrick Sathyanathan
Attaching reply as text since outlook.com insists on eating XML and formatting.


--Patrick


> From: mcqui...@sfu.ca 
> Date: Thu, 24 Sep 2015 10:35:34 -0700 
> To: david.ha...@toshiba-trel.com 
> CC: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] Function Probe and OOT Blocks 
> 
> Hi David: 
> 
> I'm a relative newbie myself, but I can say that I had this same issue. 
> I had a block with a static parameter that I wanted to be able to 
> change dynamically at runtime. 
> 
> I looked at the block's source code, and also at a block that had a 
> dynamically adjustable parameter. 
> 
> Basically, and with a little help from the list (Marcus Muller in 
> particular) as I had to learn c++, I was able to use the code from the 
> dynamic block as an example, and modify the static block to change the 
> parameter to be dynamically changeable. It all came down to at most a 
> couple dozen lines of code. The bigger challenge was learning about 
> Gnuradio's architecture, to know what to do. 
> 
> I would suggest a similar approach. You will find the list members 
> very helpful. I'd also look at the guided tutorials, there are good 
> examples there under "how to write a c++ block". 
> 
> I will help if I can but alas, I am still quite a newbie, so others 
> will be able to help much more efficiently! 
> 
> Kevin 
> 
> Sent from my iPad 
> 
> On Sep 23, 2015, at 4:12 AM, David Halls 
> mailto:david.ha...@toshiba-trel.com>> 
> wrote: 
> 
> 
> ​Hi guys, 
> 
> 
> I am familiar with using function probes to update values to blocks. 
> This is straightforward with built in blocks like Multiply Const, where 
> the input is underline in the GRC dialogue box. 
> 
> 
> How do I create a block, specifically a Python block, that allows me to 
> update parameters in this fashion so that they are not fixed at 
> runtime? 
> 
> 
> Regards, 
> 
> 
> David 
> 
>  
> 
> 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 
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio   
>   Hi David, 

Making the parameter vary at runtime is simple and just needs 
some extra XML and python code. The parameter should be an argument to 
the __init__ method (constructor) of your block and should have a "" 
declaration in the matching XML file. Let's say the parameter name is 
"variable_param" with a declaration like:


   Variable parameter
   variable_param
   42
   int


Then you need to add the following in the XML file: 

set_variable_param($variable_param)

And you need to implement the "set_variable_param" method in your python class 
to take whatever action is needed when the parameter value changes. This method 
will be called every time the value of the expression in the underlined 
"Variable parameter" box in the GUI changes. The method will look like: 

   def set_variable_param(self, new_value): 
  whatever code 
  
This should make GRC underline the variable_param in the GUI and it will be 
variable 
at runtime. 

Thanks, 

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


Re: [Discuss-gnuradio] host format versus device format

2015-09-24 Thread Martin Braun
On 23.09.2015 11:44, Jason Matusiak wrote:
> For some reason I got myself wrapped around the axle with what is going
> on with the host and device format options.  For instance, if I look at
> the RFNoC Radio block, it has a host format with the options: complex
> float32, complex int16, and vita word32, and a device format of complex
> int16 (with no other options).
> 
> The way I understand things, the host format is basically the wire
> connection between blocks.  So complex float32 is I/Q with 4B for each
> in float format (so 8B per sample), and complex int16 is 2B on int for
> I/Q (4B per sample).  Am I still OK?  If so, I am failing to understand
> the device format option...
> 
> Although, all that said, as I look at a USRP Source block, it uses the
> term "output type" (which is analogous to the host format) and a "wire
> format" which I am guessing is the same as the "device format"  If that
> is correct, that means I don't have any idea what that wire is doing (as
> I would have mentally thought that the output type is the "wire").
> 
> I tried looking for some documentation on this but came up empty (though
> I am sure it is out there somewhere).

Good point about lacking info. Here's the gist of it:

- When data goes from device -> host, it uses the wire format (or otw
format)
- On the host, it gets converted to the host format inside UHD.
- Currently, all FPGA blocks use integer formats, on the X300, it's
always sc16
- In RFNoC, things become ambiguous. If you connect rfnoc block -> rfnoc
block, you never use the host format, even if it's set. If you connect
rfnoc block -> host, you convert to host format on the host. Downstream
GNU Radio blocks will thus use host format.

Not sure if this answers all your questions, but please come back if you
have any more!

Cheers,
Martin


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


Re: [Discuss-gnuradio] Function Probe and OOT Blocks

2015-09-24 Thread Patrick Sathyanathan
Retrying in plain text, since browser/outlook ate the XML I had typed:


Hi David, 


Making the parameter vary at runtime is simple and just needs some extra XML 
and python code. 

The parameter should be an argument to the __init__ method (constructor) of 
your block and should 

have a "" declaration in the matching XML file. Let's say the parameter name is 

"variable_param" with a declaration like:



   Variable parameter
   variable_param
   42
   int



Then you need to add the following in the XML file: 


set_variable_param($variable_param)


And you need to implement the "set_variable_param" method in your python class 
to take whatever 

action is needed when the parameter value changes. This method will be called 
every time the value 

of the expression in the underlined "Variable parameter" box in the GUI 
changes. The method will look 

like: 


   def set_variable_param(self, new_value): 
  whatever code 
  
This should make GRC underline the variable_param in the GUI and it will be 
variable at runtime. 


Thanks, 


--Patrick 

From: mcqui...@sfu.ca
Date: Thu, 24 Sep 2015 10:35:34 -0700
To: david.ha...@toshiba-trel.com
CC: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Function Probe and OOT Blocks


Hi David:




I'm a relative newbie myself, but I can say that I had this same issue.  I had 
a block with a static parameter that I wanted to be able to change dynamically 
at runtime.




I looked at the block's source code, and also at a block that had a dynamically 
adjustable parameter.




Basically, and with a little help from the list (Marcus Muller in particular) 
as I had to learn c++, I was able to use the code from the dynamic block as an 
example, and modify the static block to change the parameter to be dynamically 
changeable. It all came down to at most a couple dozen lines of code. The 
bigger challenge was learning about Gnuradio's architecture, to know what to do.




I would suggest a similar approach. You will find the list members very 
helpful. I'd also look at the guided tutorials, there are good examples there 
under "how to write a c++ block".




I will help if I can but alas, I am still quite a newbie, so others will be 
able to help much more efficiently!




Kevin

Sent from my iPad


On Sep 23, 2015, at 4:12 AM, David Halls  wrote:




​Hi guys,





I am familiar with using function probes to update values to blocks. This is 
straightforward with built in blocks like Multiply Const, where the input is 
underline in the GRC dialogue box.





How do I create a block, specifically a Python block, that allows me to update 
parameters in this fashion so that they are not fixed at runtime?





Regards,





David





 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 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] Questions about burst communication

2015-09-24 Thread julian . arnold
Hi Logan,

The problem is that the USRP does not know where your burst of data starts and 
how long it is and therefore it will respond with Us as soon as no new data is 
coming in. In order to tell the USRP how long a packet of data is the USRP sink 
in GNURadio offers the 'length tag name' property. If you set this to something 
not empty the USRP sink will work like a tagged stream block and can therefore 
handle tagged streams properly. 

However, you are reporting to see Os and not Us. That is a little strange. 
Normally it indicates that your PC is not able to keep up with the processing 
of the incoming data. This should be more or less independent on weather or not 
you are transmitting bursty data. 
Are you not seeing any Us and only Os?

Cheers,
Julian



> Am 24.09.2015 um 17:20 schrieb Washbourne, Logan 
> :
> 
> Hello all,
> 
> I've been trying to modify the chat app tutorial into a system that can 
> utilize USRPs and an acknowledgement system. The acknowledgement system works 
> so far, the RX just sends a pdu back to the TX side saying that it received 
> the message. I am now trying to implement the USRPs to have an over the air 
> system, instead of just using one computer and simulating the channel. 
> 
> My grc files are on github, https://github.com/loganwashbourne/Logan.git. The 
> modified Chat Receiver and Chat Sanitizer blocks are on the github as well.
> 
> My question is, do I need to treat a burst communication system different 
> than a continuous system? My problem is that on each side I am getting O's 
> whenever I start the program, I have tried increasing and decreasing the 
> sampling rate, and I didn't see any change to the output. 
> 
> I am using the USRP1's, with the RFX2400 daughter boards. 
> 
> If anyone has any ideas or avenues for me to look into it would be much 
> appreciated.
> 
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Submitting OOT Module Questions

2015-09-24 Thread Martin Braun
Ron's comment is very helpful, here's some more factoids:

On 23.09.2015 13:55, Richard Bell wrote:
> Sorry if these are obvious questions, but this is very not obvious to
> me. As I understand it right now, it's not even a question of copy and
> pasting files over to gr-analog, because that would overwrite the code
> for all the other blocks, at least when it comes to swig. So let me
> outline what I need to do and see how close I am to understanding this:
> 
> 1) I can copy and paste the source code, the qa code and example files
> over to corresponding gr-analog directories
> 2) I have to make changes to existing swig files in gr-analog, which
> amounts to copying the various lines from my OOT swig into the gr-analog
> swig
> 3) I don't know if I should be copying CMakeFile stuff or touching any
> of that by hand. I need guidance here.

You can use gr_modtool inside in-tree components. Maybe that'll help you
show how to set up stuff. Otherwise, reading the CMake files should give
you all you need to know -- just follow how the other blocks are added.

> Am I supposed to build this and confirm its merged correctly before I
> submit a pull request?

Absolutely! I haven't checked your code, but I'm hoping it includes unit
tests? So, please make, make test, make install and see it works in GRC.
If you can provide example flowgraphs in gr-analog/examples, that'll be
great, too.

Cheers,
Martin

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


Re: [Discuss-gnuradio] Questions about burst communication

2015-09-24 Thread Martin Braun
On 24.09.2015 08:20, Washbourne, Logan wrote:
> My question is, do I need to treat a burst communication system
> different than a continuous system? My problem is that on each side I am
> getting O's whenever I start the program, I have tried increasing and
> decreasing the sampling rate, and I didn't see any change to the output.
> 
> I am using the USRP1's, with the RFX2400 daughter boards.

Choice of USRP shouldn't matter. I haven't checked out your fg, but
here's a couple of facts: O's mean your receiving end isn't picking up
stuff fast enough. Also, your receiver needs to run continuously because
it doesn't know when packets are coming in. So yes, your bursty receiver
is no different from a continuous receiver in this respect.

Have you made sure you can sustain the receive rates on your machine?

Cheers,
Martin

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


Re: [Discuss-gnuradio] Announcing cgran.org: Re-launching the Comprehensive GNU Radio Archive Network

2015-09-24 Thread West, Nathan
On Thu, Sep 24, 2015 at 3:51 PM, Andrea Montefusco <
andrea.montefu...@gmail.com> wrote:

> On 04/05/2015 07:16 PM, Martin Braun wrote:
>
> There are automatic update cycles. The whole design hinges upon us not
>> having to do any manual
>> intervention.
>>
>> In a nutshell, we fetch all the recipes for OOTs on a regular basis, run
>> our CGRAN codes against
>> that, and update the page.
>>
>> As an OOT maintainer, there's nothing you need to do except wait a few
>> hours tops.
>>
>
> Hi Martin,
> a few days ago I submitted the pull  request in order to have the recipes
> for Persues HF receiver modules added in
> https://github.com/gnuradio/recipes.
> The pull request was accepted and  the two recipe files are there now.
> Afterwards I created the MANIFEST.md into
> https://github.com/amontefusco/gr-microtelecom , however the cgran.org
> home page didn't get updated.
> I am quite doubtful about the following line in the MANIFEST.md:
>
> repo: https://github.com/amontefusco/gr-microtelecom
>
> Maybe should I have add a git:// as prefix or I did something else wrong ?
>
>
>  73 *am*
>
> --
> Andrea Montefusco iw0hdv   (ex FAI10655) http://www.montefusco.com
> tel: +393356992791  fax: +390623318709
> --
>
>
You've done it correctly and the page is updated. I just need to go to
another hackfest and spend a day fine-tuning things.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Function Probe and OOT Blocks

2015-09-24 Thread Patrick Sathyanathan
Hi David,




Making the parameter vary at runtime is simple and just needs some extra XML 
and python code. The parameter should be an argument to the __init__ method 
(constructor) of your block and should have a "" declaration in the matching 
XML file. Let's say the parameter name is "variable_param" with a declaration 
like:






   Variable parameter

   variable_param

   42

   int






Then you need to add the following in the XML file:




set_variable_param($variable_param)




And you need to implement the "set_variable_param" method in your python class 
to take whatever action is needed when the parameter value changes. This method 
will be called every time the value of the expression in the underlined 
"Variable parameter" box in the GUI changes. The method will look like:





 def set_variable_param(self, new_value):

   whatever code




This should make GRC underline the variable_param in the GUI and it will be 
variable at runtime.




Thanks,




--Patrick


> From: mcqui...@sfu.ca 
> Date: Thu, 24 Sep 2015 10:35:34 -0700 
> To: david.ha...@toshiba-trel.com 
> CC: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] Function Probe and OOT Blocks 
> 
> Hi David: 
> 
> I'm a relative newbie myself, but I can say that I had this same issue. 
> I had a block with a static parameter that I wanted to be able to 
> change dynamically at runtime. 
> 
> I looked at the block's source code, and also at a block that had a 
> dynamically adjustable parameter. 
> 
> Basically, and with a little help from the list (Marcus Muller in 
> particular) as I had to learn c++, I was able to use the code from the 
> dynamic block as an example, and modify the static block to change the 
> parameter to be dynamically changeable. It all came down to at most a 
> couple dozen lines of code. The bigger challenge was learning about 
> Gnuradio's architecture, to know what to do. 
> 
> I would suggest a similar approach. You will find the list members 
> very helpful. I'd also look at the guided tutorials, there are good 
> examples there under "how to write a c++ block". 
> 
> I will help if I can but alas, I am still quite a newbie, so others 
> will be able to help much more efficiently! 
> 
> Kevin 
> 
> Sent from my iPad 
> 
> On Sep 23, 2015, at 4:12 AM, David Halls 
>  
> wrote: 
> 
> 
> ​Hi guys, 
> 
> 
> I am familiar with using function probes to update values to blocks. 
> This is straightforward with built in blocks like Multiply Const, where 
> the input is underline in the GRC dialogue box. 
> 
> 
> How do I create a block, specifically a Python block, that allows me to 
> update parameters in this fashion so that they are not fixed at 
> runtime? 
> 
> 
> Regards, 
> 
> 
> David 
> 
>  
> 
> 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 
> 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] Announcing cgran.org: Re-launching the Comprehensive GNU Radio Archive Network

2015-09-24 Thread Andrea Montefusco

On 04/05/2015 07:16 PM, Martin Braun wrote:


There are automatic update cycles. The whole design hinges upon us not having 
to do any manual
intervention.

In a nutshell, we fetch all the recipes for OOTs on a regular basis, run our 
CGRAN codes against
that, and update the page.

As an OOT maintainer, there's nothing you need to do except wait a few hours 
tops.


Hi Martin,
a few days ago I submitted the pull  request in order to have the recipes for Persues HF receiver 
modules added in https://github.com/gnuradio/recipes.

The pull request was accepted and  the two recipe files are there now.
Afterwards I created the MANIFEST.md into https://github.com/amontefusco/gr-microtelecom , however 
the cgran.org home page didn't get updated.

I am quite doubtful about the following line in the MANIFEST.md:

repo: https://github.com/amontefusco/gr-microtelecom

Maybe should I have add a git:// as prefix or I did something else wrong ?


 73 *am*

--
Andrea Montefusco iw0hdv   (ex FAI10655) http://www.montefusco.com
tel: +393356992791  fax: +390623318709
--

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


Re: [Discuss-gnuradio] Function Probe and OOT Blocks

2015-09-24 Thread Kevin McQuiggin
Hi David:

I'm a relative newbie myself, but I can say that I had this same issue.  I had 
a block with a static parameter that I wanted to be able to change dynamically 
at runtime.

I looked at the block's source code, and also at a block that had a dynamically 
adjustable parameter.

Basically, and with a little help from the list (Marcus Muller in particular) 
as I had to learn c++, I was able to use the code from the dynamic block as an 
example, and modify the static block to change the parameter to be dynamically 
changeable.  It all came down to at most a couple dozen lines of code.  The 
bigger challenge was learning about Gnuradio's architecture, to know what to do.

I would suggest a similar approach.  You will find the list members very 
helpful.  I'd also look at the guided tutorials, there are good examples there 
under "how to write a c++ block".

I will help if I can but alas, I am still quite a newbie, so others will be 
able to help much more efficiently!

Kevin

Sent from my iPad

On Sep 23, 2015, at 4:12 AM, David Halls mailto:david.ha...@toshiba-trel.com>> wrote:

> ​Hi guys,
> 
> I am familiar with using function probes to update values to blocks. This is 
> straightforward with built in blocks like Multiply Const, where the input is 
> underline in the GRC dialogue box.
> 
> How do I create a block, specifically a Python block, that allows me to 
> update parameters in this fashion so that they are not fixed at runtime?
> 
> Regards,
> 
> David
> 
> 
> 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 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] missing length tag

2015-09-24 Thread cdl
hello
i write a grc,i use the virtual sink and virtual source,the grc woked well
when i replace the virtual sin and source with usrp sink and source,there is a 
problem occured
the message is:

gr::log :FATAL: repack_bits_bb0 - Missing a required length tag on port 0 at 
item #0
thread[thread-per-block[10]: ]: Missing length tag.

i have set the block (repack bits)'s parameter length tag key  == "tsb_tag",
but what this message "missing length tag" mean,
thank you


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


[Discuss-gnuradio] Questions about burst communication

2015-09-24 Thread Washbourne, Logan
Hello all,

I've been trying to modify the chat app tutorial into a system that can
utilize USRPs and an acknowledgement system. The acknowledgement system
works so far, the RX just sends a pdu back to the TX side saying that it
received the message. I am now trying to implement the USRPs to have an
over the air system, instead of just using one computer and simulating the
channel.

My grc files are on github, https://github.com/loganwashbourne/Logan.git.
The modified Chat Receiver and Chat Sanitizer blocks are on the github as
well.

My question is, do I need to treat a burst communication system different
than a continuous system? My problem is that on each side I am getting O's
whenever I start the program, I have tried increasing and decreasing the
sampling rate, and I didn't see any change to the output.

I am using the USRP1's, with the RFX2400 daughter boards.

If anyone has any ideas or avenues for me to look into it would be much
appreciated.

Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] RFNoc and data rates

2015-09-24 Thread mleech
 

Since you'd be decimating on the FPGA, your latency would be dominated
by the rate at which you send FFTs to the host. In the scenario
descibed, that would be about 0.01second, plus the inherent group delay
of the filters in the radio, which if you're running at full ADC
bandwidth won't be much. 

Define "instantaneous". Are you switching between "sky" and "reference",
and want to be sure that you have no cross-contamination between the two
virtual "channels"? You'll always have *some*. When I've done similar
things, I always discard some samples during the switching interval,
because both analog and digital bits and pieces make samples delivered
during that time ambiguous. 

On 2015-09-24 03:48, Simon Olvhammar wrote: 

> Thanks!
> One concern that I have however is how the iir filter will affect delays in 
> the flow graph. In the current (non RFNoC) application; when I switch the 
> input RF to another source I would like to to see an almost instantaneous 
> change in the samples of the file sink. Which I pretty much do right now with 
> all averaging done in python. Could the iir filter affect this aspect? What 
> delay time could I expect from the x310:s A/D converter down to file sink?
> 
> Simon
> 
> On 09/24/2015 02:14 AM, Marcus D. Leech wrote:
> On 09/23/2015 06:13 PM, Simon Olvhammar wrote: What would be a good choice 
> for N in this case? However, this seems very promising and I thank you for 
> your help! Cheers Simon Whatever rate you're comfortable receiving integrated 
> FFTs at. You'd adjust the 'alpha' value for the IIR filter and N 
> appropriately. Let's say you're running the FFT input at full 
> bandwidth--200Msps, and you have an FFT size of 2048. That's 97.7e3 
> FFTs/second being produced in the FFT machinery in RFNoC, including the 
> complex-to-mag part. Run that through a single-pole-IIR filter with an alpha 
> value of, let's say, 0.01 (or the integer/fixed-point equivalent). Then set 
> your 'N' in keep-one-in-N to be about 100. You'll get roughly 97.7e1 
> FFTs/second into your host instead of 97.7e3 FFTs/second. At those low rates, 
> even a purely-Python-based secondary long-term integrator should be able to 
> keep up just fine. On 09/23/2015 11:40 PM, Marcus D. Leech wrote: On 
> 09/23/2015 04:19 PM, Simon Olvhammar wrote: Hi Marcus,
No, we also have some spectrometers for atmospheric measurements. Regarding the 
keep 1 in N. It occurs to me then that by using this I would loose (N-1)/N 
percent of the FFT data for a given amount of observation time? Or am I missing 
something? Simon Since you're integrating prior to decimation here, there 
should be no loss of information. Den 2015-09-23 kl. 21:40, skrev Marcus D. 
Leech: On 09/23/2015 03:06 PM, Marcus D. Leech wrote: On 09/23/2015 02:49 PM, 
Simon Olvhammar wrote: Hello, Thank you for your answers. Yes we do alot of 
averaging to expose the signal, in some applications we even average over 
several months.
 Are these astronomical spectral features? They usually aren't that
wide, even with doppler spreading.
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] 

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

 

Links:
--
[1] 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] import Qwt error

2015-09-24 Thread Michael Dickens
Hi Nemanja - SIP is used in Qwt and other PyQt related projects. It has
its own internal API, which must be compatible for all Python modules
being loaded (including SIP itself). So, what this error means is that
the Qwt module was built using a given SIP API (6.0 looks like), then
SIP was upgraded to provide a newer API (11.[01] looks like). The
solution is to rebuild/reinstall the offending module[s] (Qwt looks
like) using the new SIP version. Hope this helps! - MLD

On Thu, Sep 24, 2015, at 07:17 AM, Nemanja Savic wrote:
> i am trying to install gnuradio 3.7.7.1 version og gnuradio on my
> RHEL6 machine in a local path and to preserve my 3.6.5.1 version.
> After instaling many different programs i also screwed my old version.
> Ok it was not that bad but filter design tool doesn't work for me. I
> get the following error
>
> Traceback (most recent call last):  File
> "/usr/local/bin/gr_filter_design", line 22, in     import
> PyQt4.Qwt5 as Qwt  File "/usr/lib64/python2.6/site-
> packages/PyQt4/Qwt5/__init__.py", line 32, in     from Qwt
> import * RuntimeError: the sip module implements API v11.0 to v11.1
> but the PyQt4.Qwt5.Qwt module requires API v6.0
>
> Did anybody has already ex[erienced this error and maybe have
> suggestion how to solve it?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] import Qwt error

2015-09-24 Thread Nemanja Savic
Hi all guys,

i am trying to install gnuradio 3.7.7.1 version og gnuradio on my RHEL6
machine in a local path and to preserve my 3.6.5.1 version. After instaling
many different programs i also screwed my old version. Ok it was not that
bad but filter design tool doesn't work for me. I get the following error

Traceback (most recent call last):
  File "/usr/local/bin/gr_filter_design", line 22, in 
import PyQt4.Qwt5 as Qwt
  File "/usr/lib64/python2.6/site-packages/PyQt4/Qwt5/__init__.py", line
32, in 
from Qwt import *
RuntimeError: the sip module implements API v11.0 to v11.1 but the
PyQt4.Qwt5.Qwt module requires API v6.0


Did anybody has already ex[erienced this error and maybe have suggestion
how to solve it?

Cheers,

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


Re: [Discuss-gnuradio] RFNoc and data rates

2015-09-24 Thread Simon Olvhammar

Thanks!
One concern that I have however is how the iir filter will affect delays 
in the flow graph. In the current (non RFNoC) application; when I switch 
the input RF to another source I would like to to see an almost 
instantaneous change in the samples of the file sink. Which I pretty 
much do right now with all averaging done in python. Could the iir 
filter affect this aspect? What delay time could I expect from  the 
x310:s A/D converter down to file sink?


Simon

On 09/24/2015 02:14 AM, Marcus D. Leech wrote:

On 09/23/2015 06:13 PM, Simon Olvhammar wrote:

What would be a good choice for N in this case?
However, this seems very promising and I thank you for your help!

Cheers
Simon
Whatever rate you're comfortable receiving integrated FFTs at. You'd 
adjust the 'alpha' value for the IIR filter and N appropriately.


Let's say you're running the FFT input at full bandwidth--200Msps, and 
you have an FFT size of 2048.  That's 97.7e3 FFTs/second
  being produced in the FFT machinery in RFNoC, including the 
complex-to-mag part.  Run that through a single-pole-IIR filter with
  an alpha value of, let's say, 0.01 (or the integer/fixed-point 
equivalent).  Then set your 'N' in keep-one-in-N to be about 100. 
You'll get
  roughly 97.7e1 FFTs/second into your host instead of 97.7e3 
FFTs/second.  At those low rates, even a purely-Python-based secondary

  long-term integrator should be able to keep up just fine.




On 09/23/2015 11:40 PM, Marcus D. Leech wrote:

On 09/23/2015 04:19 PM, Simon Olvhammar wrote:

Hi Marcus,
No, we also have some spectrometers for atmospheric measurements.

Regarding the keep 1 in N. It occurs to me then that by using this 
I would loose (N-1)/N percent of the FFT data for a given amount of 
observation time? Or am I missing something?

Simon
Since you're integrating prior to decimation here, there should be 
no loss of information.





Den 2015-09-23 kl. 21:40, skrev Marcus D. Leech:

On 09/23/2015 03:06 PM, Marcus D. Leech wrote:

On 09/23/2015 02:49 PM, Simon Olvhammar wrote:

Hello,
Thank you for your answers.
Yes we do alot of averaging to expose the signal, in some 
applications we even average over several months.
Are these astronomical spectral features?   They usually aren't 
that wide, even with doppler spreading.




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



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



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



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



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



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