Re: Regarding missing osmocom source

[Fabian Schwartau]

Hi,
I cannot open the grc file, it complains with some parsing error.
However, I am wandering what you did in the screenshot. That makes no
sense to me. You have the BladeRF at 2.4 GHz center frequency with a
sample rate of 61.44 MHz (is that supported by the BladeRF?). Even if,
why are you generating an additional signal with a Frequency of -2.4GHz
at a sample rate of 61.44 MHz? It is certainly possible to do that, but
I think it is not your intention. The signal coming from the Osmocom
source is centered around 2.4 GHz, thus a frequency of 0 corresponds to
2.4 GHz. Remove the "Signal Source" and just display the received
spectrum. On the TX side set the osmocom sink to 2.4 GHz and set the
signal source you use to feed the osmocom sink with to something like 1
MHz. Now you should see a signal at 1 MHz in the receiver.

Best regards,
Fabian

Am 18.11.20 um 11:20 schrieb Rozana Alam:
> Hello community,
> I am trying to transmit  continuous waves (CW signal)  using bladeRF
> through gnu-radio. i can see the transmitting signal through QT-Gui but
> i can't receive the signal in network analyser. In the gnu block i have
> used signal source and osmocom sink to transmit signal. I am attaching
> my grc file and snapshots for your reference. I would really appreciate
> your help.
> Sincerely,
> Rozana
> 
> On Wed, Nov 4, 2020 at 4:39 PM Rozana Alam  > wrote:
> 
> Hello community,
> I want to generate simple continuous wave with bladeRF using gnu
> radio and am a Linux user.but in the gnu platform I am not getting
> any osmocom source.i have downloaded the gnu from ppa .is there any
> supplement of osmocom source to generate signal by bladeRF?
> Your suggestions are highly appreciated.
> Best regards,
> Rozana.
>   
> 

Re: Regarding missing osmocom source

[Aditya Arun Kumar]

You are trying to transmit right?
Source is used for receiving data, not transmitting. Use a Osmo Sink.

On Wed, Nov 18, 2020 at 3:53 PM Rozana Alam  wrote:

> Hello community,
> I am trying to transmit  continuous waves (CW signal)  using bladeRF
> through gnu-radio. i can see the transmitting signal through QT-Gui but i
> can't receive the signal in network analyser. In the gnu block i have used
> signal source and osmocom sink to transmit signal. I am attaching my grc
> file and snapshots for your reference. I would really appreciate your help.
> Sincerely,
> Rozana
>
> On Wed, Nov 4, 2020 at 4:39 PM Rozana Alam  wrote:
>
>> Hello community,
>> I want to generate simple continuous wave with bladeRF using gnu radio
>> and am a Linux user.but in the gnu platform I am not getting any osmocom
>> source.i have downloaded the gnu from ppa .is there any supplement of
>> osmocom source to generate signal by bladeRF?
>> Your suggestions are highly appreciated.
>> Best regards,
>> Rozana.
>>
>>

-- 
S. Aditya Arun Kumar
Security Researcher, Comms
+919123517465

Re: [USRP-users] Direction finding based on USRP E310 board

[Ivan Zahartchuk]

Another question of interest is which channels are coherent? Rx1 and RX2 or
RX1 and RX / TX?

вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice :

> Right!
> Be careful, DOA estimation using only 2 antennas works but it’s not so
> accurate.
> Enjoy!
>
> Ivan
>
> > Il giorno 17 nov 2020, alle ore 00:35, Ivan Zahartchuk <
> adray0...@gmail.com> ha scritto:
> >
> > 
> >
> >
> >
> > That is, in theory, I can simply start two streams from two channels and
> further process them using certain direction finding algorithms?
> >
> >
>
>

Re: [USRP-users] Direction finding based on USRP E310 board

[Julian Arnold]

Ivan,

to the best of my knowledge, there should not be any RX1 port.
Instead, you should have two (coherent) channels "A" and "B" both 
allowing you to select one out of two available antenna ports when 
receiving ("TX/RX" or "RX2").


Cheers,
Julian

On 11/18/20 10:31 AM, Ivan Zahartchuk via USRP-users wrote:


Another question of interest is which channels are coherent? Rx1 and RX2 
or RX1 and RX / TX?


вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice >:


Right!
Be careful, DOA estimation using only 2 antennas works but it’s not
so accurate.
Enjoy!

Ivan

 > Il giorno 17 nov 2020, alle ore 00:35, Ivan Zahartchuk
mailto:adray0...@gmail.com>> ha scritto:
 >
 > 
 >
 >
 >
 > That is, in theory, I can simply start two streams from two
channels and further process them using certain direction finding
algorithms?
 >
 >


___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Direction finding based on USRP E310 board

[Derek Kozel]

Hi Ivan,

The TX/RX and RX2 are ports on the same receiver channel. As Julian says 
there are two receivers, A and B. For a receive only application the RX2 
ports are slightly better performing as they have one less switch that 
the signal passes through.


Regards,
Derek

On 18/11/2020 14:01, Julian Arnold wrote:

Ivan,

to the best of my knowledge, there should not be any RX1 port.
Instead, you should have two (coherent) channels "A" and "B" both 
allowing you to select one out of two available antenna ports when 
receiving ("TX/RX" or "RX2").


Cheers,
Julian

On 11/18/20 10:31 AM, Ivan Zahartchuk via USRP-users wrote:


Another question of interest is which channels are coherent? Rx1 and 
RX2 or RX1 and RX / TX?


вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice >:


    Right!
    Be careful, DOA estimation using only 2 antennas works but it’s not
    so accurate.
    Enjoy!

    Ivan

 > Il giorno 17 nov 2020, alle ore 00:35, Ivan Zahartchuk
    mailto:adray0...@gmail.com>> ha scritto:
 >
 > 
 >
 >
 >
 > That is, in theory, I can simply start two streams from two
    channels and further process them using certain direction finding
    algorithms?
 >
 >


___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: Regarding missing osmocom source

[Christophe Seguinot]

  
  
Hi 

About Osmocom-sink

  It seems that you have gr-osmosdr installed since your
flowgraph has one osmocom-source. 
  
  What you need is an osmocom-sink and if you have
osmocom-source you must also have osmocom-sink too!! 
  
  so What is you GR version, and do you have installedgr-osmocom?

  
  It seems that you are using GR 3.8 or 3.9, see on this list
how to use gr-osmocom on GR3.8
  

About your simulation. It seems to me that you don't have
  knowledge about Equivalent baseband representation  (see recent
  discussions on this list and on line tutorial before using
  GNURadio) as well as signal sampling : 


  When dealing with a F0=3.4 GHz signal 
  
  
Center frequency is set to 3.4 GHz for hardware (osmocom)
  sink and sources
Signal delivered at output is of hardware source and at
  input of hardware sink are complex  equivalent baseband
  signals centered on 0Hz. 

Simulated signal source must be complex at 0Hz to simulate
  the corresponding signal at 2.4 GHz

  

 The attached flowgraph (GR3.9 or 3.8) and figure simulates 3
  signals at baseband : 


  Data1 at 0 Hz which appears at 3.400 GHz since we told the
spectrum analyzer to center spectrum at 3.4 GHz (Changing the
Frequency axis is an artefact to get a representation
corresponding to the real signal at 3.4 GHz captured by a source
or generated by an hardware sink)
  
  Data2 at F0=10 MHz which appears at 3.4GHz + 10 MHz (normal
you can try any F0 value in the range [-Fs/2, Fs/2]
  Data0 (your signal source) at F0=3.4 Ghz which is NOT at 3.4
GHz ! Why ?
  A F0=3.4 GHz signal  sampled at Fs=61.44 MHz have peaks in its
spectrum at every frequency Fn such as Fn=F0 +n Fs
  
chose N=-53 : F53= F0 -53 Fs = 20.8 Mhz . This is the only
  one peak seen in the [-Fs/2, Fs/2] frequency band of
  simulation 

  
  Since we told the spectrum analyzer to center spectrum at 3.4
GHz, this peak appears at 3.4G + 20.8 Mhz = 3420.8MHz
  Fo data0 source we can conclude that : 
  
  
this signal is equivalent to a 20.8 MHZ baseband signal 

F0 to any value such as 20.8 MHz+kFs  (k integer) will give
  the exact same results 3.4 GHz is one of these values)

  

Regards, Christophe




On 18/11/2020 11:20, Rozana Alam wrote:


  
  
Hello community,
I am trying to transmit  continuous waves (CW signal) 
  using bladeRF through gnu-radio. i can see the transmitting
  signal through QT-Gui but i can't receive the signal in
  network analyser. In the gnu block i have used signal source
  and osmocom sink to transmit signal. I am attaching my grc
  file and snapshots for your reference. I would really
  appreciate your help.
Sincerely,
Rozana

  
  
  
On Wed, Nov 4, 2020 at 4:39 PM
  Rozana Alam  wrote:


  

  

  

  
Hello community,
  I want to generate simple
continuous wave with bladeRF using gnu radio
and am a Linux user.but in the gnu platform
I am not getting any osmocom source.i have
downloaded the gnu from ppa .is there any
supplement of osmocom source to generate
signal by bladeRF?
  Your suggestions are highly
appreciated.
  Best regards,
  Rozana.



  

  

  
  

  

  

  




  

  

  

  

  

  

  



cw_tx.grc
Description: application/gnuradio-grc

Re: Regarding missing osmocom source

[Fabian Schwartau]

Disable the low pass filter, it is filtering out the excepted signal if
the cutoff frequency is 20kHz. Maybe you mixed up the cutoff frequency
and the transistion width.

Am 18.11.20 um 17:21 schrieb Rozana Alam:
> Hi,
> Thank you for your detailed clarification, I am really sorry for all the
> mistakes I have made . I tried to understand your findings. Yes I am
> using grc 3.8 and sorry for mistakenly giving the grc file of receiving
> instead of transmitting. I tried to build a loopback block again by
> considering the maillist help. i tried to transmit a 3.7 Gig signal
> through balderf and receive the signal by the loopback osmosink. Later I
> want to measure the signal through a spectrum analyser. may i get help
> to get the correctness of the block?
> 
> 
> On Wed, Nov 18, 2020 at 11:27 PM Christophe Seguinot
> mailto:christophe.segui...@orange.fr>>
> wrote:
> 
> Hi
> 
> About Osmocom-sink
> 
>   * It seems that you have gr-osmosdr installed since your flowgraph
> has one osmocom-source.
>   * What you need is an osmocom-sink and if you have osmocom-source
> you must also have osmocom-sink too!!
>   * so What is you GR version, and do you have installedgr-osmocom?
>   * It seems that you are using GR 3.8 or 3.9, see on this list how
> to use gr-osmocom on GR3.8
> 
> About your simulation. It seems to me that you don't have knowledge
> about Equivalent baseband representation  (see recent discussions on
> this list and on line tutorial before using GNURadio) as well as
> signal sampling :
> 
>   * When dealing with a F0=3.4 GHz signal
>   o Center frequency is set to 3.4 GHz for hardware (osmocom)
> sink and sources
>   o Signal delivered at output is of hardware source and at
> input of hardware sink are complex  equivalent baseband
> signals centered on 0Hz.
>   o Simulated signal source must be complex at 0Hz to simulate
> the corresponding signal at 2.4 GHz
> 
> The attached flowgraph (GR3.9 or 3.8) and figure simulates 3 signals
> at baseband :
> 
>   * Data1 at 0 Hz which appears at 3.400 GHz since we told the
> spectrum analyzer to center spectrum at 3.4 GHz (Changing the
> Frequency axis is an artefact to get a representation
> corresponding to the real signal at 3.4 GHz captured by a source
> or generated by an hardware sink)
>   * Data2 at F0=10 MHz which appears at 3.4GHz + 10 MHz (normal you
> can try any F0 value in the range [-Fs/2, Fs/2]
>   * Data0 (your signal source) at F0=3.4 Ghz which is NOT at 3.4 GHz
> ! Why ?
>   * A F0=3.4 GHz signal  sampled at Fs=61.44 MHz have peaks in its
> spectrum at every frequency Fn such as Fn=F0 +n Fs
>   o chose N=-53 : F53= F0 -53 Fs = 20.8 Mhz . This is the only
> one peak seen in the [-Fs/2, Fs/2] frequency band of simulation
>   * Since we told the spectrum analyzer to center spectrum at 3.4
> GHz, this peak appears at 3.4G + 20.8 Mhz = 3420.8MHz
>   * Fo data0 source we can conclude that :
>   o this signal is equivalent to a 20.8 MHZ baseband signal
>   o F0 to any value such as 20.8 MHz+kFs  (k integer) will give
> the exact same results 3.4 GHz is one of these values)
> 
> Regards, Christophe
> 
> 
> On 18/11/2020 11:20, Rozana Alam wrote:
>> Hello community,
>> I am trying to transmit  continuous waves (CW signal)  using
>> bladeRF through gnu-radio. i can see the transmitting signal
>> through QT-Gui but i can't receive the signal in network analyser.
>> In the gnu block i have used signal source and osmocom sink to
>> transmit signal. I am attaching my grc file and snapshots for your
>> reference. I would really appreciate your help.
>> Sincerely,
>> Rozana
>>
>> On Wed, Nov 4, 2020 at 4:39 PM Rozana Alam > > wrote:
>>
>> Hello community,
>> I want to generate simple continuous wave with bladeRF using
>> gnu radio and am a Linux user.but in the gnu platform I am not
>> getting any osmocom source.i have downloaded the gnu from ppa
>> .is there any supplement of osmocom source to generate signal
>> by bladeRF?
>> Your suggestions are highly appreciated.
>> Best regards,
>> Rozana.
>>
>>  
>>

Re: Passing real data from a thread to the next block

[isaac mario tupac davila]

Hi Martin and Nick

Thanks for your answers. I overwrite the start method proposed for Martin
and works in a suitable and simple way.

Thank you so much.
Regards
Isaac.

El mié., 18 nov. 2020 a las 1:27, Martin Lülf () escribió:

> Dear Isaac,
>
> you can overwrite the start method of gr::block
>
> https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f
>
> This function will be called once the processing starts.
>
> Yours
> Martin
>
>
> On 2020-11-18 02:35, isaac mario tupac davila wrote:
> > Hi Marcus
> >
> > Thanks for your answer. I am restructuring the design of my OOT block.
> >
> > I'd like to ask a last question about it...I am trying to send some
> > commands (array of bytes) to an external hardware only ONCE before
> > starting with my real time data acquisition . The problem is that if I
> > implement the sending of the commands in the general work of my block,
> > the commands will be sent each time the general work finishes and starts
> > again. My solution proposed is to begin the execution of my flowgraph
> > and send an external signal (specificallykill -SIGIO PID) from terminal
> > to call the implemented method which sends the commands, so that my
> > general work will only focus on the data acquisition and I will send the
> > commands only once.
> >
> > My question is: Is there a facility or tool that GNU Radio gives me to
> > solve this situation? There should be a more suitable solution.
> >
> > Any help or recommendation would be appreciated.
> > Thanks
> >
> > Regards
> > Isaac.
> >
> >
> >
> > El dom., 15 nov. 2020 a las 13:50, Marcus Müller ( > >) escribió:
> >
> > Hello,
> >
> > On 15.11.20 06:26, isaac mario tupac davila wrote:
> >  > Hello
> >  >
> >  > I'm Isaac.
> >
> > Hi Isaac, nice having you.
> >
> >  > I have a question about threads. I've created three
> >  > threads and I want to pass real data from one thread to the next
> > block
> >  > directly without returning to the general work method.
> >
> > That sounds like a misguided design approach. Please don't do that.
> >
> > The work function is meant to be seen as atomically processing a bit
> of
> > data from its input to its output.
> >
> > If you need asynchronous messaging, then use the msg_passing
> facilities.
> > These make sure you don't change the state of the block while its
> > general_work is executing.
> >
> >  > I could give
> >  > value to the out array in the thread but for some reason the data
> >  > doesn't pass to the next block. I am not sure if it's because I
> > didn't
> >  > put: return noutput_items in the thread,
> >
> > What you describe as thread makes no sense – the way GNU Radio is,
> > there's exactly one thread executing a block's general_work at a
> time,
> > and that's the thread of the block_executor. And `return` ends that
> > execution; that's how C++ works.
> >
> >  > as normally this is in the
> >  > general work method... I also add that the function is defined in
> the
> >  > thread as void*function and I defined the out array as a
> > complex*.
> >  >
> >  > Any help would be appreciated.
> >
> > I'm afraid there's something not GNU Radio-compatible in the way
> you've
> > architected your system, but we sadly don't know your system well
> enough
> > to comment on what to change.
> >
> > Best regards,
> > Marcus
> >
>
>

Re: [USRP-users] Direction finding based on USRP E310 board

[Ivan Zahartchuk]

Hello I am trying to install RFNoC for uhd 3.15. As far as I understand,
this version supports RFNoC. And in order for me to have blocks in
gnuradio, as I understand it, I need to install gr-ettus. But when
installing, I get this error The found UHD version (3.15.0.0-3build2) is
not compatible with the version required (4.0). how can I be in such a
situation?

ср, 18 нояб. 2020 г. в 16:24, Derek Kozel :

> Hi Ivan,
>
> The TX/RX and RX2 are ports on the same receiver channel. As Julian says
> there are two receivers, A and B. For a receive only application the RX2
> ports are slightly better performing as they have one less switch that
> the signal passes through.
>
> Regards,
> Derek
>
> On 18/11/2020 14:01, Julian Arnold wrote:
> > Ivan,
> >
> > to the best of my knowledge, there should not be any RX1 port.
> > Instead, you should have two (coherent) channels "A" and "B" both
> > allowing you to select one out of two available antenna ports when
> > receiving ("TX/RX" or "RX2").
> >
> > Cheers,
> > Julian
> >
> > On 11/18/20 10:31 AM, Ivan Zahartchuk via USRP-users wrote:
> >>
> >> Another question of interest is which channels are coherent? Rx1 and
> >> RX2 or RX1 and RX / TX?
> >>
> >> вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice  >> >:
> >>
> >> Right!
> >> Be careful, DOA estimation using only 2 antennas works but it’s not
> >> so accurate.
> >> Enjoy!
> >>
> >> Ivan
> >>
> >>  > Il giorno 17 nov 2020, alle ore 00:35, Ivan Zahartchuk
> >> mailto:adray0...@gmail.com>> ha scritto:
> >>  >
> >>  > 
> >>  >
> >>  >
> >>  >
> >>  > That is, in theory, I can simply start two streams from two
> >> channels and further process them using certain direction finding
> >> algorithms?
> >>  >
> >>  >
> >>
> >>
> >> ___
> >> USRP-users mailing list
> >> usrp-us...@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
>
>

USRP N210 Latency and underrun

[Fabien PELLET]

Hello,

I'm trying to make work the attached flowgraph : a simple Audio source, 
some filtering and feeding an USRP sink (N210).


I have two problems with it :

- I measure the latency between audio input and RF output of the N210 
and it is too long for me as I have about 30-40ms at the minimum.


- I have some underruns  at the startup of the flowgraph and then 
sometimes others  appear. The problem is that at each new , the 
latency is increasing.


I do not use that over hours but the latency seems to be out of control.

I'm working on a laptop DELL Precision M4800 with a I7-4800M, 8Go RAM 
and a NVidia Quadro K2100M.


GNURadio 3.8.2 is installed from source on Lubuntu 20.04 with UHD4.0. 
UHD and GNURadio are installed from source.


I try a lot of things without any beginning of a small optimization or 
correction of the problem :


- Working on a Lubuntu with a LXQT and lowlatency kernel,

- Try to play with the MTU and send/recv buffers,

- Install Cuda and OpenCL to play with GR-CLENABLED and GR-LFAST for the 
filters,


- Reduce the taps of my FFT bandpass filter,

- Test UHD bandwidth using benchmark provided : with 25Msps in TX and 
25Msps in RX at the same time, no underrun.


- Decimate the signal from the Audio Source around 10Ksps to get small 
number of taps for the FFT bandpass filter.


The only way to remove the underrun are :

- Feed the USRP sink with an little higher sampling than it expects (but 
signal at the TX output is wrong, I know).


- Remove completly the FFT bandpass filter and the Hilbert.

My flowgraph seems so simple that I hope I only miss a stupid thing. I 
hope someone here could help me find where is my mistake and how I can, 
at the minimum, warranty that my latency are stable even if it is at 
40-50ms.


Thanks for your help,

Best regards,

Fabien, F4CTZ.

options:
  parameters:
author: ''
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: testN210TX
max_nouts: ''
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: '1'
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: Test N210 TX
window_size: ''
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled

blocks:
- name: decimation
  id: variable
  parameters:
comment: ''
value: '20'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [205, 74]
rotation: 0
state: enabled
- name: frequency
  id: variable_qtgui_range
  parameters:
comment: ''
gui_hint: ''
label: Frequence
min_len: '100'
orient: Qt.Horizontal
rangeType: float
start: 1e6
step: '1'
stop: 30e6
value: 10e6
widget: counter_slider
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [323, 11]
rotation: 0
state: true
- name: samp_rate
  id: variable
  parameters:
comment: ''
value: 100e6/500
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [206, 9]
rotation: 0
state: enabled
- name: audio_source_0
  id: audio_source
  parameters:
affinity: ''
alias: ''
comment: ''
device_name: pulse
maxoutbuf: '0'
minoutbuf: '0'
num_outputs: '2'
ok_to_block: 'False'
samp_rate: '48000'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [77, 456]
rotation: 0
state: enabled
- name: blocks_complex_to_real_0
  id: blocks_complex_to_real
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [393, 436]
rotation: 0
state: disabled
- name: blocks_null_sink_0
  id: blocks_null_sink
  parameters:
affinity: ''
alias: ''
bus_structure_sink: '[[0,],]'
comment: ''
num_inputs: '1'
type: float
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [412, 551]
rotation: 0
state: enabled
- name: fft_filter_xxx_1
  id: fft_filter_xxx
  parameters:
affinity: ''
alias: ''
comment: ''
decim: '1'
maxoutbuf: '0'
minoutbuf: '8192'
nthreads: '1'
samp_delay: '0'
taps: firdes.low_pass_2(1,48e3,3050,300,30,firdes.WIN_BLACKMAN_HARRIS)
type: ccc
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [600, 357]
rotation: 0
state: enabled
- name: hilbert_fc_0
  id: hilbert_fc
  parameters:
affinity: ''
alias: ''
beta: '6.76'
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
num_taps: '639'
win

Re: how to auto detect peak frequency in QT FFT sink

[Kyle A Logue]

2 things that come to mind:

  1.  stream -> fft -> argmax
  2.  in sandia fhss utilities they have an FFT Peak block that does what you 
want

https://github.com/sandialabs/gr-fhss_utils

Kyle Logue
Senior Engineering Specialist
⚝ The Aerospace Corporation

From: Discuss-gnuradio  
on behalf of james jordan 
Sent: Monday, November 16, 2020 19:09
To: discuss-gnuradio@gnu.org 
Subject: how to auto detect peak frequency in QT FFT sink

Hi all,
i want to see the fft of the signal and also want to detect the peak frequency 
if there is a peak signal.
how to achieve this?

Re: how to auto detect peak frequency in QT FFT sink

[james jordan]

Hi Kyle,
Thanks. my cmake version is too low so i can not build gr-fhss. i try to use 
fft->max but how to store max result to a gui label?





From: Kyle A Logue 
Sent: Thursday, November 19, 2020 4:05 AM
To: james jordan ; discuss-gnuradio@gnu.org 

Subject: Re: how to auto detect peak frequency in QT FFT sink

2 things that come to mind:

  1.  stream -> fft -> argmax
  2.  in sandia fhss utilities they have an FFT Peak block that does what you 
want

https://github.com/sandialabs/gr-fhss_utils

Kyle Logue
Senior Engineering Specialist
⚝ The Aerospace Corporation

From: Discuss-gnuradio  
on behalf of james jordan 
Sent: Monday, November 16, 2020 19:09
To: discuss-gnuradio@gnu.org 
Subject: how to auto detect peak frequency in QT FFT sink

Hi all,
i want to see the fft of the signal and also want to detect the peak frequency 
if there is a peak signal.
how to achieve this?