[Discuss-gnuradio] Change mailing list email address

[David Halls]

Hi guys,

Sorry for the mundane question but it was so long ago that I signed up to the 
mailing list. How do I go about changing my email address?

Cheers!!



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Editing Academic Wiki

[David Halls]

Thanks Martin,

Yup, I was convinced there *used* to be an Edit button! It has now reappeared.

Cheers,

David

-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com]
Sent: 11 January 2017 22:57
To: David Halls <david.ha...@toshiba-trel.com>; GNURadio Discussion List 
<discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Editing Academic Wiki

Try again? (I've clicked some buttons). Should be next to the title.
(Edit, Watch, History).

-- M

On 01/11/2017 07:38 AM, David Halls wrote:
> Hi All,
>
>
>
> I have signed in but can't find the edit button on
> http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers in
> order to update it - I have edited it before - what am I missing?
>
>
>
> Thanks!
>
>
>
> David
>
>
>
>
> --
> --
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read,
> copied and used only by the intended recipient. If you are not the
> intended recipient, please destroy this message, delete any copies
> held on your system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> --
> -- This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> --
> --
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Editing Academic Wiki

[David Halls]

Hi All,

I have signed in but can't find the edit button on 
http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers in order to 
update it - I have edited it before - what am I missing?

Thanks!

David




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 8-node USRP network with PHY Network Coding and Distributed Synchronisation

[David Halls]

Hi All,

As part of a recently completed EU collaborative FP7 project called Dense 
Cooperate Wireless Networks (DIWINE - http://diwine-project.eu/public/) we have 
developed an 8-node N210 network spread over a large office space demonstrating 
PHY network coding and distributed synchronisation. The abstract for the 
project is:

“DIWINE considers wireless communication in a dense relay / node scenario where 
WNC (Wireless Network Coding) messages are flooded via dense massively 
air-interacting nodes in the self-contained cloud while the PHY air-interface 
between the terminals (sources / destinations) and the cloud is simple and 
uniform. A complex infrastructure cloud creates an equivalent air-interface to 
the terminal, which is as simple as possible. Source and destination 
air-interfaces are completely blind to the cloud network structure. The cloud 
has its own self-contained organising and processing capability.

This concept facilitates energy-efficient, high-throughput and low-latency 
network communication performed directly at the PHY layer, which is capable of 
operating in complicated, dense, randomly defined network topologies and 
domains. The applications of the DIWINE paradigm are generic, being relevant to 
complex systems ranging from intelligent transport systems to healthcare and 
even machine-type communication in wireless networks.

However, in order to exhibit practical, highly focused and high impact results, 
DIWINE concentrates on two core application / demonstration cases: (i) smart 
metering networks and (ii) critical industrial monitoring and control 
applications. To this end, DIWINE algorithms and theoretical technology will be 
integrated into two industrial proof-of-concept demonstration platforms 
targeting the aforementioned applications. Both of these applications require 
low-latency, dense networking solutions and are sure to be integral to future 
European policy and society as evidenced by recent European Commission 
initiatives such as EUROPE 2020.”

The final demonstrator report is at 
http://diwine-project.eu/public/content/files/public/DIWINE_D5.42.pdf, please 
get in touch if you are interested in any of the theory or practice therein. 
One of the key features we used was to enable deployed MATLAB code (compiled 
shared libraries) so be called directly from C++ GR blocks allowing rapid 
prototyping. A manual of how to achieve this is currently being tested and I 
will post this ASAP.

Regards,

David






NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Text size on WX graphics text box

[David Halls]

?Thanks Marcus, Will,


in forms.py there is a function


"

def make_bold(widget):
font = widget.GetFont()
font.SetWeight(wx.FONTWEIGHT_BOLD)
widget.SetFont(font)"

using this format, one can create

"
def make_big(widget,FontSize):
font = widget.GetFont()
font.SetPointSize(FontSize)
widget.SetFont(font)"

and call this from

"class text_box(_form_base):"

e.g.

make_bold(self._text_box)
make_big(self._text_box, FontSize)?

this has the down-size that it does this to ALL text boxes. A quick and dirty 
fix is to do

if label == X or label == Y:
make_bold(self._text_box)
make_big(self._text_box, FontSize)
?
?clearly a more elegant solution is close at hand.

DH



From: Discuss-gnuradio 
 on behalf of 
Will Thompson 
Sent: 15 November 2016 17:02
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] Text size on WX graphics text box

Hi All.
I know GNU radio has moved to QT graphics, however, we need to increase the 
text size on a WX GUI text box element.
Is this possible to do, and if so, how?

Any help will be greatly appreciated.

Kind regards
Will



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl




This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Probing value when no items

[David Halls]

Hi All,


To do this I used a Complex to Mag^2 block, into a probe, giving a normalized 
received power from UHD. I then use this as part of an 'if' statement in the 
Textbox showing ?EVM, like


"float('Inf') if UHD_Probed < 1e-6 or UHD_Probed > 2e-3 else EVM_Probed"


This is a slight hack, and involves setting thresholds, but it works for what 
we need!


Cheers,


David


________
From: David Halls
Sent: 16 November 2016 18:49
To: GNURadio Discussion List
Subject: Probing value when no items


Hi guys,


I am showing EVM (a block we have written) in a text box using a probe signal, 
in an OFDM system based on MB's OFDM example.


this works fine when packets are being received, but I would like to show 0 
when no packets are received (no items coming through HPD), rather than just 
the EVM calculated based on the last *received* packet.


Thanks for your help!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Probing value when no items

[David Halls]

Hi guys,


I am showing EVM (a block we have written) in a text box using a probe signal, 
in an OFDM system based on MB's OFDM example.


this works fine when packets are being received, but I would like to show 0 
when no packets are received (no items coming through HPD), rather than just 
the EVM calculated based on the last *received* packet.


Thanks for your help!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Digital Video Transmission

[David Halls]

Hi guys,


It's been a long time!


I am trying to send some digital video over USRPs, we are using this to show 
the quality of some transmission technique we are working on, can someone 
please point me towards a good example or thread?


We just want to transmit a prerecorded .TS file, and ideally play at the 
receiver side, e.g. using VLC.


Thanks for any pointers!!


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Schmidl & Cox Detector

[David Halls]

Thanks Martin, will look into this. I think we are picking up some very weak 
interferers too.

DH

From: Martin Braun <martin.br...@ettus.com>
Sent: 12 January 2016 07:30
To: David Halls; GNURadio Discussion List
Cc: Will Thompson
Subject: Re: Schmidl & Cox Detector

Noise shouldn't cause false triggers, but if you increase the gain you
might see more artefacts (e.g. more DC offset), which will cause false
triggers.

You can run the block through simulation and see how it behaves.

Cheers,
Martin

On 01/11/2016 11:50 PM, David Halls wrote:
> Hi guys,
>
>
>
> Happy New Year to everyone.
>
>
>
> We are using a flow graph based on the OFDM example in GR, including the
> Schmidl and Cox detector block. Having spread the USRPs out over our
> test environment we have increased the receiver gain significantly (to
> about 30dB). (N210 XCVR240 @ 1MS/s, 2.4GHz)
>
>
>
> Anything above around 10dB Rx gain, we get a lot of false triggering on
> the S block. Presumably the heightened noise causes false peaks in the
> peak detector? The technique doesn’t have a fixed threshold does it? So
> is there a way we can avoid this issue? Not sure how to debug as it’s a
> hierarchical block so not sure how to effectively get intermediate
> debugging output.
>
>
>
> Thanks!
>
>
>
> David
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> 
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> 




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Schmidl & Cox Detector

[David Halls]

Hi guys,

Happy New Year to everyone.

We are using a flow graph based on the OFDM example in GR, including the 
Schmidl and Cox detector block. Having spread the USRPs out over our test 
environment we have increased the receiver gain significantly (to about 30dB). 
(N210 XCVR240 @ 1MS/s, 2.4GHz)

Anything above around 10dB Rx gain, we get a lot of false triggering on the S 
block. Presumably the heightened noise causes false peaks in the peak detector? 
The technique doesn't have a fixed threshold does it? So is there a way we can 
avoid this issue? Not sure how to debug as it's a hierarchical block so not 
sure how to effectively get intermediate debugging output.

Thanks!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[David Halls]

Hi Nemanja, Marcus,

Did you get anywhere with this issue?

We have an equivalent problem that sprung up with one of our flow graphs, 
seemingly randomly. We’re not sure what changed…! We then found that *any* of 
our blocks that used MSG input or output ports gave equivalent errors when in 
even the simplest of flowgraphs. The same does not happen with GR blocks.

By rebuilding our whole out of tree module, the problem seems to have gone 
away. For now. Strange…

Also strange is when I click ‘reload blocks’, all MSG connection arrows are 
deleted and have to be redrawn.

Regards,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Nemanja Savic
Sent: 05 November 2015 12:20
To: Marcus Müller 
Cc: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] message port declaration problem after changing 
to 3.7.8

Hi,
here is a simple photo representing my block. The block is hierarchical and 
consists of a few deframers. When deframers decode correct message, they are 
supposed to send message to db_logger who write information from the message 
into a database. Deframers are written in c++ while db_logger is written in 
python. All deframers have output port whose name is hardcoded to "out_port", 
while db_logger has input port whose name was hardcoded as "in_port"
In previous case, self is db_logger. I have shown there how the message port 
inside that block was defined.

Inside hier block where everything is packed I have lines like this
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger, in_port)
here self references hier block.
Cheers,
Nemanja

On Wed, Nov 4, 2015 at 10:49 PM, Marcus Müller 
> wrote:
I've lost oversight.. is self a hier block, in this case?

On 11/04/2015 06:49 PM, Nemanja Savic wrote:
So, a block called db_logger is written in python and port is defined in 
following way:
self.message_port_register_in(pmt.pmt_intern(in_port))
Well, I am not sure, this works fine in older version.

On Wed, Nov 4, 2015 at 6:41 PM, Marcus Müller 
> wrote:
What does your message_port_register_in call look like?
Or is it a message_port_register_hier_in call? (should it be?)

Cheers,
Marcus

On 11/04/2015 06:37 PM, Nemanja Savic wrote:
Hi,
ok thanks. Does it matter how I everything is declared, but it is clear that 
something changed since 3.6.5.1.
So i have hier block written in python where i define
in_port = 'in_port'
out_port='out_port'
These arguments are passed in the following way:
in_port is receiving port of a block that receives messages from blocks which 
have registered out_block as their transmitting port.
out_port is passed to constructors of all transmitting blocks. They are passed 
as type const char*. Blocks have member d_msg_out_port defined as string. So 
something like this:
d_msg_out_port(msg_out_port)
...
body of constructor:
message_port_register_out(pmt::mp(d_msg_out_port));
So, later on, at the end of hier block I call:
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger, in_port)
Could it be that problem is something with strings (I am not sure is null 
character is passed, no idea)?
Nemanja

On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller 
> wrote:
Hi,

not really, what it says is really "I can't find  in ", with that list being the names of the registered ports.
So, the interesting thing is that seemingly,comparin pmt::symbol("in_port") 
with pmt::symbol("in_port") doesn't quite work well.

I'd have to look into what pmt::comparator looks like; it's my first suspect 
for why that might fail.

Best regards,
Marcus


On 11/04/2015 06:20 PM, Nemanja Savic wrote:
Hi,
hm, could just tell me if I am thinking wrong, but this looks like some of my 
blocks is also called in_port?
Nemanja

On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller 
> wrote:
Hi Nemanja,

a blind suspicion: as "system" is a port that should be registered by the 
runtime for each block, there might be some confusion happening.
Does it work better when you rename your block to something else?

Best regards,
Marcus

On 11/04/2015 06:05 PM, Nemanja Savic wrote:
Hi all guys,
I recently installed 3.7.8, and before that I had 3.6.5.1.
I was using message passing in some of my blocks, but now I get error which is 
following:
Could not find port: in_port in:
in_port
system

Traceback (most recent call last):
  File "./top_block.py", line 178, in 
tb = top_block()
  File "./top_block.py", line 124, in __init__
self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba", samp_rate, 
0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja", "nemanja", 
"det_id_proba", "detectors")
  File 

Re: [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period (Refresh Rate)

[David Halls]

​The error at run-time was caused by setting one of the Alphas > 1. That's 
fixed.


I set the trigger to Free and this seems to resolve the problem. I have also 
split them up so there is only one input per plot as it looks better anyway.


Thanks!


From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
<discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org> on behalf of 
David Halls <david.ha...@toshiba-trel.com>
Sent: 19 November 2015 18:39
To: Johannes Demel; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period 
(Refresh Rate)

Thanks Johannes,

I am currently trying with different trigger modes, and just one input - great 
minds think alike :)

Unfortunately there is no data at any higher rates in the flow graph, its a 
complex relay implementation and the source sends packets with very low duty 
cycle. This is surely the cause of the issue, if there was plenty of data at 
high rate then I am sure it would work fine...

I have got this error at run-time that I just noticed...

"QColor::setAlpha": invalid value 2550
"QColor::setAlpha": invalid value 2550

DH

From: Johannes Demel <uf...@student.kit.edu>
Sent: 19 November 2015 17:37
To: David Halls; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period 
(Refresh Rate)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi David,

I can't find any obvious mistakes with the configuration. Did you try
to play around with different trigger modes?
Did you try to only have one input?
It may be an issue with different rates from your input data and
output data streams.
Did you try to view data in other parts of your system? Maybe you
could nail it down to a specific block where nothing gets displayed
anymore.

Cheers
Johannes

On 19.11.2015 15:48, David Halls wrote:
> Thanks Johannes,
>
> I tried setting update period to 0, and still no luck. I have
> passed the data to text file and checked in MATLAB and the data is
> fine. With WX graphics the update was slow but with my QT, it
> seems that I am not getting any update at all, I think it's only
> the first 576 points that show for the whole duration of the run.
>
> Attached are the settings.
>
> Any ideas?!!?!?!
>
> Thanks!
>
> DH  From:
> discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org<mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org>
> <discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org> on
> behalf of Johannes Demel <uf...@student.kit.edu> Sent: 17 November
> 2015 12:40 To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> 
> Subject: Re:
> [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period
> (Refresh Rate)
>
> Hi David,
>
>> 2) Should I set 'Number of Points' to 576?
> Yes. The block will take this amount of points and display it. Then
> wait a given time and take the next chunk to display it. As long as
> the block does not have at least the specified amount of symbols
> available, it will not update or display anything.
>
>
>> 3) Update period, what is this in terms of, Hz or..., what
>> should I set this to?
> It should be a value in seconds. Since the sink is only updated
> when enough new samples are available and you send only very few
> to the sink, I recommend setting this value to 0.0. This should
> trigger an update every 'Number of Points' received samples.
>
>
>
>> Sorry if this is all detailed somewhere but I can't find it
>> easily in https://gnuradio.org/doc/doxygen/page_qtgui.html
>
>
>
>> 
>
>> NOTE: The information in this email and any attachments may be
>> confidential and/or legally privileged. This message may be read,
>> copied and used only by the intended recipient. If you are not
>> the intended recipient, please destroy this message, delete any
>> copies held on your system and notify the sender immediately.
>
>> Toshiba Research Europe Limited, registered in England and Wales
>> (2519556). Registered Office 208 Cambridge Science Park, Milton
>> Road, Cambridge CB4 0GZ, England. Web:
>> www.toshiba.eu/research/trl<http://www.toshiba.eu/research/trl>
>> -
- -
>
>>
>>
- -
>
>
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
>> For more information please visit http://www.mimecast.com
>> -
- -
>
&

Re: [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period (Refresh Rate)

[David Halls]

Thanks Johannes,

I am currently trying with different trigger modes, and just one input - great 
minds think alike :)

Unfortunately there is no data at any higher rates in the flow graph, its a 
complex relay implementation and the source sends packets with very low duty 
cycle. This is surely the cause of the issue, if there was plenty of data at 
high rate then I am sure it would work fine...

I have got this error at run-time that I just noticed...

"QColor::setAlpha": invalid value 2550
"QColor::setAlpha": invalid value 2550

DH

From: Johannes Demel <uf...@student.kit.edu>
Sent: 19 November 2015 17:37
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period 
(Refresh Rate)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi David,

I can't find any obvious mistakes with the configuration. Did you try
to play around with different trigger modes?
Did you try to only have one input?
It may be an issue with different rates from your input data and
output data streams.
Did you try to view data in other parts of your system? Maybe you
could nail it down to a specific block where nothing gets displayed
anymore.

Cheers
Johannes

On 19.11.2015 15:48, David Halls wrote:
> Thanks Johannes,
>
> I tried setting update period to 0, and still no luck. I have
> passed the data to text file and checked in MATLAB and the data is
> fine. With WX graphics the update was slow but with my QT, it
> seems that I am not getting any update at all, I think it's only
> the first 576 points that show for the whole duration of the run.
>
> Attached are the settings.
>
> Any ideas?!!?!?!
>
> Thanks!
>
> DH  From:
> discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
> <discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org> on
> behalf of Johannes Demel <uf...@student.kit.edu> Sent: 17 November
> 2015 12:40 To: discuss-gnuradio@gnu.org Subject: Re:
> [Discuss-gnuradio] QT GUI (Constellation Sink) Update Period
> (Refresh Rate)
>
> Hi David,
>
>> 2) Should I set 'Number of Points' to 576?
> Yes. The block will take this amount of points and display it. Then
> wait a given time and take the next chunk to display it. As long as
> the block does not have at least the specified amount of symbols
> available, it will not update or display anything.
>
>
>> 3) Update period, what is this in terms of, Hz or..., what
>> should I set this to?
> It should be a value in seconds. Since the sink is only updated
> when enough new samples are available and you send only very few
> to the sink, I recommend setting this value to 0.0. This should
> trigger an update every 'Number of Points' received samples.
>
>
>
>> Sorry if this is all detailed somewhere but I can't find it
>> easily in https://gnuradio.org/doc/doxygen/page_qtgui.html
>
>
>
>> 
>
>> NOTE: The information in this email and any attachments may be
>> confidential and/or legally privileged. This message may be read,
>> copied and used only by the intended recipient. If you are not
>> the intended recipient, please destroy this message, delete any
>> copies held on your system and notify the sender immediately.
>
>> Toshiba Research Europe Limited, registered in England and Wales
>>  (2519556). Registered Office 208 Cambridge Science Park, Milton
>>  Road, Cambridge CB4 0GZ, England. Web:
>> www.toshiba.eu/research/trl
>> -
- -
>
>>
>>
- -
>
>
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
>> For more information please visit http://www.mimecast.com
>> -
- -
>
>>
>>
- -
>
>
>
>
>> ___ 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
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read,
> copied and used only by the intended recipient. If you are not the
> intended recipient, please destroy this message, delete any copies
> held on your system and notify the sender immediately.
>
> Toshiba Research Europe Limited,

[Discuss-gnuradio] QT GUI (Constellation Sink) Update Period (Refresh Rate)

[David Halls]

Hi all,


I am using QT, finally, but I am struggling with the 'refresh rate' on the 
Constellation Sink.


My system receives one packet of 576 symbols (points), every second (slow!). I 
would like the plot to display all 576 each second, then wipe, and show the 
next 576 etc. There seems to be a lot of persistence and almost no update...


1) Line Alpha is to do with the transparency - not persistence?

2) Should I set 'Number of Points' to 576?

3) Update period, what is this in terms of, Hz or..., what should I set this to?


Sorry if this is all detailed somewhere but I can't find it easily in 
https://gnuradio.org/doc/doxygen/page_qtgui.html





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FEC, Repetition Encoder/Decoder

[David Halls]

Hi guys,


I am trying to use a combination of a CC code and a repetition code. This might 
sounds a bit odd, but it just so happens I have 5 short ints 5*8 bits, so I am 
repeating this 7 times, then using 1/2 rate to fill my packet - 576bits.


I can get the codes to work separately, but please see attached .grc, I can't 
get the repetition decoder to work, it doesn't output anything. I clearly have 
some parameters/sizes wrong. When I use the FEC Decoder (disabled) rather that 
the Extended FEC decoder for the repetition decoder, I get the right number of 
bytes out - but the wrong values.


Thanks for your help!!


David?



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
#!/usr/bin/env python2
##
# GNU Radio Python Flow Graph
# Title: Fecapi Cc Decoders
# Generated: Tue Nov 17 09:33:12 2015
##

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 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 wxgui as grc_wxgui
from optparse import OptionParser
import wx


class fecapi_cc_decoders(grc_wxgui.top_block_gui):

def __init__(self, frame_size=5, puncpat='11', reps=7):
grc_wxgui.top_block_gui.__init__(self, title="Fecapi Cc Decoders")
_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

##
# Parameters
##
self.frame_size = frame_size
self.puncpat = puncpat
self.reps = reps

##
# Variables
##
self.rate = rate = 2
self.polys = polys = [109, 79]
self.k = k = 7
self.samp_rate = samp_rate = 5


self.enc_rep = enc_rep = fec.repetition_encoder_make(frame_size*8, reps)



self.enc_cc = enc_cc = fec.cc_encoder_make(reps*frame_size*8, k, rate, (polys), 0, fec.CC_TERMINATED, True)



self.dec_rep = dec_rep = fec.repetition_decoder.make(frame_size*8, reps, 0.5)



self.dec_cc = dec_cc = fec.cc_decoder.make(reps*frame_size*8, k, rate, (polys), 0, -1, fec.CC_TERMINATED, True)


##
# Blocks
##
self.fec_extended_encoder_0_0 = fec.extended_encoder(encoder_obj_list=enc_rep, threading= None, puncpat=puncpat)
self.fec_extended_encoder_0 = fec.extended_encoder(encoder_obj_list=enc_cc, threading= None, puncpat=puncpat)
self.fec_extended_decoder_0_0_0 = self.fec_extended_decoder_0_0_0 = fec_extended_decoder_0_0_0 = fec.extended_decoder(decoder_obj_list=dec_cc, threading= None, ann=None, puncpat=puncpat, integration_period=1)
self.fec_extended_decoder_0_0 = self.fec_extended_decoder_0_0 = fec_extended_decoder_0_0 = fec.extended_decoder(decoder_obj_list=dec_cc, threading= None, ann=None, puncpat=puncpat, integration_period=1)
self.digital_map_bb_0 = digital.map_bb(([-1, 1]))
self.blocks_vector_source_x_0_1_0 = blocks.vector_source_b([2,3,9,12,2+3+9+12], False, 1, [])
self.blocks_unpack_k_bits_bb_0 = blocks.unpack_k_bits_bb(8)
self.blocks_pack_k_bits_bb_0_0 = blocks.pack_k_bits_bb(8)
self.blocks_file_sink_0_0 = blocks.file_sink(gr.sizeof_char*1, "fec_input.dat")
self.blocks_file_sink_0_0.set_unbuffered(True)
self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_char*1, 

[Discuss-gnuradio] Radio Buttons that are Output as well as Inputs

[David Halls]

?Hi guys,


I am using radio buttons to change source parameters, namely coding rate and 
constellation order.


I also have an adaptive mode. When I enable this, I want the radio buttons to 
become outputs instead of inputs showing the value chosen by the algorithm.


Is there any way to do this?


Thanks!!


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[David Halls]

?Thanks for your reply Marcus, but does that mean there is no way around the 
problem?


Regards,


David



From: mle...@ripnet.com <mle...@ripnet.com>
Sent: 25 September 2015 20:24
To: Andy Walls
Cc: David Halls; discuss-gnuradio@gnu.org; 
discuss-gnuradio-bounces+mleech=ripnet@gnu.org
Subject: Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send 
error:send_to: Message too long


If the sending machine sets DF in the IP header, then any interstitial machine 
that must fragment will drop the packet as well.

Best to stick to MTU-sized payloads with UDP, since IP fragmentation is handled 
poorly in many cases--either due to policy, or bad implementations.







On 2015-09-25 15:17, Andy Walls wrote:

From: David Halls Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send

error:send_to: Message too long

Date: Fri, 25 Sep 2015 09:05:56 +
Dear All, When I increase my packet length in a transmission flow graph to over 
16,000 bits, I get the following error "ERROR: send error:send_to: Message too 
long?"

This looks like the underlying sendto() system call is returning
EMSGSIZE.  From man sendto:

 EMSGSIZE
  The  socket  type  requires that message be sent atomically, and
  the size of the message to be sent made this impossible.

this is from the UDP block which I am using in order to send the transmitted 
bits to the destination in order to perform BER. I am sending the packets in 
bursts, one packet every two seconds.
I currently have the Payload size set to 147.2k and Send Null Pkt as EOF set to 
true.
Is this some fundamental limit, or can I overcome the issue?

16,000 bits is 2000 bytes.  The default MTU is usually 1500 bytes (for
IP header, UDP header, and payload together).  Try modifying the MTU on
your machine's network interface to something larger, say 4000.

The MTU of the receiving machine or other network hardware might still
be only 1500, so the the UDP packet could get IP fragmented.  I'm not
sure how well UDP works when fragmented.

-Andy


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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[David Halls]

Dear All,


When I increase my packet length in a transmission flow graph to over 16,000 
bits, I get the following error


"ERROR: send error:send_to: Message too long?"


this is from the UDP block which I am using in order to send the transmitted 
bits to the destination in order to perform BER. I am sending the packets in 
bursts, one packet every two seconds.

I currently have the Payload size set to 147.2k and Send Null Pkt as EOF set to 
true.


Is this some fundamental limit, or can I overcome the issue?


Regards,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Function Probe and OOT Blocks

[David Halls]

​Thanks Patrick,


There may be many ways to skin a cat, but this method was very quick and easy 
to implement and does exactly as I need :)


From: Patrick Sathyanathan <wp...@hotmail.com>
Sent: 24 September 2015 21:27
To: Kevin McQuiggin; David Halls
Cc: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Function Probe and OOT Blocks

Hi David, Making the parameter vary at runtime is simple and just needs some 
extra XML and python code. The parameter should be an argument to the __init__ 
method (constructor) of your block and should have a "" declaration in the 
matching XML file. Let's say the parameter name is "variable_param" with a 
declaration like: Variable parameter variable_param 42 int Then you need to add 
the following in the XML file: set_variable_param($variable_param) And you need 
to implement the "set_variable_param" method in your python class to take 
whatever action is needed when the parameter value changes. This method will be 
called every time the value of the expression in the underlined "Variable 
parameter" box in the GUI changes. The method will look like: def 
set_variable_param(self, new_value): whatever code This should make GRC 
underline the variable_param in the GUI and it will be variable at runtime. 
Thanks, --Patrick  > From: mcqui...@sfu.ca > 
Date: Thu, 24 Sep 2015 10:35:34 -0700 > To: david.ha...@toshiba-trel.com > CC: 
discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Function Probe and 
OOT Blocks > > Hi David: > > I'm a relative newbie myself, but I can say that I 
had this same issue. > I had a block with a static parameter that I wanted to 
be able to > change dynamically at runtime. > > I looked at the block's source 
code, and also at a block that had a > dynamically adjustable parameter. > > 
Basically, and with a little help from the list (Marcus Muller in > particular) 
as I had to learn c++, I was able to use the code from the > dynamic block as 
an example, and modify the static block to change the > parameter to be 
dynamically changeable. It all came down to at most a > couple dozen lines of 
code. The bigger challenge was learning about > Gnuradio's architecture, to 
know what to do. > > I would suggest a similar approach. You will find the list 
members > very helpful. I'd also look at the guided tutorials, there are good > 
examples there under "how to write a c++ block". > > I will help if I can but 
alas, I am still quite a newbie, so others > will be able to help much more 
efficiently! > > Kevin > > Sent from my iPad > > On Sep 23, 2015, at 4:12 AM, 
David Halls > > > wrote: > > > ​Hi guys, > > > I am familiar with using 
function probes to update values to blocks. > This is straightforward with 
built in blocks like Multiply Const, where > the input is underline in the GRC 
dialogue box. > > > How do I create a block, specifically a Python block, that 
allows me to > update parameters in this fashion so that they are not fixed at 
> runtime? > > > Regards, > > > David > >  > > 
NOTE: The information in this email and any attachments may be > confidential 
and/or legally privileged. This message may be read, > copied and used only by 
the intended recipient. If you are not the > intended recipient, please destroy 
this message, delete any copies held > on your system and notify the sender 
immediately. > > Toshiba Research Europe Limited, registered in England and 
Wales > (2519556). Registered Office 208 Cambridge Science Park, Milton Road, > 
Cambridge CB4 0GZ, England. Web: > www.toshiba.eu/research/trl > > > > 
 > This email has been scanned for email 
related threats and delivered > safely by Mimecast. > For more information 
please visit http://www.mimecast.com >  > 
___ > 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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambr

[Discuss-gnuradio] Function Probe and OOT Blocks

[David Halls]

?Hi guys,


I am familiar with using function probes to update values to blocks. This is 
straightforward with built in blocks like Multiply Const, where the input is 
underline in the GRC dialogue box.


How do I create a block, specifically a Python block, that allows me to update 
parameters in this fashion so that they are not fixed at runtime?


Regards,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Scheduler and Tags - HELP!

[David Halls]

Dear All,


I have recently updated my GR from a prehistoric version. I am having some 
problems related to scheduling/tags.


I have a Python block that takes in vectors of 7680 complex items. This is made 
up of 10 packets, each with 16 OFDM symbols with 48 data carriers each.


I am sending just 10 packets, one burst, and in my old GR version this block 
would then be called once, and only once, and all tags would be present (each 
symbol, i.e. every 48th item, is tagged with the channel taps). I


n the new version of GR (no other changes), it is now called TWICE, and the 
first time only the tags from the first 5 packets are available, although the 
ITEMs for all 10 seem available.


This almost seems like some kind of parallelisation, that the block is being 
called before the tags are completely applied by a preceding block. Can anyone 
help at all? I can of course provide code...


Many thanks,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduler and Tags - HELP!

[David Halls]

Dear All,


I have found more closely the issue.


When the first burst is received, the block that does 'stream_to_vector', only 
copies the first half of the tags contained within the range of items.


For subsequent bursts the correct number of tags are copied, but starting with 
the second half of those that should be in the first vector.


Can anyone suggest what's going wrong?


Regards,


David



From: David Halls
Sent: 10 September 2015 12:56
To: discuss-gnuradio@gnu.org
Cc: martin.br...@ettus.com
Subject: Scheduler and Tags - HELP!


Dear All,


I have recently updated my GR from a prehistoric version. I am having some 
problems related to scheduling/tags.


I have a Python block that takes in vectors of 7680 complex items. This is made 
up of 10 packets, each with 16 OFDM symbols with 48 data carriers each.


I am sending just 10 packets, one burst, and in my old GR version this block 
would then be called once, and only once, and all tags would be present (each 
symbol, i.e. every 48th item, is tagged with the channel taps). I


n the new version of GR (no other changes), it is now called TWICE, and the 
first time only the tags from the first 5 packets are available, although the 
ITEMs for all 10 seem available.


This almost seems like some kind of parallelisation, that the block is being 
called before the tags are completely applied by a preceding block. Can anyone 
help at all? I can of course provide code...


Many thanks,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduler and Tags - HELP!

[David Halls]

Thanks Jeff,

The block is a sync block as it should take in one vector and pass out one 
vector, of the same size. The get_tags_in_range should be OK too. Again as its 
one vector coming in there is only one 'item' at a time too.

tags = self.get_tags_in_range(0,self.nitems_read(0),self.nitems_read(0) + 
len(input_items[0]),pmt.string_to_symbol("ofdm_sync_chan_taps"))

As I said it worked fine on my ancient GNU Radio version.

I have pinned down the problem, as it occurs *before* my block. When I put a 
'tag_debug' after the 'stream_to_vector' block that precedes my Python block, 
there are only half the number of tags in the first vector, than are produced 
by a 'tag_debug' block placed before the  'stream_to_vector' block.

Of course when it is a stream the tags are spread over a number of items, these 
create just one vector which 'scoops' up all these tags and puts them onto the 
single item that represents the vector.

In the 2nd and onwards vectors there are the right number of tags, but the 
first half are from the previous vectors worth of items.

Thanks,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
<discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org> on behalf of 
Jeff Long <willco...@gmail.com>
Sent: 10 September 2015 16:46
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduler and Tags - HELP!

Do you have a forecast() function defined in your block? If not, the
scheduler will call it with however many items it has available at the time.

Tags would be propagated by stream_to_vector at the same time it copies
items to its output buffer. Your block would need to specify the
appropriate start/end in get_tags_in_range().

- Jeff

On 09/10/2015 10:49 AM, David Halls wrote:
> Dear All,
>
>
> I have found more closely the issue.
>
>
> When the first burst is received, the block that does
> 'stream_to_vector', only copies the first half of the tags contained
> within the range of items.
>
>
> For subsequent bursts the correct number of tags are copied, but
> starting with the second half of those that should be in the first vector.
>
>
> Can anyone suggest what's going wrong?
>
>
> Regards,
>
>
> David
>
>
> 
> *From:* David Halls
> *Sent:* 10 September 2015 12:56
> *To:* discuss-gnuradio@gnu.org
> *Cc:* martin.br...@ettus.com
> *Subject:* Scheduler and Tags - HELP!
>
> Dear All,
>
>
> I have recently updated my GR from a prehistoric version. I am having
> some problems related to scheduling/tags.
>
>
> I have a Python block that takes in vectors of 7680 complex items. This
> is made up of 10 packets, each with 16 OFDM symbols with 48 data
> carriers each.
>
>
> I am sending just 10 packets, one burst, and in my old GR version this
> block would then be called once, and only once, and all tags would be
> present (each symbol, i.e. every 48th item, is tagged with the channel
> taps). I
>
>
> n the new version of GR (no other changes), it is now called TWICE, and
> the first time only the tags from the first 5 packets are available,
> although the ITEMs for all 10 seem available.
>
>
> This almost seems like some kind of parallelisation, that the block is
> being called before the tags are completely applied by a preceding
> block. Can anyone help at all? I can of course provide code...
>
>
> Many thanks,
>
>
> David
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> 
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> 
>
>
> ___
> 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-gnur

Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version

[David Halls]

​Dear All,


I have now had success building GNU Radio with previous Boost (1.49) version. 
Thanks for the help.


First you have to get boost 1.49 to build from source, download from


http://www.boost.org/users/history/version_1_49_0.html


then some edits are required as per


this involves find and replace of TIME_UTC with TIME_UTC_ in a number of files. 
Just do a find and replace in all of the source code, they are all shown in


https://svn.boost.org/trac/boost/changeset/78802


then do the install to a local directory somewhere...


./boostrap.sh --prefix=PATH_TO_LOCAL_DIRECTORY (i.e. not system folders, do not 
want to conflict with system boost)

./b2 install


then make GNU Radio with:


cmake -DBOOST_INCLUDEDIR=/PATH_TO_LOCAL_DIRECTORY/include 
-DBOOST_LIBRARYDIR=/PATH_TO_LOCAL_DIRECTORY​/lib ../


then make, install...


Finally at run-time one must point to the 1.49 libraries when launching GRC. I 
achieved this by adding the library path to /etc/ld.so.conf, but others may 
correct me and suggest a more suitable location for that change.


Thanks all for the help.


David


p.s. I will go on to create full documentation about how to call MATLAB shared 
libraries from GNU Radio, now the boost conflict has been resolved...



From: David Halls
Sent: 19 August 2015 17:48
To: Marcus Müller; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Building GNU Radio with previous Boost version


​Marcus, Nathan, All,


Thanks Marcus I have tried building GNU Radio with Boost 1.49 (that required by 
MATLAB)


I've made a little progress, but it's slow going. I got the header files (not 
included with the MATLAB release) by downloading Boost 1.49, and building it 
and installing it to a home directory (not /usr/...).

cmake seems to run fine with

"cmake -DBOOST_INCLUDEDIR=/home/gnuradio/gnuradio_trlcode/boost_1_49/include 
-DBOOST_LIBRARYDIR=/usr/local/MATLAB/MATLAB_Compiler_Runtime/v81/bin/glnxa64 
../"

(so I am pointing to my header files for the INCLUDEDIR, and MATLABs libraries 
for the LIBRARYDIR)

the output includes positive sounding things like
​
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   filesystem
--   system
--   unit_test_framework
--   program_options

and

-- Configuring gnuradio-runtime support...
--   Dependency Boost_FOUND = 1

​etc

but when I then try "make VERBOSE=1", there seem to be problems linking volk as 
pasted below. Can anyone help? Thanks!

David

make VERBOSE=1
/usr/bin/cmake -H/home/gnuradio/gnuradio_build/gnuradio 
-B/home/gnuradio/gnuradio_build/gnuradio/build --check-build-system 
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start 
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles 
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make -f volk/lib/CMakeFiles/volk.dir/build.make 
volk/lib/CMakeFiles/volk.dir/depend
make[2]: Entering directory `/home/gnuradio/gnuradio_build/gnuradio/build'
cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /home/gnuradio/gnuradio_build/gnuradio 
/home/gnuradio/gnuradio_build/gnuradio/volk/lib 
/home/gnuradio/gnuradio_build/gnuradio/build 
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib 
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib/CMakeFiles/volk.dir/DependInfo.cmake
 --color=
make[2]: Leaving directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make -f volk/lib/CMakeFiles/volk.dir/build.make 
volk/lib/CMakeFiles/volk.dir/build
make[2]: Entering directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make[2]: Nothing to be done for `volk/lib/CMakeFiles/volk.dir/build'.
make[2]: Leaving directory `/home/gnuradio/gnuradio_build/gnuradio/build'
/usr/bin/cmake -E cmake_progress_report 
/home/gnuradio/gnuradio_build/gnuradio/build/CMakeFiles  95 96 97 98 99
[  5%] Built target volk
make -f volk/lib/CMakeFiles/test_all.dir/build.make 
volk/lib/CMakeFiles/test_all.dir/depend
make[2]: Entering directory `/home/gnuradio/gnuradio_build/gnuradio/build'
cd /home/gnuradio/gnuradio_build/gnuradio/build && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /home/gnuradio/gnuradio_build/gnuradio 
/home/gnuradio/gnuradio_build/gnuradio/volk/lib 
/home/gnuradio/gnuradio_build/gnuradio/build 
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib 
/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib/CMakeFiles/test_all.dir/DependInfo.cmake
 --color=
make[2]: Leaving directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make -f volk/lib/CMakeFiles/test_all.dir/build.make 
volk/lib/CMakeFiles/test_all.dir/build
make[2]: Entering directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make[2]: Nothing to be done for `volk/lib/CMakeFiles/test_all.dir/build'.
make[2]: Leaving directory `/home/gnuradio/gnuradio_build/gnurad

Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version

[David Halls]

 
cmake_depends Unix Makefiles /home/gnuradio/gnuradio_build/gnuradio 
/home/gnuradio/gnuradio_build/gnuradio/volk/apps 
/home/gnuradio/gnuradio_build/gnuradio/build 
/home/gnuradio/gnuradio_build/gnuradio/build/volk/apps 
/home/gnuradio/gnuradio_build/gnuradio/build/volk/apps/CMakeFiles/volk_profile.dir/DependInfo.cmake
 --color=
make[2]: Leaving directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make -f volk/apps/CMakeFiles/volk_profile.dir/build.make 
volk/apps/CMakeFiles/volk_profile.dir/build
make[2]: Entering directory `/home/gnuradio/gnuradio_build/gnuradio/build'
Linking CXX executable volk_profile
cd /home/gnuradio/gnuradio_build/gnuradio/build/volk/apps  /usr/bin/cmake -E 
cmake_link_script CMakeFiles/volk_profile.dir/link.txt --verbose=1
/usr/bin/c++-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 
-DNDEBUGCMakeFiles/volk_profile.dir/volk_profile.cc.o 
CMakeFiles/volk_profile.dir/__/lib/qa_utils.cc.o  -o volk_profile -rdynamic 
../lib/libvolk.so.0.0.0 -lboost_filesystem -lboost_system 
-lboost_unit_test_framework -lboost_program_options -ldl -lorc-0.4 
-Wl,-rpath,/home/gnuradio/gnuradio_build/gnuradio/build/volk/lib:
CMakeFiles/volk_profile.dir/volk_profile.cc.o: In function `main':
volk_profile.cc:(.text.startup+0x613b): undefined reference to 
`boost::filesystem3::path::wchar_t_codecvt_facet()'
volk_profile.cc:(.text.startup+0x6193): undefined reference to 
`boost::filesystem3::path::parent_path() const'
volk_profile.cc:(.text.startup+0x61a2): undefined reference to 
`boost::filesystem3::detail::status(boost::filesystem3::path const, 
boost::system::error_code*)'
volk_profile.cc:(.text.startup+0x65b1): undefined reference to 
`boost::filesystem3::path::parent_path() const'
volk_profile.cc:(.text.startup+0x6613): undefined reference to 
`boost::filesystem3::path::parent_path() const'
volk_profile.cc:(.text.startup+0x6622): undefined reference to 
`boost::filesystem3::detail::create_directories(boost::filesystem3::path 
const, boost::system::error_code*)'
collect2: error: ld returned 1 exit status
make[2]: *** [volk/apps/volk_profile] Error 1
make[2]: Leaving directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
make[1]: Leaving directory `/home/gnuradio/gnuradio_build/gnuradio/build'
make: *** [all] Error 2






From: Marcus Müller marcus.muel...@ettus.com
Sent: 17 August 2015 15:22
To: David Halls; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Building GNU Radio with previous Boost version

Hi David,

I think we can all agree that the community starting to run at the mention of 
Matlab is not a good thing - I think there might be frustration behind this 
flight instinct, so let's try to make this a success story.

I concur with the pretty detailed reply from mathworks; the reason is likely to 
be the binary/abi mismatch between the boost GNU Radio/your native runtime 
linker uses and the one that the Matlab library needs.

Now, you should be able to specify the boost that cmake uses when configuring 
the build process:
cmake -DBOOST_INCLUDEDIR=matlab-shipped boost includes 
-DBOOST_LIBRARY_DIR=matlab-shipped library dir ..
Also make sure to specify export LD_LIBRARY_DIR containing the same matlab 
library dir; otherwise, at runtime your system's boost will get linked in, and 
that will still result in segfaults.

Maybe there is also the option to statically link the Matlab library before 
loading it from GNU Radio, instead of doing it the other way around (which is 
option 2). To me, that sounds more logically sound, since it's Matlab that 
introduces library dependencies that are incompatible with your system 
libraries, because otherwise you might run into the same problem for other 
libraries that both Mathworks code and GNU Radio use and Mathworks ships their 
own version with. However, I don't know if that would even be possible, as I 
don't have Matlab around to test it.

All in all, I also like option 3 from Mathwork's reply, though I don't think 
the .mat method would work well for streaming like GNU Radio does;
you should be able to just open a file (fopen) and read from it (fread) in a 
loop, so that you can get what a file source in GNU Radio writes to a FIFO; 
basically, as Matlab pseudocode:

infile = fopen(/tmp/fifo_in);
outfile = fopen(/tmp/fifo_out, w);
while 1
datain = fread(infile, 1000, float32);
dataout = do_some_processing(datain);
fwrite(outfile, dataout, float32);
end

you'd have to

mkfifo /tmp/fifo_in /tmp/fifo_out

first and then use file sink/source to write/read to/from these.

Of course, a socket- or IPC-based solution might be cleaner, but I don't know 
much popular matlab tools that make it easy to write real-world compatible 
Matlab code (I think that lack of knowledge of high-quality well-known 
libraries might be what leads people to run away as soon as you mention Matlab).

Best regards,
Marcus


Am 17. August 2015 12

Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version

[David Halls]

/gnuradio_trlcode/gr-trl/lib/libdla.so+8747 
libdlaInitialize+0023
[ 18] 0x7f1ec6c3393d  
/usr/local/lib/libgnuradio-trl.so+00493885
[ 19] 0x7f1ec6c33e08  
/usr/local/lib/libgnuradio-trl.so+00495112 
_ZN2gr3trl5dla_r4makeEiiibbfb+0104
[ 20] 0x7f1ec70bb740 
/usr/local/lib/python2.7/dist-packages/trl/_trl_swig.so+02164544
[ 21] 0x0052c6d5   
/usr/bin/python2+01230549 PyEval_EvalFrameEx+1061
[ 22] 0x0055c594   
/usr/bin/python2+01426836 PyEval_EvalCodeEx+0676
[ 23] 0x0052ca8d   
/usr/bin/python2+01231501 PyEval_EvalFrameEx+2013
[ 24] 0x0056d0aa   
/usr/bin/python2+01495210
[ 25] 0x004d9854   
/usr/bin/python2+00890964
[ 26] 0x004d8379   
/usr/bin/python2+00885625
[ 27] 0x004f5d0b   
/usr/bin/python2+01006859
[ 28] 0x0052cc20   
/usr/bin/python2+01231904 PyEval_EvalFrameEx+2416
[ 29] 0x0055c594   
/usr/bin/python2+01426836 PyEval_EvalCodeEx+0676
[ 30] 0x005b7392   
/usr/bin/python2+01799058 PyEval_EvalCode+0050
[ 31] 0x00469663   
/usr/bin/python2+00431715
[ 32] 0x004699e3   
/usr/bin/python2+00432611 PyRun_FileExFlags+0146
[ 33] 0x00469f1c   
/usr/bin/python2+00433948 PyRun_SimpleFileExFlags+0750
[ 34] 0x0046ab81   
/usr/bin/python2+00437121 Py_Main+2910
[ 35] 0x7f1ee229cec5
/lib/x86_64-linux-gnu/libc.so.6+00138949 __libc_start_main+0245
[ 36] 0x0057497e   
/usr/bin/python2+01526142


If this problem is reproducible, please submit a Service Request via:
http://www.mathworks.com/support/contact_us/

A technical support engineer might contact you with further information.

Thank you for your help.** This crash report has been saved to disk as 
/home/gnuradio/matlab_crash_dump.16446-1 **



MATLAB is exiting because of fatal error

 Done​



The stack trace strongly suggests that the crash is related to a Boost library 
version conflict. MATLAB R2013a/MCR v8.1 includes and depends on Boost 1.49 
libraries. In the stack trace we see that in practice your system's Boost 1.54 
libraries are being accessed however.

These things may occur if you load a MATLAB Compiler Shared Library into an 
application which is already making use of this system Boost library.

There are no quick/easy workarounds for such issues other than:

1. Making sure that all components involved make use of the same Boost library 
versions, or

2. Making sure that the components which require Boost statically link against 
the Boost version which they prefer, or

3. Separating the different components which require Boost into separate 
applications.

In further detail:

Option 1: It looks like you are making use of GNU Radio from Python, I do 
believe that GNU Radio depends on Boost. You may be able to (re)compile GNU 
Radio to make it use Boost 1.49 and where you even specifically link it to the 
Boost libraries shipped with the MCR (these can be found in the bin/glnxa64 
directory).

Option 2: If GNU Radio specifically requires a different Boost version you may 
be able to recompile it and statically link it against this version.

Option 3: Instead of compiling your MATLAB Code into a Shared Library, compile 
it into a standalone application which you can launch from your Python process. 
This separate standalone should be able to use its own Boost libraries without 
problems then. There are Python libraries which can read and write MAT-files so 
you can relatively efficiently pass in- and outputs from and to that standalone 
application through MAT-files.




From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org on behalf of 
Marcus Müller marcus.muel...@ettus.com
Sent: 14 August 2015 17:59
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version

Hi David,

boost  1.35 should work, but 1.49 is, if I remember correctly, an especially 
buggy version, especially in Ubuntu.
I guess you wouldn't ask if there wasn't a problem, so maybe you want to 
elaborate?

Best regards,
Marcus

On 08/14/2015 06:00 PM, David Halls wrote:

​Hi guys,


For a number of complicated reasons I would like to build GNU Radio with an 
older version of Boost. Specifically 1.49.


Thanks,


David



NOTE: The information in this email and any attachments may be confidential

Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version

[David Halls]

??Thanks Nathan,


Marcus - would you agree?


I am not sure I totally understand what that entails, and I certainly am not 
clear how to go about doing it!! Does it mean that GNU Radio would use it's 
preferred Boost via static linking leaving MATLAB to use a different version 
- how would this run differently to the current setup, and avoid conflict?


Thanks guys.


David




From: West, Nathan n...@ostatemail.okstate.edu
Sent: 17 August 2015 14:56
To: David Halls
Cc: Marcus Müller; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version



On Mon, Aug 17, 2015 at 6:27 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:

There are no quick/easy workarounds for such issues other than:

1. Making sure that all components involved make use of the same Boost library 
versions, or

2. Making sure that the components which require Boost statically link against 
the Boost version which they prefer, or

3. Separating the different components which require Boost into separate 
applications.

In further detail:

Option 1: It looks like you are making use of GNU Radio from Python, I do 
believe that GNU Radio depends on Boost. You may be able to (re)compile GNU 
Radio to make it use Boost 1.49 and where you even specifically link it to the 
Boost libraries shipped with the MCR (these can be found in the bin/glnxa64 
directory).

Option 2: If GNU Radio specifically requires a different Boost version you may 
be able to recompile it and statically link it against this version.

Option 3: Instead of compiling your MATLAB Code into a Shared Library, compile 
it into a standalone application which you can launch from your Python process. 
This separate standalone should be able to use its own Boost libraries without 
problems then. There are Python libraries which can read and write MAT-files so 
you can relatively efficiently pass in- and outputs from and to that standalone 
application through MAT-files.

This sounds like good advice. Option 2 sounds the most sane.



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Building GNU Radio with previous Boost version

[David Halls]

?Hi guys,


For a number of complicated reasons I would like to build GNU Radio with an 
older version of Boost. Specifically 1.49.


Thanks,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] N210 XCVR2450 Max Transmit Gain

[David Halls]

?Dear All,


For some experiments I would like to transmit using N210s with XCVR2450 with 
maximum transmit gain.

I can see Ettus website that the XCVR2450 board in the transmit path has a gain 
of:
 VGA: 0-30 dB range
 BB: 0-5 dB range?

Can I just set the gain via GNU Radio/UHD to 35, or do I need to set these two 
values individually, and if so how.

I read this thread, but didn't quite follow

http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00462.html?

Thanks!







NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Adding EOB when using Vectors

[David Halls]

Thanks Martin,

Unfortunately I couldn't get this to work, even when adding packet_len.

To solve the problem I added another custom sync block called 'add_EOB' that 
takes in packet_len and adds EOB on the relevant item.

for(int i=0; inoutput_items; i++)
{
if( nitems_written(0)+i == (d_samples-1)+d_burst_num*d_samples )
{
add_item_tag(0, //stream ID
nitems_written(0)+i,
pmt::string_to_symbol(tx_eob), //tag name
pmt::from_bool(1)//, //set this true to indicate end of burst
//pmt::string_to_symbol(id.str())
);
d_burst_num++;
}
out[i] = in[i];
}


From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org on behalf of 
Martin Braun martin.br...@ettus.com
Sent: 23 January 2015 18:56
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Adding EOB when using Vectors

It hast to be whatever you set it to when you make the block. See the
make() function in the manual for a description.

Cheers,
M

On 01/23/2015 07:20 PM, David Halls wrote:
 Thanks. Does it matter what the tag is, does it have to be packet_len?

 DH
 
 From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
 mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
 discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org on
 behalf of Martin Braun martin.br...@ettus.com
 Sent: 23 January 2015 18:18
 To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Adding EOB when using Vectors

 Use tagged streams. usrp_sink will place the EOB on your last sample,
 even if bursts are of different lengths in that case.

 M

 On 01/23/2015 06:47 PM, David Halls wrote:
 ​Dear All,


 I am trying to use TX_TIME, SOB, EOB. How do I add the EOB when I am
 using a vector?


 The block I have created takes in vector of 47520 samples, i.e. one
 item, I want to add TX_TIME and SOB to the first sample. This is no
 problem, I add it to the item. After the following 'vector_to_stream'
 conversion, the TX_TIME and SOB map through to item 0, 47520, 95040 etc.


 But how do I get the EOB to be on item 47519?


 Regards,


 David


 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl



 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 


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



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

 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl


 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 


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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba

[Discuss-gnuradio] Adding EOB when using Vectors

[David Halls]

?Dear All,


I am trying to use TX_TIME, SOB, EOB. How do I add the EOB when I am using a 
vector?


The block I have created takes in vector of 47520 samples, i.e. one item, I 
want to add TX_TIME and SOB to the first sample. This is no problem, I add it 
to the item. After the following 'vector_to_stream' conversion, the TX_TIME and 
SOB map through to item 0, 47520, 95040 etc.


But how do I get the EOB to be on item 47519?


Regards,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Adding EOB when using Vectors

[David Halls]

Thanks. Does it matter what the tag is, does it have to be packet_len?

DH

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org on behalf of 
Martin Braun martin.br...@ettus.com
Sent: 23 January 2015 18:18
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Adding EOB when using Vectors

Use tagged streams. usrp_sink will place the EOB on your last sample,
even if bursts are of different lengths in that case.

M

On 01/23/2015 06:47 PM, David Halls wrote:
 ​Dear All,


 I am trying to use TX_TIME, SOB, EOB. How do I add the EOB when I am
 using a vector?


 The block I have created takes in vector of 47520 samples, i.e. one
 item, I want to add TX_TIME and SOB to the first sample. This is no
 problem, I add it to the item. After the following 'vector_to_stream'
 conversion, the TX_TIME and SOB map through to item 0, 47520, 95040 etc.


 But how do I get the EOB to be on item 47519?


 Regards,


 David


 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl



 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 


 ___
 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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Vectors for GNU Radio Python Blocks

[David Halls]

Hi all,

How do I write the init section for a Python block with an complex input vector 
of length v_len, so I need to adapt the following...

def __init__(self, Nb, Ns, mapping, v_len):
gr.basic_block.__init__(self,
name=Demodulator_relay_py_cd,
in_sig=[numpy.complex64],
out_sig=[numpy.int32,numpy.uint8])?


Thanks!


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

[Discuss-gnuradio] CFO in OFDM

[David Halls]

Dear all,

I am suffering from issues related to residual CFO error manifesting itself as 
a slight rotation over time. This can be partially corrected in the FD using 
tracking pilots which I have implemented but there is still a slight problem 
which may be caused by ICI.

In the OFDM example code, how is the value for the Frequency Mod sensitivity 
(-2/FFT_len) derived? Has anyone implemented other CFO estimation blocks for 
OFDM systems, other than the Schmidl and Cox technique?

Regards,

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

[Discuss-gnuradio] Channel Options in WX GUI Scope

[David Halls]

Hi Guys,

I want to set 'Marker' to 'Dot Large' by default, can I set this in the flow 
graph somehow?

Thanks!!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Get a pointer to UHD Sink from other block in flow graph

[David Halls]

Thanks Sebastian,

My solution in the end was to use a UHD source, which generates rx_time, I then 
created a block which reads in this rx_time tag and sends it as a message to a 
block just before my UHD sink which converts this to a tx_time based on the 
number of bursts sent, and the burst interval that I desire.

Note that if you are transmitting MIMO, i.e. multiple USRPs in one UHD sink, 
you also have to use multiple USRPs in the UHD source to produce the rx_time 
(although they multiple rx_times will be equal).

Regards,

David

-Original Message-
From: Koslowski, Sebastian (CEL) [mailto:sebastian.koslow...@kit.edu]
Sent: 16 October 2014 12:12
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Get a pointer to UHD Sink from other block in 
flow graph


On 10/16/2014 12:41 PM, David Halls wrote:
 Is there any way to get a pointer to a UHD sink block from another
 block in a flow graph, such that I can read from the time registers of
 a USRP?

Depends how you're building your flow-graph: In Python, simply pass a reference 
to your UHD block object to your block.
In GRC, there is no way to reference another block id in a block's params. Try 
this patch, if you want that [0]. Else, you could assume a fixed uhd sink block 
id and add that to your blocks XML's make template.

Sebastian

[0]
https://github.com/skoslowski/gnuradio/commit/c90e2ddf1cea38ee2400ef56b234758048d980bf

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Sebastian Koslowski
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe, Germany

Phone: +49 721 608-46275
Fax:   +49 721 608-46071
Email: sebastian.koslow...@kit.edu
Web:   http://www.cel.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and National Research 
Center of the Helmholtz Association





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

John thanks for all your help, this works, although it is necessary to add 
‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using the latest 
gr-uhd).

If you are using MIMO it is more complicated, as you have to add a ‘tx_time’ 
tag as well. This is not obvious how to generate in a tx flow graph.

My solution was to use a UHD source (the same address as the tx USRP), which 
generates rx_time, I then created a block which reads in this rx_time tag and 
sends it as a message to a block just before my UHD sink which converts this to 
a tx_time based on the number of bursts sent, and the burst interval that I 
desire.



As I am using MIMO, i.e. multiple USRPs in one UHD sink, I also had to use 
multiple USRPs in the UHD source to produce the rx_time (although the multiple 
rx_times will be equal).



From: John Malsbury [mailto:jmalsbury.perso...@gmail.com]
Sent: 15 October 2014 20:03
To: David Halls
Cc: Matt Ettus; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

H.. I've never done burst transmissions with a 2x MIMO case.  That may or 
may not put a minor wrinkle in things.  Let's go for the gusto and try this 
anyway...

(or were you not looking for a burst transmission?)

This assumes you're using a relatively recent (past couple months?) build of 
UHD and GR.

  1.  Produce some data as a PDU.  The quickest is to use a message strobe into 
a random PDU generator.  If you want data you control, use a message strobe 
with something like this as the message value:

pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))

Of course, you'd ultimately replace this fixed or random data with your own 
PDU-producing block.  Or maybe use some clever python inside or outside the 
flowgraph.
  2.  Use PDU-to-stream block, make sure the length tag name matches whatever 
UHD is using downstream (this is a parameter in the uhd sink now).
  3.  Put that stream through your modulator.
  4.  I think there's a block that multiplies the value of the length in the 
length tag.  set this to the interpolation factor of your modulator and put it 
somewhere in the chain.  If this block does not have one, borrow the one from 
gr-mac.  
burst_taggerhttps://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc

In summary:

   Message Strobe - Random PDU - PDU to Stream - Modulator -[see 
how the constellation works]

Give it a shot.  If it doesnt work, give a brief try with the SISO case.

You'll want to add some leading/trailing samples to flush FIR-filters and such 
for the full frame to get out of the USRP unscathed.  We can address this 
next...
-John

On Wed, Oct 15, 2014 at 11:47 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Hi John,

I have been trying at this all day! Not familiar with the async message stuff, 
I have tried putting ‘sleep()’ in the source block, I have tried a throttle 
outside it and even discarding the first X items just before the UHD sink to 
flush the buffer away.

This all causes weird underflows and things at the USRP and results in a 
horrible looking constellation at the RX (I am transmitting 2x1 MISO which 
requires perfect TX sync). This is exactly the behaviour, I think, that Matt 
warned of!!

Could you give me a bit more of an idea of how to even do the simpler idea, 
that I had thought of… I need to basically trigger the source at certain 
intervals. How does the message queue interact with the block, does the program 
flow jump to ‘parse_header_data_msg()’ automatically when a message arrives?

DH

From: John Malsbury 
[mailto:jmalsbury.perso...@gmail.commailto:jmalsbury.perso...@gmail.com]
Sent: 14 October 2014 23:42
To: David Halls
Cc: Matt Ettus; GNURadio

Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

In the implementation I have in mind, the upstream logic didn't make decisions 
on when the data generating block should generate data per se...  Instead, the 
upstream block provided feedback on the number of packets received by the USRP 
(via the old async message block).  With this feedback and knowledge of the 
interpolation steps between itself and the USRP, the data generating block 
could throttle its own output to achieve a specified latency [on the order of 
10's of ms].
I think using a simpler scheme of triggering with an async message would be a 
more convenient place to start though... What do you think, David?

-John

On Tue, Oct 14, 2014 at 3:23 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Hi John,

Nice to hear from you.

Perhaps in a similar fashion to Martin's HPD block; I can pass a message back 
from later in the flow graph to indicate when to release a packet from the 
source?

David

 Original message 
From: John Malsbury
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

David,

Perhaps you

[Discuss-gnuradio] Block taking in message, outputting items

[David Halls]

Dear All,

How can I create a block like 'Random PDU Generator', but that outputs items 
rather than PDUs over a message port?

Hopefully its easy but I am not clear if I need a work function or not, and if 
I don't have one then how do I pass the items out, as one does in a normal 
block?

Perhaps there are already blocks that do what I am trying to achieve?

Thanks for your help!!

Regards,

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

That's right John, the tx_time tag was required.

This is actually relatively involved to create in a tx flow graph. I added a 
UHD source to acquire rx_time which I then pass as a message to a block just 
before the twin UHD sink, where I calculate a desired tx_time.

perhaps someone can chime in as to whether the new message ports that Martin 
has added to the UHD blocks allow messages to pass out of the block or are they 
for passing info in only? If so this would be an easier way to do it I guess

I still get 2 Us (one for each usrp) at the very beginning. Although this 
doesn't seem to damage performance.  If I add some padding items to the 
beginning before the first burst would this help? and if so what's an elegant 
way to do so?

Interested to hear if anyone can answer John's question too!


 Original message 
From: John Malsbury
Date:2014/10/16 16:40 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

I'm happy this is working for you, David.  So do I understand correctly, that 
the adding tx_time finally made the MIMO case work?

I'd never done burst transmission with multiple USRP outputs.  I'm not totally 
surprised but I wasn't sure what would happen.

Maybe someone from Ettus can comment on this?  Since UHD is trying to do time 
alignment in the multi_usrp class, what happens to time alignemt in the 
non-continuous-streaming case if you *don't* include a tx_time tag?

-John

On Thu, Oct 16, 2014 at 7:23 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
John thanks for all your help, this works, although it is necessary to add 
‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using the latest 
gr-uhd).

If you are using MIMO it is more complicated, as you have to add a ‘tx_time’ 
tag as well. This is not obvious how to generate in a tx flow graph.

My solution was to use a UHD source (the same address as the tx USRP), which 
generates rx_time, I then created a block which reads in this rx_time tag and 
sends it as a message to a block just before my UHD sink which converts this to 
a tx_time based on the number of bursts sent, and the burst interval that I 
desire.



As I am using MIMO, i.e. multiple USRPs in one UHD sink, I also had to use 
multiple USRPs in the UHD source to produce the rx_time (although the multiple 
rx_times will be equal).



From: John Malsbury 
[mailto:jmalsbury.perso...@gmail.commailto:jmalsbury.perso...@gmail.com]
Sent: 15 October 2014 20:03

To: David Halls
Cc: Matt Ettus; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

H.. I've never done burst transmissions with a 2x MIMO case.  That may or 
may not put a minor wrinkle in things.  Let's go for the gusto and try this 
anyway...

(or were you not looking for a burst transmission?)

This assumes you're using a relatively recent (past couple months?) build of 
UHD and GR.

  1.  Produce some data as a PDU.  The quickest is to use a message strobe into 
a random PDU generator.  If you want data you control, use a message strobe 
with something like this as the message value:

pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))

Of course, you'd ultimately replace this fixed or random data with your own 
PDU-producing block.  Or maybe use some clever python inside or outside the 
flowgraph.
  2.  Use PDU-to-stream block, make sure the length tag name matches whatever 
UHD is using downstream (this is a parameter in the uhd sink now).
  3.  Put that stream through your modulator.
  4.  I think there's a block that multiplies the value of the length in the 
length tag.  set this to the interpolation factor of your modulator and put it 
somewhere in the chain.  If this block does not have one, borrow the one from 
gr-mac.  
burst_taggerhttps://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc

In summary:

   Message Strobe - Random PDU - PDU to Stream - Modulator -[see 
how the constellation works]

Give it a shot.  If it doesnt work, give a brief try with the SISO case.

You'll want to add some leading/trailing samples to flush FIR-filters and such 
for the full frame to get out of the USRP unscathed.  We can address this 
next...
-John

On Wed, Oct 15, 2014 at 11:47 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Hi John,

I have been trying at this all day! Not familiar with the async message stuff, 
I have tried putting ‘sleep()’ in the source block, I have tried a throttle 
outside it and even discarding the first X items just before the UHD sink to 
flush the buffer away.

This all causes weird underflows and things at the USRP and results in a 
horrible looking constellation at the RX (I am transmitting 2x1 MISO which 
requires perfect TX sync). This is exactly the behaviour, I think, that Matt 
warned of!!

Could you give me a bit more of an idea of how to even do

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

 Original message 
From: Matt Ettus
Date:2014/10/16 22:42 (GMT+00:00)
To: John Malsbury
Cc: David Halls ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control



On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury 
jmalsbury.perso...@gmail.commailto:jmalsbury.perso...@gmail.com wrote:
I'm happy this is working for you, David.  So do I understand correctly, that 
the adding tx_time finally made the MIMO case work?

I'd never done burst transmission with multiple USRP outputs.  I'm not totally 
surprised but I wasn't sure what would happen.

Maybe someone from Ettus can comment on this?  Since UHD is trying to do time 
alignment in the multi_usrp class, what happens to time alignemt in the 
non-continuous-streaming case if you *don't* include a tx_time tag?


Noncontinuous streaming means there is some amount of down time.  If you don't 
include tx_time tags, the device doesn't know when to start back up again, so 
each antenna is going to start at a different time.

Matt


That seemed exactly the kind of behaviour I saw where sync between the two 
streams was lost. Matt, can you comment on whether I need to put dummy padding 
items before the first burst? to flush buffers and is there a delicate way to 
do this?




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Thanks Matt. is this likely to be the cause of the Us at the beginning? How can 
I pad simply in GNU radio? can i add padding to every burst? if so that seems 
straightforward. I can just mux some zeros in.

Also should the padding be included in the burst length?


 Original message 
From: Matt Ettus
Date:2014/10/16 22:54 (GMT+00:00)
To: David Halls
Cc: John Malsbury ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


On TX, if you need your first sample to be valid and everything settled in the 
radio, you should zero pad ahead of it.  If you need your last sample to go out 
clean, you should zero pad after it.  In both cases, a few microseconds worth 
is usually fine.  This flushes buffers and filters, but also gives physical 
devices like antenna switches to settle.

Matt

On Thu, Oct 16, 2014 at 2:46 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:


 Original message 
From: Matt Ettus
Date:2014/10/16 22:42 (GMT+00:00)
To: John Malsbury
Cc: David Halls ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control



On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury 
jmalsbury.perso...@gmail.commailto:jmalsbury.perso...@gmail.com wrote:
I'm happy this is working for you, David.  So do I understand correctly, that 
the adding tx_time finally made the MIMO case work?

I'd never done burst transmission with multiple USRP outputs.  I'm not totally 
surprised but I wasn't sure what would happen.

Maybe someone from Ettus can comment on this?  Since UHD is trying to do time 
alignment in the multi_usrp class, what happens to time alignemt in the 
non-continuous-streaming case if you *don't* include a tx_time tag?


Noncontinuous streaming means there is some amount of down time.  If you don't 
include tx_time tags, the device doesn't know when to start back up again, so 
each antenna is going to start at a different time.

Matt


That seemed exactly the kind of behaviour I saw where sync between the two 
streams was lost. Matt, can you comment on whether I need to put dummy padding 
items before the first burst? to flush buffers and is there a delicate way to 
do this?




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl




This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Hi John,

I have been trying at this all day! Not familiar with the async message stuff, 
I have tried putting ‘sleep()’ in the source block, I have tried a throttle 
outside it and even discarding the first X items just before the UHD sink to 
flush the buffer away.

This all causes weird underflows and things at the USRP and results in a 
horrible looking constellation at the RX (I am transmitting 2x1 MISO which 
requires perfect TX sync). This is exactly the behaviour, I think, that Matt 
warned of!!

Could you give me a bit more of an idea of how to even do the simpler idea, 
that I had thought of… I need to basically trigger the source at certain 
intervals. How does the message queue interact with the block, does the program 
flow jump to ‘parse_header_data_msg()’ automatically when a message arrives?

DH

From: John Malsbury [mailto:jmalsbury.perso...@gmail.com]
Sent: 14 October 2014 23:42
To: David Halls
Cc: Matt Ettus; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

In the implementation I have in mind, the upstream logic didn't make decisions 
on when the data generating block should generate data per se...  Instead, the 
upstream block provided feedback on the number of packets received by the USRP 
(via the old async message block).  With this feedback and knowledge of the 
interpolation steps between itself and the USRP, the data generating block 
could throttle its own output to achieve a specified latency [on the order of 
10's of ms].
I think using a simpler scheme of triggering with an async message would be a 
more convenient place to start though... What do you think, David?

-John

On Tue, Oct 14, 2014 at 3:23 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Hi John,

Nice to hear from you.

Perhaps in a similar fashion to Martin's HPD block; I can pass a message back 
from later in the flow graph to indicate when to release a packet from the 
source?

David

 Original message 
From: John Malsbury
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

David,

Perhaps you can use an async message to trigger the blocks output?

In some applications that require filler between valid data frames, I've seen 
people throttle based off of the number and size of received messages at the 
USRP.
-John


On Tue, Oct 14, 2014 at 3:02 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
That sounds promising. The only thing is that the data *is* valid from time 
zero, but I just want to send the values from my source block, say once per 
second.

What can I use to block in my block, just not produce any items for some period 
of time or a number of calls?  and is there anyway to know when I can stop 
blocking? What will fill the buffers further down the chain?

thanks,

David

 Original message 
From: Matt Ettus
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff Long ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


No, if you don't have anything useful to output in a source block, you can (and 
should) block while you wait.  If you have something useful, but not as much as 
requested, you can output only what you have.  There is no need to generate 
filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David

 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
willco...@gmail.commailto:willco...@gmail.com wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add

[Discuss-gnuradio] Obtain rx_time (to create tx_time) in a tx flow graph with USRP

[David Halls]

Hi guys,

I think I have said it all in the title, any ideas how I can get create tx_time 
in a transmit flow graph with a USRP UHD sink? I know that UHD source spits out 
rx_time, but I don't have a UHD source in my flow graph, and if I did how would 
I mux in the tag into my tx streams?

Cheers!

Regards,

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

[Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Dear All,

I am wondering how to add some flow control to a source block, so that  it 
doesn't fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing and 
combining, before transmission via USRP, with bursts being transmitted every 
few seconds.

What happens is that the block fires out 1,000s of vectors, and then seems to 
slow down and settle into sync with the rest of the flow graph after a few 
seconds. As my source block is reading in from a Database, I want to slow this 
initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Thanks guys!

I am transmitting data from a database, which is inserted by some sensors. The 
network is contains multiple relay hops and the processing at each relay is 
highly complex therefore the system o's not real time. The source transmits a 
data burst every 0.5 secs.

The issue is that the initial burst reads frantically and fills the buffers 
with the same value,  which then takes ages to propagate through the system.

does that make any sense?


 Original message 
From: Jeff Long
Date:2014/10/14 20:20 (GMT+00:00)
To: Matt Ettus
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

Agree the throttle it not the best solution. David - what is your
source, and what problem are those 1000's of vectors causing at startup?

- Jeff

On 10/14/2014 06:08 PM, Matt Ettus wrote:

 Jeff,

 If there is a hardware device like a USRP in the chain, then you should
 not use a throttle block.  What you are seeing is the initial startup
 burst.  When everything starts up, all the buffers are empty, and GNU
 Radio will generate data until something backs up.  Once they fill up,
 you are seeing the rate settle down.  This is all normal.

 If you really need to rate limit what gets requested of the database
 during the initial transient (which I don't recommend), you should do
 that within your source block.

 Matt


 On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long willco...@gmail.com
 mailto:willco...@gmail.com wrote:

 Should have mentioned ... set the throttle rate just slightly higher
 than what the chain would consume at steady state when all the
 buffers are filled and the USRP is transmitting. How well this works
 depends on what the rest of the chain looks like.

 - Jeff


 On 10/14/2014 05:52 PM, Jeff Long wrote:

 Use a throttle block immediately after your source block,
 setting the
 vector size to match your source.

 - Jeff

 On 10/14/2014 04:34 PM, David Halls wrote:

 Dear All,

 I am wondering how to add some flow control to a source
 block, so that
 it doesn’t fire out items so quickly.

 Later stages of my flow graph are slowed by various bits of
 processing
 and combining, before transmission via USRP, with bursts being
 transmitted every few seconds.

 What happens is that the block fires out 1,000s of vectors,
 and then
 seems to slow down and settle into sync with the rest of the
 flow graph
 after a few seconds. As my source block is reading in from a
 Database, I
 want to slow this initial rate significantly.

 The block outputs vectors of bytes (v_len=144). Any ideas?

 Regards,

 David

 
 --__--__---

 David Halls Ph.D.

 Research Engineer

 Toshiba Research Europe Limited

 32 Queen Square, Bristol, BS1 4ND, UK

 Tel: +44 (0) 117 906 0790
 tel:%2B44%20%280%29%20117%20906%200790


 
 --__--__

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be
 read, copied
 and used only by the intended recipient. If you are not the
 intended
 recipient, please destroy this message, delete any copies
 held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park,
 Milton Road,
 Cambridge CB4 0GZ, England. Web: 
 www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl



 
 --__--__
 This email has been scanned for email related threats and
 delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 
 --__--__


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




 _
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
 https://lists.gnu.org

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

That sounds promising. The only thing is that the data *is* valid from time 
zero, but I just want to send the values from my source block, say once per 
second.

What can I use to block in my block, just not produce any items for some period 
of time or a number of calls?  and is there anyway to know when I can stop 
blocking? What will fill the buffers further down the chain?

thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff Long ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


No, if you don't have anything useful to output in a source block, you can (and 
should) block while you wait.  If you have something useful, but not as much as 
requested, you can output only what you have.  There is no need to generate 
filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
willco...@gmail.commailto:willco...@gmail.com wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790tel:%2B44%20%280%29%20117%20906%200790




NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: 
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl




This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com



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




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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Hi John,

Nice to hear from you.

Perhaps in a similar fashion to Martin's HPD block; I can pass a message back 
from later in the flow graph to indicate when to release a packet from the 
source?

David


 Original message 
From: John Malsbury
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

David,

Perhaps you can use an async message to trigger the blocks output?

In some applications that require filler between valid data frames, I've seen 
people throttle based off of the number and size of received messages at the 
USRP.

-John


On Tue, Oct 14, 2014 at 3:02 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
That sounds promising. The only thing is that the data *is* valid from time 
zero, but I just want to send the values from my source block, say once per 
second.

What can I use to block in my block, just not produce any items for some period 
of time or a number of calls?  and is there anyway to know when I can stop 
blocking? What will fill the buffers further down the chain?

thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff Long ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


No, if you don't have anything useful to output in a source block, you can (and 
should) block while you wait.  If you have something useful, but not as much as 
requested, you can output only what you have.  There is no need to generate 
filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
willco...@gmail.commailto:willco...@gmail.com wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790tel:%2B44%20%280%29%20117%20906%200790




NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: 
www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl




This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com

[Discuss-gnuradio] MySQL?

[David Halls]

Dear All,

Has anyone tried using MySQL from GNU Radio? I am just posting some simple 
stuff to a MySQL database that runs fine in a stand-alone C program. It builds 
fine in GNU Radio, by including mysql.h, but there is a swig problem on 
running in GNU Radio Companion

ImportError: /usr/local/lib/libgnuradio-trl.so: undefined symbol: mysql_init

Presumably I need to add some libraries to the CMakeLists.txt, or similar?

Thanks in advance!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] MySQL?

[David Halls]

Hi Martin, All,

It was a basic linker problem, I hadn't correctly included the library file in 
the /lib/CMakeFiles.txt, one needs to include just mysqlclient (and the linker 
directory of course)

Sorry! I wonder if anyone else has use MySQL before with GNU Radio - if not *IT 
WORKS*!!

Thanks,

DH

-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 13 October 2014 17:59
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] MySQL?

David,

is the MySQL include in any of your public headers, and does it need to be? It 
might be SWIG is picking up stuff you don't actually want to pick up.

You can also tell SWIG to ignore stuff, have you checked that?

M

On 10/13/2014 05:13 PM, David Halls wrote:
 Dear All,



 Has anyone tried using MySQL from GNU Radio? I am just posting some
 simple stuff to a MySQL database that runs fine in a stand-alone C
 program. It builds fine in GNU Radio, by including mysql.h, but
 there is a swig problem on running in GNU Radio Companion



 ImportError: /usr/local/lib/libgnuradio-trl.so: undefined symbol:
 mysql_init



 Presumably I need to add some libraries to the CMakeLists.txt, or similar?



 Thanks in advance!



 David



 ---

 David Halls Ph.D.

 Research Engineer

 Toshiba Research Europe Limited

 32 Queen Square, Bristol, BS1 4ND, UK

 Tel: +44 (0) 117 906 0790




 --
 --

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read,
 copied and used only by the intended recipient. If you are not the
 intended recipient, please destroy this message, delete any copies
 held on your system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl



 --
 -- This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 --
 --


 ___
 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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

[David Halls]

Dear All,

I am trying to get the latest gr-fec code running in an older version of GNU 
Radio. I know this sounds like a terrible idea, and I don't expect any sympathy 
but there is a reason why we can't upgrade to the newest GNU Radio, due to some 
legacy issues.

If you are still reading...

I can't get the CC Encoder Definition block to appear in GNU Radio, we are 
using 3.7.2. I have copied the whole of the gr-fec folder from the latest 
install including the grc folder which contains 
'variable_cc_encoder_def_list.xml'. Is there something else fundamentally 
missing from older version of GNU Radio to support this kind of definition 
block?

Thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

[David Halls]

The problem appears to be using var_make and var_value in the xml files.

Presumably this is a new(ish) additional functionality in GNU Radio, which my 
old version can’t parse?

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of David Halls
Sent: 07 October 2014 15:21
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

Dear All,

I am trying to get the latest gr-fec code running in an older version of GNU 
Radio. I know this sounds like a terrible idea, and I don’t expect any sympathy 
but there is a reason why we can’t upgrade to the newest GNU Radio, due to some 
legacy issues.

If you are still reading…

I can’t get the CC Encoder Definition block to appear in GNU Radio, we are 
using 3.7.2. I have copied the whole of the gr-fec folder from the latest 
install including the grc folder which contains 
‘variable_cc_encoder_def_list.xml’. Is there something else fundamentally 
missing from older version of GNU Radio to support this kind of definition 
block?

Thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl



This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

[David Halls]

From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau 
[t...@trondeau.com]
Sent: 07 October 2014 16:27
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

On Tue, Oct 7, 2014 at 10:40 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
The problem appears to be using var_make and var_value in the xml files.

Presumably this is a new(ish) additional functionality in GNU Radio, which my 
old version can’t parse?

Yes, those are new in 3.7 (3.7.4, I think but would have to check to verify). 
It's a way of letting us build objects within GRC and use them as such in other 
areas of the flowgraph. So you can define an FEC variable and call methods on 
it, like cc.K() to get the CC's constraint length.

You can probably remove these from the .xml files and lose that functionality. 
It's a nice convenience but not necessary. You can replace it by having another 
variable, say for K, and use that in any place you might require it instead of 
pulling it straight from the CC variable itself.

Tom


Thanks Tom, that is a useful piece of functionality indeed. I commented out the 
var_make and var_value and have instead

makeself.$(id) = $(id) = fec.cc_encoder_make($framebits, $k, $rate, $polys, 
$state_start, $mode, $padding)/make

Is that OK? I can also manually create the Encoder Objects variable as

fec.cc_encoder_make(frame_size*8, k, rate, (polys), start_state,  
fec.CC_TERMINATED, padding)

how would I add the parallelism

(fec.cc_encoder_make(frame_size*8, k, rate, (polys), start_state,  
fec.CC_TERMINATED, padding);fec.cc_encoder_make(frame_size*8, k, rate, (polys), 
start_state,  fec.CC_TERMINATED, padding))

or similar?


From: 
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.orgmailto:toshiba-trel@gnu.org
 
[mailto:discuss-gnuradio-bounces+david.hallsmailto:discuss-gnuradio-bounces%2Bdavid.halls=toshiba-trel@gnu.orgmailto:toshiba-trel@gnu.org]
 On Behalf Of David Halls
Sent: 07 October 2014 15:21
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)

Dear All,

I am trying to get the latest gr-fec code running in an older version of GNU 
Radio. I know this sounds like a terrible idea, and I don’t expect any sympathy 
but there is a reason why we can’t upgrade to the newest GNU Radio, due to some 
legacy issues.

If you are still reading…

I can’t get the CC Encoder Definition block to appear in GNU Radio, we are 
using 3.7.2. I have copied the whole of the gr-fec folder from the latest 
install including the grc folder which contains 
‘variable_cc_encoder_def_list.xml’. Is there something else fundamentally 
missing from older version of GNU Radio to support this kind of definition 
block?

Thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790tel:%2B44%20%280%29%20117%20906%200790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl



This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl




This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com


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

Re: [Discuss-gnuradio] Slow down rate of Python source block

[David Halls]

From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: 01 August 2014 14:31
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Slow down rate of Python source block

On Fri, Aug 1, 2014 at 5:24 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:


From: trond...@trondeau.commailto:trond...@trondeau.com 
[trond...@trondeau.commailto:trond...@trondeau.com] on behalf of Tom Rondeau 
[t...@trondeau.commailto:t...@trondeau.com]
Sent: 31 July 2014 19:11
To: David Halls
Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Slow down rate of Python source block


On Thu, Jul 31, 2014 at 12:21 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com
 wrote:
Dear All,

I have a Python block that produces packets of size 1536 bytes. Due to various 
reasons, the latter parts of my flow graph are very slow (this is desired and 
cannot be changed). After producing 510 packets, I get the following error.

handler caught exception: operands could not be broadcast together with shapes 
(1527) (1536)
Traceback (most recent call last):
File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 55, 
in eval
try: self._callback()
File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 160, 
in __gr_block_handle
) for i in self.__out_indexes],
File /usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py, line 198, in 
work
out_cA[0:len(cAm)] = cAm
ValueError: operands could not be broadcast together with shapes (1527) (1536)
thread[thread-per-block[1]: block blsd_enc_b (2)]: caught unrecognized 
exception

Debugging more carefully, I can see that:

len(cAm) = 1536 , len(out_cA) = 32768

Just a quick response without really studying the problem or your code. The 
dynamic scheduler in GR is getting in your way, and the throttle block is 
definitely not the right way to help you. You need to either tell the scheduler 
what you need it to send your block or handle it internally. There are three 
ways to solve these issues:

1. Use set_output_multiple in the constructor, which will only allow the 
scheduler to send you chunks of data of some multiple of the number you pass 
that. I've seen this slow down the scheduler in other situations, but it sounds 
like you're going slow, anyways, so this shouldn't cause a problem.

2. Make your input signature your packet_length so each item will be a vector 
of that length. This would not be my preferred way, but we've played that game 
before.

3. Handle it internally. Buffer up the input until you have enough to produce 
what you need. You'd need to inherit from gr.basic_block here and do more 
management of the data and buffers yourself.

Tom



Tom,

Thanks for your reply. Unfortunately as it is a Python block, I cannot use 
'set_output_multiple'. For 2. do you mean set the input signature of the blocks 
fed from the source block. This could be possible but quite a few different 
blocks (some standard GR blocks) are fed from it. Could you provide some more 
details, or a link to similar implementation for option 3. - again is this 
possible from within a Python block?

Regards,

David


David,

set_output_multiple is exposed through the Python gateway code, so you should 
be able to call self.set_output_multiple inside the constructor..

For 2, yes, I mean that you can adjust the io signature of the block, 
essentially taking in a vector so that 1 item is now a full packet. But yes, 
this makes it more difficult to integrate with other blocks; one reason I said 
this isn't a preferred method.

And for 3, the only think that I can think of is the qtgui sinks, like the freq 
sink that passes a chunk of data the length of the FFT size and buffers it 
internally. The work functions for these types of blocks tend to become more 
complex, though, and difficult to read. But you can certainly do it inside a 
Python block; you just may need to do hard copies out of the input buffers to 
make sure the data is actually moved and stored locally.

Tom






Hi Tom,

I tried self.set_output_multiple and this doesn't work in Python, I believe for 
the same reasons as

The set_min_noutput_items() is not yet a supported python statement [1] as 
per March 06, 2014.
Also, I believe this statement should be placed in the member functions 
(constructor, work function, callback function etc) of your custom block, don't 
put it at the wrong place.
In alternative, you may want to replace it with set_output_multiple() if this 
is more appropriate.

1. 
http://gnuradio.4.n7.nabble.com/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio-td46731.html

Re: [Discuss-gnuradio] Slow down rate of Python source block

[David Halls]

From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau 
[t...@trondeau.com]
Sent: 31 July 2014 19:11
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Slow down rate of Python source block

On Thu, Jul 31, 2014 at 12:21 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Dear All,

I have a Python block that produces packets of size 1536 bytes. Due to various 
reasons, the latter parts of my flow graph are very slow (this is desired and 
cannot be changed). After producing 510 packets, I get the following error.

handler caught exception: operands could not be broadcast together with shapes 
(1527) (1536)
Traceback (most recent call last):
File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 55, 
in eval
try: self._callback()
File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 160, 
in __gr_block_handle
) for i in self.__out_indexes],
File /usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py, line 198, in 
work
out_cA[0:len(cAm)] = cAm
ValueError: operands could not be broadcast together with shapes (1527) (1536)
thread[thread-per-block[1]: block blsd_enc_b (2)]: caught unrecognized 
exception

Debugging more carefully, I can see that:

len(cAm) = 1536 , len(out_cA) = 32768

Just a quick response without really studying the problem or your code. The 
dynamic scheduler in GR is getting in your way, and the throttle block is 
definitely not the right way to help you. You need to either tell the scheduler 
what you need it to send your block or handle it internally. There are three 
ways to solve these issues:

1. Use set_output_multiple in the constructor, which will only allow the 
scheduler to send you chunks of data of some multiple of the number you pass 
that. I've seen this slow down the scheduler in other situations, but it sounds 
like you're going slow, anyways, so this shouldn't cause a problem.

2. Make your input signature your packet_length so each item will be a vector 
of that length. This would not be my preferred way, but we've played that game 
before.

3. Handle it internally. Buffer up the input until you have enough to produce 
what you need. You'd need to inherit from gr.basic_block here and do more 
management of the data and buffers yourself.

Tom



Tom,

Thanks for your reply. Unfortunately as it is a Python block, I cannot use 
'set_output_multiple'. For 2. do you mean set the input signature of the blocks 
fed from the source block. This could be possible but quite a few different 
blocks (some standard GR blocks) are fed from it. Could you provide some more 
details, or a link to similar implementation for option 3. - again is this 
possible from within a Python block?

Regards,

David



for the first 490 packets, and then the length of 'out_cA' begins to reduce

packet_num = 490
len(cAm) = 1536 , len(out_cA) = 32247
packet_num = 491
len(cAm) = 1536 , len(out_cA) = 30711
packet_num = 492
len(cAm) = 1536 , len(out_cA) = 29175
packet_num = 493
len(cAm) = 1536 , len(out_cA) = 27639
packet_num = 494
len(cAm) = 1536 , len(out_cA) = 26103
packet_num = 495
len(cAm) = 1536 , len(out_cA) = 24567
packet_num = 496
len(cAm) = 1536 , len(out_cA) = 23031
packet_num = 497
len(cAm) = 1536 , len(out_cA) = 21495
packet_num = 498
len(cAm) = 1536 , len(out_cA) = 19959
packet_num = 499
len(cAm) = 1536 , len(out_cA) = 18423
packet_num = 500
len(cAm) = 1536 , len(out_cA) = 16887
packet_num = 501
len(cAm) = 1536 , len(out_cA) = 15351
packet_num = 502
len(cAm) = 1536 , len(out_cA) = 13815
packet_num = 503
len(cAm) = 1536 , len(out_cA) = 12279
packet_num = 504
len(cAm) = 1536 , len(out_cA) = 10743
packet_num = 505
len(cAm) = 1536 , len(out_cA) = 9207
packet_num = 506
len(cAm) = 1536 , len(out_cA) = 7671
packet_num = 507
len(cAm) = 1536 , len(out_cA) = 6135
packet_num = 508
len(cAm) = 1536 , len(out_cA) = 4599
packet_num = 509
len(cAm) = 1536 , len(out_cA) = 3063
packet_num = 510
len(cAm) = 1536 , len(out_cA) = 1527

I believe this is because the latter parts of the flow graph are blocking, 
their buffers become full, and this backs up to my source block. This is 
confirmed by connecting my source block to null sinks, which then allows the 
source block to run infinitely (well, a long while!).

Is there a way I can slow up this block? I tried using a throttle on the 
output, but this doesn't help (in fact it seems to make it worse!).

The full code of the block is attached.

Thanks!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies

[Discuss-gnuradio] Slow down rate of Python source block

[David Halls]

Dear All,

I have a Python block that produces packets of size 1536 bytes. Due to various 
reasons, the latter parts of my flow graph are very slow (this is desired and 
cannot be changed). After producing 510 packets, I get the following error.

handler caught exception: operands could not be broadcast together with shapes 
(1527) (1536)
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 
55, in eval
try: self._callback()
  File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 
160, in __gr_block_handle
) for i in self.__out_indexes],
  File /usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py, line 198, in 
work
out_cA[0:len(cAm)] = cAm
ValueError: operands could not be broadcast together with shapes (1527) (1536)
thread[thread-per-block[1]: block blsd_enc_b (2)]: caught unrecognized 
exception

Debugging more carefully, I can see that:

len(cAm) =  1536 , len(out_cA) =  32768

for the first 490 packets, and then the length of 'out_cA' begins to reduce

packet_num =  490
len(cAm) =  1536 , len(out_cA) =  32247
packet_num =  491
len(cAm) =  1536 , len(out_cA) =  30711
packet_num =  492
len(cAm) =  1536 , len(out_cA) =  29175
packet_num =  493
len(cAm) =  1536 , len(out_cA) =  27639
packet_num =  494
len(cAm) =  1536 , len(out_cA) =  26103
packet_num =  495
len(cAm) =  1536 , len(out_cA) =  24567
packet_num =  496
len(cAm) =  1536 , len(out_cA) =  23031
packet_num =  497
len(cAm) =  1536 , len(out_cA) =  21495
packet_num =  498
len(cAm) =  1536 , len(out_cA) =  19959
packet_num =  499
len(cAm) =  1536 , len(out_cA) =  18423
packet_num =  500
len(cAm) =  1536 , len(out_cA) =  16887
packet_num =  501
len(cAm) =  1536 , len(out_cA) =  15351
packet_num =  502
len(cAm) =  1536 , len(out_cA) =  13815
packet_num =  503
len(cAm) =  1536 , len(out_cA) =  12279
packet_num =  504
len(cAm) =  1536 , len(out_cA) =  10743
packet_num =  505
len(cAm) =  1536 , len(out_cA) =  9207
packet_num =  506
len(cAm) =  1536 , len(out_cA) =  7671
packet_num =  507
len(cAm) =  1536 , len(out_cA) =  6135
packet_num =  508
len(cAm) =  1536 , len(out_cA) =  4599
packet_num =  509
len(cAm) =  1536 , len(out_cA) =  3063
packet_num =  510
len(cAm) =  1536 , len(out_cA) =  1527

I believe this is because the latter parts of the flow graph are blocking, 
their buffers become full, and this backs up to my source block. This is 
confirmed by connecting my source block to null sinks, which then allows the 
source block to run infinitely (well, a long while!).

Is there a way I can slow up this block? I tried using a throttle on the 
output, but this doesn't help (in fact it seems to make it worse!).

The full code of the block is attached.

Thanks!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2014 +YOU OR YOUR COMPANY+.
# 
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
# 

import numpy
from gnuradio import gr
import os, sys, inspect
sys.path.insert(0,'/home/gnuradio/gnuradio_trlcode/gr-trl/examples/ofdm_bsld/Pfiles/LDPC_lib')
from rew import *
from LDPC_lib import *
import datetime as dt
import LDPC_dec_lib
import pmt
import time

class blsd_enc_b(gr.sync_block):

docstring for block blsd_enc_b

def __init__(self, kA1=4,kB1=4,k2=4,NA1=8,NB1=8,N2=8,M=8,num_packets=1):
gr.sync_block.__init__(self,
name=blsd_enc_b,
in_sig=None,

Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block

[David Halls]

 From: Activecat [active...@gmail.com]
 Sent: 17 June 2014 08:39
 To: discuss-gnuradio@gnu.org
 Cc: David Halls
 Subject: Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block

 On Tue, Jun 17, 2014 at 1:02 AM, David Halls 
 david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
 Hey Martin,

 My calls using

 self.set_min_output_buffer(4096*2)

 and

 self.set_min_noutput_items(4096)

 fail at runtime. Perhaps I am missing some import statements?

 AttributeError: 'bsld_dec_butterfly_cfb' object has no attribute 
 'set_min_output_buffer'

 Regards,

 David


 The set_min_noutput_items() is not yet a supported python statement [1] as 
 per March 06, 2014.
 Also, I believe this statement should be placed in the member functions 
 (constructor, work function, callback function etc) of your custom block, 
 don't put it at the wrong place.
 In alternative, you may want to replace it with set_output_multiple() if 
 this is more appropriate.

 1. 
 http://gnuradio.4.n7.nabble.com/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio-td46731.html




Thanks Activecat!! I had the problem that

out_rc[0:len(rcABm)] = rcABm
ValueError: operands could not be broadcast together with shapes (4096) (5376)

where out_rc = output_items[3]

using set_output_multiple(4096*2) has resolved my problem by increasing the 
length of the output buffer vector to 4096*2. I wonder if there is a fixed 
limit as to how far I can stretch this? In the future I may want my decoder to 
output even more than blocks in one go.

Regards,

David





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block

[David Halls]

Hey Martin,

My calls using

self.set_min_output_buffer(4096*2)

and

self.set_min_noutput_items(4096)

fail at runtime. Perhaps I am missing some import statements?

AttributeError: 'bsld_dec_butterfly_cfb' object has no attribute 
'set_min_output_buffer'

Regards,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: 13 June 2014 19:45
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block

On 13.06.2014 15:49, David Halls wrote:
 Dear All,

 Is it possible to use set_min_output_buffer() in Python? I want to be
 able to output more than 4096 items from a Python block during one call
 to the work function. Is there a way to do this?

Hey David,

sure, this function is available in Python. It's even in GRC, if you
want to create code to see how it's used.

M

 Regards,

 David

 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl


 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 


 ___
 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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] Using set_min_output_buffer() in Python block

[David Halls]

Dear All,

Is it possible to use set_min_output_buffer() in Python? I want to be able to 
output more than 4096 items from a Python block during one call to the work 
function. Is there a way to do this?

Regards,

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

[David Halls]

 Original message 
From: Activecat
Date:2014/06/05 7:57 AM (GMT+00:00)
To: David Halls ,discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission


On Wed, Jun 4, 2014 at 7:10 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Activecat,
In fact my horrible hack doesn't work properly. Once items start arriving at 
Payload TD Tx 2, they still don't arrive as 'consistently' (for want of a 
better word), as those from the Noise Source block, and thus zeros are inserted 
when they are not required!

David


David,

Basically my idea to solve the problem may involve an overhaul of your existing 
flowgraph, as below:

1).  You must understand that the output of UHD source is at constant rate. In 
particular I am referring to the Relay Rx USRP.
  Even when the USRP does not receive any RF signal, it keeps sending out 
zeros (plus noise) as its output, at constant rate.

  Try to make all your blocks behave in this way. I am referring to the 
blocks between the Relay Rx and Relay Tx.
  The idea is: keep transmitting, don't produce no output at any time.  If 
nothing need to be produced, then output zeros at constant rate.
  In this case all your custom blocks are either sync block, decimation or 
interpolation blocks. You don't need any general block.

2).  With above condition fulfilled, we could ensure that the data fed into the 
Relay Tx USRP is at constant rate, and we could then determine this rate by 
simple calculations.
  The data stream into the Relay Tx USRP will not stop at any instance. 
It is 'consistent'.

3).  You want the Relay Rx USRP ignores the received signal during the time 
that the Relay Tx USRP is transmitting, that is fine.
  But just try to make the downstream block of Relay Rx USRP keep 
transmitting zeros rather than stop transmitting during this period.

4).  With these, you will have both Relay Tx USRP and Source USRP 
transmitting at constant data rate and nonstop.
  They could be transmitting at different rates, that is ok, and this is 
not difficult to handle.

With this, you avoid the initial problem (problem of occasionally there is no 
items at one of the inputs) mentioned in this thread, which is the root cause 
of your problem.
Then your problem is solved !


Great! Thanks active cat.  This will take some time, I'll will report back once 
I have it working!! :)



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

[David Halls]

From: xianda [mailto:wangxianda920...@163.com]
Sent: 05 June 2014 09:50
To: David Halls
Subject: Re:Re: [Discuss-gnuradio] Scheduling a block even with no input items 
RE: Flow graph blocking when doing 2x1 transmission

Hi David:
   Thank you in advance.
   I want to ask a question about Payload TD Tx 1 is derived from 
input codewords that are generated in MATLAB and stored in a file, then loaded 
into the flow graph. as you said.I want to ask how to gnerated  a dat document 
which is in MATLAB.What command you use in MATLAB?
  Thanks very much.
Best regards,
xianda


Hi Xianda,
Please find the zip file attached with files to read and write (to/from MATLAB) 
both complex, and byte types.
Syntax is
input = read_complex_binary('filename.dat')
input = read_char_binary('filename.dat')
write_complex_binary(data,'filename.dat')
write_char_binary(data,'filename.dat')
Regards,
David

At 2014-06-04 08:53:31, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:

Hi Activecat,

I have disconnected the rest of the flow graph because it is extremely complex.

In the system I have a Source, a Relay (1 rx USRP, 1 tx USRP), a Destination. S 
--- R_rx/R_tx -- D

The two transmitters that you see on that flow graph snippet I sent you are the 
the Source Tx and the Relay Tx.

Payload TD Tx 1 is derived from input codewords that are generated in MATLAB 
and stored in a file, then loaded into the flow graph. The payload is created 
in a similar fashion to Martin's original OFDM_tx. This is then transmitted 
from Source Tx.

Until this point, no packets are received by Relay Rx but once the source 
transmits, these packets are then received by Relay Rx, and then there is a 
decode-and-forward chain of blocks, and this then creates Payload TD Tx 2.

The full flow graph is attached, but may be missing many blocks for you...

David

From: Activecat [active...@gmail.commailto:active...@gmail.com]
Sent: 04 June 2014 13:45
To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Cc: David Halls
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 7:10 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com
 wrote:
Activecat,

In fact my horrible hack doesn't work properly. Once items start arriving at 
Payload TD Tx 2, they still don't arrive as 'consistently' (for want of a 
better word), as those from the Noise Source block, and thus zeros are inserted 
when they are not required!

David


David,

Could you please explain in details, what is this Payload TD Tx 2?
How does it generate data, is it getting data from a hardware or console, why 
it sometime idle but sometime transmitting?

This is a virtual source. Where is it associated virtual sink?



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl


This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---




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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

[David Halls]

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 16:02
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:52 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Not quite...

i). the Source Tx USRP has a constant stream of data, and is constantly 
transmitting. If the codewords in the file are exhausted it repeats.
ii). the Relay Tx USRP transmits data only when data has been received by the 
Relay Rx (I will use tx_time to control when the received burst is 
re-transmitted)
iii). the Relay Rx USRP will receive data only when the Source Tx USRP 
transmits (section where Relay Tx's too will be ignored),

What do you mean by section where Relay Tx's too will be ignored ?


I have changed the block you suggested, to avoid inserting 0's mid burst.

So does this give better results?


1) this is to avoid loop interference, the Relay Rx will ignore the received 
signal during the time that the Relay Tx is transmitting.
2) Yes avoiding adding 0's gives me pretty much the performance I require, I 
need to work on some other parts of the implementation to be sure. (it is 
definitely not the neatest way yet!!)






NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

[David Halls]

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 16:13
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:52 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Not quite...

i). the Source Tx USRP has a constant stream of data, and is constantly 
transmitting. If the codewords in the file are exhausted it repeats.
ii). the Relay Tx USRP transmits data only when data has been received by the 
Relay Rx (I will use tx_time to control when the received burst is 
re-transmitted)
iii). the Relay Rx USRP will receive data only when the Source Tx USRP 
transmits (section where Relay Tx's too will be ignored),


To clarify, is it true that both the Source TX USRP and Relay Tx USRP are 
controlled by the same UHD Sink in the flowgraph?

Yes, they are both controlled by the same UHD sink. This ensures, in a simple 
fashion, that the Source Tx and Relay Tx transmissions have sample-level 
synchronicity - a must for my Quantize Map and Forward scheme.



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

[David Halls]

Dear All,

Had anyone tried to implementing a gnuradio block that will output zeros if 
there are no items at the input, and will simply copy the input to output 
otherwise?

I find that if there are no items at the input, the block never gets scheduled.

I want this block to feed zeros to my USRP until actual data is ready to be 
passed to it.

Regards,

David

-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com]
Sent: 03 June 2014 07:45
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

Hi David,

I think you got that right.
Using msg_port_register_in(..) you could set up a message port, define a 
message handler, in which you set a class member (eg. d_datatosend) to the 
message'd content, and in your work check whether d_datatosend is empty or not, 
and in the latter case, emit that.

That's only one way to solve your non-constant streaming issue, and it's one of 
the most computationally intensive, so I don't really know if my advice was 
good...

Greetings,
Marcus
On 02.06.2014 23:30, David Halls wrote:
 Hi Marcus,

 I'm not sure if understand correctly then, how would you suggest it is
 possible to implement your suggestion

 'a block that (rate limitedly) produces zero-samples, unless data comes in on 
 a message port?'

 ...My new block is connected to the UHD sink - so this should consume the 
 output buffer of the block at a constant rate, and so my setup *should* work?

 Many thanks,

 David


  Original message 
 From: Marcus Müller
 Date:02/06/2014 19:56 (GMT+00:00)
 To: David Halls ,discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1
 transmission

 Hi David,

 you're right, the scheduler will only call your block when out- or
 input buffer situation have changed, and there's no elegant way to coerce 
 that.
 However, given a sink that consumes with a constant continous rate,
 that will never be a problem for a longer time.

 Greetings,
 Marcus

 On 02.06.2014 18:55, David Halls wrote:
 Hi All, Marcus

 I have created a simple block (not yet finished) to create zeros. How do I 
 get this to be scheduled if there are no items at the input? If I connect a 
 source to it, then it works, if I connect my 'sample source b' to it which 
 has no items at time zero, then the block is not scheduled.

 void
 avoid_block_impl::forecast (int noutput_items, gr_vector_int 
 ninput_items_required)
 {
 ninput_items_required[0] = noutput_items;
 }

 int
 avoid_block_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
 {
 const gr_complex *in = (const gr_complex *) input_items[0];
 gr_complex *out = (gr_complex *) output_items[0];

 for(int idx=0; idx  noutput_items; idx++)
 {
 out[idx] = 0;
 }

 // Tell runtime system how many input items we consumed on
 // each input stream.
 consume_each (noutput_items);

 // Tell runtime system how many output items we produced.
 return noutput_items;
 }

 Regards,

 David
 
 From: Marcus Müller [marcus.muel...@ettus.com]
 Sent: 02 June 2014 17:16
 To: David Halls; discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1
 transmission

 Hi David,

 easiest way to achieve coherence on both USRP would be a MIMO
 cable, or GPSDO's.
 That being said, depending on your definition of sync, just setting
 the time at both USRPs would little to some little, yet existent error.
 This error should also occur when using the two USRPs with the same
 USRP Sink, as long as you don't physically synchronize them. You
 could then issue timed commands. The python code would look something like:

 zero_time = uhd.time_spec(0.0)
 usrp_sink0.set_time_now(zero_time)
 usrp_sink1.set_time_now(zero_time)

 If both can receive the same signal, you could synchronize on a
 signal that both receive; that would of course make your application
 more complex, and also needs to be done periodically, since it's
 physically impossible to keep clocks perfectly aligned over a long time.

 Greetings,
 Marcus

 On 02.06.2014 17:49, David Halls wrote:
 Hi Marcus,

 Yes, your diagram represents what I am trying to achieve.

 Using two sinks would be really nice! But I have had some problems with 
 achieving sync using time stamps (where as using one UHD sink is very 
 straightforward). For example, how do I obtain the current time from the 
 transmit USRPs, but from another block in the flow graph - in order to 
 create a tx_time with the right value? Where I have a UHD source its easy 
 as these output an rx_time tag...

 I thought that I could use

 ::uhd

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

[David Halls]

Hey Martin,

Good to hear from you as always. Gnuradio scheduling baffles me more than 
anything else on this planet. The day I get my head around it will be a happy 
day indeed. :0

The problem with using 'sob', 'eob' is because I have two inputs to the USRP 
UHD sink. One is constantly transmitting and has items coming in from time=0, 
but the other has no input items from time=0, they only arrive later on. As a 
result the sink seems to block waiting for items on *both* inputs before it 
will transmit anything. I don't want the USRP to have to wait for the second 
stream to be populated before it transmits anything...

I thought 'forecast' may help me out, but wasn't sure what to put in the 
function to make it schedule even when there are no input items?

David

-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com]
Sent: 03 June 2014 14:53
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On 06/03/2014 03:30 PM, David Halls wrote:
 Dear All,

 Had anyone tried to implementing a gnuradio block that will output
 zeros if there are no items at the input, and will simply copy the
 input to output otherwise?

 I find that if there are no items at the input, the block never gets
 scheduled.

 I want this block to feed zeros to my USRP until actual data is ready
 to be passed to it.

Hey David,

any reason you can't use eob/sob?

Also, did you set forecast accordingly?

Note that this can go wrong easily: If this blocks produces a bajillion zeros 
very quickly, nothing will happen until the USRP has consumed them all.

M




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[David Halls]

Dear All,

I am using N210s with XCVR2450s. I have successfully performed 2x1 
transmission, but not I am not transmitting the same stream over both 
transmitters. One stream is constantly available, and is no problem. The second 
stream only starts later on, and thus it is blocking the flow graph. I tried 
using a mux for the second stream with some noise so that it will transmit 
noise for the first X samples, and then the second stream, but this doesn't 
work either.

Any suggestions guys?

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[David Halls]

Hi Martin,

How's it going?

I am using a single UHD sink, with 2 motherboards specified, in order that the 
transmission is sync'd.

D

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: 02 June 2014 13:16
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1  
transmission

On 06/02/2014 12:34 PM, David Halls wrote:
 I am using N210s with XCVR2450s. I have successfully performed 2x1
 transmission, but not I am not transmitting the same stream over both
 transmitters. One stream is constantly available, and is no problem. The
 second stream only starts later on, and thus it is blocking the flow
 graph. I tried using a mux for the second stream with some noise so that
 it will transmit noise for the first X samples, and then the second
 stream, but this doesn’t work either.

Are you using 2 uhd sinks?

M

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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[David Halls]

Hi Marcus,

Yes, your diagram represents what I am trying to achieve.

Using two sinks would be really nice! But I have had some problems with 
achieving sync using time stamps (where as using one UHD sink is very 
straightforward). For example, how do I obtain the current time from the 
transmit USRPs, but from another block in the flow graph - in order to create a 
tx_time with the right value? Where I have a UHD source its easy as these 
output an rx_time tag...

I thought that I could use

::uhd::time_spec_t
usrp_sink_impl::get_time_now(size_t mboard)
{
  return _dev-get_time_now(mboard);
}

but how do I get a pointer to this in other blocks in the flow graph?

I like the idea of the block to creates zeros (with rate limiting), unless 
there is an input signal. Will this block get scheduled even if there are no 
items at its input, though? Isn't that similar to my simple idea of using a mux 
between a noise source (with 0 amplitude) with sample source b?

I will try to provide some more detail, although the setup is complicated 
indeed and might involve explaining a lot of the background...

Regards,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
Marcus Müller [marcus.muel...@ettus.com]
Sent: 02 June 2014 15:50
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1  
transmission

Hi David,
Generally, this sounds like in principle, your application looks like
(nb: not an actual GR flowgraph)

+-+ +--+
| sample source a || USRP |--- [USRP1]
+-+ |  |
| sink |
+-+ |  |
| sample source b ||  |--- [USRP2]
+-+ +--+

Let's assume a is continuous and b starts later, or bursts or the like.
Can't you just split the flow graph into two independent flowgraphs,
syncing the USRPs using time stamps?

Alternatively, what about having a block that (rate limitedly) produces
zero-samples, unless data comes in on a message port?

Generally, using start-of-burst tags, the newly added command time
message interface for the uhd blocks, and multiple ways to detangle your
sample streams, there are many ways to solve your issues.
I think it would be wise if you described your setup in a little more
detail.

Greetings,
Marcus

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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[David Halls]

Hi Marcus,

Thanks - I require sample level timing sync. Using the external sync to get 
accurate LO frequencies is great, but not sufficient. Using a single UHD block 
with 2 motherboards gives me sample-level sync.

Thanks for the code but how are the uhd, and usrp_sink0, usrp_sink0 objects 
obtained within my own out-of-tree block?

Also setting their time will synchronise the time registers of the two USRPs in 
the same way as using the external sync (with PPS - I have an octoclock-G), but 
don't I need to use a 'tx_time' tag (and 'sob', 'eob') too so that they know 
*when* to transmit their respective bursts? This means having some 
communication between the two source streams so they can agree on a mutually 
agreeable tx_time?

Regards,

David

From: Marcus Müller [marcus.muel...@ettus.com]
Sent: 02 June 2014 17:16
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

Hi David,

easiest way to achieve coherence on both USRP would be a MIMO cable,
or GPSDO's.
That being said, depending on your definition of sync, just setting
the time at both USRPs would little to some little, yet existent error.
This error should also occur when using the two USRPs with the same USRP
Sink, as long as you don't physically synchronize them. You could then
issue timed commands. The python code would look something like:

zero_time = uhd.time_spec(0.0)
usrp_sink0.set_time_now(zero_time)
usrp_sink1.set_time_now(zero_time)

If both can receive the same signal, you could synchronize on a signal
that both receive; that would of course make your application more
complex, and also needs to be done periodically, since it's physically
impossible to keep clocks perfectly aligned over a long time.

Greetings,
Marcus

On 02.06.2014 17:49, David Halls wrote:
 Hi Marcus,

 Yes, your diagram represents what I am trying to achieve.

 Using two sinks would be really nice! But I have had some problems with 
 achieving sync using time stamps (where as using one UHD sink is very 
 straightforward). For example, how do I obtain the current time from the 
 transmit USRPs, but from another block in the flow graph - in order to create 
 a tx_time with the right value? Where I have a UHD source its easy as these 
 output an rx_time tag...

 I thought that I could use

 ::uhd::time_spec_t
 usrp_sink_impl::get_time_now(size_t mboard)
 {
   return _dev-get_time_now(mboard);
 }

 but how do I get a pointer to this in other blocks in the flow graph?

 I like the idea of the block to creates zeros (with rate limiting), unless 
 there is an input signal. Will this block get scheduled even if there are no 
 items at its input, though? Isn't that similar to my simple idea of using a 
 mux between a noise source (with 0 amplitude) with sample source b?

 I will try to provide some more detail, although the setup is complicated 
 indeed and might involve explaining a lot of the background...

 Regards,

 David
 
 From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
 [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
 Marcus Müller [marcus.muel...@ettus.com]
 Sent: 02 June 2014 15:50
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1  
 transmission

 Hi David,
 Generally, this sounds like in principle, your application looks like
 (nb: not an actual GR flowgraph)

 +-+ +--+
 | sample source a || USRP |--- [USRP1]
 +-+ |  |
 | sink |
 +-+ |  |
 | sample source b ||  |--- [USRP2]
 +-+ +--+

 Let's assume a is continuous and b starts later, or bursts or the like.
 Can't you just split the flow graph into two independent flowgraphs,
 syncing the USRPs using time stamps?

 Alternatively, what about having a block that (rate limitedly) produces
 zero-samples, unless data comes in on a message port?

 Generally, using start-of-burst tags, the newly added command time
 message interface for the uhd blocks, and multiple ways to detangle your
 sample streams, there are many ways to solve your issues.
 I think it would be wise if you described your setup in a little more
 detail.

 Greetings,
 Marcus

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

 

 NOTE: The information in this email and any attachments may be confidential 
 and/or legally privileged. This message may be read, copied and used only by 
 the intended recipient. If you are not the intended recipient, please destroy 
 this message, delete any copies held on your system and notify the sender 
 immediately.

 Toshiba

Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[David Halls]

Hi All, Marcus

I have created a simple block (not yet finished) to create zeros. How do I get 
this to be scheduled if there are no items at the input? If I connect a source 
to it, then it works, if I connect my 'sample source b' to it which has no 
items at time zero, then the block is not scheduled.

void
avoid_block_impl::forecast (int noutput_items, gr_vector_int 
ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}

int
avoid_block_impl::general_work (int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];

for(int idx=0; idx  noutput_items; idx++)
{
out[idx] = 0;
}

// Tell runtime system how many input items we consumed on
// each input stream.
consume_each (noutput_items);

// Tell runtime system how many output items we produced.
return noutput_items;
}

Regards,

David

From: Marcus Müller [marcus.muel...@ettus.com]
Sent: 02 June 2014 17:16
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

Hi David,

easiest way to achieve coherence on both USRP would be a MIMO cable,
or GPSDO's.
That being said, depending on your definition of sync, just setting
the time at both USRPs would little to some little, yet existent error.
This error should also occur when using the two USRPs with the same USRP
Sink, as long as you don't physically synchronize them. You could then
issue timed commands. The python code would look something like:

zero_time = uhd.time_spec(0.0)
usrp_sink0.set_time_now(zero_time)
usrp_sink1.set_time_now(zero_time)

If both can receive the same signal, you could synchronize on a signal
that both receive; that would of course make your application more
complex, and also needs to be done periodically, since it's physically
impossible to keep clocks perfectly aligned over a long time.

Greetings,
Marcus

On 02.06.2014 17:49, David Halls wrote:
 Hi Marcus,

 Yes, your diagram represents what I am trying to achieve.

 Using two sinks would be really nice! But I have had some problems with 
 achieving sync using time stamps (where as using one UHD sink is very 
 straightforward). For example, how do I obtain the current time from the 
 transmit USRPs, but from another block in the flow graph - in order to create 
 a tx_time with the right value? Where I have a UHD source its easy as these 
 output an rx_time tag...

 I thought that I could use

 ::uhd::time_spec_t
 usrp_sink_impl::get_time_now(size_t mboard)
 {
   return _dev-get_time_now(mboard);
 }

 but how do I get a pointer to this in other blocks in the flow graph?

 I like the idea of the block to creates zeros (with rate limiting), unless 
 there is an input signal. Will this block get scheduled even if there are no 
 items at its input, though? Isn't that similar to my simple idea of using a 
 mux between a noise source (with 0 amplitude) with sample source b?

 I will try to provide some more detail, although the setup is complicated 
 indeed and might involve explaining a lot of the background...

 Regards,

 David
 
 From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
 [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
 Marcus Müller [marcus.muel...@ettus.com]
 Sent: 02 June 2014 15:50
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1  
 transmission

 Hi David,
 Generally, this sounds like in principle, your application looks like
 (nb: not an actual GR flowgraph)

 +-+ +--+
 | sample source a || USRP |--- [USRP1]
 +-+ |  |
 | sink |
 +-+ |  |
 | sample source b ||  |--- [USRP2]
 +-+ +--+

 Let's assume a is continuous and b starts later, or bursts or the like.
 Can't you just split the flow graph into two independent flowgraphs,
 syncing the USRPs using time stamps?

 Alternatively, what about having a block that (rate limitedly) produces
 zero-samples, unless data comes in on a message port?

 Generally, using start-of-burst tags, the newly added command time
 message interface for the uhd blocks, and multiple ways to detangle your
 sample streams, there are many ways to solve your issues.
 I think it would be wise if you described your setup in a little more
 detail.

 Greetings,
 Marcus

 ___
 Discuss-gnuradio mailing

Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[David Halls]

Hi Marcus,

I'm not sure if understand correctly then, how would you suggest it is possible 
to implement your suggestion

'a block that (rate limitedly) produces zero-samples, unless data comes in on a 
message port?'

...My new block is connected to the UHD sink - so this should consume the 
output buffer of the block at a constant rate, and so my setup *should* work?

Many thanks,

David


 Original message 
From: Marcus Müller
Date:02/06/2014 19:56 (GMT+00:00)
To: David Halls ,discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

Hi David,

you're right, the scheduler will only call your block when out- or input
buffer situation have changed, and there's no elegant way to coerce that.
However, given a sink that consumes with a constant continous rate, that
will never be a problem for a longer time.

Greetings,
Marcus

On 02.06.2014 18:55, David Halls wrote:
 Hi All, Marcus

 I have created a simple block (not yet finished) to create zeros. How do I 
 get this to be scheduled if there are no items at the input? If I connect a 
 source to it, then it works, if I connect my 'sample source b' to it which 
 has no items at time zero, then the block is not scheduled.

 void
 avoid_block_impl::forecast (int noutput_items, gr_vector_int 
 ninput_items_required)
 {
 ninput_items_required[0] = noutput_items;
 }

 int
 avoid_block_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
 {
 const gr_complex *in = (const gr_complex *) input_items[0];
 gr_complex *out = (gr_complex *) output_items[0];

 for(int idx=0; idx  noutput_items; idx++)
 {
 out[idx] = 0;
 }

 // Tell runtime system how many input items we consumed on
 // each input stream.
 consume_each (noutput_items);

 // Tell runtime system how many output items we produced.
 return noutput_items;
 }

 Regards,

 David
 
 From: Marcus Müller [marcus.muel...@ettus.com]
 Sent: 02 June 2014 17:16
 To: David Halls; discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 
 transmission

 Hi David,

 easiest way to achieve coherence on both USRP would be a MIMO cable,
 or GPSDO's.
 That being said, depending on your definition of sync, just setting
 the time at both USRPs would little to some little, yet existent error.
 This error should also occur when using the two USRPs with the same USRP
 Sink, as long as you don't physically synchronize them. You could then
 issue timed commands. The python code would look something like:

 zero_time = uhd.time_spec(0.0)
 usrp_sink0.set_time_now(zero_time)
 usrp_sink1.set_time_now(zero_time)

 If both can receive the same signal, you could synchronize on a signal
 that both receive; that would of course make your application more
 complex, and also needs to be done periodically, since it's physically
 impossible to keep clocks perfectly aligned over a long time.

 Greetings,
 Marcus

 On 02.06.2014 17:49, David Halls wrote:
 Hi Marcus,

 Yes, your diagram represents what I am trying to achieve.

 Using two sinks would be really nice! But I have had some problems with 
 achieving sync using time stamps (where as using one UHD sink is very 
 straightforward). For example, how do I obtain the current time from the 
 transmit USRPs, but from another block in the flow graph - in order to 
 create a tx_time with the right value? Where I have a UHD source its easy as 
 these output an rx_time tag...

 I thought that I could use

 ::uhd::time_spec_t
 usrp_sink_impl::get_time_now(size_t mboard)
 {
   return _dev-get_time_now(mboard);
 }

 but how do I get a pointer to this in other blocks in the flow graph?

 I like the idea of the block to creates zeros (with rate limiting), unless 
 there is an input signal. Will this block get scheduled even if there are no 
 items at its input, though? Isn't that similar to my simple idea of using a 
 mux between a noise source (with 0 amplitude) with sample source b?

 I will try to provide some more detail, although the setup is complicated 
 indeed and might involve explaining a lot of the background...

 Regards,

 David
 
 From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
 [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
 Marcus Müller [marcus.muel...@ettus.com]
 Sent: 02 June 2014 15:50
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1  
 transmission

 Hi David,
 Generally, this sounds like in principle, your application looks like
 (nb: not an actual GR flowgraph

Re: [Discuss-gnuradio] OFDM Example, 'Noisy' final symbol

[David Halls]

Hi Martin,

This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The results 
I sent are over a cable, and the results I sent are post equalizer.

It is only the final symbol of a burst, not the final symbol of each packet.

I agree they should all be equally noisy, and I am certain it's not 'noise' as 
such.

I thought if the timing window is too late, then some TD samples for the 
*final* symbol will be included in the FFT that are just noise. I have stored 
the TD samples and manually performed FFT and eq'n and shifting the window of 
samples to pass to the FFT (either forwards or backwards) by up 16 samples does 
not help.

You have never noticed this happen?

DH

From: Martin Braun [martin.br...@ettus.com]
Sent: 30 April 2014 12:07
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: OFDM Example, 'Noisy' final symbol

On 30.04.2014 11:51, David Halls wrote:
 Hi Martin, All,

 Has anyone noticed that the final symbol of any burst (no matter how
 many packets in a transmission) appears slightly 'noisy' in the OFDM
 example code? Is it something to do with my set-up?

 I attach a picture of the eq'd FD constellation when I send two packet:
 a) the first packet, b) the second packet (excluding the final (16th)
 symbol), and c) second packet (with all symbols)

 Is it to do with sample alignment/timing error? I have tried sliding the
 samples passed to the FFT at the receiver, moving the window backwards
 and forwards and can't get a better result...

This was my first thought when I read the subject line... where are you
getting symbols? Before the equalizer? And is this OTA, or simulated?

Really, all OFDM symbols should be equally noisy. A timing offset will
normally only make the acquisition start somewhere between start and end
of the cyclic prefix. So, I'm unsure what this is without any further
analysis.

Martin




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] Obtaining 'time_spec' from Out-of-tree C++ Module

[David Halls]

Dear All,

I would like to have knowledge of the USRP time in my transmitter flow graph. 
In the receiver flow graph this is straight forward because 'rx_time' tag is 
propagated from a USRP source as a tag.

How can I obtain the time_spec from a c++ block in my transmitter flow graph?

usrp_sink_impl.cc has the function

::uhd::time_spec_t
usrp_sink_impl::get_time_now(size_t mboard)
{
  return _dev-get_time_now(mboard);
}

But how can I call this from outside the usrp_sink block?

Many thanks!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] OFDM Example, 'Noisy' final symbol

[David Halls]

Hi,

It's just the built in basic FDE. Its not awesome, but works well enough at 
high SNR.

Yes, when I send multiple packets, its only the last OFDM symbol of the last 
packet that is affected.

I have tried suffixing FFT_len/4 (i.e. 16 = CP) lots of 0's in the TD at the 
transmitter, and this fixes the problem (low power noise instead of 0's also 
works).

Could it be an analogue issue? It is always the last symbol, i.e. the end of 
the transmission, and it looks like the power might trail off from the attached 
picture? But it seems strange that it's exactly the last symbol?

Could the pulse shaping performed in the cyclic prefixer have any effect?!

Regards,

David

From: Martin Braun [martin.br...@ettus.com]
Sent: 30 April 2014 14:56
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: OFDM Example, 'Noisy' final symbol

On 30.04.2014 13:14, David Halls wrote:
 Hi Martin,

 This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
 results I sent are over a cable, and the results I sent are post equalizer.

Which equalizer are you using? A custom one? Those in GNU Radio aren't
fantastic, and they don't output soft info.

 It is only the final symbol of a burst, not the final symbol of each packet.

So what you're saying is that when you send several packets directly one
after another, only the last one gets this?

 I agree they should all be equally noisy, and I am certain it's not
 'noise' as such.

 I thought if the timing window is too late, then some TD samples for the
 *final* symbol will be included in the FFT that are just noise. I have
 stored the TD samples and manually performed FFT and eq'n and shifting
 the window of samples to pass to the FFT (either forwards or backwards)
 by up 16 samples does not help.

If the timing window's late, something's seriously wrong. It should
always be early.

I currently don't have a good idea, though.

M


 You have never noticed this happen?

 DH
 
 From: Martin Braun [martin.br...@ettus.com]
 Sent: 30 April 2014 12:07
 To: David Halls; discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org
 Subject: Re: OFDM Example, 'Noisy' final symbol

 On 30.04.2014 11:51, David Halls wrote:
   Hi Martin, All,
  
   Has anyone noticed that the final symbol of any burst (no matter how
   many packets in a transmission) appears slightly 'noisy' in the OFDM
   example code? Is it something to do with my set-up?
  
   I attach a picture of the eq'd FD constellation when I send two packet:
   a) the first packet, b) the second packet (excluding the final (16th)
   symbol), and c) second packet (with all symbols)
  
   Is it to do with sample alignment/timing error? I have tried sliding the
   samples passed to the FFT at the receiver, moving the window backwards
   and forwards and can't get a better result...

 This was my first thought when I read the subject line... where are you
 getting symbols? Before the equalizer? And is this OTA, or simulated?

 Really, all OFDM symbols should be equally noisy. A timing offset will
 normally only make the acquisition start somewhere between start and end
 of the cyclic prefix. So, I'm unsure what this is without any further
 analysis.

 Martin


 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl


 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com

Re: [Discuss-gnuradio] Obtaining 'time_spec' from Out-of-tree C++ Module

[David Halls]

Hi Marcus!

 get_time_now is a public function of usrp_sink, it is accessible from 
 everywhere :)

Great, I thought it was a public function, just wasn't sure how to get a 
pointer to it.

 uhd::time_spec_t now = my_usrp_sink-get_time_now();

Sure thing.

 You'll need a (shared) pointer to that usrp_sink

I am not clear how I obtain that (to then I pass it to my C++ module as a 
constructor?)

Regards,

David

From: Marcus Müller [marcus.muel...@ettus.com]
Sent: 30 April 2014 14:37
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Obtaining 'time_spec' from Out-of-tree C++ 
Module

Hello David,

as get_time_now is a public function of usrp_sink, it is accessible from 
everywhere :)
You'll need a (shared) pointer to that usrp_sink;using that, you can do 
something like
uhd::time_spec_t now = my_usrp_sink-get_time_now();
You could, for example, take an usrp_sink::sptr as an argument for your block's 
constructor and store that reference to use it later in your work() function.

Greetings,
Marcus




On Wed, Apr 30, 2014 at 2:26 PM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Dear All,

I would like to have knowledge of the USRP time in my transmitter flow graph. 
In the receiver flow graph this is straight forward because 'rx_time' tag is 
propagated from a USRP source as a tag.

How can I obtain the time_spec from a c++ block in my transmitter flow graph?

usrp_sink_impl.cc has the function

::uhd::time_spec_t
usrp_sink_impl::get_time_now(size_t mboard)
{
return _dev-get_time_now(mboard);
}

But how can I call this from outside the usrp_sink block?

Many thanks!

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl



This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com


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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] OFDM Example, 'Noisy' final symbol

[David Halls]

Hi Martin,

Setting the rolloff factor in the cyclic prefixer to CP_len (16 samples) fixes 
the problem?! Previously I had rolloff = 0.

Any thoughts?

DH

From: Martin Braun [martin.br...@ettus.com]
Sent: 30 April 2014 14:56
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: OFDM Example, 'Noisy' final symbol

On 30.04.2014 13:14, David Halls wrote:
 Hi Martin,

 This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
 results I sent are over a cable, and the results I sent are post equalizer.

Which equalizer are you using? A custom one? Those in GNU Radio aren't
fantastic, and they don't output soft info.

 It is only the final symbol of a burst, not the final symbol of each packet.

So what you're saying is that when you send several packets directly one
after another, only the last one gets this?

 I agree they should all be equally noisy, and I am certain it's not
 'noise' as such.

 I thought if the timing window is too late, then some TD samples for the
 *final* symbol will be included in the FFT that are just noise. I have
 stored the TD samples and manually performed FFT and eq'n and shifting
 the window of samples to pass to the FFT (either forwards or backwards)
 by up 16 samples does not help.

If the timing window's late, something's seriously wrong. It should
always be early.

I currently don't have a good idea, though.

M


 You have never noticed this happen?

 DH
 
 From: Martin Braun [martin.br...@ettus.com]
 Sent: 30 April 2014 12:07
 To: David Halls; discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org
 Subject: Re: OFDM Example, 'Noisy' final symbol

 On 30.04.2014 11:51, David Halls wrote:
   Hi Martin, All,
  
   Has anyone noticed that the final symbol of any burst (no matter how
   many packets in a transmission) appears slightly 'noisy' in the OFDM
   example code? Is it something to do with my set-up?
  
   I attach a picture of the eq'd FD constellation when I send two packet:
   a) the first packet, b) the second packet (excluding the final (16th)
   symbol), and c) second packet (with all symbols)
  
   Is it to do with sample alignment/timing error? I have tried sliding the
   samples passed to the FFT at the receiver, moving the window backwards
   and forwards and can't get a better result...

 This was my first thought when I read the subject line... where are you
 getting symbols? Before the equalizer? And is this OTA, or simulated?

 Really, all OFDM symbols should be equally noisy. A timing offset will
 normally only make the acquisition start somewhere between start and end
 of the cyclic prefix. So, I'm unsure what this is without any further
 analysis.

 Martin


 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl


 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] OFDM Example, 'Noisy' final symbol

[David Halls]

Sorry, my fault - I altered the FDE so it *does* give soft outputs, because the 
constellation decoder makes hard decisions anyway - so I didn't see the need 
for it to be done twice.

I forgot i'd made changes :s But now maybe I understand why people haven't seen 
this issue - because they have never looked at the soft outputs of the FDE!!

I am not quite clear how the pulse shaping works, it seems to extend each 
*packet* by rolloff_len/2 samples, it works out the flanks by

for (int i = 1; i  d_rolloff_len; i++) {
  d_up_flank[i-1]   = 0.5 * (1 + cos(M_PI * i/rolloff_len - M_PI));
  d_down_flank[i-1] = 0.5 * (1 + cos(M_PI * (rolloff_len-i)/rolloff_len 
- M_PI));
}

Which makes sense...

then applies using

if (d_rolloff_len) {
  for (int i = 0; i  d_rolloff_len-1; i++) {
out[i] = out[i] * d_up_flank[i] + d_delay_line[i];
d_delay_line[i] = in[i] * d_down_flank[i];
  }
}

Is it extending the symbol and then shaping? Not sure I understand why each 
*packet* is extended by rolloff_len/2, not each symbol.

Is pulse shaping applied in the USRP, and can this be controlled from USRP_sink?

Phew!

DH


From: Martin Braun [martin.br...@ettus.com]
Sent: 30 April 2014 15:56
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: OFDM Example, 'Noisy' final symbol

On 30.04.2014 16:03, David Halls wrote:
 It's just the built in basic FDE. Its not awesome, but works well enough
 at high SNR.

Hm, the FDE doesn't output soft info, so I'm stumped why you'd see
anything other than clean constellation points in the first place.

 Yes, when I send multiple packets, its only the last OFDM symbol of the
 last packet that is affected.

 I have tried suffixing FFT_len/4 (i.e. 16 = CP) lots of 0's in the TD at
 the transmitter, and this fixes the problem (low power noise instead of
 0's also works).

 Could it be an analogue issue? It is always the last symbol, i.e. the
 end of the transmission, and it looks like the power might trail off
 from the attached picture? But it seems strange that it's exactly the
 last symbol?

 Could the pulse shaping performed in the cyclic prefixer have any effect?!

 From your other email, it looks like it does... but you can't set the
rolloff to the CP length, you need some space for multipath.

Martin



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled

[David Halls]

Hi Martin,

Sorry for the very slow reply. Life is hectic here!

I found that if I removed the SNR input, that provides many few inputs that the 
other (its an SNR value *per packet*, so there is only 1 input item to this for 
every 768 to the other input), the output buffer increases to

Out_bA1.shape(512,)
Est_bA1m.shape(3840,)
Len(out_bA1) = 512

So the output buffer seems dominated by the input that has fewer items coming 
in???

I managed to resolve the problem completely by changing

Ninput_items_required[i] = noutput_items/pow(2,13)

In 'forecast', perhaps there are more elegant solutions, but this seems to work 
fine (there is only one output).

Regards,

David

-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 12 March 2014 08:54
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

On 11.03.2014 17:10, David Halls wrote:
 Hi,

 Yes, the len(output_items[0]), is either 1 or 2...

 If I set_output_multiple to 10, then this value raises to 10.

Can you post the entire block code?

M

 It is dominated by the fact that one of the inputs to my block is much
 lower than the other?? Input[0] is the data stream and has say 768
 items, input[1] is the packet average SNR, so it only has 1 or 2 items
 in the same period.

 Forecast is currently

 For I in range (len(ninput_items_required)):
 Ninput_items_required[i] = noutput_items

 Does this need to be altered for my case where I have two inputs with
 very different requirements.

 If I ever get my head around the scheduler in GNU radio, it will be a
 happy day :)

 D

 -Original Message-
 From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
 mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
 [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org]
 On Behalf Of Martin Braun
 Sent: 11 March 2014 15:27
 To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] output operand requires a reduction,
 but reduction is not enabled

 On 03/11/2014 04:24 PM, David Halls wrote:
   Please see the papers we've submitted so far this year. Not exactly
  WNC, yet... We're putting one together as we speak though.
  
   I am not sure I understand your reply fully...
  
   Len(out_bA1) is only 1 or 2, so I can only set one or two elements?

 Is this before or after you assign something? What's len(output_items[0])?

   How can I extend the length of out_bA1, so I can output all of est_bA1m?

 You can't, not in the work function. You can do things like
 set_output_multiple() to influence the size of the output buffer.

   Or alternatively Is it possible for me to set
 output_items[0][0:len(est_bA1m)] = est_bA1m

 That would work, if len(est_bA1m)  len(output_items[0]) AND they have
 the right shape (in matrix terms).

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


 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read,
 copied and used only by the intended recipient. If you are not the
 intended recipient, please destroy this message, delete any copies
 held on your system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl


 --
 -- This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 --
 --


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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely

[Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled

[David Halls]

Thanks Martin, this is clear and makes sense. I should have read the numpy data 
types more thoroughly and worked it out. Anyway...

My collaborators are writing their Wireless Network Coding bits in Python. Once 
I get this block working, I can combined it with the relay work I was doing and 
we will have a pretty exciting setup to report!! :)

I have one more problem though...

I have

out_bA1 = output_items[0]

...
...code
...

out_bA1[0:len(est_bA1m)] = est_bA1m

where

out_bA1.shape = (1,)
est_bA1m.shape = (3840,)

I get the error  output operand requires a reduction, but reduction is not 
enabled

*Sometimes* I get

out_bA1.shape = (2,)
est_bA1m.shape = (3840,)

and I get the error operands could not be broadcast together with shapes (2) 
(3840)

I wondered if the problem is with 'forecast' (which I have not changed since 
the template was created by gr_modtool) or having to set_output_multiple? The 
scheduling aspect of GNU radio seems complex.

If I use

 out_bA1 = est_bA1m

Then it *runs* OK, but the output of the block i.e. output_items[0] is then no 
longer altered and 0's are output.

Many thanks,

David


-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 11 March 2014 08:33
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch

On 03/11/2014 02:06 AM, David Halls wrote:
 You're a genius! It works.

 Interestingly for a float it requires numpy.float32 or a similar error
 occurs.

Yes, in GNU Radio we consistently use 32-bit floats. A complex value consists 
of two of these, hence the 64 bits.

Note that this is just for buffers. A lot of blocks use double internally (i.e. 
64-bit float, or 128-bit complex) for accuracy reason.
However, for signals, it's just a waste of bandwidth (most of time, SNR will 
trump quantization noise anyway).

M


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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled

[David Halls]

Hi,

Yes, the len(output_items[0]), is either 1 or 2...

If I set_output_multiple to 10, then this value raises to 10.

It is dominated by the fact that one of the inputs to my block is much lower 
than the other?? Input[0] is the data stream and has say 768 items, input[1] is 
the packet average SNR, so it only has 1 or 2 items in the same period.

Forecast is currently

For I in range (len(ninput_items_required)):
Ninput_items_required[i] = noutput_items

Does this need to be altered for my case where I have two inputs with very 
different requirements.

If I ever get my head around the scheduler in GNU radio, it will be a happy day 
:)

D

-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 11 March 2014 15:27
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

On 03/11/2014 04:24 PM, David Halls wrote:
 Please see the papers we've submitted so far this year. Not exactly
 WNC, yet... We're putting one together as we speak though.

 I am not sure I understand your reply fully...

 Len(out_bA1) is only 1 or 2, so I can only set one or two elements?

Is this before or after you assign something? What's len(output_items[0])?

 How can I extend the length of out_bA1, so I can output all of est_bA1m?

You can't, not in the work function. You can do things like
set_output_multiple() to influence the size of the output buffer.

 Or alternatively Is it possible for me to set

 output_items[0][0:len(est_bA1m)] = est_bA1m

That would work, if len(est_bA1m)  len(output_items[0]) AND they have the 
right shape (in matrix terms).

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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] FW: output operand requires a reduction, but reduction is not enabled

[David Halls]

From: David Halls
Sent: 11 March 2014 16:10
To: Martin Braun; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

Hi,

Yes, the len(output_items[0]), is either 1 or 2...

If I set_output_multiple to 10, then this value raises to 10.

It is dominated by the fact that one of the inputs to my block is much lower 
than the other?? Input[0] is the data stream and has say 768 items, input[1] is 
the packet average SNR, so it only has 1 or 2 items in the same period.

Forecast is currently

For I in range (len(ninput_items_required)):
Ninput_items_required[i] = noutput_items

Does this need to be altered for my case where I have two inputs with very 
different requirements.

If I ever get my head around the scheduler in GNU radio, it will be a happy day 
:)

D

-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 11 March 2014 15:27
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but 
reduction is not enabled

On 03/11/2014 04:24 PM, David Halls wrote:
 Please see the papers we've submitted so far this year. Not exactly
 WNC, yet... We're putting one together as we speak though.

 I am not sure I understand your reply fully...

 Len(out_bA1) is only 1 or 2, so I can only set one or two elements?

Is this before or after you assign something? What's len(output_items[0])?

 How can I extend the length of out_bA1, so I can output all of est_bA1m?

You can't, not in the work function. You can do things like
set_output_multiple() to influence the size of the output buffer.

 Or alternatively Is it possible for me to set

 output_items[0][0:len(est_bA1m)] = est_bA1m

That would work, if len(est_bA1m)  len(output_items[0]) AND they have the 
right shape (in matrix terms).

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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] Python block, itemsize mismatch

[David Halls]

Hi,

I get the following error connecting 'OFDM Serializer' (GNU Radio block with 
complex output), to my own Python block 'blsd_dec_bfb' (with complex input)

ValueError: itemsize mismatch: ofdm_serializer_vcc0:0 using 8, blsd_dec_bfb0:0 
using 16

This is the code in the beginning of my block

class blsd_dec_bfb(gr.basic_block):

docstring for block blsd_dec_bfb

def __init__(self, num_packets=1, K=50, K2=20, kA1=4, NA1=8, 
num_carriers=64):
gr.basic_block.__init__(self,
name=blsd_dec_bfb,
in_sig=[numpy.complex],
out_sig=[numpy.uint8,numpy.uint8,numpy.uint8])

the xml is

... sink
namein/name
typecomplex/type
  /sink
  source
namebA1/name
typebyte/type
  /source
  source
namebA2/name
typebyte/type
  /source
  source
nameb2/name
typebyte/type
  /source...

The colours match in the GRC, and it lets me run it (i.e. no complaints about 
type mismatch before run-time).

I hope it is just a silly mistake. Can anyone help?

Regards,

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Python block, itemsize mismatch

[David Halls]

You're a genius! It works.

Interestingly for a float it requires numpy.float32 or a similar error occurs.

D

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: 10 March 2014 21:29
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch

On 03/10/2014 06:57 PM, David Halls wrote:
 Hi,

 I get the following error connecting 'OFDM Serializer' (GNU Radio block
 with complex output), to my own Python block 'blsd_dec_bfb' (with
 complex input)

 ValueError: itemsize mismatch: ofdm_serializer_vcc0:0 using 8,
 blsd_dec_bfb0:0 using 16

 This is the code in the beginning of my block

 class blsd_dec_bfb(gr.basic_block):
 
 docstring for block blsd_dec_bfb
 
 def __init__(self, num_packets=1, K=50, K2=20, kA1=4, NA1=8,
 num_carriers=64):
 gr.basic_block.__init__(self,
 name=blsd_dec_bfb,
 in_sig=[numpy.complex],
 out_sig=[numpy.uint8,numpy.uint8,numpy.uint8])

I think you need to do numpy.complex64 -- not 100%, can you please tell
us if this worked.

M

 the xml is

 ... sink
 namein/name
 typecomplex/type
 /sink
 source
 namebA1/name
 typebyte/type
 /source
 source
 namebA2/name
 typebyte/type
 /source
 source
 nameb2/name
 typebyte/type
 /source...

 The colours match in the GRC, and it lets me run it (i.e. no complaints
 about type mismatch before run-time).

 I hope it is just a silly mistake. Can anyone help?

 Regards,

 David

 

 NOTE: The information in this email and any attachments may be
 confidential and/or legally privileged. This message may be read, copied
 and used only by the intended recipient. If you are not the intended
 recipient, please destroy this message, delete any copies held on your
 system and notify the sender immediately.

 Toshiba Research Europe Limited, registered in England and Wales
 (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
 Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
 http://www.toshiba.eu/research/trl


 
 This email has been scanned for email related threats and delivered
 safely by Mimecast.
 For more information please visit http://www.mimecast.com
 


 ___
 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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] (Python) Source Block Outputs All 0's

[David Halls]

Hi All,

I have implemented a python source block:

def __init__(self, kA1=4,kB1=4,k2=4,NA1=8,NB1=8,N2=8,M=8):
gr.sync_block.__init__(self,
name=blsd_enc_b,
in_sig=None,
out_sig=[numpy.uint8,numpy.uint8])


but I can't get it to output anything but 0's

def work(self, input_items, output_items):
out_cA = output_items[0]
out_cB = output_items[1]

out_cA = [ 5, 6, 7, 8, 9, 10 ] #cA[0]
out_cB = [ 5, 6, 7, 8, 9, 10 ] #cB[0]
self.produce(0,len(out_cA))
self.produce(1,len(out_cB))
print 'out_cA = ', out_cA, ', len(out_cA) = ', len(out_cA)
print 'out_cB = ', out_cB, ', len(out_cB) = ', len(out_cB)
return -1 #-2


I connect both outputs to a file sync of type byte, and it stores 6 bytes but 
its all \00\00\00\00\00\00

The print lines give:

out_cA =  [5, 6, 7, 8, 9, 10] , len(out_cA) =  6
out_cB =  [5, 6, 7, 8, 9, 10] , len(out_cB) =  6

as expected.

Any advice?

Regards,

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] (Python) Source Block Outputs All 0's

[David Halls]

Hi Nathan,

Thanks for your reply :)

I've done little python before, am trying to incorporate a collaborators code 
into my system and he's used python.

I am used to C, where it would copy the pointer. I understand your advice - 
thanks, I will look at the link.

The return value is mimicking the WORK_CALLED_PRODUCE (-2) and WORK_DONE return 
values that can be used when you have multiple outputs which may output 
different number of items and the produce function is used.

I am not sure why the block keeps repeating if I use -2 as I use successfully 
in many c++ blocks - I'm not used to writing source blocks... maybe others have 
comments?

David

From: West, Nathan [n...@ostatemail.okstate.edu]
Sent: 18 February 2014 21:06
To: David Halls
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] (Python) Source Block Outputs All 0's

On Tue, Feb 18, 2014 at 12:50 PM, David Halls
david.ha...@toshiba-trel.com wrote:
 Hi All,

 I have implemented a python source block:

 def __init__(self, kA1=4,kB1=4,k2=4,NA1=8,NB1=8,N2=8,M=8):
 gr.sync_block.__init__(self,
 name=blsd_enc_b,
 in_sig=None,
 out_sig=[numpy.uint8,numpy.uint8])


 but I can't get it to output anything but 0's

 def work(self, input_items, output_items):
 out_cA = output_items[0]
 out_cB = output_items[1]

 out_cA = [ 5, 6, 7, 8, 9, 10 ] #cA[0]
 out_cB = [ 5, 6, 7, 8, 9, 10 ] #cB[0]
 self.produce(0,len(out_cA))
 self.produce(1,len(out_cB))
 print 'out_cA = ', out_cA, ', len(out_cA) = ', len(out_cA)
 print 'out_cB = ', out_cB, ', len(out_cB) = ', len(out_cB)
 return -1 #-2


 I connect both outputs to a file sync of type byte, and it stores 6 bytes
 but its all \00\00\00\00\00\00

 The print lines give:

 out_cA = [5, 6, 7, 8, 9, 10] , len(out_cA) = 6
 out_cB = [5, 6, 7, 8, 9, 10] , len(out_cB) = 6

 as expected.

 Any advice?

 Regards,

 David



David,

The problem here is that you're not inserting items in to the out_cA
(and out_cB) arrays, you're actually reassigning out_cA to be this new
list.

Honestly, I've never written a python block, but my understanding is
that you'd have to do something like this http://dpaste.com/1634971/

The items in the out_items list are actually numpy arrays, and they
need to be indexed. The [:] indexing is a shortcut of indexing the
entire array.

Another thing I'm not really sure about is whether the -1 will work or
not. I think you might have to return 6 so that the scheduler knows
there are 6 items to work on, and then the next time work is called
you return -1 ( assuming you're wanting to stop the flowgraph here?).
Somebody else might chime in here if I'm wrong.

Nathan




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Half-Duplex Relay

[David Halls]

Hi Martin and all,

I am looking at some AF stuff for now, where the delay is much better.

I am using something similar to HPD at the relay to implement some gain to the 
payload samples only. I call

// Copy header
copy_n_symbols(in, out, 0, samples_per_header);
// Copy payload
copy_n_symbols(in, out, 0, samples_per_payload);

where the function is:

void packet_detector_impl::copy_n_symbols(const unsigned char *in, unsigned 
char *out, int port, int n_symbols)
{
// Copy samples
memcpy((void *) out, (void *) in, n_symbols*sizeof(gr_complex));
// Copy tags
std::vectortag_t tags;
get_tags_in_range(tags, 0, nitems_read(0), nitems_read(0) + n_symbols);
for (unsigned t = 0; t  tags.size(); t++)
{
int new_offset = tags[t].offset - nitems_read(0);
add_item_tag(port, nitems_written(port) + new_offset, tags[t].key, 
tags[t].value);
}
}

My questions is probably stupid, but I want to multiply the payload symbols by 
a certain gain, say 'G', but I am not clear how to do it.  I am not clear how 
to access the items individually to scale them.

As a first step, I tried first replacing the memcpy with

  for(int i = 0; i  samples_per_packet; i++) out[i] = in[i];

but that of course doesn't successfully replace the functionality?

Regards,

David


From: Martin Braun [martin.br...@ettus.com]
Sent: 30 January 2014 15:56
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

On 30.01.2014 16:49, David Halls wrote:
 Thanks Martin,

 So your recommendation would be not to spend too much time poking around
 with USRP latency stuff:

 http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency

This is an excellent guide, and a good read. In this case, I doubt UHD
is the limiting factor.

 Is there an obvious way to benchmark the latency in GNU Radio? I have
 basically stuck your decoder and encoders back to back in the relay
 code, so it is pretty intensive. I suppose that implementing some of it
 in the FPGA may help? I have no experience in that field at all though...

It would certainly help, but you'd be looking at an absurd amount of
work. I can't think of a good pure GNU Radio way to measure latency, though.

 The current implementation is enough to show proof of concept but is
 very inefficient.

That's true, but given that it's clicked together, 10 ms latency is not
all that bad.

 Is there an obvious way to increase the payload length without getting
 buffer issues in the code - have you ever tried increasing it
 significantly in your implementation?

See Aditya's question. Tagged stream blocks operate on one packet at a
time, so it's limited.

MB



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Half-Duplex Relay

[David Halls]

Hi Johannes,

Thanks for your email. Have been reading through the link you sent me, just 
trying to relate the direct UHD stuff with the equivalent in gr-uhd code.

I am planning to implement some LDPC code that I wrote for another application. 
Have you tried implementing something similar?

Regards,

David

From: Johannes Demel [johannes.de...@ettus.com]
Sent: 29 January 2014 18:53
To: David Halls
Cc: Martin Braun; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

Hi David,

you could consider to tweak the latency [1] of your system between host and 
USRP. This way your relay is less dependent on that and you can reduce the gaps 
between packets if the host side signal processing can keep up.
If you increase the packet size of your OFDM system you might also consider to 
use channel coding, e.g. a convolutional code.

happy hacking
Johannes

[1] http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency


On Wed, Jan 29, 2014 at 10:11 AM, David Halls 
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Hi Martin, and all,

I am making good progress with the relay.

At the source, I transmit packets interspersed with 0's to create a silent 
period. This is achieved using vector_insert. Perhaps there are better ways, 
but it works well. Currently the gap is 20ms (2e4 samples at 1e6Ms/s) between 
tx'd packets from source.

At the relay I take the rx_time UHD tag, then in HPD I work out the actual time 
that each trigger is received (i.e. beginning of each packet) using 
nitems_read(0) with rx_time and sample_rate, I then decode, re-encode, and then 
add sob, eob, and a tx_time created by adding 10ms to the rx_time, so that it 
is transmitted half-way between the packets from the source.

This works but gives large gaps - each burst is (3+3+16)*80 = 1760 samples, a 
lot of time is wasted.

The decoding/encoding delay in the relay seems to vary between around 3000 and 
1 samples, so I can't reduce the timeslot length without some packets at 
the relay arriving at the USRP late 'L'.

I am not sure how to proceed. I can increase the packet length at the 
transmitter to fill the gap, but not sure if this will lengthen the relay 
decoding delay or not. Also with the OFDM_tx code, I get buffer errors with a 
payload longer than 96Bx2. i.e. 32 symbol payload.

Any thoughts?

David

From: 
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.orgmailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.orgmailto:toshiba-trel@gnu.org]
 on behalf of Martin Braun 
[martin.br...@ettus.commailto:martin.br...@ettus.com]
Sent: 14 January 2014 16:56

To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

On Tue, Jan 14, 2014 at 11:29:51AM +, David Halls wrote:
 Thanks Martin,

 Yes, I am using USRP N210. I aim to have separate code on S, R and D as you 
 suggest. I have built a 2 x 1 MISO system developing from your OFDM GRC code 
 - thanks :)

 I have added a number of new elements including 802.16e randomiser, random 
 vector source, SNR estimate, BER estimate and orthogonal headers... anyway I 
 digress.

 I am already using some tagging. I hope I can use the rx_time timestamp and 
 number of samples received to work out the time I want to begin and end 
 transmission at the relay. This, as Marcus comments, will be much more 
 complicated as the network topology grows. Currently I will assume just two 
 time slots and allow a generous amount of time for propagataion and 
 decoding/reencoding delay.

 I will then try to use 'set_command_time' to control when the relay txs.

 Do you feel this makes sense? I will let you know how I progress.

Sounds good. Tell us how you're coming along, and do ask for advice
if necessary.

MB

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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl



This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com

Re: [Discuss-gnuradio] Half-Duplex Relay

[David Halls]

Hi Martin, and all,

I am making good progress with the relay.

At the source, I transmit packets interspersed with 0's to create a silent 
period. This is achieved using vector_insert. Perhaps there are better ways, 
but it works well. Currently the gap is 20ms (2e4 samples at 1e6Ms/s) between 
tx'd packets from source.

At the relay I take the rx_time UHD tag, then in HPD I work out the actual time 
that each trigger is received (i.e. beginning of each packet) using 
nitems_read(0) with rx_time and sample_rate, I then decode, re-encode, and then 
add sob, eob, and a tx_time created by adding 10ms to the rx_time, so that it 
is transmitted half-way between the packets from the source.

This works but gives large gaps - each burst is (3+3+16)*80 = 1760 samples, a 
lot of time is wasted.

The decoding/encoding delay in the relay seems to vary between around 3000 and 
1 samples, so I can't reduce the timeslot length without some packets at 
the relay arriving at the USRP late 'L'.

I am not sure how to proceed. I can increase the packet length at the 
transmitter to fill the gap, but not sure if this will lengthen the relay 
decoding delay or not. Also with the OFDM_tx code, I get buffer errors with a 
payload longer than 96Bx2. i.e. 32 symbol payload.

Any thoughts?

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: 14 January 2014 16:56
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

On Tue, Jan 14, 2014 at 11:29:51AM +, David Halls wrote:
 Thanks Martin,

 Yes, I am using USRP N210. I aim to have separate code on S, R and D as you 
 suggest. I have built a 2 x 1 MISO system developing from your OFDM GRC code 
 - thanks :)

 I have added a number of new elements including 802.16e randomiser, random 
 vector source, SNR estimate, BER estimate and orthogonal headers... anyway I 
 digress.

 I am already using some tagging. I hope I can use the rx_time timestamp and 
 number of samples received to work out the time I want to begin and end 
 transmission at the relay. This, as Marcus comments, will be much more 
 complicated as the network topology grows. Currently I will assume just two 
 time slots and allow a generous amount of time for propagataion and 
 decoding/reencoding delay.

 I will then try to use 'set_command_time' to control when the relay txs.

 Do you feel this makes sense? I will let you know how I progress.

Sounds good. Tell us how you're coming along, and do ask for advice
if necessary.

MB

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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

attachment: Screenshot from 2014-01-29 18:08:36.png___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[David Halls]

Dear Martin,

I wondered, if you are working on the HPD, if it's possible to look into making 
a change when a header is received incorrectly, e.g. low SNR or sudden 
shadowing. I find that (although it no longer crashes with the recent update to 
adjust buffer size) it loses synchronisation and does not recover in later 
packets. I can't quite work out why...

Regards,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Aditya Dhananjay
Sent: 22 January 2014 15:02
To: Martin Braun
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when 
using random bit stream (variable trigger location)


Dear Martin,

Thanks for the ideas.



Two ideas:
- You could remove the sync block and sync your rx/tx paths with other
means (e.g. MIMO connector, it depends on your hardware). This makes the
sync influence independent of the noise.

Good idea, I will try it out once I get the cables.

- Reconsider if the phase rotation really makes your measurements
invalid. You'll have a phase rotation in any case (due to channel,
propagation time etc.). The timing-related phase offset is constant,
after all, and the phase difference between sub-carriers depends on the
sub-carrier distance, too. Perhaps it doesn't matter all that much?

That makes sense. I want to study the different phenomena that affect phase 
rotations in the channel. By eliminating the USRP hardware (by connecting the 
TX and RX blocks to each other through a channel model block), I can control 
the PDP of the simulated channel, for example.

Thank you for your inputs. This is very useful to me.

best regards,
aditya



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

[Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[David Halls]

Hi Martin,

Making good progress with the relay but on another topic, I find if I use a 
random data source (rather than the 1...range in the original example) the 
trigger signal arrives occasionally one or two samples earlier than expected.

Say we have 96B data this gives 768/48 = 16 data symbols. Adding 3 preamble 
gives 19×80 samples = 1520. Sometimes there are only 1519 or 1518 samples 
between triggers.

This means that in the HPD code, too many items are consumed by the processing 
of the previous packet and thus the next trigger = 1 item is consumed in error 
so it is never found.

A simple hack is to consume 'x' fewer samples in the HPD code I.e. In the line

consume_each (d_header_len * (d_items_per_symbol + d_gi));

And the equivalent in the payload case, we can append ' - 3'
A slightly more robust way would be to check where the next trigger occurs and 
remove the corresponding number of times.

Are you able to recreate this issue? I realise that the problem only occurs 
when using a different data source than the standard demo, so of course it's 
not a bug as such at all.

Many thanks,

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[David Halls]

sorry - I meant to say that adding the additional hack removed the rotation on 
the constellation eq'd by h2_est but not the rotation on the constellation eq'd 
by h1_est, thus there is still some timing issue. This can seen in the *.png

Aditya - am I to understand that you want to have perfect timing sync?

In my case I am happy to have a few samples offset, because the FDE can remove 
this problem, as long as the samples in the header where the channel taps are 
calculated are synchronized with those in the payload where the taps are 
applied.


From: David Halls
Sent: 21 January 2014 17:50
To: Martin Braun; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when 
using random bit stream (variable trigger location)

Thanks Martin and Aditya,

Yes Martin your recap is correct.

Indeed our solutions are hacks. I had an initial worry that not consuming all 
of the items would end up with some sort of back-log. I am not sure I can get 
my head around why this in fact doesn't cause a problem?! But it hasn't stopped 
me sleeping at night just yet.

BUT, as with all hacks, it has come back to bite me. The exact nature is *very* 
difficult to explain, but I have implemented a 2x1 MISO system, and this uses 
orthogonal headers, so in HPD it receives header from tx1, then header from tx2 
(rather than moving straight to payload), then receives (a superimposed tx1 + 
tx2) payload.

The hack caused some kind of timing issue and so rotation of the superimposed 
constellation was caused if I tried to equalize the superimposed constellation 
with h1 or h2.

(N.B. I realise (x1h1 + x2h2 + n)/h2 does not give x1 or x2; I am working on 
Wireless (PHY) Network Coding and the receiver will soon be a relay performing 
Hierarchical NC)

Anyway, adding another hack of:

case STATE_PAYLOAD:

  if (check_items_available(d_curr_payload_len, ninput_items, 
noutput_items, nread))
  {
   .blah blah
  }
  else
  {
// Bug-fix for rotation on EQ2
consume_each(VARIABLE_TRIGGER);
  }

where VARIABLE_TRIGGER = 3.

I can't expect anyone to solve my specific problem - but if a more elegant fix 
to the initial problem was possible, then this would most likely resolve my 
issue too.

Many thanks,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: 21 January 2014 17:26
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when 
using random bit stream (variable trigger location)

On 01/21/2014 05:55 PM, Aditya Dhananjay wrote:
 Hello David,

 I was facing the exact same issue, and the fix I use is identical to
 yours. I consume 4 symbols less than I need to, so the subsequent packet
 is not lost.

 Best,
 Aditya

 On Tue, Jan 21, 2014 at 11:14 AM, David Halls
 david.ha...@toshiba-trel.com mailto:david.ha...@toshiba-trel.com wrote:

 Hi Martin,

 Making good progress with the relay but on another topic, I find if
 I use a random data source (rather than the 1...range in the
 original example) the trigger signal arrives occasionally one or two
 samples earlier than expected.

Yes, I have seen this happen. To recap (please correct me if this is in
fact not exactly your problem):

Say the input signal looks like this:

1 1 1 1 1 1 1 2 2 2 2 2 2 2 2- items
^ ^  - triggers

...everything is fine. Now, the trigger might be early (because of noise
etc.):

1 1 1 1 1 1 1 2 2 2 2 2 2 2 2- items
^   ^- triggers

In this case, the trigger is consumed with the first packet, and the
second one can't be won't be detected.

Your solution will work, but you have to admit it's a hack. Who says my
payload is 3 or 4 symbols long? I'm currently working on the HPD, and
I'll figure out a way to get this in.
I guess not consuming the last symbol would be sufficient in most cases,
and since a payload must have at least one, this would be OK. For OFDM,
this must work since one OFDM symbol is longer than the detection timing
ambiguity.

MB


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



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton

Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[David Halls]

Ah, I see. You want to isolate the effect of the channel. I believe it will be 
difficult, if not impossible, to remove the slight jitter of the trigger, even 
in very high SNR - perhaps others can comment/help?

From: Aditya Dhananjay [adi...@cs.nyu.edu]
Sent: 21 January 2014 17:57
To: David Halls
Cc: Martin Braun; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when 
using random bit stream (variable trigger location)

Aditya - am I to understand that you want to have perfect timing sync?

Correct. This is because I want to study how the channel changes across OFDM 
subcarriers (caused due to multi-path). Having rotations in the channel across 
subcarriers caused by trigger timing offsets is what I want to eliminate.

best,
aditya




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[David Halls]

...having said that, I never saw the trigger jitter until I started using a 
random data source rather than 'range(packet_len)', do you get jitter in this 
case?

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of 
David Halls [david.ha...@toshiba-trel.com]
Sent: 21 January 2014 18:03
To: Aditya Dhananjay
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when 
using random bit stream (variable trigger location)

Ah, I see. You want to isolate the effect of the channel. I believe it will be 
difficult, if not impossible, to remove the slight jitter of the trigger, even 
in very high SNR - perhaps others can comment/help?

From: Aditya Dhananjay [adi...@cs.nyu.edu]
Sent: 21 January 2014 17:57
To: David Halls
Cc: Martin Braun; discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when 
using random bit stream (variable trigger location)

Aditya - am I to understand that you want to have perfect timing sync?

Correct. This is because I want to study how the channel changes across OFDM 
subcarriers (caused due to multi-path). Having rotations in the channel across 
subcarriers caused by trigger timing offsets is what I want to eliminate.

best,
aditya




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trlhttp://www.toshiba.eu/research/trl



This email has been scanned for email related threats and delivered safely by 
Mimecast.
For more information please visit http://www.mimecast.com




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Half-Duplex Relay

[David Halls]

Thanks Martin,

Yes, I am using USRP N210. I aim to have separate code on S, R and D as you 
suggest. I have built a 2 x 1 MISO system developing from your OFDM GRC code - 
thanks :)

I have added a number of new elements including 802.16e randomiser, random 
vector source, SNR estimate, BER estimate and orthogonal headers... anyway I 
digress.

I am already using some tagging. I hope I can use the rx_time timestamp and 
number of samples received to work out the time I want to begin and end 
transmission at the relay. This, as Marcus comments, will be much more 
complicated as the network topology grows. Currently I will assume just two 
time slots and allow a generous amount of time for propagataion and 
decoding/reencoding delay.

I will then try to use 'set_command_time' to control when the relay txs.

Do you feel this makes sense? I will let you know how I progress.

Regards,

David


-Original Message-
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Martin Braun
Sent: 10 January 2014 21:16
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

On 01/10/2014 03:06 PM, David Halls wrote:
 Hi all,

 Hopefully a very easy question! How do I implement a relay such that
 it will not begin transmitting until it has received a whole 'burst'
 of data. As there will be a direct path from source to destination, I
 don't want the relay to start transmitting until the source has
 finished transmitting. Thus I want to implement a TDMA restriction
 where source transmits in time slot 1, then transmits nothing during
 time slot 2 (easy), then I want the relay to listen only in time slot
 1 and then not begin transmitting until time slot 2.

 I was wondering if I should use some kind of tagging?

Most likely, yes. Although I know one student at CEL wrote a relay before tags 
were around (I doubt the code is still available...).

Not transmitting is not as trivial as it sounds :) I'm assuming you're using 
UHD devices (USRPs). In this case, have a look at the tx_sob and tx_eob tags 
and what they do in the UHD sink (they shut down the transmitter and fire it up 
again, so your USRP doesn't expect samples when you're in an idle slot).

There's a couple of things to consider. If you're doing some relay-specific 
experiment, you probably have dedicated code for source, relay and destination.

The source will only send out a burst (use the mentioned tags to mark
that) and wait. Alternatively, you can also send out zeros between tags.

The destination node is even simpler -- you rx all the time and pass packets to 
an upper layer for combining. Nothing special here.
Same with the relay, although you'll need the tags again for retransmission. 
Also, you should keep timing in mind, which can sometimes be a bit random in 
GNU Radio. If you're expecting decoding within a certain time after decoding 
(or just reception if you do AaF).

Have a look at the manual page for tagged streams and PDUs as well as the 
examples for packet-based transceivers (e.g. the OFDM code).
If you need anything more specific, just ask here!

MB



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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

[Discuss-gnuradio] Half-Duplex Relay

[David Halls]

Hi all,

Hopefully a very easy question! How do I implement a relay such that it will 
not begin transmitting until it has received a whole 'burst' of data. As there 
will be a direct path from source to destination, I don't want the relay to 
start transmitting until the source has finished transmitting. Thus I want to 
implement a TDMA restriction where source transmits in time slot 1, then 
transmits nothing during time slot 2 (easy), then I want the relay to listen 
only in time slot 1 and then not begin transmitting until time slot 2.

I was wondering if I should use some kind of tagging?

Many thanks!

David

---
David Halls Ph.D.
Research Engineer
Toshiba Research Europe Limited
32 Queen Square, Bristol, BS1 4ND, UK
Tel: +44 (0) 117 906 0790




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


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

[Discuss-gnuradio] Strange Received Signal for 2x1 MISO OFDM (sometimes!)

[David Halls]

Hi,

I am trying to transmit 2x1 MISO OFDM. The two transmit USRPs are connected by 
MIMO cable, and the USRP sink section of the .py file is:

self.uhd_usrp_sink_0_0_0 = uhd.usrp_sink(
device_addr=addr0=192.168.10.2,addr1=192.168.10.7,
stream_args=uhd.stream_args(
cpu_format=fc32,
otw_format=sc16,
channels=range(2),
),
)
self.uhd_usrp_sink_0_0_0.set_clock_source(mimo, 1)
self.uhd_usrp_sink_0_0_0.set_time_source(mimo, 1)
self.uhd_usrp_sink_0_0_0.set_samp_rate(samp_rate)
self.uhd_usrp_sink_0_0_0.set_center_freq(uhd.tune_request(center_freq, 
rf_freq=(center_freq + 
lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
self.uhd_usrp_sink_0_0_0.set_gain(tx_gain, 0)
self.uhd_usrp_sink_0_0_0.set_antenna(tx_ant, 0)
self.uhd_usrp_sink_0_0_0.set_center_freq(uhd.tune_request(center_freq, 
rf_freq=(center_freq + 
lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 1)
self.uhd_usrp_sink_0_0_0.set_gain(tx_gain, 1)
self.uhd_usrp_sink_0_0_0.set_antenna(tx_ant, 1)

At the receiver I sometimes get a very strange response - see attached picture.

If I use an external PPS signal, and set sync to 'Unknown PPS', the occurrence 
of this strange signal - where some parts of the signal seem to just be a noisy 
sinusoid, is *dramatically* reduced - but not avoided always. Using 'PC Clock' 
does not improve the situation.

Is there something obviously wrong with the way I am trying to transmit over 
two USRPs simultaneously? I am not clearly why the problem is intermittent. All 
3 USRPs are connected two one PC, they are N210s with XCVR2450s, tx gain = 0, 
rx gain = 0, centre freq = 2.4GHz, samp rate = 1M.

Regards,

David





NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl



Scanned by MailDefender - managed email security from intY - 
www.maildefender.netattachment: 2x1_TD_RX.png___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Minimum amount of data to trigger WX GUI Scope Sink? and Ch 1 vs. Ch2 with Ch 3 vs. Ch 4

[David Halls]

Hi,

I am using WX GUI Scope Sink, and I have set the sample rate = 1M, same as the 
USRP. It seems that a minimum number of data points are required before 
anything appears on the plot - is that correct, and how can it be adjusted?

Also, I am looking at constellations, using the XY mode to show real and 
imaginary. It is possible to have multiple inputs, but is it possible to view 
multiple 'series' in XY mode?

I seem to be only able to choose Ch X vs Ch Y, e.g. Ch 1 vs. Ch 2 ( Re(in1) vs. 
Im(in1) ) or Ch 1 vs. Ch 4 (Re(in1) vs. Im(in2)). I would like to see Ch 1 vs. 
Ch 2 and Ch 3 vs Ch 4 simultaneously?

Thanks in advance! :)

David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl



Scanned by MailDefender - managed email security from intY - 
www.maildefender.net___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio