[Discuss-gnuradio] Writing a custom source block, debugging incorrect output

[Derek Kozel]

Hi Yuxiao,

Your messages have gotten spread out over several threads now, so lets 
get it all in one place. We've been talking off-list about how the list 
is setup and how to reply, hopefully it works now.


Please do test the output of your custom block and TX flowgraph by using 
the file sink and plotting the results. Many many things can go wrong 
when actually using radios and wireless links, make sure that your 
generated signal is correct before trying to transmit and receive it 
over the air.


Derek

Others: For reference here is the text from Yuxiao's first message.
Images are located here: 
https://lists.gnu.org/archive/html/discuss-gnuradio/2018-12/msg3.html


""
# Communication State Machine:

I create a OOT module that uses a state machine structure to implement a 
wireless transmission protocol (i.e., command sequences in the air) that 
communicate with a backscatter device. The commands are in the following 
order: (CMD 1 + CW) -> (CMD2 + CW) -> POWER_DOWN -> (CMD 1 + CW), in 
which CW is the carrier wave signal (i.e., constant bit 1s) and 
POWER_DOWN is constant bit 0s. I add a power_down state because 
otherwise CW amplitudes will continuously fall down to nearly zero. 
Please refer to the trend in the figure MessyCommandOrders.png even if 
POWER_DOWN state is added.


# Implementation Details:

As GNURadio OOT module does not support a source block, I create a dummy 
source block like a low-frequency SIN wave and connect it to my OOT 
block, and ignore the input in the forecast() and general_work() 
functions. In the apps/ folder, I create a python code that uses two 
independent hierarchical blocks to configure the Tx and Rx path 
respectively. In the Tx path, I connect my OOT block to amplifier, 
float_to_complex and USRP sink. The frequency of the dummy source block 
is 100Hz. The sampling rate of both the OOT block and USRP sink is 
around 3.33e6. The timing of command durations in the air is made by 
creating enough number of bits based on this sampling rate. In the Rx 
path, I simply connect a USRP source block to a file sink. The sampling 
rate of USRP source is 20e6. I have inspected the state machine 
execution using gr_log function and it seems that the state machine 
functions well. However, when I look at the waveform of the received 
samples, the commands become disordered after some rounds.



# Hardware/Software Configuration:


GNURadio version: 3.7.9
USRP N210 + SBX Board Rev. 5.1 (daughterboard)

Operating system: Ubuntu 16.04

Antenna: Laird S8658PR, 865-868 MHz (can operate in 915MHz band), 8 dBic

Operating frequency: 915MHz

# Figure Illustration:

MessyCommandOrders.png: after several rounds the waveform of a command 
changes polarity: a bit 1 becomes low amplitude and a bit 0 becomes high 
amplitude. Sometimes only part of the command waveform can be observed; 
it seems that the USRP suddenly stops transmitting the command and goes 
to the next one.
MessyCommandOrders.png: Sometimes the order of the commands is messy and 
does not match the state machine in the code.

NoCWTransmission.png: CW is not transmitted.


Could anyone explain about this phenomenon and how to fix this issue? 
Thanks!




On 09/01/2019 11:51, Yuxiao Hou wrote:

Dear Derek,

Thank you for your reply. I have attached two graphs, one is the 
example command waveform, another is the flow graph of my application.


As for your questions, first I think I encountered some “U” letters,I 
was not aware of its indication; I have thought about dumping the 
transmitted signal to a file trace, but I have not done this yet; I 
think 20MS/s may be the highest receiver sampling rate that is allowed 
by USRPN210 for a valid file record. I have tested with this rate and 
it works fine sometimes, for other times I am not sure.


I will test with file sink output and have a look at the gr-osmosdr 
example and update my latest progress with you here.


Best Regards,
Yuxiao


___
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] Replace SWIG

[CEL]

Hi Andrej, hey folks,

> Development of Python bindings with PyBind11 could even happen in a
separate CMake project

hm, that sounds like an additional complication,

On Wed, 2019-01-09 at 17:07 +0100, Andrej Rode wrote:
> since the only thing required for Python
> bindings are available headers and shared libraries.

While that is mostly true, working Python bindings are more of a core
feature than a lot of things that we keep around. 

Having a proper C++ block <-> Python object <-> GRC block isomorphism
is paramount to GNU Radio's transparency.

So, I'm very much worried that decoupling the generation and testing of
Python bindings from the main tree is counterproductive in terms of
"actually works". 

Also, most of our math-oriented unit testing happens in Python. I don't
want to start writing C++ unit tests, but I sure also don't believe
that a circular dependency
"In-tree unit tests" -> "Ext. Python Bindings" -> "In-tree C++ headers"
is in the interest of any one. The "external" becomes a lie, because
it's part of the internal testing.

>  Since that could
> be easier on new developers.

I'd ask you to elaborate on how? Yes, SWIG is ugly, but in-tree python
and in-tree swig files are divided from C++ code by a clear folder
hierarchy.

> I agree that currently most users are using Python as development
> environment and we should ship the bindings with GNU Radio itself.

So, same page?

> Also we had a discussion on generation of bindings and I don't see a
> need of automatically generated bindings during each build. 

Well, if our bindings weren't so intricate, but the same for every
block, then I'd agree with you; we'd just have to add
"another_block_ff" to the list of things that get the block-typical
wrapping.
But since that's not the case currently and we don't want things to
break on the Python/C++ boundary when someone changes the API of a C++
object but forgets to manually rebuild the bindings: not a big fan of
the idea.

Either the binding generation becomes reliable and reproducible, and in
that case we could just as well run it every time, or it doesn't; but
then we'll stick with SWIG, I guess, because that *works*.

> Maybe a
> first generation can be done using binder[0]. But since that is a
> separate tool I wouldn't want to depend on that to generate the sources.

> Rather add the bindings during code review (or have a checkbox to check
> for that during code review).

I don't think that binding generation should be a human's manual job.
Again, if it's easy to trigger programmatically (e.g. in a githook)
then we can just as well do it at build time.

Cheers,
Marcus


> Cheers
> Andrej
> 
> [0] https://github.com/RosettaCommons/binder
> 
> 
> 
> ___
> 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

Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files

[Andrej Rode]

Hi Martin, 

On Thu, 27 Dec 2018 13:54:54 -0800
Martin Braun  wrote:

> Hi all,
> 
> final GREP of the day:
> https://github.com/gnuradio/greps/blob/master/grep-0016-separate-scheduler.md
> 
> This is possible the most fundamental and influential GREPs that were
> added so far. I would find it hard to find any reasons not to do this
> -- of course, the question remains, who will do it. Any takers? I'm
> hoping that by separating scheduler from base, we can open up the
> avenue for more and better research into scheduling, as well as
> custom scheduler development.

So current situation is: we basically have a architecture where one
could write another scheduler and plug it into the current system. The
major problem with that: the current architecture has gone through a
lot of patching and growing and thus a lot of boundaries between blocks
and the scheduler have become unclear. 

Aside from uncluttering the runtime and cleaning up, a new architecture
design should be discussed without mental barriers looking at the
current design. Important points: how to we want to run the flowgraphs,
what owns the buffers, how are buffers handled, what schedules
execution of blocks, how is control communication done, how will
heterogeneous processing be handled (locally & distributed). 

This will change almost all interfaces of the current architecture and
thus I think the current scope of the GREP is still too narrow. 
I don't have a perfect solution for this. But fundamentally there is
need for more change than outlined. E.g. the word top_block & PMT
shouldn't be in there. Though I agree on the most basic point outlined:
the current UX must be preserved (or even improved).

I have some ideas on architecture and buffer handling in a new design,
but they need more thoughts & proof-of-concepts until they're ripe for
discussing.

Thanks for starting the discussion!

Cheers
Andrej


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

Re: [Discuss-gnuradio] [GREP] Replace SWIG

[Andrej Rode]

Hi, 

On Fri, 28 Dec 2018 17:30:05 -0800
Martin Braun  wrote:

> Here's a summary of of comments that have come up in chat:
> 
> - Andrej recommended using PyBind11, a close cousin to boost.python.
> it comes recommended by Sebastian Koslowski also. It's only a few
> headers and we could ship it as part of the source tree.
> - The question arose if we even need the python bindings as part of
> the standard install. Personally I think we do, installing GNU Radio
> from source should simply give you all the features. But it's a good
> thing to discuss.

Development of Python bindings with PyBind11 could even happen in a
separate CMake project since the only thing required for Python
bindings are available headers and shared libraries. Since that could
be easier on new developers.

I agree that currently most users are using Python as development
environment and we should ship the bindings with GNU Radio itself.

Also we had a discussion on generation of bindings and I don't see a
need of automatically generated bindings during each build. Maybe a
first generation can be done using binder[0]. But since that is a
separate tool I wouldn't want to depend on that to generate the sources.

Rather add the bindings during code review (or have a checkbox to check
for that during code review).

Cheers
Andrej

[0] https://github.com/RosettaCommons/binder



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

[Discuss-gnuradio] This is another reply test

[Yuxiao Hou]

___
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

[Maitry Raval]

Hello,
I have seen those examples for packet_tx and packet_rx. but the issue here is I 
want to do contionous transmission and I think, header/payload demux block is 
for packet transmission, and besides, this block differentiate header and 
payload , and I want to do is to extract preamble(CCSDS syncbits-32 bits) from 
the contionous frame and receive only frame bits except syncbits. can you 
please give suggestion about this?
and yes, It is great to see those examples from which i can get an idea about 
modulation/demodulation without the use of deprecated blocks. 

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

- Original Message -
From: "Müller, Marcus (CEL)" 
To: "discuss-gnuradio" , "maitry raval" 

Sent: Wednesday, January 9, 2019 2:44:09 AM
Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block

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