Re: [Discuss-gnuradio] GRC Reacting Slowly

[Richard Bell]

Andreas,

No I'm not using an embedded system to develop on. I'm using an HP Core i7
laptop with 16Gig of RAM, Ubuntu 14.04 with GNU Radio 3.7.8.

The delay also occurs everytime I want to make a change to a blocks
paramters. I have to wait >2 seconds for the blocks paramter window to open
and then another >2 seconds for it to close. It all adds up. If the reason
is what Murray said, I would agree it would be nice to have the option of
checking only when you click the play button or something similar.

v/r,
Rich

On Wed, May 27, 2015 at 12:08 PM, Murray Thomson  wrote:

> I had this problem for a while when using a large number of blocks. The
> cause, I think, is that the companion checks if the flowgraph is correct
> after every change. You will only be able to compile if it's correct
> (blocks are connected, variable names exist...).
> If this is really the reason, It would be nice to have an icon that, when
> unselected disables this check and when selected it checks the flowgraph
> and enables the compile and run options if everything is ok.
>
> Regards,
> Murray
>
> 2015-05-27 16:08 GMT+01:00 Andreas Ladanyi :
>
>>  Hi rich,
>>
>> on which hardware platform are you working ? Is this a PC or embedded
>> device ?
>>
>> cheers,
>> Andy
>>
>>
>> Am 27.05.2015 um 01:09 schrieb Richard Bell:
>>
>> GNU Radio 3.7.8, Ubuntu 14.04
>>
>> I have an admittedly large number of blocks in my current flow graph
>> because I'm in the middle of some hardcore debugging. Every time I select a
>> block to enable/disable it, there is a > 2 second delay between the block
>> becoming enabled/disabled and hitting the E/D keys. The same is true when
>> connecting new ports together with wires. I've been working with this for a
>> while, but it's annoying enough now that I'd like to know if there is a
>> workaround to this or simply understand the cause of it?
>>
>>  v/r,
>>  Rich
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Is file sink block resetting USRP?

[Marcus D. Leech]

On 05/27/2015 05:52 PM, Carl Olsson wrote:

Hi all,

I use a file sink block in my flow graph to record samples from a USRP 
N210. I start the flow graph and then after some time starts to record 
using the file sink block by switching it on using a selector block.


My question is, when the file sink is activated, is the flow graph in 
any way restarted?


I have attached a plot of the real part of the samples I recorded. I 
see strange behavior in the beginning as I would expect if I instantly 
started to record when the flow graph is started (due to the time it 
takes for the radio to tune in).


The reason to why I am asking is that I suspect that the phase of the 
signal is changed when I start to record, and maybe this could explain 
why.


Best regards,

Carl


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
My recollection is that the selector blocks stop the graph, reconfigure 
it, and start it again, which means source streams probably get restarted.


When I've need to do this in the past, I just tie the filename to a 
variable that is controlled by my "start recording" button--when I'm not 
recording, the file sink is set to "/dev/null", and when I *am* 
recording, it's set to the target file.


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

Re: [Discuss-gnuradio] Is it possible to create a block from other blocks?

[Carl Olsson]

Thank you for all the answers!

I will try the different solutions.

Best regards,

Carl

On 27 May 2015 at 00:42, Douglas Geiger 
wrote:

> Scrolling back I see I missed a little bit of the earlier discussion - so
> to elaborate a little:
>
> Simple 'merging of blocks' (i.e. I have several blocks connected together
> in a particular way, and want to wrap that up to re-use in other places) is
> what GNURadio refers to as a hierarchical block. The blocks are being
> re-used (to avoid duplication of code, which all programmers learn to hate
> the second time they copy and paste code and then have to go back and fix
> bugs in both places), but not being modified: and their connections are
> static.
>
> If you want to use the functionality of several blocks and not have a
> static flowgraph (e.g. I want to access particular functions of particular
> blocks, but in some dynamic fashion that is not easily rendered as a static
> flowgraph), then you would want to do as Richard suggests: create your own
> out-of-tree module with custom blocks. For what I would consider to be any
> advanced functionality (i.e. application-specific function that is more
> than just a custom flowgraph) this is going to be required. That said -
> there is a fairly large set of things that you can do within the static
> flowgraph framework - and you can certainly spend a long time developing
> applications entirely within GRC before you need to go down the path of
> creating custom blocks. Since the amount of things you will need to learn
> at that point greatly increases, I suggest holding off until you know for
> sure this is what you need.
>
>  Doug
>
> On Tue, May 26, 2015 at 6:33 PM, Douglas Geiger <
> doug.gei...@bioradiation.net> wrote:
>
>> GRC has had the ability to create a hierarchical blocks for a little
>> while (I forget which release added that): if you select multiple blocks
>> you can right-click, and select more to find the 'Create Hier' option. This
>> is described on the wiki at:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Hierarchical-Blocks
>>
>> It is just creating another XML wrapper around the blocks to create the
>> hier block (with pads to allow input/output). I think usability wise it is
>> essentially equivalent to the Simulink 'merge blocks' function.
>>
>>  Doug
>>
>> On Tue, May 26, 2015 at 6:20 PM, Richard Bell 
>> wrote:
>>
>>> You can't do it the way you asked specifically. The GUI functionality of
>>> GNU Radio compared to Simulink is very different. The hierarchical block
>>> mentioned by Chris above is a way of putting several blocks together using
>>> code to do the wrapping. You need to create a new block using gr_modtool
>>> and wrap all the subblocks into this top block. It takes a lot more
>>> experience to do then the few simulink clicks. If you're are not afraid of
>>> that and plan on using gnuradio long term, it's worth learning how to do.
>>>
>>> Rich
>>>
>>> On Tue, May 26, 2015 at 3:14 PM, Chris Kuethe 
>>> wrote:
>>>
 Yes.
 https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Hierarchical-Blocks

 You can also increase the canvas size in the top block options.

 On Tue, May 26, 2015 at 2:46 PM, Carl Olsson 
 wrote:
 > Hi all,
 >
 > I wonder if there is a similar feature in grc as in Simulink where
 one can
 > create a block from other blocks? (Select the blocks, right click and
 merge
 > into one) Or how do you do more complicated flow graphs containing
 many many
 > blocks? I am a beginner and I already have a hard time fitting in all
 the
 > blocks in the window of grc.
 >
 > Best regards,
 >
 > Carl
 >
 > ___
 > Discuss-gnuradio mailing list
 > Discuss-gnuradio@gnu.org
 > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 >



 --
 GDB has a 'break' feature; why doesn't it have 'fix' too?

 ___
 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
>>>
>>>
>>
>>
>> --
>> Doug Geiger
>> doug.gei...@bioradiation.net
>>
>
>
>
> --
> Doug Geiger
> doug.gei...@bioradiation.net
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Reacting Slowly

[Murray Thomson]

I had this problem for a while when using a large number of blocks. The
cause, I think, is that the companion checks if the flowgraph is correct
after every change. You will only be able to compile if it's correct
(blocks are connected, variable names exist...).
If this is really the reason, It would be nice to have an icon that, when
unselected disables this check and when selected it checks the flowgraph
and enables the compile and run options if everything is ok.

Regards,
Murray

2015-05-27 16:08 GMT+01:00 Andreas Ladanyi :

>  Hi rich,
>
> on which hardware platform are you working ? Is this a PC or embedded
> device ?
>
> cheers,
> Andy
>
>
> Am 27.05.2015 um 01:09 schrieb Richard Bell:
>
> GNU Radio 3.7.8, Ubuntu 14.04
>
> I have an admittedly large number of blocks in my current flow graph
> because I'm in the middle of some hardcore debugging. Every time I select a
> block to enable/disable it, there is a > 2 second delay between the block
> becoming enabled/disabled and hitting the E/D keys. The same is true when
> connecting new ports together with wires. I've been working with this for a
> while, but it's annoying enough now that I'd like to know if there is a
> workaround to this or simply understand the cause of it?
>
>  v/r,
>  Rich
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Integration of python's time.time() and work() calls

[Anil Kumar Yerrapragada]

Hi

I'm writing a custom block in python. The application goes like this:

I specify the minimum number of samples I need by using the forecast
function. This ensures that I have that many samples available in the
in-buffer of the block every time work is called. Once I have as many
samples as I need, I slide a window over the samples. In each window slide
I measure signal power. If power less than a pre-set threshold (I assume
only noise is being received), do nothing. Keep sliding.

The moment power exceeds the threshold for the first time, I have to start
measuring time. I need to see how many windows I'm able to slide in the
next let's say, 10 milliseconds (because I expect that the actual signal
transmission is to last for that long). As a hypothetical example, let's
say by 7 milliseconds I've reached the end of the buffer. If my
understanding is correct, once I reach the end, the next set of samples
come in (as per forecast) and work is called again. My question is how do I
make this next work call aware of this concept of time and that 3
milliseconds were unaccounted for in the last call?


Or is there a way to make sure that the in-buffer gets updated multiple
times within the same work call?


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

Re: [Discuss-gnuradio] Choose thread

[marco Ribero]

Il giorno mer 27 mag 2015 alle ore 16:29 Marcus Müller <
marcus.muel...@ettus.com> ha scritto:

> Yes. The Thread-per-Block-scheduler gets its name from the fact that
> every block gets its own thread.
> You should really use it -- using STS will probably kill the performance
> you can gain by accelerating stuff on a GPU, because nearly no one uses
> single-core CPUs any more, and to my knowledge, only the FFT blocks are
> internally multithreaded.
>
I hope to bring on CUDA the more time-consuming blocks..for the moment FIR
and IIR filter, and FFT..

> I'm a bit surprised that CUDA requires you to run everything in one
> thread -- doesn't using cudaSetDevice in every thread (==in every
> block's work() method on the first call) suffice?
> NVidia claims CUDA is thread safe, i.e. worst case your multi-threading
> performance is as bad as doing everything in a single thread.
> >
> > I'd like that other blocks(not related with CUDA) can run in parallel
> > threads..
> That's really awesome because it scales so well :)
>
> Best regards,
> Marcus
>
It's my fault: I've reason, from CUDA 4.0 the same GPU can be shared
between different threads/processes..I got formation from older books :)
Thank you!!

Now I need to change a litte my code..I was not so concerned about this
capability because my blocks just launch asynchronously kernels/memcpy and
exit..

It seems that with multithread I'm able to reduce "pause time" between
execution of kernels of differents blocks from 1-3microseconds to
0.3microseconds..not bad!!(each block waits the previous with streams
attached to events).
The drawback is that each kernel execution must be bigger,because otherwise
its execution wouldn't hide the bigger overhead due to "reasignment of
device" to a different thread.

Thanks for your replies,
marco
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Buffer Overflow Debug

[Richard Bell]

Martin,

I'll update you on this in a new thread soon. We had been running into the age 
old problem of plugging one hole and having two more leaks spring up. We are 
finally onto something that seems to be fixing everything. It's a simple code 
change in HPD. 

Rich

Sent from my iPhone

> On May 27, 2015, at 5:45 AM, Martin Braun  wrote:
> 
> Hey Richard,
> 
> I'm going to need some time, peace and quiet to get to the bottom of
> this. Which means not in the very near future :) But I'm very interested
> in getting this to work. Can you post some failing codes/OOTs somewhere
> for me to start testing?
> 
> M
> 
>> On 22.05.2015 15:22, Richard Bell wrote:
>> Martin et. al.,
>> 
>> I implemented my own block that produces a trigger signal when a
>> specific tag is encountered, and I feed this into the detect port of the
>> HPD block. This is an attempt to overcome the tag trigger issues we've
>> been having in this email chain. The trigger_tag block simply outputs
>> zeros until a specified tag_key is found, at which point it outputs a 1
>> on that sample and then continues outputting zeros. It has the same
>> trigger behavior as the Schmidt Cox block used to create the detect
>> signal in the OFDM example.
>> 
>> This has resolved the HPD block freezing issue, however, a new issue has
>> arisen. Now the block will output the correct header and payload for a
>> little while, and then randomly start passing the wrong header portion
>> through, even though the detect signal is still on the correct trigger
>> point at the input to the HPD block. I confirmed this by comparing the
>> HPD port0 input with the HPD port1 input, confirming the detect peeks
>> correspond exactly with the port0 tags that signify a header start. Even
>> while the HPD block allows the wrong header portion through, the detect
>> signal is aligned perfectly with the header start at input0.
>> 
>> If you wouldn't mind confirming my HPD block settings, I will detail
>> them here. I don't think this could be the issue, because I expect the
>> block would never work correctly if they were off, but better to be
>> safe. The input0 type is complex unpacked data. My header is 32 bits
>> long packed. I correspondingly set the following:
>> 
>> *Header Length (Symbols): 4
>> Items per Symbol: 8
>> *
>> *Guard Interval (items): 0
>> *
>> *Output Format: Items
>> *
>> *IO Type: Complex
>> *
>> *Sampling Rate: *
>> 
>> Now, to add on to this confusing block, I tried using the following
>> settings and it worked better than the above settings. However, looking
>> at the source code, it makes no sense to me why it should work at all.
>> This is because the payload size is calculated by using the
>> packet_length read off the message passed in multiplied by the
>> items_per_symbol variable. This would correspond to a huge payload
>> (128*32 in my case, instead of 128*8), yet it works.
>> 
>> *Header Length (Symbols): 1
>> Items per Symbol: 32*
>> 
>> Using the other possible combination that produces the correct header
>> length when multiplied together, it does not work for any length of time.
>> 
>> *Header Length (Symbols): 2
>> Items per Symbol: 16*
>> 
>> I'm starting to think there is a major bug in the HPD block when used
>> without the 'Output Format Symbols' mode. I say this because this is the
>> last difference between the OFDM example, which seems to work fine, and
>> my own. At this point I'm stuck code diving into the HPD block to see if
>> I can figure out what's going on.
>> 
>> v/r,
>> Rich
>> 
>> 
>> 
>> On Wed, May 20, 2015 at 6:27 PM, Richard Bell > > wrote:
>> 
>>Yes I will file a bug.
>> 
>>We put a tag_debug block right before the HPD input. The tag debug
>>stdout statements continue, while the get_tags_in_range function of
>>the HPD block returns none.
>> 
>>We will continue debugging this to see if we can learn something
>>more concrete. The time it takes the flow graph to generate this
>>error is very variable. From hours to seconds.
>> 
>>If there is other useful debug info you'd like us to generate please
>>let me know and we will.
>> 
>>V/r,
>>Rich
>> 
 On May 20, 2015, at 6:05 PM, Martin Braun >>> wrote:
>>> 
>>> This is interesting, and kinda serious. Also, we've had reports that
>>> tags go missing in the past, but it's something that's hard to verify.
>>> 
>>> How did you confirm the input stream is correctly tagged? If
>>> get_tags_in_range isn't finding tags that it should, that is most
>>likely
>>> the issue you're seeing here.
>>> 
>>> Can you please file a bug report on the issue tracker, with as much
>>> detail as you can provide?
>>> 
>>> On a side note, you might be able to use the trigger input instead of
>>> the tags, but that doesn't solve this problem.
>>> 
>>> Thanks,
>>> Martin
>>> 
 On 20.05.2015 11:02, Richard Bell wrote:
 Hi Martin,
 
 Sorry for the delay in response. We 

Re: [Discuss-gnuradio] GRC Reacting Slowly

[Andreas Ladanyi]

Hi rich,

on which hardware platform are you working ? Is this a PC or embedded 
device ?


cheers,
Andy

Am 27.05.2015 um 01:09 schrieb Richard Bell:

GNU Radio 3.7.8, Ubuntu 14.04

I have an admittedly large number of blocks in my current flow graph 
because I'm in the middle of some hardcore debugging. Every time I 
select a block to enable/disable it, there is a > 2 second delay 
between the block becoming enabled/disabled and hitting the E/D keys. 
The same is true when connecting new ports together with wires. I've 
been working with this for a while, but it's annoying enough now that 
I'd like to know if there is a workaround to this or simply understand 
the cause of it?


v/r,
Rich


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


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

Re: [Discuss-gnuradio] Choose thread

[Marcus Müller]

Dear Marco,
> I need that different blocks run under the same thread(because CUDA
> require to make everything inside a single thread..each thread is
> associated to a different GPGPU)..so,without the usage of STS
> scheduler,is not possible to run different blocks with same thread?
Yes. The Thread-per-Block-scheduler gets its name from the fact that
every block gets its own thread.
You should really use it -- using STS will probably kill the performance
you can gain by accelerating stuff on a GPU, because nearly no one uses
single-core CPUs any more, and to my knowledge, only the FFT blocks are
internally multithreaded.
I'm a bit surprised that CUDA requires you to run everything in one
thread -- doesn't using cudaSetDevice in every thread (==in every
block's work() method on the first call) suffice?
NVidia claims CUDA is thread safe, i.e. worst case your multi-threading
performance is as bad as doing everything in a single thread.
>
> I'd like that other blocks(not related with CUDA) can run in parallel
> threads..
That's really awesome because it scales so well :)

Best regards,
Marcus


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

Re: [Discuss-gnuradio] Choose thread

[marco Ribero]

Il giorno dom 24 mag 2015 alle ore 19:52 Tom Rondeau  ha
scritto:

> Don't use the STS scheduler. It is, after all, the Single-Threaded
> Scheduler. And setting the thread affinity under that condition is a nop.
> That will only work with the default TPB scheduler.
>
> Tom
>
> I need that different blocks run under the same thread(because CUDA
require to make everything inside a single thread..each thread is
associated to a different GPGPU)..so,without the usage of STS scheduler,is
not possible to run different blocks with same thread?

I'd like that other blocks(not related with CUDA) can run in parallel
threads..

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

Re: [Discuss-gnuradio] Buffer Overflow Debug

[Martin Braun]

Hey Richard,

I'm going to need some time, peace and quiet to get to the bottom of
this. Which means not in the very near future :) But I'm very interested
in getting this to work. Can you post some failing codes/OOTs somewhere
for me to start testing?

M

On 22.05.2015 15:22, Richard Bell wrote:
> Martin et. al.,
> 
> I implemented my own block that produces a trigger signal when a
> specific tag is encountered, and I feed this into the detect port of the
> HPD block. This is an attempt to overcome the tag trigger issues we've
> been having in this email chain. The trigger_tag block simply outputs
> zeros until a specified tag_key is found, at which point it outputs a 1
> on that sample and then continues outputting zeros. It has the same
> trigger behavior as the Schmidt Cox block used to create the detect
> signal in the OFDM example.
> 
> This has resolved the HPD block freezing issue, however, a new issue has
> arisen. Now the block will output the correct header and payload for a
> little while, and then randomly start passing the wrong header portion
> through, even though the detect signal is still on the correct trigger
> point at the input to the HPD block. I confirmed this by comparing the
> HPD port0 input with the HPD port1 input, confirming the detect peeks
> correspond exactly with the port0 tags that signify a header start. Even
> while the HPD block allows the wrong header portion through, the detect
> signal is aligned perfectly with the header start at input0.
> 
> If you wouldn't mind confirming my HPD block settings, I will detail
> them here. I don't think this could be the issue, because I expect the
> block would never work correctly if they were off, but better to be
> safe. The input0 type is complex unpacked data. My header is 32 bits
> long packed. I correspondingly set the following:
> 
> *Header Length (Symbols): 4
> Items per Symbol: 8
> *
> *Guard Interval (items): 0
> *
> *Output Format: Items
> *
> *IO Type: Complex
> *
> *Sampling Rate: *
> 
> Now, to add on to this confusing block, I tried using the following
> settings and it worked better than the above settings. However, looking
> at the source code, it makes no sense to me why it should work at all.
> This is because the payload size is calculated by using the
> packet_length read off the message passed in multiplied by the
> items_per_symbol variable. This would correspond to a huge payload
> (128*32 in my case, instead of 128*8), yet it works.
> 
> *Header Length (Symbols): 1
> Items per Symbol: 32*
> 
> Using the other possible combination that produces the correct header
> length when multiplied together, it does not work for any length of time.
> 
> *Header Length (Symbols): 2
> Items per Symbol: 16*
> 
> I'm starting to think there is a major bug in the HPD block when used
> without the 'Output Format Symbols' mode. I say this because this is the
> last difference between the OFDM example, which seems to work fine, and
> my own. At this point I'm stuck code diving into the HPD block to see if
> I can figure out what's going on.
> 
> v/r,
> Rich
> 
> 
> 
> On Wed, May 20, 2015 at 6:27 PM, Richard Bell  > wrote:
> 
> Yes I will file a bug.
> 
> We put a tag_debug block right before the HPD input. The tag debug
> stdout statements continue, while the get_tags_in_range function of
> the HPD block returns none.
> 
> We will continue debugging this to see if we can learn something
> more concrete. The time it takes the flow graph to generate this
> error is very variable. From hours to seconds.
> 
> If there is other useful debug info you'd like us to generate please
> let me know and we will.
> 
> V/r,
> Rich
> 
> > On May 20, 2015, at 6:05 PM, Martin Braun  > wrote:
> >
> > This is interesting, and kinda serious. Also, we've had reports that
> > tags go missing in the past, but it's something that's hard to verify.
> >
> > How did you confirm the input stream is correctly tagged? If
> > get_tags_in_range isn't finding tags that it should, that is most
> likely
> > the issue you're seeing here.
> >
> > Can you please file a bug report on the issue tracker, with as much
> > detail as you can provide?
> >
> > On a side note, you might be able to use the trigger input instead of
> > the tags, but that doesn't solve this problem.
> >
> > Thanks,
> > Martin
> >
> >> On 20.05.2015 11:02, Richard Bell wrote:
> >> Hi Martin,
> >>
> >> Sorry for the delay in response. We have been able to put some
> time into
> >> debugging this issue and here is what we've found:
> >>
> >> 1) We have confirmed that the input stream to the HPD block is
> correctly
> >> tagged when the block freezes. The tags we set as "trigger tag"
> in the
> >> block are on the input stream.
> >>
> >> 2) At some point