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

[WarMonkey]

Bug

When input amplitude is too large, symbol_sync_cc get stuck.
Screenshot

[image: frame1]

[image: 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;
*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

   - 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

[Discuss-gnuradio] Single step a stream

[Rudolf Wigblurr]

Hi,

 

Is it possible to single step a flow graph?

 

I have a recorded stream of FSK modulated data with about 25 bursts of messages.
When this is later decoded I do not get 100% detection, about 4 of 25 bursts fails.

 

Now my thinking is can I play this burst by burst and see what is wrong.
So my plan was to stop the scheduler after each burst.
Can I control (stop) the scheduler when a 'tag' is detected and restart it with a GUI button.

 

Block,Python,C++ dosen't matter...

 

/Rudolf

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

Re: [Discuss-gnuradio] Single step a stream

[Michael Dickens]

Hi Rudolf - That's a very cool idea, but to the best of my knowledge GNU
Radio can't do stepping like you describe. I think it would be an -excellent-
feature to add; not sure how one would deal with the non-deterministic
nature of threads waking / sleeping / executing when using the thread-per-
block scheduler, but maybe there's a way. Maybe someone else knows
better? - MLD
On Mon, Jan 7, 2019, at 2:41 PM, Rudolf Wigblurr wrote:
> Hi,
>  
> Is it possible to single step a flow graph?
>  
> I have a recorded stream of FSK modulated data with about 25 bursts of
> messages.>  When this is later decoded I do not get 100% detection, about 4 
> of 25
>  bursts fails.>  
> Now my thinking is can I play this burst by burst and see what
> is wrong.>  So my plan was to stop the scheduler after each burst.
>  Can I control (stop) the scheduler when a 'tag' is detected and
>  restart it with a GUI button.>  
> Block,Python,C++ dosen't matter...
>  
> /Rudolf
> _
> 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]

Okay, well you'll have to post your flowgraph and I'll try to help you.

Or post your python code and maybe someone on the list may be able to
help you.

-- 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
> 


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

Re: [Discuss-gnuradio] [GREP] Remove log4cpp

[Martin Braun]

I've started to summarize this thread in a GREP PR:

https://github.com/gnuradio/greps/pull/16

On Sun, Jan 6, 2019 at 1:58 PM Martin Braun  wrote:

> Hi all,
>
> there's been a little discussion outside of this thread, and I'd like to
> consolidate all the points. Marcus, I and some others have also discussed
> some things on chat, too, and of course there's Jared's and Michael's
> comments here. Let me summarize:
>
> - We would like to drop any kind of dependency and hand-roll our logger.
> I'll make some points on why further down.
> - Any log message must have a severity and a "category" (or "source ID").
> We already have this, but want to keep it.
>   - The source ID for a block should be its ID. I like Jared's suggestion
> of the log-hierarchy following the block-hierarchy.
> - We'll also drop the debug logger vs the regular logger. Devs can use the
> DEBUG and TRACE log levels for their debugging.
> - We absolutely want to make sure that log messages are properly
> interleaved. This requires some amount of serialization/thread handling,
> I'll also comment on that later.
> - By default, there should be log files and logging to stderr. However, we
> also want to enable (or at least, not disable) other logging paths, such as
> journald, or network logging. This might be as simple as providing generic
> hooks for other loggers.
> - If  possible, we would also like to pull in log messages from
> dependencies, so they all go through the same logging interface. For
> example, UHD log messages could be redirected to the GNU Radio logger when
> running gr-uhd applications, so UHD and GNU Radio don't clobber each other
> with different formats of their logging messages.
>
>
> Out of these requirements, there fall some design decisions:
> - There will be one central "root logger". All other logger objects (such
> as a logger attached to a block) will be childs of the root logger
> - Every child logger can filter log messages by severity. Do we also want
> to filter in the root logger, or do we just inherit the default log level
> from it? That's up for debate.
> - The root logger will implement a thread-safe multi-writer queue for log
> infos. It will serially handle the actual logging, which means the logging
> is not fully synchronous -- but it also means that the publishing of the
> log messages is not handled by the thread that is producing it, which is
> good for performance.
>   - We will most likely start with the dumbest form of such a queue, maybe
> a std::queue with a mutex and a notification variable. We can optimize
> later, if need be. Lockfree data structures tend to be worse for best-case
> and better for worst-case latency, which probably makes them less suitable
> but who knows.
> - The root logger will be created at runtime in a singleton pattern.
> Andrej pointed out that might cause trouble at destruction time, so we
> should think about that. Maybe only child loggers share a reference to the
> root logger, and the singleton factory only stores a weak pointer to it. It
> runs a separate thread to dispatch log messages to the various logging
> back-ends.
>
> On top of that, here's a couple of suggestions from myself, which are the
> least fixed out of all of these bullet points:
> - We could further simplify the block logging interface by adding an API
> call to the block itself, rather than exposing the logger object. This
> guarantees that the source ID for block log messages is always correct.
> - I want (optional) colours on the stderr output :)
>
>
> Cheers,
> Martin
>
> On Fri, Dec 28, 2018 at 4:49 PM Michael Dickens 
> wrote:
>
>> I'll second what Jared wrote, and add the following: I'd like -any-
>> logging GR uses to provide protected printing, such that logged messages do
>> not interleave. [Obviously, unlogged messages might interleave / intermix;
>> all depends on the actual printing interface.] Trying to parse such
>> interleaved messages is a total PITA. I've personally gone so far as to
>> implement a mutex interface via SWIG from C++ to Python, to allow logged
>> messages in both to not interleave. Ideally, all of stdout and stderr would
>> be redirected to the logging interface, regardless of language source.
>> Log4Cpp provides the printing blocking (non-interleaving) functionality,
>> though it doesn't coerce both C++ and Python into the same printing
>> interface (at least in my testing). - MLD
>>
>> On Fri, Dec 28, 2018, at 7:08 PM, U L wrote:
>>
>> I think many users, myself included, use logs for debugging.  I would
>> hesitate to have the log messages propagate through the very system that
>> you are trying to debug with said messages.  I would rather the logs be
>> emitted from the system under test as simply and promptly as possible.  I
>> think that hierarchical organization within the logs should be handled by
>> log metadata.  It's not clear that one would want to impose the same naming
>> hierarchy on logs as you do your flowgraph, but one could do so if desir

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

[Cinaed Simson]

Incidentally, you may not be able to see your posts but this is the
third post of "Regarding correlate access code-tag block".

Also, you really haven't provide - at least for me - sufficient
information to reproduce the problem, i.e., the grc and input files.

I'll punt to someone else who might be able to spot the problem by
looking at the image.

-- Cinaed


On 1/7/19 10:10 PM, Maitry Raval wrote:
> Hello,
> 
> Please find attached screenshot of GNU flow graph for CCSDS TM
> transmitter and receiver, in which I have used correlate access code-tag
> block in order to trigger at CCSDS sync bits and produce tags which is
> followed by custom block from gr-satellites fixed length packet tagger
> block in order to extract that sync bits from payload and provide
> payload file in file sink.
> 
> 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.
> 
> that means, there may be an issue to correlate access code-tag block.
> Can anyone please guide me where am I doing wrong? I have also tried by
> attaching time sink at the output of correlate access code-tag block and
> by right clicking the time domain spectrum and selecting
> trigger-mode-tag , but after executing, following is the message. but
> not trigger at the tag.
> Generating: 'C:\\Users\\maitry.raval\\Desktop\\top_block.py'
> 
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\Users\maitry.raval\Desktop\top_block.py
> 
> DEBUG: Access code: 1acffc1d
> DEBUG: Mask: 
> gr::pagesize: no info; setting pagesize = 4096
> 
> 
> I have GNU radio version: 3.7.13.4 in windows OS.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> ___
> 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] Regarding correlate access code-tag block

[Thomas Lavarenne]

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

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

[Thomas Lavarenne]

Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.

Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne 
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