Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[Cinaed Simson]

I broke down and looked at the image.

Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
Decoder have been depreciated.

And they're usually depreciated because they have problems - and they
are usually replaced with different blocks which work better and are
typically more general.

The tutorials are good place to start looking for the replacements.

-- Cinaed


On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
> Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
> 
> Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
> mailto:thomas.lavare...@gmail.com>> a écrit :
> 
> 
> 
> Hi,
> 
> But, the issue is that correlate access code-tag block is not
> working and producing tags, so that my output file will come
> blank. as  I am certain that at the output of FEC extended
> decoder, both the sync bits and payload is available which I
> have seen by attaching file sink at the output of FEC extended
> decoder.
> 
> 
> There is a block "Tag Debug" to see if the tag is generated behind
> "correlate access code - tag block".
> 
> On the other hand, the documentation of "Tagged File sink" indicate
> that the block need the keyword "burst" (with value: True) to
> trigger the saving of the data.
> 
> Best regards,
> 
> Thomas
> 
> ___
> 
> 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] HELP with "packet header parser"

[Cinaed Simson]

I'm assuming the reason you're not looking at the rx_ofdm.py code is
because you don't have the rx_ofdm.py code.

You can use

  grcc -d . rx_ofdm.grc

to generate the python code.

-- Cinaed


On 1/6/19 2:10 AM, Alban Meffre wrote:
> hi
> i does not work because the packet header parser expect an
> "packet_header_default" object instead of a "header_format_base" object
> bob
> 
> Le dim. 6 janv. 2019 à 02:50, Cinaed Simson  > a écrit :
> 
> On 1/5/19 2:26 PM, Alban Meffre wrote:
> > ok sorry my mistake i got "packet_header_default" and
> > "header_format_default" mixed up
> > bob
> 
> The error message at the bottom indicates the wrong number arguments.
> 
>   digital.header_format_default('1101001110010001', 0)
> 
> Try
> 
>   digital.header_format_default('1101001110010001', 0, bps)
> 
> where bps is the number of bits per symbol for your problem.
> 
> See
> 
>    Default Header Format Obj.
> 
> in the grc.
> 
> -- Cinaed
> 
> 
> 
> 
> >
> > Le sam. 5 janv. 2019 à 22:13, Alban Meffre  
> > >> a écrit :
> >
> >     hi all
> >
> >     i try to figure out how to use the "packet header parser" block
> >     as a formatter i use
> >     "digital.header_format_default('1101001110010001', 0)"
> >
> >     when i launch i get the error
> >     "
> >     Traceback (most recent call last):
> >       File "/Users/alban/gnuradio/top_block.py", line 146, in 
> >     main()
> >       File "/Users/alban/gnuradio/top_block.py", line 134, in main
> >     tb = top_block_cls()
> >       File "/Users/alban/gnuradio/top_block.py", line 71, in __init__
> >     self.digital_packet_headerparser_b_0 =
> >     digital.packet_headerparser_b(hdr_format_dec_0)
> >       File
> >   
>  
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/digital/digital_swig2.py",
> >     line 2651, in make
> >     return _digital_swig2.packet_headerparser_b_make(*args)
> >     NotImplementedError: Wrong number or type of arguments for
> >     overloaded function 'packet_headerparser_b_make'.
> >       Possible C/C++ prototypes are:
> >    
> >   
>  
> gr::digital::packet_headerparser_b::make(gr::digital::packet_header_default::sptr
> >     const &)
> >     gr::digital::packet_headerparser_b::make(long,std::string
> const &)
> >     "
> >
> >
> >     in the "rx_ofdm" example supplied with gnuradio, the  "packet
> header
> >     parser" use the formatter  "header_formatter.base()"
> >
> >     i do not find any documentation about the base() method
> >     as you can see the doxygen is empty
> >   
>  
> https://www.gnuradio.org/doc/doxygen/classgr_1_1digital_1_1header__format__base.html#a5a7b2939707146f2b28d7e91e04103c2
> >
> >     if i add ".base()" to the formatter in my top_block i get an
> error too
> >
> >     please someone can explain me hox to use this block ?
> >     thank you all
> >     --
> >     Alban MEFFRE F4GSW
> >
> >
> >
> >
> > --
> > Alban MEFFRE F4GSW
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> 
> -- 
> Alban MEFFRE F4GSW
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: OFDM Rx
# Description: Example of an OFDM receiver
# Generated: Mon Jan  7 17:56:51 2019
##

from gnuradio import analog
from gnuradio import blocks
from gnuradio import channels
from gnuradio import digital
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio.digital.utils import tagged_streams
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from optparse import OptionParser
import numpy


class rx_ofdm(gr.top_block):

def __init__(self):
gr.top_block.__init__(self, "OFDM Rx")

##
# Variables
##
self.pilot_symbols = pilot_symbols = ((1, 1, 1, -1,),)
self.pilot_carriers = pilot_carriers = ((-21, -7, 7, 21,),)
self.payload_mod = payload_mod = digital.constellation_qpsk()
self.packet_length_tag_key = packet_le

Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[Maitry Raval]

Hello, 
thanks for your guidance.
I have also attached the grc file, input/output files and python file for your 
reference. after adding tag debug, still didn't get any output. I have also 
tried this same in ubuntu 18.04 with GNU radio 3.7.11 version.
actually because these psk blocks are deprecated, I have tried it with dpsk 
mod, demod block. But as I wanted to do continuous transmission, I didn't find 
replaced block for correlate access code-tag block, and the cusom block from 
gr-satellites are for extracting syncbits. 
I have also tried with simple flow graph by just sream muxing 2 files one with 
sync bits and other one is payload file and give that output to correlate 
access code-tag block, but that also didn't work.

It would be grateful, If you guide me on this. I just want to make that sync 
bits searching and extracting from payload and receive only payload at the 
output. 


With Best Regards,
Maitry Raval,


- Original Message -
From: "Cinaed Simson" 
To: "discuss-gnuradio" 
Sent: Tuesday, January 8, 2019 1:47:56 PM
Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block

I broke down and looked at the image.

Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
Decoder have been depreciated.

And they're usually depreciated because they have problems - and they
are usually replaced with different blocks which work better and are
typically more general.

The tutorials are good place to start looking for the replacements.

-- Cinaed


On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
> Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
> 
> Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
> mailto:thomas.lavare...@gmail.com>> a écrit :
> 
> 
> 
> Hi,
> 
> But, the issue is that correlate access code-tag block is not
> working and producing tags, so that my output file will come
> blank. as  I am certain that at the output of FEC extended
> decoder, both the sync bits and payload is available which I
> have seen by attaching file sink at the output of FEC extended
> decoder.
> 
> 
> There is a block "Tag Debug" to see if the tag is generated behind
> "correlate access code - tag block".
> 
> On the other hand, the documentation of "Tagged File sink" indicate
> that the block need the keyword "burst" (with value: True) to
> trigger the saving of the data.
> 
> Best regards,
> 
> Thomas
> 
> ___
> 
> 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-gnuradio0001101011001101110110101010#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Ccsds Tm
# Generated: Tue Jan  8 13:52:35 2019
##

from distutils.version import StrictVersion

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"

from PyQt5 import Qt, QtCore
from gnuradio import blocks
from gnuradio import digital
from gnuradio import eng_notation
from gnuradio import fec
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from grc_gnuradio import blks2 as grc_blks2
from optparse import OptionParser
import numpy
import satellites
import sys
from gnuradio import qtgui


class ccsds_TM(gr.top_block, Qt.QWidget):

def __init__(self):
gr.top_block.__init__(self, "Ccsds Tm")
Qt.QWidget.__init__(self)
self.setWindowTitle("Ccsds Tm")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "ccsds_TM")

if 

[Discuss-gnuradio] anyone know what is the theory of the implementation of pll_freqdet_cf

[wu jo]

Hi ALL,
I am reading a block that using pll_freqdet_cf. it said pll_freqdet_cf detect a 
frequency then lock to it. but what is the theory of the impletation of that? 
anyone can share the knowledge?

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

Re: [Discuss-gnuradio] symbol_sync_cc stuck when error too large (resulting d_avg_period goes negative)

[Andy Walls]

Hello:

> Date: Mon, 7 Jan 2019 20:24:57 +0800
> Bug
> 
> When input amplitude is too large, symbol_sync_cc get stuck.
> Screenshot
> 
> frame1
> frame2
> Tracing
> 
> in file symbol_sync_cc_impl.cc line 537:
>   error = -488.4;
>   advance_loop(error);
> in file clock_tracking_loop.cc line 128 function advance_loop(float 
> error) :
>   before: d_avg_period=10.771521, d_beta=0.0090558, error=-488.4;
>   d_avg_period = d_avg_period + d_beta * error;
>   after: d_avg_period = -0.417
>   out of range [d_min_avg_period, d_max_avg_period]
> back to file symbol_sync_cc_impl.cc line 540:
>   d_clock->phase_wrap();
> in file clock_tracking_loop.cc line 145 function phase_wrap()
> 
> phase = -87.227, limit=-0.417/2=-0.20895, now we stuck in these while
> loops;

Thank you! for the detailed tracing of the problem you encountered.

Please report the bug on the github.com/gnuradio Issue tracker:

https://github.com/gnuradio/gnuradio/issues

So this is certainly a problem with the block: it should never hang
even if used improperly.

However, given the large error sample value of -488.4, it looks like
you are not properly conditioning your input sample stream to the
block.

For best results with the symbol_sync_cc block, please ensure:

1. You have a filter block acting as a channel filter or IF filter,
filtering noise from the input signal

2. You use an Automatic Gain Control block to control the amplitude of
the input signal to a consistent value.  Your input amplitude should be
what the derivation of the particular Timing Error Detector (TED) in
use is expecting.  For Decision Directed TEDs, the input amplitudes
should match what the slicer constellation is expecting.  For the
signal*slope ML approximation TED, the input amplitude should be
significantly less than 1.0.  For the signum*slope TED, the amplitude
should be greater than 1.0.

3. Use a level shifter/DC removal block.  Almost all of the TED's
expect the amplitude excursions to be centered about 0.

4. You have a matched filter conditioning the input stream, either out
in front of the block, or done by the block's internal PFB
interpolation filter, to peak the symbol centers and reduce noise.  If
you have rectangular pulses and use a TED that requires a derivative,
you must use an external filter block for the matched filter.

5. That you have set the TED gain based of the slope of the TED S-Curve 
at timing offset = 0.  The TED S-Curve for you situation must be
determined from modeling and simulation of the TED with various timing
offsets in your specific Signal/Noise/ISI situation in MatLab, Octave,
Python, R, or some other mathematical simulation tool.


If you are doing all of the above and the problem is induced by AGC
amplifying up noise in between received bursts, I would like to know.


> ps: i think period should be d_avg_period, because avg period is
> estimated symbol period. when loop bandwidth relatively larger (
> 0.05~0.25 ), limiting d_inst_period can make tracking error larger,
> even loop unlock. i'll benchmark both later.
> Workaround
> 
> apply limit to d_avg_period immediately after d_avg_period changed

It is a potential change to make when fixing the block.

I pondered this choice when I initially wrote the block.  Back then I
decided to let the out of limits d_avg_period be applied to the
feedback, thinking that the excursion could never be so large as to
cause a problem, and that it might speed lock-in.  I never imagined the
error signal being so large with proper conditioning of the input and
setting of the TED gain.

Regards,
Andy

> in file clock_tracking_loop.cc line 127
> 
> Ultimate solution
> 
> check every input, state and output in range when calculate
> control loop
> 
> 


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

Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[CEL]

As indicated, have you worked through the tutorials on 
https://tutorials.gnuradio.org?
That's the place where I'd start.
You should drop *all* the blocks that are deprecated. As said, these
are deprecated for a reason (buggy and no-one is willing or able to fix
them – most of the ones you're using are simply broken on a conceptual
level).

Instead of the correlate access block, my guess is that the
header_payload_demux-based examples from gr-
digital/examples/packet/packet_rx.grc and packet_tx.grc and
packet_loopback_hier.grc will make you much happier.

You'll probably find them in
/usr/share/gnuradio/examples/digital/packet.

Best regards,
Marcus
 
On Tue, 2019-01-08 at 14:10 +0530, Maitry Raval wrote:
> Hello, 
> thanks for your guidance.
> I have also attached the grc file, input/output files and python file for 
> your reference. after adding tag debug, still didn't get any output. I have 
> also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version.
> actually because these psk blocks are deprecated, I have tried it with dpsk 
> mod, demod block. But as I wanted to do continuous transmission, I didn't 
> find replaced block for correlate access code-tag block, and the cusom block 
> from gr-satellites are for extracting syncbits. 
> I have also tried with simple flow graph by just sream muxing 2 files one 
> with sync bits and other one is payload file and give that output to 
> correlate access code-tag block, but that also didn't work.
> 
> It would be grateful, If you guide me on this. I just want to make that sync 
> bits searching and extracting from payload and receive only payload at the 
> output. 
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Cinaed Simson" 
> To: "discuss-gnuradio" 
> Sent: Tuesday, January 8, 2019 1:47:56 PM
> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
> 
> I broke down and looked at the image.
> 
> Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
> Decoder have been depreciated.
> 
> And they're usually depreciated because they have problems - and they
> are usually replaced with different blocks which work better and are
> typically more general.
> 
> The tutorials are good place to start looking for the replacements.
> 
> -- Cinaed
> 
> 
> On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
> > Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
> > 
> > Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
> > mailto:thomas.lavare...@gmail.com>> a écrit :
> > 
> > 
> > 
> > Hi,
> > 
> > But, the issue is that correlate access code-tag block is not
> > working and producing tags, so that my output file will come
> > blank. as  I am certain that at the output of FEC extended
> > decoder, both the sync bits and payload is available which I
> > have seen by attaching file sink at the output of FEC extended
> > decoder.
> > 
> > 
> > There is a block "Tag Debug" to see if the tag is generated behind
> > "correlate access code - tag block".
> > 
> > On the other hand, the documentation of "Tagged File sink" indicate
> > that the block need the keyword "burst" (with value: True) to
> > trigger the saving of the data.
> > 
> > Best regards,
> > 
> > Thomas
> > 
> > ___
> > 
> > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio