Re: [Discuss-gnuradio] Constant carrier digital transmission

[Ed Criscuolo]

On 8/16/16 11:28 PM, Inspire Me wrote:

Hi Ed

Much appreciated. You mentioned latency due to queued flags. This has
potential to cause us issues. I was wondering if it is possible to build
a block as a sort of switch that takes input from the standard HDLC
Framer but executues continuously, ie once every symbol period T=
n*(1/(9600*4), it would check to see if any items are in the input
buffer and if not push nFlags out (n being small), boost sleep for on
n*symbol period and repeat. I know this would be highly inefficient but
given it will be a very basic block it would only execute for a fraction
of the symbol time. The other option was to have a seperate thread in
the block for sending the flags which runs independent of the Work
function and use a semaphore to enable / disable the sending of flags..
Your thoughts and insight would be valuable.


Again, I repeat that GnuRadio blocks are timing agnostic.  You cannot
"pace" the bitstream in real-time by the use of "sleeps".

You need to write a block that has NO bitstream inputs, and one
bitstream output. This is known as a "source" block. In addition
it should have a message port for receiving HDLC frames.  As in
the example I showed you, this new block should check the message
port for an HDLC frame, bitstuff it into the output bitstream, and
repeat this until either the message port is empty or the output
buffer is full.  If the message port is empty on the initial entry
to work, output a single FLAG worth of bits and exit, returning a
value of 8.


Q.I thought I read that the schedular only schedules work function when
there is input data to process. In other words if no input is available
then the work function would not be scheduled. Is this correct ? If not
where can I find more information on the scheduler. I have read material
available online including (
https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee20e4b09162d0863578/1380223973117/gr_scheduler_overview.pdf
)


The scheduler will schedule a block to run if there is input available
AND the output buffer is available.  That is, all of the immediately
downstream blocks have indicated that they have consumed the data.
This is called backpressure.  In the case of a source block, there
are no inputs, and the block is run whenever the output buffer space is
available.


Once again thank you for spending time helping.


No problem.  I believe you said you're doing a CubeSat application?
On small satellites, often the best approach to this problem is to
use an HDLC framer chip, which does all this for you and produces
a simple bitstream with flags and frames all in their proper places.
This bitstream is then straightforward to handle and send to a modulator.

One last note.  Keep the discussion on-list so others may benefit
(do a "Reply All" instead of a "Reply", otherwise it just comes to me).

@(^.^)@  Ed



Kind Regards
Frank

On 17 August 2016 at 11:59, Ed Criscuolo > wrote:

In a GnuRadio block that is derived from a "sync" block, the number of
input and output items are the same, so the work function is supplied
with a single value called "nitems".  The normal control flow of a
typical work function uses a loop that iterates over nitems, taking
one item from the input(s) buffer(s) and producing one item into the
output buffer. This process repeats until all input items are consumed
and all output buffer item spaces are full.  The work function then
returns a value of "nitems" to indicate to the scheduler how many items
were consumed and produced.

But it is perfectly legal for the loop in the work function to
terminate early, in which case it should return the number of items
_actually_ processed.  The scheduler will take care of keeping track
of the partial buffers and no data will be lost.  But performance
will be reduced.

GnuRadio blocks are timing agnostic.  They run as fast as they can,
and process an entire buffer's worth of items (typically 64K items)
per call to the work function.  This is done to improve throughput.
Timing only happens when your bitstream meets up with a hardware
device, like a USRP. But as long as the _average_ throughput is
fast enough to keep up with the hardware, everything is fine.
The amount of CPU processing "headroom" determines how far you can
degrade a block's average throughput without creating underruns.

This level of understanding is fundamental to writing any GnuRadio
blocks, so you really should take the time to play with it and get
to know it.

Here is a snippet of VERY OLD code for example only. It that always
runs "nitems" times. When idle (ie - no hdlc packets available), it
produces 64k bits (8k of flags) on every invocation! This results in
a large latency when a packet finally does come along.
It should be modified to break the loop on the 

Re: [Discuss-gnuradio] Constant carrier digital transmission

[Ed Criscuolo]

In a GnuRadio block that is derived from a "sync" block, the number of
input and output items are the same, so the work function is supplied
with a single value called "nitems".  The normal control flow of a
typical work function uses a loop that iterates over nitems, taking
one item from the input(s) buffer(s) and producing one item into the
output buffer. This process repeats until all input items are consumed
and all output buffer item spaces are full.  The work function then
returns a value of "nitems" to indicate to the scheduler how many items
were consumed and produced.

But it is perfectly legal for the loop in the work function to terminate 
early, in which case it should return the number of items

_actually_ processed.  The scheduler will take care of keeping track
of the partial buffers and no data will be lost.  But performance
will be reduced.

GnuRadio blocks are timing agnostic.  They run as fast as they can,
and process an entire buffer's worth of items (typically 64K items)
per call to the work function.  This is done to improve throughput.
Timing only happens when your bitstream meets up with a hardware
device, like a USRP. But as long as the _average_ throughput is
fast enough to keep up with the hardware, everything is fine.
The amount of CPU processing "headroom" determines how far you can
degrade a block's average throughput without creating underruns.

This level of understanding is fundamental to writing any GnuRadio
blocks, so you really should take the time to play with it and get
to know it.

Here is a snippet of VERY OLD code for example only. It that always
runs "nitems" times. When idle (ie - no hdlc packets available), it
produces 64k bits (8k of flags) on every invocation! This results in a 
large latency when a packet finally does come along.

It should be modified to break the loop on the second fifo empty
test and return "i" instead of "nitems"

int
sc_hdlc_router_source_b::work (int   noutput_items,
   gr_vector_const_void_star _items,
   gr_vector_void_star   _items)
{
  unsigned char * outbuf = (unsigned char *) output_items[0];
  int i;

  // Loop until the requested number of output stream bytes have been 
generated

  for(i=0; i> wrote:

Hi Frank,

I'm the author of the GMSK Spacecraft Groundstation project you
referenced.  Been on vacation for the last 2 weeks without internet,
so I'm just seeing this.

All in all, Marcus is giving you good advice.  At the time I wrote
it, there were no tags or messages, so everything related to
PDU-like behavior had to be implemented in a single  C++ block. Now,
packets can come in as PDUs, and get converted into a bitstream in a
single, much simpler block.

As for the issue of putting HDLC flag octets out back-to-back as the
"idle" pattern between frames, I had tried two different solutions,
one of which Marcus touched upon.

First approach was to simply reduce the buffer size of all blocks by
recompiling GnuRadio with the appropriate global constant reset to a
smaller value.  This has significant impact on overall performance,
but because our data rate was modest (only a few hundred Kbits/sec)
and we had some wicked fast hardware (for the times!) we were able
to get this to work, reducing the added latency of outbound packets
from over ten seconds to only a few seconds. This was OK for our
particular requirements, but not for a general purpose system.  It
was an easy but VERY brute-force solution.

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Marcus Müller]

You could try by creating a symbolic link to /dev/null somewhere you can
create arbitrary files; eg.

ln -s /dev/null /tmp/nirvana

and use that instead of /dev/null


On 16.08.2016 23:40, Derek Kozel wrote:
> Hello Michael,
>
> Unfortunately we've reached past my depth in the file sinks and tags.
> Hopefully someone with more experience can step in at this point. My
> guess with the detached headers is that Nate's trick with the
> filenames and /dev/null fails because there's a suffix being added for
> the detached header and /dev/null.metadata (or whatever the suffix is)
> doesn't exist.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 2:32 PM, Michael Giallorenzo  > wrote:
>
> Derek,
>
> Funny you should mention the file meta sink block... originally
> that was what we had implemented using a copy block to create the
> push button recording functionality, but that introduced errors in
> the alignment between headers and the IQ data since the copy block
> did not play nice with absolute item numbers.
>
> I was hoping that writing to a null file would then produce() as
> much data and keep the headers and IQ data in sync so I tried
> using the same file name construction used in Nate's flowgraph
> with .dat replaced with .cfile
> (prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile"
> if recording_checkbox else "/dev/null"), but I am noticing a few
> problems again.
>
> If the meta data file sink is set to have a detached header, which
> would be ideal, I get a runtime error when I try to run the
> flowgraph (RuntimeError: file_meta_sink: can't open file). 
>
> On the other hand, with the detached header field turned off, the
> recording process doesn't throw any errors and everything appears
> to function the way I'd like. However when playing back one of
> these recorded files using a file meta source, I get the following
> error:
>
> RuntimeError: pmt::deserialize: malformed input stream, tag value
> = : 31
>
> Not sure what to make of either of these.
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel  > wrote:
>
> I'd recommend leaving the filenames as is. The call to the
> mboard sensor will cause delays and doesn't reflect the time
> that the samples actually were acquired. Instead change to
> using a File Meta Sync which will store the timestamp tags
> produced by the USRP and gr-uhd. These contain the USRP's
> internal time which eliminates most sources of error in the
> time stamps. Setting the USRP's internal time is covered in
> the manual and a few times on the list. If you have any
> trouble with that please let us know.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo
> > wrote:
>
> Marcus,
>
> Thanks for getting back to me so quickly.
>
> I'm currently using an Ettus X310 with a UBX-160
> daughterboard, and the output of uhd_usrp_probe is as follows:
>
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.git-156-g2d68f228
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller
>  > wrote:
>
> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording
>> selected samples of data while viewing the spectrum
>> (the user can watch a waterfall display of the
>> readings being taken on an Ettus x310, and press and
>> hold a button to record data when the spectrum looks
>> interesting).
>>
>> The combination of the burst tagger block and the
>> tagged file sink block in GRC seem to be the perfect
>> solution to this, but I'm noticing an error whenever
>> i change the frequency during execution. The
>> timestamps recorded in the resulting filenames
>> rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag
>> debug block or writing the same data to a metadata
>> file and reading its header). When I'm using my GPSDO
>> as a time source, the time starts out in sync with
>> GPS but rapidly gets 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

Hello Michael,

Unfortunately we've reached past my depth in the file sinks and tags.
Hopefully someone with more experience can step in at this point. My guess
with the detached headers is that Nate's trick with the filenames and
/dev/null fails because there's a suffix being added for the detached
header and /dev/null.metadata (or whatever the suffix is) doesn't exist.

Regards,
Derek

On Tue, Aug 16, 2016 at 2:32 PM, Michael Giallorenzo 
wrote:

> Derek,
>
> Funny you should mention the file meta sink block... originally that was
> what we had implemented using a copy block to create the push button
> recording functionality, but that introduced errors in the alignment
> between headers and the IQ data since the copy block did not play nice with
> absolute item numbers.
>
> I was hoping that writing to a null file would then produce() as much data
> and keep the headers and IQ data in sync so I tried using the same file
> name construction used in Nate's flowgraph with .dat replaced with .cfile
> (prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile" if
> recording_checkbox else "/dev/null"), but I am noticing a few problems
> again.
>
> If the meta data file sink is set to have a detached header, which would
> be ideal, I get a runtime error when I try to run the flowgraph
> (RuntimeError: file_meta_sink: can't open file).
>
> On the other hand, with the detached header field turned off, the
> recording process doesn't throw any errors and everything appears to
> function the way I'd like. However when playing back one of these recorded
> files using a file meta source, I get the following error:
>
> RuntimeError: pmt::deserialize: malformed input stream, tag value = : 31
>
> Not sure what to make of either of these.
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel  wrote:
>
>> I'd recommend leaving the filenames as is. The call to the mboard sensor
>> will cause delays and doesn't reflect the time that the samples actually
>> were acquired. Instead change to using a File Meta Sync which will store
>> the timestamp tags produced by the USRP and gr-uhd. These contain the
>> USRP's internal time which eliminates most sources of error in the time
>> stamps. Setting the USRP's internal time is covered in the manual and a few
>> times on the list. If you have any trouble with that please let us know.
>>
>> Regards,
>> Derek
>>
>> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
>> wrote:
>>
>>> Marcus,
>>>
>>> Thanks for getting back to me so quickly.
>>>
>>> I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
>>> output of uhd_usrp_probe is as follows:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>>>
>>> Thanks again,
>>>
>>> Mike G
>>>
>>>
>>> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
>>> wrote:
>>>
 Hi Michael,

 what USRP are you using, and which version of UHD?


 Best regards,

 Marcus

 On 16.08.2016 17:41, Michael Giallorenzo wrote:

 Hi everyone,

 I'm currently trying to develop a gui for recording selected samples of
 data while viewing the spectrum (the user can watch a waterfall display of
 the readings being taken on an Ettus x310, and press and hold a button to
 record data when the spectrum looks interesting).

 The combination of the burst tagger block and the tagged file sink
 block in GRC seem to be the perfect solution to this, but I'm noticing an
 error whenever i change the frequency during execution. The timestamps
 recorded in the resulting filenames rapidly jump ahead in time (easily
 confirmed by comparing the filenames to the output of the tag debug block
 or writing the same data to a metadata file and reading its header). When
 I'm using my GPSDO as a time source, the time starts out in sync with GPS
 but rapidly gets corrupted as i change the frequency. Likewise when I use
 relative time, timestamps start at 0 but increase too quickly.

 As far as I can tell, this is because the tagged file sink block is not
 seeing the rx_time tags on the data stream and is instead trying to
 calculate the time based on the sample rate, but is confused when the
 changing frequency results in extra tags that are effectively being
 generated faster than expected.

 I'm fairly new to gnuradio and my background isn't really software but
 I've been experimenting with OOT modules and have modified a few built in
 blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
 100, i believe time_tags_outer.size() is returning a value of 0 and that
 may be the source of my problems. Perhaps this stems from my lack of
 understanding of how the scheduler calls the work function (ie how is the
 value of noutput_items determined?), but I'm not 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Derek,

Funny you should mention the file meta sink block... originally that was
what we had implemented using a copy block to create the push button
recording functionality, but that introduced errors in the alignment
between headers and the IQ data since the copy block did not play nice with
absolute item numbers.

I was hoping that writing to a null file would then produce() as much data
and keep the headers and IQ data in sync so I tried using the same file
name construction used in Nate's flowgraph with .dat replaced with .cfile
(prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile" if
recording_checkbox else "/dev/null"), but I am noticing a few problems
again.

If the meta data file sink is set to have a detached header, which would be
ideal, I get a runtime error when I try to run the flowgraph (RuntimeError:
file_meta_sink: can't open file).

On the other hand, with the detached header field turned off, the recording
process doesn't throw any errors and everything appears to function the way
I'd like. However when playing back one of these recorded files using a
file meta source, I get the following error:

RuntimeError: pmt::deserialize: malformed input stream, tag value = : 31

Not sure what to make of either of these.

Thanks again,

Mike G

On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel  wrote:

> I'd recommend leaving the filenames as is. The call to the mboard sensor
> will cause delays and doesn't reflect the time that the samples actually
> were acquired. Instead change to using a File Meta Sync which will store
> the timestamp tags produced by the USRP and gr-uhd. These contain the
> USRP's internal time which eliminates most sources of error in the time
> stamps. Setting the USRP's internal time is covered in the manual and a few
> times on the list. If you have any trouble with that please let us know.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
> wrote:
>
>> Marcus,
>>
>> Thanks for getting back to me so quickly.
>>
>> I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
>> output of uhd_usrp_probe is as follows:
>>
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>>
>> Thanks again,
>>
>> Mike G
>>
>>
>> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
>> wrote:
>>
>>> Hi Michael,
>>>
>>> what USRP are you using, and which version of UHD?
>>>
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>>
>>> Hi everyone,
>>>
>>> I'm currently trying to develop a gui for recording selected samples of
>>> data while viewing the spectrum (the user can watch a waterfall display of
>>> the readings being taken on an Ettus x310, and press and hold a button to
>>> record data when the spectrum looks interesting).
>>>
>>> The combination of the burst tagger block and the tagged file sink block
>>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>>> whenever i change the frequency during execution. The timestamps recorded
>>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>>> comparing the filenames to the output of the tag debug block or writing the
>>> same data to a metadata file and reading its header). When I'm using my
>>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>>> gets corrupted as i change the frequency. Likewise when I use relative
>>> time, timestamps start at 0 but increase too quickly.
>>>
>>> As far as I can tell, this is because the tagged file sink block is not
>>> seeing the rx_time tags on the data stream and is instead trying to
>>> calculate the time based on the sample rate, but is confused when the
>>> changing frequency results in extra tags that are effectively being
>>> generated faster than expected.
>>>
>>> I'm fairly new to gnuradio and my background isn't really software but
>>> I've been experimenting with OOT modules and have modified a few built in
>>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>>> may be the source of my problems. Perhaps this stems from my lack of
>>> understanding of how the scheduler calls the work function (ie how is the
>>> value of noutput_items determined?), but I'm not really sure how to modify
>>> this or really why this is happening.
>>>
>>> Sorry if my thoughts here are kind of all over the place. Any insight or
>>> reading material that anyone could offer would be greatly appreciated.
>>>
>>> Thanks,
>>>
>>> Mike G
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

I'd recommend leaving the filenames as is. The call to the mboard sensor
will cause delays and doesn't reflect the time that the samples actually
were acquired. Instead change to using a File Meta Sync which will store
the timestamp tags produced by the USRP and gr-uhd. These contain the
USRP's internal time which eliminates most sources of error in the time
stamps. Setting the USRP's internal time is covered in the manual and a few
times on the list. If you have any trouble with that please let us know.

Regards,
Derek

On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
wrote:

> Marcus,
>
> Thanks for getting back to me so quickly.
>
> I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
> output of uhd_usrp_probe is as follows:
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> what USRP are you using, and which version of UHD?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording selected samples of
>> data while viewing the spectrum (the user can watch a waterfall display of
>> the readings being taken on an Ettus x310, and press and hold a button to
>> record data when the spectrum looks interesting).
>>
>> The combination of the burst tagger block and the tagged file sink block
>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>> whenever i change the frequency during execution. The timestamps recorded
>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag debug block or writing the
>> same data to a metadata file and reading its header). When I'm using my
>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>> gets corrupted as i change the frequency. Likewise when I use relative
>> time, timestamps start at 0 but increase too quickly.
>>
>> As far as I can tell, this is because the tagged file sink block is not
>> seeing the rx_time tags on the data stream and is instead trying to
>> calculate the time based on the sample rate, but is confused when the
>> changing frequency results in extra tags that are effectively being
>> generated faster than expected.
>>
>> I'm fairly new to gnuradio and my background isn't really software but
>> I've been experimenting with OOT modules and have modified a few built in
>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>> may be the source of my problems. Perhaps this stems from my lack of
>> understanding of how the scheduler calls the work function (ie how is the
>> value of noutput_items determined?), but I'm not really sure how to modify
>> this or really why this is happening.
>>
>> Sorry if my thoughts here are kind of all over the place. Any insight or
>> reading material that anyone could offer would be greatly appreciated.
>>
>> Thanks,
>>
>> Mike G
>>
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Derek,

Thanks for responding, that is indeed very close to the functionality I'm
after. However there is one small(?) deviation from what I'm after and that
is that I'm trying to use GPS time stamps with the intent of synchronized
acquisitions between separate X310 units at a later time.

To that end, I changed the filename in the file sink block to:

prefix +
str(self.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_real()) +
".dat" if recording_checkbox else "/dev/null"

And its throwing the error :
"IOError: [Errno 2] No such file or directory:
'/home/acquisitions/temp_1388780308.0.dat'"

Apparent loss of precision on the timestamp from the GPSDO aside, I am
confused as that directory (/home/acquisitions/) does exist and normally
the file would be created and written to (the append file field is still
set to "overwrite" and in this respect the block functions as intended when
the filename is set to datetime.now()...

I realize this changes the nature of my original question, but any further
help would be greatly appreciated!

-Mike G


On Tue, Aug 16, 2016 at 1:49 PM Derek Kozel  wrote:

> Hello Mike,
>
> Here is a simple, but clever, flowgraph put together by Nate Temple which
> does exactly what you describe. It isn't an answer to the time errors
> you've seen, but I hope it is useful anyways.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 9:08 AM, Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> what USRP are you using, and which version of UHD?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording selected samples of
>> data while viewing the spectrum (the user can watch a waterfall display of
>> the readings being taken on an Ettus x310, and press and hold a button to
>> record data when the spectrum looks interesting).
>>
>> The combination of the burst tagger block and the tagged file sink block
>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>> whenever i change the frequency during execution. The timestamps recorded
>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag debug block or writing the
>> same data to a metadata file and reading its header). When I'm using my
>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>> gets corrupted as i change the frequency. Likewise when I use relative
>> time, timestamps start at 0 but increase too quickly.
>>
>> As far as I can tell, this is because the tagged file sink block is not
>> seeing the rx_time tags on the data stream and is instead trying to
>> calculate the time based on the sample rate, but is confused when the
>> changing frequency results in extra tags that are effectively being
>> generated faster than expected.
>>
>> I'm fairly new to gnuradio and my background isn't really software but
>> I've been experimenting with OOT modules and have modified a few built in
>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>> may be the source of my problems. Perhaps this stems from my lack of
>> understanding of how the scheduler calls the work function (ie how is the
>> value of noutput_items determined?), but I'm not really sure how to modify
>> this or really why this is happening.
>>
>> Sorry if my thoughts here are kind of all over the place. Any insight or
>> reading material that anyone could offer would be greatly appreciated.
>>
>> Thanks,
>>
>> Mike G
>>
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Marcus,

Thanks for getting back to me so quickly.

I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
output of uhd_usrp_probe is as follows:

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228

Thanks again,

Mike G


On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
wrote:

> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples of
> data while viewing the spectrum (the user can watch a waterfall display of
> the readings being taken on an Ettus x310, and press and hold a button to
> record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink block
> in GRC seem to be the perfect solution to this, but I'm noticing an error
> whenever i change the frequency during execution. The timestamps recorded
> in the resulting filenames rapidly jump ahead in time (easily confirmed by
> comparing the filenames to the output of the tag debug block or writing the
> same data to a metadata file and reading its header). When I'm using my
> GPSDO as a time source, the time starts out in sync with GPS but rapidly
> gets corrupted as i change the frequency. Likewise when I use relative
> time, timestamps start at 0 but increase too quickly.
>
> As far as I can tell, this is because the tagged file sink block is not
> seeing the rx_time tags on the data stream and is instead trying to
> calculate the time based on the sample rate, but is confused when the
> changing frequency results in extra tags that are effectively being
> generated faster than expected.
>
> I'm fairly new to gnuradio and my background isn't really software but
> I've been experimenting with OOT modules and have modified a few built in
> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
> 100, i believe time_tags_outer.size() is returning a value of 0 and that
> may be the source of my problems. Perhaps this stems from my lack of
> understanding of how the scheduler calls the work function (ie how is the
> value of noutput_items determined?), but I'm not really sure how to modify
> this or really why this is happening.
>
> Sorry if my thoughts here are kind of all over the place. Any insight or
> reading material that anyone could offer would be greatly appreciated.
>
> Thanks,
>
> Mike G
>
>
> ___
> 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] Illegal sub-command when installing

[Martin Braun]

On 08/16/2016 09:45 AM, Jason Matusiak wrote:
> Attempted to install gnuradio on a tablet and had a problem with
> rtl-sdr.  I blew away my install directory as well as .pybombs.  Now
> when I run the recipe add command from the instructions, I get and error:
> PyBOMBS.recipes - ERROR - Illegal sub-command: `add'
> PyBOMBS.recipes - ERROR - Valid sub-commands are:
> list-repos,add,list,update,remove
> 
> What is the issue with add?  And is the fact that there are two
> different types of "tics" around the word "add" in the error message
> telling in some way?

No, that's just a quotation style. I remember someone posting this error
before... I just can't quite remember what the issue was.

Anyway, what's happening here is that a KeyError is making it's way out
to the code that then shows the error message. There's nothing wrong
with the 'add' command, it's just the error message is for the wrong
error. I've pushed a fix to PyBOMBS that would at least give you the
right error message. Can you please try again?

Thanks,
Martin


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

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael M]

I created an hier block that does exactly that: run it once, reload your
blocks, and then use the "QT GUI Record Button" block as a sink in other
flowgraphs.

Thank you Derek for sharing Nate's flowgraph - my block had been using a
selector block, and created a 0-byte file every time a flowgraph using it
was run. Using "if/then" in the file sink like Nate did eliminates that!

Best,
Michael Morrison

On Tue, Aug 16, 2016 at 12:47 PM, Derek Kozel  wrote:

> Hello Mike,
>
> Here is a simple, but clever, flowgraph put together by Nate Temple which
> does exactly what you describe. It isn't an answer to the time errors
> you've seen, but I hope it is useful anyways.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 9:08 AM, Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> what USRP are you using, and which version of UHD?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording selected samples of
>> data while viewing the spectrum (the user can watch a waterfall display of
>> the readings being taken on an Ettus x310, and press and hold a button to
>> record data when the spectrum looks interesting).
>>
>> The combination of the burst tagger block and the tagged file sink block
>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>> whenever i change the frequency during execution. The timestamps recorded
>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag debug block or writing the
>> same data to a metadata file and reading its header). When I'm using my
>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>> gets corrupted as i change the frequency. Likewise when I use relative
>> time, timestamps start at 0 but increase too quickly.
>>
>> As far as I can tell, this is because the tagged file sink block is not
>> seeing the rx_time tags on the data stream and is instead trying to
>> calculate the time based on the sample rate, but is confused when the
>> changing frequency results in extra tags that are effectively being
>> generated faster than expected.
>>
>> I'm fairly new to gnuradio and my background isn't really software but
>> I've been experimenting with OOT modules and have modified a few built in
>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>> may be the source of my problems. Perhaps this stems from my lack of
>> understanding of how the scheduler calls the work function (ie how is the
>> value of noutput_items determined?), but I'm not really sure how to modify
>> this or really why this is happening.
>>
>> Sorry if my thoughts here are kind of all over the place. Any insight or
>> reading material that anyone could offer would be greatly appreciated.
>>
>> Thanks,
>>
>> Mike G
>>
>>
>> ___
>> 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
>
>


push-to-record.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

Hello Mike,

Here is a simple, but clever, flowgraph put together by Nate Temple which
does exactly what you describe. It isn't an answer to the time errors
you've seen, but I hope it is useful anyways.

Regards,
Derek

On Tue, Aug 16, 2016 at 9:08 AM, Marcus Müller 
wrote:

> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples of
> data while viewing the spectrum (the user can watch a waterfall display of
> the readings being taken on an Ettus x310, and press and hold a button to
> record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink block
> in GRC seem to be the perfect solution to this, but I'm noticing an error
> whenever i change the frequency during execution. The timestamps recorded
> in the resulting filenames rapidly jump ahead in time (easily confirmed by
> comparing the filenames to the output of the tag debug block or writing the
> same data to a metadata file and reading its header). When I'm using my
> GPSDO as a time source, the time starts out in sync with GPS but rapidly
> gets corrupted as i change the frequency. Likewise when I use relative
> time, timestamps start at 0 but increase too quickly.
>
> As far as I can tell, this is because the tagged file sink block is not
> seeing the rx_time tags on the data stream and is instead trying to
> calculate the time based on the sample rate, but is confused when the
> changing frequency results in extra tags that are effectively being
> generated faster than expected.
>
> I'm fairly new to gnuradio and my background isn't really software but
> I've been experimenting with OOT modules and have modified a few built in
> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
> 100, i believe time_tags_outer.size() is returning a value of 0 and that
> may be the source of my problems. Perhaps this stems from my lack of
> understanding of how the scheduler calls the work function (ie how is the
> value of noutput_items determined?), but I'm not really sure how to modify
> this or really why this is happening.
>
> Sorry if my thoughts here are kind of all over the place. Any insight or
> reading material that anyone could offer would be greatly appreciated.
>
> Thanks,
>
> Mike G
>
>
> ___
> 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
>
>


grc_recording.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Illegal sub-command when installing

[Jason Matusiak]

Attempted to install gnuradio on a tablet and had a problem with 
rtl-sdr.  I blew away my install directory as well as .pybombs.  Now 
when I run the recipe add command from the instructions, I get and error:

PyBOMBS.recipes - ERROR - Illegal sub-command: `add'
PyBOMBS.recipes - ERROR - Valid sub-commands are: 
list-repos,add,list,update,remove


What is the issue with add?  And is the fact that there are two 
different types of "tics" around the word "add" in the error message 
telling in some way?


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

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Marcus Müller]

Hi Michael,

what USRP are you using, and which version of UHD?


Best regards,

Marcus


On 16.08.2016 17:41, Michael Giallorenzo wrote:
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples
> of data while viewing the spectrum (the user can watch a waterfall
> display of the readings being taken on an Ettus x310, and press and
> hold a button to record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink
> block in GRC seem to be the perfect solution to this, but I'm noticing
> an error whenever i change the frequency during execution. The
> timestamps recorded in the resulting filenames rapidly jump ahead in
> time (easily confirmed by comparing the filenames to the output of the
> tag debug block or writing the same data to a metadata file and
> reading its header). When I'm using my GPSDO as a time source, the
> time starts out in sync with GPS but rapidly gets corrupted as i
> change the frequency. Likewise when I use relative time, timestamps
> start at 0 but increase too quickly.
>
> As far as I can tell, this is because the tagged file sink block is
> not seeing the rx_time tags on the data stream and is instead trying
> to calculate the time based on the sample rate, but is confused when
> the changing frequency results in extra tags that are effectively
> being generated faster than expected.
>
> I'm fairly new to gnuradio and my background isn't really software but
> I've been experimenting with OOT modules and have modified a few built
> in blocks to suit my needs before. In "tagged_file_sink_impl.cc"
> around line 100, i believe time_tags_outer.size() is returning a value
> of 0 and that may be the source of my problems. Perhaps this stems
> from my lack of understanding of how the scheduler calls the work
> function (ie how is the value of noutput_items determined?), but I'm
> not really sure how to modify this or really why this is happening.
>
> Sorry if my thoughts here are kind of all over the place. Any insight
> or reading material that anyone could offer would be greatly appreciated.
>
> Thanks,
>
> Mike G
>
>
> ___
> 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] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Hi everyone,

I'm currently trying to develop a gui for recording selected samples of
data while viewing the spectrum (the user can watch a waterfall display of
the readings being taken on an Ettus x310, and press and hold a button to
record data when the spectrum looks interesting).

The combination of the burst tagger block and the tagged file sink block in
GRC seem to be the perfect solution to this, but I'm noticing an error
whenever i change the frequency during execution. The timestamps recorded
in the resulting filenames rapidly jump ahead in time (easily confirmed by
comparing the filenames to the output of the tag debug block or writing the
same data to a metadata file and reading its header). When I'm using my
GPSDO as a time source, the time starts out in sync with GPS but rapidly
gets corrupted as i change the frequency. Likewise when I use relative
time, timestamps start at 0 but increase too quickly.

As far as I can tell, this is because the tagged file sink block is not
seeing the rx_time tags on the data stream and is instead trying to
calculate the time based on the sample rate, but is confused when the
changing frequency results in extra tags that are effectively being
generated faster than expected.

I'm fairly new to gnuradio and my background isn't really software but I've
been experimenting with OOT modules and have modified a few built in blocks
to suit my needs before. In "tagged_file_sink_impl.cc" around line 100, i
believe time_tags_outer.size() is returning a value of 0 and that may be
the source of my problems. Perhaps this stems from my lack of understanding
of how the scheduler calls the work function (ie how is the value of
noutput_items determined?), but I'm not really sure how to modify this or
really why this is happening.

Sorry if my thoughts here are kind of all over the place. Any insight or
reading material that anyone could offer would be greatly appreciated.

Thanks,

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

Re: [Discuss-gnuradio] qa_polar_xxx and qa_zeromq_xxx failed in the make test!

[Ron Economos]

Same fix for the zeromq errors.

sudo apt-get install python-zmq

BTW, the detailed error log is in 
gnuradio/build/Testing/Temporary/LastTest.log


Ron

On 08/16/2016 12:31 AM, Johannes Demel wrote:

Hi all,

for clarification. Scipy is an optional dependency. Thus, the tests 
might fail.
All polar tests import 'polar.channel_construction', which imports 
'polar.channel_construction_awgn', which in turn uses 
'scipy.optimize.fsolve' and 'scipy.special.erfc'.
When I wrote this peace of code, I thought about replacing it, but 
it's quite a lot of work to emulate 'fsolve'.

As far as I know, the issue was resolved by installing scipy.

I don't know about ZeroMQ though!

Cheers
Johannes

On 16.08.2016 00:40, Ron Economos wrote:

I believe the polar encoder and decoder tests need scipy to run.

sudo apt-get install python-scipy

Ron

On 08/15/2016 06:15 AM, Ali The GREAT! wrote:

Hi everyone,

I have installed  uhd_3_11_0 and gnuradio_3_7_10_1.
Everything seems OK but these failed qa tests:

1 qa_polar_encoder
2 qa_polar_encoder_systematic
3 qa_polar_decoder_sc
4 qa_polar_decoder_sc_list
5 qa_polar_decoder_sc_systematic
6 qa_zeromq_pub
7 qa_zeromq_pubsub
8 qa_zeromq_pushpull

I'm using debian 8.4 and KDE.

Thanks in advance!
Ali





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

Re: [Discuss-gnuradio] qa_polar_xxx and qa_zeromq_xxx failed in the make test!

[Johannes Demel]

Hi all,

for clarification. Scipy is an optional dependency. Thus, the tests 
might fail.
All polar tests import 'polar.channel_construction', which imports 
'polar.channel_construction_awgn', which in turn uses 
'scipy.optimize.fsolve' and 'scipy.special.erfc'.
When I wrote this peace of code, I thought about replacing it, but it's 
quite a lot of work to emulate 'fsolve'.

As far as I know, the issue was resolved by installing scipy.

I don't know about ZeroMQ though!

Cheers
Johannes

On 16.08.2016 00:40, Ron Economos wrote:

I believe the polar encoder and decoder tests need scipy to run.

sudo apt-get install python-scipy

Ron

On 08/15/2016 06:15 AM, Ali The GREAT! wrote:

Hi everyone,

I have installed  uhd_3_11_0 and gnuradio_3_7_10_1.
Everything seems OK but these failed qa tests:

1 qa_polar_encoder
2 qa_polar_encoder_systematic
3 qa_polar_decoder_sc
4 qa_polar_decoder_sc_list
5 qa_polar_decoder_sc_systematic
6 qa_zeromq_pub
7 qa_zeromq_pubsub
8 qa_zeromq_pushpull

I'm using debian 8.4 and KDE.

Thanks in advance!
Ali


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




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



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