bug & SNR routine

2022-11-04 Thread George Katsimaglis 
Hello,
1) In Log Power FFT documentation 'Create a log10(abs(fft)) stream chain, with 
real or complex input.' it seems that is missing the ^2.
2) I write a generic SNR routine as a Python block. It seems OK.

import numpy as npfrom gnuradio import gr
class my_snr(gr.decim_block): # decimation = fft_size    """SNR calculation by 
George SV1BDS"""
    def __init__(self, fft_size = 1024 ):  # only default arguments here        
"""arguments to this function show up as parameters in GRC"""        
gr.decim_block.__init__(            self,            name='SNR',   # will show 
up in GRC            in_sig=[np.complex64],            out_sig=[np.float32],    
        decim = fft_size        )        self.set_relative_rate(1.0/fft_size)   
     self.fft_size = fft_size
    def work(self, input_items, output_items):        """SNR routine"""        
a = np.asarray(input_items[0][:])        f = np.fft.fft(a)        x =  
10*np.log10(np.real(f*np.conj(f)))        output_items[0][:] = 
np.amax(x)-np.mean(x)          return 1          Is it of general interest to 
include it in GNURadio ?
Best regards

Re: bug & SNR routine

2022-11-04 Thread Marcus Müller 

Hi George,

> 1) In Log Power FFT documentation 'Create a log10(abs(fft)) stream chain, with real or 
complex input.' it seems that is missing the ^2.


I think this is [1], right?

In that case, you're right, the block actually calculates the magnitude square. Fixed 
that! You can do such fixes yourself, by the way: you just need to sign up for a wiki 
account (had to close down the approval chain for unauthenticated edits to the wiki. Spam 
sucks.)


> 2) I write a generic SNR routine as a Python block. It seems OK.

What is generic SNR? Such a thing does in general not exist! You're assuming your signal 
fits into a single FFT bin, so, having sinc spectrum, meaning having gone through a 
(frequency-shifted) rectangular filter exactly the length of your FFT, and is also 
perfectly synchronized to the position of a single FFT bin in frequency. That is (almost) 
surely not the case!
If it's not exactly in the position of an FFT bin, you get leakage. And that means you 
both underestimate your signal power, and overestimate the noise power. Not a great 
estimation method, because assuming you don't know the frequency of your signal exactly, 
you're likely to not hit the right frequency very well, so you don't know by how much you 
underestimate the SNR.


If I'd want to estimate the SNR and all I know my signal is a narrowband signal 
(otherwise, there might be better methods), I'd use the PLL Carrier Tracking [2] block, to 
mix down my narrowband signal to 0 Hz, then use a low-pass filter block on that to really 
get rid of the things around, then Complex to Mag²[3], then a long Moving Average[4] block 
to get an average signal power. Do the same Complex to Mag² -> Moving Average on the 
unprocessed input, subtract the signal power from above to get the noise power. Now you 
have S and N (in linear terms), so you get your SNR :)


Also, your work method has two bugs:
1. You're not excluding the signal from the noise power calculation; S/N > 
S/(S+N) !!
2. You're assuming there's always the same number of input items available at the input. 
That's not the case!



Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php/Log_Power_FFT
[2] https://wiki.gnuradio.org/index.php?title=PLL_Carrier_Tracking
[3] https://wiki.gnuradio.org/index.php?title=Complex_to_Mag_Squared
[4] https://wiki.gnuradio.org/index.php?title=Moving_Average
On 04.11.22 10:16, George Katsimaglis wrote:

Hello,

1) In Log Power FFT documentation 'Create a log10(abs(fft)) stream chain, with real or 
complex input.' it seems that is missing the ^2.


2) I write a generic SNR routine as a Python block. It seems OK.


import numpy as np
from gnuradio import gr

class my_snr(gr.decim_block): # decimation = fft_size
    """SNR calculation by George SV1BDS"""

    def __init__(self, fft_size = 1024 ):  # only default arguments here
        """arguments to this function show up as parameters in GRC"""
        gr.decim_block.__init__(
            self,
            name='SNR',   # will show up in GRC
            in_sig=[np.complex64],
            out_sig=[np.float32],
            decim = fft_size
        )
        self.set_relative_rate(1.0/fft_size)
        self.fft_size = fft_size

    def work(self, input_items, output_items):
        """SNR routine"""
        a = np.asarray(input_items[0][:])
        f = np.fft.fft(a)
        x =  10*np.log10(np.real(f*np.conj(f)))
        output_items[0][:] = np.amax(x)-np.mean(x)
        return 1
Is it of general interest to include it in GNURadio ?

Best regards

Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)

2022-11-04 Thread Ville Eerola 

Hi Vasil,

Here  is the output of the GDB and backtrace. Hopefully it will shed 
some light on the problem.


Regards, Ville

--- --- --- --- ---
$ gdb -ex=run --args python3 fosphor_test.py
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
(No debugging symbols found in python3)
Starting program: /usr/bin/python3 fosphor_test.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffefd9c640 (LWP 14136)]
[New Thread 0x7fffef59b640 (LWP 14137)]
[New Thread 0x7fffeed9a640 (LWP 14138)]
[New Thread 0x7fffee599640 (LWP 14139)]
[New Thread 0x7fffedd98640 (LWP 14140)]
[New Thread 0x7fffed597640 (LWP 14141)]
[New Thread 0x7fffecd96640 (LWP 14142)]
[New Thread 0x7fffec595640 (LWP 14143)]
[New Thread 0x7fffebd94640 (LWP 14144)]
[New Thread 0x7fffeb593640 (LWP 14145)]
[New Thread 0x7fffe80ac640 (LWP 14146)]
[New Thread 0x7fffe78ab640 (LWP 14147)]
[New Thread 0x7fffdf0aa640 (LWP 14148)]
[New Thread 0x7fffd68a9640 (LWP 14149)]
[New Thread 0x7fffc60a8640 (LWP 14150)]
[New Thread 0x7fffc58a7640 (LWP 14151)]
[New Thread 0x7fffbd0a6640 (LWP 14152)]
[New Thread 0x7fffb48a5640 (LWP 14153)]
[New Thread 0x7fffac0a4640 (LWP 14154)]
[New Thread 0x7fff9b8a3640 (LWP 14155)]
[New Thread 0x7fff9b0a2640 (LWP 14156)]
[New Thread 0x7fff8a8a1640 (LWP 14157)]
[New Thread 0x7fff820a0640 (LWP 14158)]
[New Thread 0x7fff7989f640 (LWP 14159)]
[New Thread 0x7fff7109e640 (LWP 14160)]
[New Thread 0x7fff6889d640 (LWP 14161)]
[New Thread 0x7fff6009c640 (LWP 14162)]
[New Thread 0x7fff5789b640 (LWP 14163)]
[New Thread 0x7fff4f09a640 (LWP 14164)]
[New Thread 0x7fff45809640 (LWP 14165)]
[New Thread 0x7fff45008640 (LWP 14166)]
[New Thread 0x7fff44807640 (LWP 14167)]
[New Thread 0x7fff44006640 (LWP 14168)]
[New Thread 0x7fff43805640 (LWP 14169)]
[New Thread 0x7fff43004640 (LWP 14170)]
[New Thread 0x7fff42803640 (LWP 14171)]
[New Thread 0x7fff42002640 (LWP 14172)]
[New Thread 0x7fff41801640 (LWP 14173)]
[New Thread 0x7fff41000640 (LWP 14174)]
[New Thread 0x7fff3dc9e640 (LWP 14175)]
[New Thread 0x7fff37fff640 (LWP 14176)]
[New Thread 0x7fff377fe640 (LWP 14177)]
[New Thread 0x7fff36ffd640 (LWP 14178)]
[New Thread 0x7fff34a7f640 (LWP 14180)]
[New Thread 0x7fff25bff640 (LWP 14181)]
[New Thread 0x7fff253fe640 (LWP 14182)]
[New Thread 0x7fff24bfd640 (LWP 14183)]

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x7fff458b5fe5 in ?? () from 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4

(gdb) bt
#0  0x7fff458b5fe5 in  () at 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#1  0x7fff45961927 in  () at 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#2  0x7fff458c193f in gr::block::allocate_detail(int, int, 
std::vector > const&, std::vectorlong, std::allocator > const&, std::vectorstd::allocator > const&) () at 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#3  0x7fff458d628e in 
gr::flat_flowgraph::allocate_block_detail(std::shared_ptr) 
() at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#4  0x7fff458d7845 in gr::flat_flowgraph::setup_connections() () at 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#5  0x7fff4590d40b in gr::top_block_impl::start(int) () at 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#6  0x7fff4590d7f6 in gr::top_block::start(int) () at 
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4
#7  0x7fff45a76d91 in  () at 
/usr/lib/python3/dist-packages/gnuradio/gr/gr_python.cpython-310-x86_64-linux-gnu.so
#8  0x7fff45a7cd43 in  () at 
/usr/lib/python3/dist-packages/gnuradio/gr/gr_python.cpython-310-x86_64-linux-gnu.so
#9  0x7fff45a09ef3 in  () at 
/usr/lib/python3/dist-packages/gnuradio/gr/gr_python.cpython-310-x86_64-linux-gnu.so

#10 0x556b031e in  ()
#11 0x556a6e4b in _PyObject_MakeTpCall ()
#12 0x5569f4f2 in _PyEval_EvalFrameDefault ()
#13 0x556be5c1 in  ()
#14 0x5569f152 in _PyEval_EvalFrameDefault ()
#15 0x556b0b6c in _PyFunction_Vectorcall ()
#16 0x55699675 in _PyEval_EvalFrameDefault ()
#17 0x55695de6 in  ()
#18 0x5578bcb6 in PyEval_EvalCode ()
#19 0x557b8748 in  ()
#20 0x557b155b in  ()
#21 0x557b8495 in  ()
#22 0x557b7978 in _PyRun_SimpleFileObjec

Re: anyone had luck with RTL-SDR on Windows GNURADIO installation?

2022-11-04 Thread Achilleas Anastasopoulos 
Thank you all for your suggestions.
Here is an update:

I installed SDR# and the RTL-SDR is recognized from the SDRSharp
application.
HOWEVER, the installed GNURADIO does not recognize the dongle, even after
installing the rtl-sdr drivers manually.

Anyone who may have made this work with the specific binary installation
please let me know.

thanks again,
Achilleas


On Thu, Nov 3, 2022 at 11:53 AM JEREMY CLARK  wrote:

> Try installing SDR# first and running the install-rtlsdr bat file, that
> will install all the windows drivers. Then see if it is recognized in GNU
> Radio.
>
> BR/JC
>
> https://airspy.com/download/
>
>
>
> Sent from Mail  for
> Windows
>
>
>
> *From: *Achilleas Anastasopoulos 
> *Sent: *November 3, 2022 10:25 AM
> *To: *Discuss-gnuradio@gnu.org 
> *Subject: *anyone had luck with RTL-SDR on Windows GNURADIO installation?
>
>
>
> Hi all,
>
>
>
> I was testing GNURADIO 3.8 Windows binary installation
>
> from  Geof Nieboer's installer hosted at gcndevelopment.com
> 
>
> http://www.gcndevelopment.com/gnuradio/index.htm
>
>
>
> Everything seems to be working fine.
>
> However I have no luck when I connect my RTL-SDR dongle.
>
> The device is not recognised.
>
>
>
> Anyone has similar experience or some suggestion?
>
>
>
> thanks
>
> Achilleas
>
>
>

Re: CCSDS BCH and CLTU coding

2022-11-04 Thread WarMonkey 
Check this out
https://github.com/opensatellite/KS-1Q/blob/master/host/gr-kcsa-ks1q/lib/halfduplex_tc_impl.cc#L195


Yotam Rabin  于2022年11月3日周四 21:50写道：

> Hi everyone!
> I'm trying to design a gnuradio based ccsds transmitter using the ccsds
> 231.0-b TC standard.
> My design requires the use of BCH (63,56) code and the encapsulation of
> the data inside the CLTU packet.
> Does anyone have any experience with this in gnuradio ? I wasn't able to
> find any implementations of such coding.
> [image: image.png]
> Any help would be greatly appreciated
> Thanks,
> Yotam
>