Hi,
Looks like very interesting techniques. The current Gnuradio
application has been up for about two weeks and it works very well
and spectrums (frequency-switched) are what's expected. To account
for delay, besides looking at transition signal, I also wait 0.001
seconds before i collect FFT:s when a S/R signal is introduced to
the GPIO/RX. However, as you said, I might have to increase this
wait time if I introduce the IIR block instead of python averaging.
Would you perhaps have a method to check the delay so can get some
sort of mean value and add to this so I know that I'm always on the
safe side? Or maybe guide me in the right direction so I can "get a
feeling" for delays in gnuradio? The "oblivious synchronous
detection" might be a solution (not sure it would work with
frequency-switching however?) but I would like to try getting the
current setup optimized first.
Yes, CPU loads and data rates are big and we'd like to use the full
160 Mhz of the UBX card, why I'm looking at RFNoC. I expect that
delay times will become alot smaller as well with RFNoC?
Den 2015-09-25 kl. 03:31, skrev 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.
|