Re: [Discuss-gnuradio] gnuradio-companion : File Descriptor Source module usage

[Tom Crane]

On Tue, 23 Jul 2019, Kevin Reid wrote:


On Tue, Jul 23, 2019 at 8:33 PM Tom Crane  wrote:
  Can anyone explain how to use the File Descriptor Source module in
  gnuradio-companion?

  I am trying to write a flow-graph to read data from an arbitrary file,
  chosen via the GUI at run time?  This must be possible, right?  I can't
  see how to do it.


I don't have time to write a full explanation, but note that you want the File 
Source block, not the File Descriptor Source block. The File Descriptor Source 
is only really useful to read from standard input or for use in more complex 
programs than you can write
with GRC.

The File Source block takes a string for the filename. If you create a Variable 
block with a string value, you can enter the ID of the Variable instead of a 
filename, and then change that Variable using GUI in the usual fashion. I 
haven't tested this, but that's
how it should work.


Thanks.  That did work.
Tom.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Units of data saved by filesink

[Marcus D. Leech]

On 07/25/2019 01:24 PM, Ellie White wrote:

Hi Marcus,

Good to know. So how would you recommend I should convert these values 
to, say, watts? (I guess perhaps it would be watts squared due to the 
mag to mag squared block). I assume I would first have to determine 
what the SDR considers full scale -- do you have any suggestions on 
how to do that?


Thank you so much for your time and input on this, I really appreciate 
it!


Take care,
Ellie

Ellie:

For microwave radio astronomy, placing a carbon-foam RF absorber sheet 
over the feed aperture (if that's possible here) gives you a known
  blackbody temperature source at temperature is in Kelvins>.   Once you know that, then you know that the

  output of your SDR processing chain is proportional to:

Tabsorber + Tsys

Pointing your feed horn (again, I'm assuming something microwavey here, 
like 21cm) at the North Celestial Pole at night will give you a good
  approximation to roughly 10K sky temperature (maybe a little more or 
less).  THAT reading will be proportional to:


Tsky + Tsplillover + Tsys

With a pyramidal horn antenna (which is what I think you've been working 
with), Tspill should be very small, perhaps 1 or 2K.  For a dish

  antenna, it's usually a bit more (perhaps 10K).


Assuming Tsys doesn't change much between those two readings, you now 
have a couple of calibration points that you can use to determine

  power readings as seen at the front of your RF chain.




On Thu, Jul 25, 2019 at 1:11 PM Müller, Marcus (CEL) > wrote:


Arbitrary counts, relative to what your Device and the attached
DSP you
or the device are doing considers full scale.

Best regards,
Marcus

On Thu, 2019-07-25 at 13:09 -0400, Ellie White wrote:
> Hi all,
>
> Hope you are doing well! I have been working on a flowgraph
(attached) that will allow me to process and save data samples
from an Ettus SDR (which is plugged in to a different computer --
the data is streamed over via a TCP socket). I am using a metadata
filesink for this, and am curious to know, what are the units in
which the data is saved? I.e., when I open the binary data file
using a separate python program (such as the one attached), and
plot the data as an averaged spectrum, what will the units on the
y-axis be -- some actual physical unit, or an arbitrary counts unit?
>
> Any info that you can provide on this would be much appreciated
-- have a great afternoon!
>
> Best,
> Ellie
> ___
> 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] DSP Block with internal variable output / monitor

[Alex Roberts]

Yeah, I'm on Linux Mint 18 aka Ubuntu 16.04 (xenial). I've been meaning to
upgrade. I'm not familiar with check_topology, I basically just copied the
gr-dtv reed Solomon decoder implementation and tried to extend the
io_signature. I probably copied pasted things into my OOT module in a way
that its likely still looking at the original reed Solomon decoded which
has only one output and complains since my implementation has two outputs.
At least that's my uneducated guess.

Federico's version does what I was looking for so I've been playing around
it. I was able successfully drop it in to the dvb-t example in place of the
stock RS decoder (re-compiled fedrico's version to support block size of 8
from hard coded default of 1). I did notice that if the transport stream
packet was degraded enough, it would cause the flowgraph to crash with the
following error:


gnuradio-runtime/include/gnuradio/buffer.h:170:
> unsigned int gr::buffer::index_add(unsigned int, unsigned int): Assertion `s
> < d_bufsize' failed.
I commented out "consume_each(i+1) in this section of his code and no
longer got the error

Line 140: // if nerrors_corrected=-1 it means that the
decoder gave up on the word
if(nerrors_corrected==-1)
{
// In order to generate a useable TS, we will
not ouput these TSP.
//printf("RS: impossible to correct\n");
// We also reset the BER average.
d_last_ber_out = 0.5;

//consume_each(i+1);
return i;
}


On Wed, Jul 24, 2019 at 3:27 PM Federico 'Larroca' La Rocca <
flarr...@gmail.com> wrote:

> Hi,
> I think it is very possible to merge them, specially in the RS decoder
> which I didn't modify much. The viterbi took me quiet some thinking and
> testing, but it's possible too.
> If it would make sense, that's another question :-). I use it mostly as
> another indicator that the flowgraph is correctly configured (sometimes the
> constellation is good enough, but if you have misspecified for instance the
> time interleaver length you will get garbage). Performance-wise it has
> negligible impact.
> If you are interested I can try to make a couple of PRs.
> best
>
> El mié., 24 jul. 2019 a las 14:21, Müller, Marcus (CEL) ()
> escribió:
>
>> Hi Federico,
>>
>> would it make sense to merge that extension back to mainline GNU Radio?
>>
>> Best regards,
>> Marcus
>> On Wed, 2019-07-24 at 12:41 -0300, Federico 'Larroca' La Rocca wrote:
>> > Hi,
>> > If you are interested in measuring the number of errors in the
>> Reed-Solomon block of DTV, you may take a look at our OOT module gr-isdbt (
>> https://github.com/git-artes/gr-isdbt) which includes modifications to
>> the RS (and the viterbi) decoder to outputs the BER (but is easily
>> modifiable to output the number of errors).
>> > best
>> > Federico
>> >
>> > El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) (<
>> muel...@kit.edu>) escribió:
>> > > Hi Alex!
>> > > Hm, interesting. Would you happen to have the full verbatim error?
>> > >
>> > > As a complete aside:
>> > > I know we're not doing any of that consistently in the tree, but
>> > > especially when handling things like polynomials "packed" into
>> > > integers, and amounts of bits, I always recommend people explicitly
>> use
>> > > "unsigned int", or directly go for an explicitly sized integer type,
>> > > e.g. "uint64_t gfpoly" for their polynomial representations, so that
>> > > there's no arithmetic surprises – signed integer overflow, for
>> example,
>> > > is way less well-defined than unsigned.
>> > >
>> > > Best regards,
>> > > Marcus
>> > >
>> > > On Wed, 2019-07-24 at 10:30 -0500, Alex Roberts wrote:
>> > > > So I tried re-implementing the gr-dtv Reed Solomon decoder with an
>> additional output so I could monitor/output the number of errors corrected.
>> > > > I used gr-modtool, created new block with new name so it wouldn't
>> conflict with the existing and made sure to update the markup language for
>> the grc block.
>> > > >
>> > > > I get an error about Number of outputs 1 exceed max 0. I'm not sure
>> why that is.
>> > > >
>> > > > Here is my impl declaration with io_signatures.
>> > > >
>> > > > custom_reed_solomon_dec_impl::custom_reed_solomon_dec_impl(int p,
>> int m, int gfpoly, int n, int k, int t, int s, int blocks)
>> > > >   : block("custom_reed_solomon_dec",
>> > > >   io_signature::make(1, 1, sizeof(unsigned char) * blocks *
>> (n - s)),
>> > > >   io_signature::make2(1, 2, sizeof(unsigned char) * blocks
>> * (k - s), sizeof(int) )), // Change to make2 to support outputting
>> nerrors_corrected in the general_work() function
>> > > >   d_n(n), d_k(k), d_s(s), d_blocks(blocks)
>> > > > {
>> > > > ...
>> > > > }
>> > > >
>> > > >
>> > > > On Tue, Jul 23, 2019 at 3:44 PM Alex Roberts 
>> wrote:
>> > > > > Marcus,
>> > > > >
>> > > > > I think what 

Re: [Discuss-gnuradio] Units of data saved by filesink

[CEL]

On Thu, 2019-07-25 at 13:24 -0400, Ellie White wrote:
> Hi Marcus,
> 
> Good to know. So how would you recommend I should convert these values to, 
> say, watts? 

I described exactly that in my other email.

> (I guess perhaps it would be watts squared due to the mag to mag squared 
> block).

No. Amplitudes are proportional to voltage, squared amplitudes to
power. Physics!

>  I assume I would first have to determine what the SDR considers full scale 
> -- do you have any suggestions on how to do that? 
> 

Calibration with a known power source.



smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about metadata filesink

[CEL]

Hi Ellie,

> The nature of the equipment I am working with requires that the SDR
be plugged in to a different computer from the one which is storing the
data,

The problem is not that it's not on the same computer – the problem is
that the samples coming from a USRP are just that: samples, not voltage
measurements calibrated to a known voltage. 

You could calibrate yourself, however, using a source of signal of
known power, and infer the proportionality between say sample magnitude
squared and watt, and from that the proportionality between sample
amplitude and volt.

> Also -- if you don't mind me asking, what does it mean that the
constructors deadlock each other?

Depending on the configuration, a TCP socket block might only finish
its constructor when the TCP connection is established. If the other
side does the same, you get a deadlock.

> If you know of any blocks or methods that are more reliable, I am
open to suggestions.

ZeroMQ blocks.

Also, I don't know which USRPs you have, but a lot of them are network-
based and could directly used by your remote computer.

Also, be double sure that your network link even allows the data rate
you want it to pass. 

Especially, you might want to send the original short samples instead
of converting them to (twice as large in data size) floating point
numbers and then pumping them through network.

Also: we've marked the WX GUI blocks deprecated about four years ago.
Please don't use WX anymore, we've removed it from GNU Radio and can't
fix any bugs with it. It's unsupported from our side! Use the Qt GUI
instead.

Most importantly: 

Your File Meta sink really makes no sense in your ettus-filesink.grc.
There's no metadata to save here, at all, because the TCP sink/source
doesn't even transport any tags.

There's zeroMQ sinks/sources that do that!

Best regards,
Marcus


On Thu, 2019-07-25 at 13:21 -0400, Ellie White wrote:
> Forgot to cc the list the first time...
> 
> 
> On Thu, Jul 25, 2019 at 1:16 PM Ellie White  wrote:
> > Hi Marcus,
> > 
> > Thanks for the suggestion, much appreciated. Do you have an alternative to 
> > recommend? The nature of the equipment I am working with requires that the 
> > SDR be plugged in to a different computer from the one which is storing the 
> > data, so that is why some kind of socket connection is needed. Also -- if 
> > you don't mind me asking, what does it mean that the constructors deadlock 
> > each other? How does this affect the data I am collecting? If you know of 
> > any blocks or methods that are more reliable, I am open to suggestions.
> > 
> > Thanks again! 
> > Ellie
> > 
> > On Thu, Jul 25, 2019 at 12:51 PM Müller, Marcus (CEL)  
> > wrote:
> > > Also, I'd recommend not to rely on TCP sink/source, it's python-only
> > > and it is indeed quite fiddly – the constructors can deadlock each
> > > other.
> > > On Wed, 2019-07-10 at 17:51 -0400, Marcus D. Leech wrote:
> > > > On 07/10/2019 02:54 PM, Ellie White wrote:
> > > > > Hello!
> > > > > 
> > > > > I am working on a radio astronomy project with the Green Bank
> > > > > Observatory / NRAO Central Development Lab this summer, utilizing GNU
> > > > > Radio and an Ettus Research SDR, and I've got a question regarding how
> > > > > to collect metadata information from a filesink.
> > > > > 
> > > > > I have attached the flowgraph I am using to this email. The project
> > > > > requires that I use two computers in tandem for data collection -- one
> > > > > is connected to the Ettus -- it is the TCP server, and sends an
> > > > > interleaved data stream to the TCP client flowgraph (attached) on the
> > > > > machine which will be storing the data. As you can see, I am saving
> > > > > integrated spectra to a file. My question is simply, how do I retrieve
> > > > > a time stamp corresponding to each spectra using the metadata time
> > > > > sink? I have been fiddling with this all afternoon attempting to get
> > > > > it to work properly, and I have been able to save data to a file, read
> > > > > out spectra (using attached Python program), and display header
> > > > > information using the command gr_read_file_metadata in the terminal,
> > > > > but this is just showing me a timestamp for the beginning of the data
> > > > > collection run, rather than showing me timestamps for each spectrum
> > > > > which is saved to file, and I am not sure how to implement this.
> > > > > 
> > > > > Any advice would be much appreciated! If I can provide any more info
> > > > > about my system or what steps I have tried, please let me know. Thank
> > > > > you so much for your time -- have a good afternoon!
> > > > > 
> > > > > Best,
> > > > > Ellie
> > > > 
> > > > So, another thing to keep in mind is that the TCP source/sink DO NOT 
> > > > CARRY metadata tags--only the samples.  So if you're relying on that,
> > > >it won't work.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Dis

Re: [Discuss-gnuradio] Units of data saved by filesink

[Ellie White]

Hi Marcus,

Good to know. So how would you recommend I should convert these values to,
say, watts? (I guess perhaps it would be watts squared due to the mag to
mag squared block). I assume I would first have to determine what the SDR
considers full scale -- do you have any suggestions on how to do that?

Thank you so much for your time and input on this, I really appreciate it!

Take care,
Ellie

On Thu, Jul 25, 2019 at 1:11 PM Müller, Marcus (CEL) 
wrote:

> Arbitrary counts, relative to what your Device and the attached DSP you
> or the device are doing considers full scale.
>
> Best regards,
> Marcus
>
> On Thu, 2019-07-25 at 13:09 -0400, Ellie White wrote:
> > Hi all,
> >
> > Hope you are doing well! I have been working on a flowgraph (attached)
> that will allow me to process and save data samples from an Ettus SDR
> (which is plugged in to a different computer -- the data is streamed over
> via a TCP socket). I am using a metadata filesink for this, and am curious
> to know, what are the units in which the data is saved? I.e., when I open
> the binary data file using a separate python program (such as the one
> attached), and plot the data as an averaged spectrum, what will the units
> on the y-axis be -- some actual physical unit, or an arbitrary counts unit?
> >
> > Any info that you can provide on this would be much appreciated -- have
> a great afternoon!
> >
> > Best,
> > Ellie
> > ___
> > 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] Question about metadata filesink

[Ellie White]

Forgot to cc the list the first time...


On Thu, Jul 25, 2019 at 1:16 PM Ellie White 
wrote:

> Hi Marcus,
>
> Thanks for the suggestion, much appreciated. Do you have an alternative to
> recommend? The nature of the equipment I am working with requires that the
> SDR be plugged in to a different computer from the one which is storing the
> data, so that is why some kind of socket connection is needed. Also -- if
> you don't mind me asking, what does it mean that the constructors deadlock
> each other? How does this affect the data I am collecting? If you know of
> any blocks or methods that are more reliable, I am open to suggestions.
>
> Thanks again!
> Ellie
>
> On Thu, Jul 25, 2019 at 12:51 PM Müller, Marcus (CEL) 
> wrote:
>
>> Also, I'd recommend not to rely on TCP sink/source, it's python-only
>> and it is indeed quite fiddly – the constructors can deadlock each
>> other.
>> On Wed, 2019-07-10 at 17:51 -0400, Marcus D. Leech wrote:
>> > On 07/10/2019 02:54 PM, Ellie White wrote:
>> > > Hello!
>> > >
>> > > I am working on a radio astronomy project with the Green Bank
>> > > Observatory / NRAO Central Development Lab this summer, utilizing GNU
>> > > Radio and an Ettus Research SDR, and I've got a question regarding how
>> > > to collect metadata information from a filesink.
>> > >
>> > > I have attached the flowgraph I am using to this email. The project
>> > > requires that I use two computers in tandem for data collection -- one
>> > > is connected to the Ettus -- it is the TCP server, and sends an
>> > > interleaved data stream to the TCP client flowgraph (attached) on the
>> > > machine which will be storing the data. As you can see, I am saving
>> > > integrated spectra to a file. My question is simply, how do I retrieve
>> > > a time stamp corresponding to each spectra using the metadata time
>> > > sink? I have been fiddling with this all afternoon attempting to get
>> > > it to work properly, and I have been able to save data to a file, read
>> > > out spectra (using attached Python program), and display header
>> > > information using the command gr_read_file_metadata in the terminal,
>> > > but this is just showing me a timestamp for the beginning of the data
>> > > collection run, rather than showing me timestamps for each spectrum
>> > > which is saved to file, and I am not sure how to implement this.
>> > >
>> > > Any advice would be much appreciated! If I can provide any more info
>> > > about my system or what steps I have tried, please let me know. Thank
>> > > you so much for your time -- have a good afternoon!
>> > >
>> > > Best,
>> > > Ellie
>> >
>> > So, another thing to keep in mind is that the TCP source/sink DO NOT
>> > CARRY metadata tags--only the samples.  So if you're relying on that,
>> >it won't work.
>> >
>> >
>> >
>> >
>> > ___
>> > 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] Units of data saved by filesink

[CEL]

Arbitrary counts, relative to what your Device and the attached DSP you
or the device are doing considers full scale.

Best regards,
Marcus

On Thu, 2019-07-25 at 13:09 -0400, Ellie White wrote:
> Hi all,
> 
> Hope you are doing well! I have been working on a flowgraph (attached) that 
> will allow me to process and save data samples from an Ettus SDR (which is 
> plugged in to a different computer -- the data is streamed over via a TCP 
> socket). I am using a metadata filesink for this, and am curious to know, 
> what are the units in which the data is saved? I.e., when I open the binary 
> data file using a separate python program (such as the one attached), and 
> plot the data as an averaged spectrum, what will the units on the y-axis be 
> -- some actual physical unit, or an arbitrary counts unit? 
> 
> Any info that you can provide on this would be much appreciated -- have a 
> great afternoon! 
> 
> Best,
> Ellie
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Units of data saved by filesink

[Ellie White]

Hi all,

Hope you are doing well! I have been working on a flowgraph (attached) that
will allow me to process and save data samples from an Ettus SDR (which is
plugged in to a different computer -- the data is streamed over via a TCP
socket). I am using a metadata filesink for this, and am curious to know,
what are the units in which the data is saved? I.e., when I open the binary
data file using a separate python program (such as the one attached), and
plot the data as an averaged spectrum, what will the units on the y-axis be
-- some actual physical unit, or an arbitrary counts unit?

Any info that you can provide on this would be much appreciated -- have a
great afternoon!

Best,
Ellie


ettus-filesink.grc
Description: application/gnuradio-grc
#plotData.py

""" This program will read in a data file from Gnu Radio and plot it.
Ellie White 25 Feb. 2017
"""

import pylab as plt
import os
import numpy as np
from tempCorrections import tempCorrections

def main():

fftsize = 8192.0
tot_time = 20
srate = 400.0 
decimation = 100.0

rpi_samptime = 5 # number of seconds between sensor readings

infile = 'data-raw2.obs' 
in_tfilename = 'timefile2.txt'
out_tfilename = 'timestamps2.txt'

tc_b = tempCorrections('balun', 1, 'RPI_DATA_07_11_2019_21-33-04.txt', 0)
#tc_rx = tempCorrections('rx', 1, '/home/ewhite/rpi-data/RPI_DATA_07_11_2019_21-33-04.txt', 0)

size = os.path.getsize(infile) / 4
shape = (size/fftsize, fftsize)
#print(str(size/fftsize))
#print(str(size))
x = np.memmap(infile, dtype='float32', mode = 'r', shape=shape)

freqPlot = np.mean(x, axis=0)
#print freqPlot
fmin = (16901-(srate/2))/100
fmax = (16901+(srate/2))/100
fidx = np.linspace(fmin, fmax, freqPlot.size)


#fraction of a second between bursts...
delta_t = tot_time / (size / fftsize)
'''tfile = open(in_tfilename, 'r')
start_time = float(tfile.read())'''

#read in data from RPI file as array
#balun temps:
balun_temps = []
btemps = tc_b.getTemps()
for b in btemps:
balun_temps.append(b)

#receiver temps
#rx_temps = tc_rx.getTemps()

#read times from RPI file...
times = tc_b.getTimes()
#print times
start_time = times[0] - rpi_samptime

#tsfile = open(out_tfilename, 'w')
data_btemps = []
ant_power = []

for i in range(int(size/fftsize)):
#assign sensor row to row i of xarray
row_time = (i+1)*delta_t
#print row_time
#print len(times)
for j in range(len(times)):
   #print "in the loop"
   #print times[j] - start_time
   if j == 0:
  if row_time <= (times[j] - start_time):
  t_index = j
  break
  else:
  continue
   elif j == (len(times)-1):
   if row_time >= times[j]:
   t_index = j
   break
   elif row_time <= (times[j] - start_time):
   t_index = j
   else:
   print "An error has occurred -- no t_index set!"
   else: 
   if (row_time >= (times[j-1] - start_time)) and (row_time < (times[j] - start_time)):
   t_index = j
   break
   else:
   continue

#get temperatures for balun and rx from sensor row
btemp_i = balun_temps[t_index]
data_btemps.append(btemp_i)

#get representative power value from data array:
pval = x[i, fftsize/2]
#print pval
ant_power.append(pval)

ant_temps = [] 
print "Ant. Temp\tPhys. Temp"

for p in range(len(ant_power)):
atemp = (float(ant_power[p])/(488.28125*1.3806*pow(10,-23))) + 57.2
ant_temps.append(atemp)
print "{0}\t{1}".format(atemp, data_btemps[p])

#mod_curves = np.empty([int(size/fftsize), freqPlot.size])
#s21mod_mag, s21mod_ph = tc_b.getS21MagPhase()  
#print s21mod_mag

#call tempCorrections with given temperature to get model curve
'''for k in range(len(data_btemps)):
btemp = data_btemps[k]
index = balun_temps.index(btemp)
mod_curves[k] = s21mod_mag[index]
#plt.plot(fidx, mod_curves[k])'''

#convert model curve to power
#apply any offsets to row i data
#subtract model from row i data
#corrected data becomes part of new corrected data array

#correctedPlot = np.mean(x_corr, axis=0)
#clip out and replace RFI channels with noise data from nearby channels

#tsfile.close()

plt.plot(fidx, freqPlot)
plt.show()


if __name__ == "__main__":
main()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem building gr-display

[Barry Duggan]

Hi Volker,

Yes, it works now :)

Thank you very much for fixing that. I will be making use of it today 
with my RTTY Terminal Unit.


Best regards,
--
Barry Duggan KV4FV

--

Message: 13
Date: Thu, 25 Jul 2019 17:43:32 +0200
From: Volker Schroer 
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Problem building gr-display
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Now the gr-display master branch builds against gnuradio 3.8.0.0-rc2



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

Re: [Discuss-gnuradio] Question about metadata filesink

[CEL]

Also, I'd recommend not to rely on TCP sink/source, it's python-only
and it is indeed quite fiddly – the constructors can deadlock each
other.
On Wed, 2019-07-10 at 17:51 -0400, Marcus D. Leech wrote:
> On 07/10/2019 02:54 PM, Ellie White wrote:
> > Hello!
> > 
> > I am working on a radio astronomy project with the Green Bank
> > Observatory / NRAO Central Development Lab this summer, utilizing GNU
> > Radio and an Ettus Research SDR, and I've got a question regarding how
> > to collect metadata information from a filesink.
> > 
> > I have attached the flowgraph I am using to this email. The project
> > requires that I use two computers in tandem for data collection -- one
> > is connected to the Ettus -- it is the TCP server, and sends an
> > interleaved data stream to the TCP client flowgraph (attached) on the
> > machine which will be storing the data. As you can see, I am saving
> > integrated spectra to a file. My question is simply, how do I retrieve
> > a time stamp corresponding to each spectra using the metadata time
> > sink? I have been fiddling with this all afternoon attempting to get
> > it to work properly, and I have been able to save data to a file, read
> > out spectra (using attached Python program), and display header
> > information using the command gr_read_file_metadata in the terminal,
> > but this is just showing me a timestamp for the beginning of the data
> > collection run, rather than showing me timestamps for each spectrum
> > which is saved to file, and I am not sure how to implement this.
> > 
> > Any advice would be much appreciated! If I can provide any more info
> > about my system or what steps I have tried, please let me know. Thank
> > you so much for your time -- have a good afternoon!
> > 
> > Best,
> > Ellie
> 
> So, another thing to keep in mind is that the TCP source/sink DO NOT 
> CARRY metadata tags--only the samples.  So if you're relying on that,
>it won't work.
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about metadata filesink

[Ellie White]

Hi Marcus, Derek,

Thank you both so much for your feedback and for all of your suggestions on
this, I really appreciate it. My apologies for the delayed response -- I
have been out of town for several days.

Based on feedback from you all and some experimentation, I came up with a
workaround for the problem I was having -- turns out the time precision
needed is not as rigorous as I expected, (plus or minus a few seconds is
fine), so I am using the Python time module to record the time at which the
flowgraph starts to run (using time.time() in top_block.py), set a timer
(using time.sleep()) which dictates how long the flowgraph runs, and then I
obtain time stamps for each vector by dividing the total time spent
observing by the number of vectors obtained, and add this increment to the
start time repeatedly until the number of time stamps matches the number of
vectors. Kind of a 'rough and ready' solution, but I think it should work
for my purposes. The reason I need the time stamps is mainly to sync up the
spectrum readings with temperature readings taken by a Raspberry Pi which
is running simultaneously, and since the outdoor temperature will be
changing on fairly slow time scales (minutes rather than seconds), that
means it is ok for the time stamps to be off by as much as a few seconds.

So that's where I am with that! I will be emailing with another, mostly
unrelated, question here soon... in the meantime, thank you again for the
advice, and hope you have a good afternoon!

Best,
Ellie

On Wed, Jul 10, 2019 at 6:04 PM Marcus D. Leech 
wrote:

> On 07/10/2019 04:19 PM, Ellie White wrote:
> > Hi Marcus,
> >
> > Thanks for getting back to me! I really appreciate your suggestion --
> > why didn't I think of that! I have done similar calculations before to
> > determine the amount of time from the beginning of a run, but for a
> > much less precise application.
> >
> > This brings me to another question, though -- I notice that when I
> > read the metadata header, the time ("Seconds" field) always says zero
> > when I get the file from the TCP client flowgraph, but when I save a
> > metadata header file on the machine that the Ettus is connected to, it
> > gives me some fractional answer (always different, never zero). Not
> > sure why that is, or what time standard the UHD is using (this is the
> > one I have, by the way:
> > https://files.ettus.com/manual/page_usrp1.html)? Maybe the Ettus just
> > needs to be connected to an external clock source -- the final system
> > will have a 10 MHz clock source connected, but the temporary system
> > that is set up now doesn't have an external clock. If you have any
> > thoughts on this, I would be interested to hear them.
> >
> > Thanks again, and have a good afternoon!
> Also, other random questions:
>
> What type of USRP (There are a plethora these days!)
>
> What type of computer is direct-connected to the USRP?
>
> Can you share the flow-graph for the computer that is direct-connected
> to the USRP?
>
>
> > Best,
> > Ellie
> >
> >
> > On Wed, Jul 10, 2019 at 3:07 PM Marcus D Leech 
> wrote:
> >> The thing to note is that the UHD sends a time stamp only on start of
> streaming and whenever there’s an overrun.
> >>
> >> You can know the time of any given sample by knowing the sample rate
> and offset from the beginning.
> >>
> >> In your case you will have to throw in some more factors to account for
> FFT size and decimation etc.
> >>
> >> More later when I get to a real computer.
> >>
> >> Sent from my iPhone
> >>
> >>> On Jul 10, 2019, at 2:54 PM, Ellie White 
> wrote:
> >>>
> >>> Hello!
> >>>
> >>> I am working on a radio astronomy project with the Green Bank
> >>> Observatory / NRAO Central Development Lab this summer, utilizing GNU
> >>> Radio and an Ettus Research SDR, and I've got a question regarding how
> >>> to collect metadata information from a filesink.
> >>>
> >>> I have attached the flowgraph I am using to this email. The project
> >>> requires that I use two computers in tandem for data collection -- one
> >>> is connected to the Ettus -- it is the TCP server, and sends an
> >>> interleaved data stream to the TCP client flowgraph (attached) on the
> >>> machine which will be storing the data. As you can see, I am saving
> >>> integrated spectra to a file. My question is simply, how do I retrieve
> >>> a time stamp corresponding to each spectra using the metadata time
> >>> sink? I have been fiddling with this all afternoon attempting to get
> >>> it to work properly, and I have been able to save data to a file, read
> >>> out spectra (using attached Python program), and display header
> >>> information using the command gr_read_file_metadata in the terminal,
> >>> but this is just showing me a timestamp for the beginning of the data
> >>> collection run, rather than showing me timestamps for each spectrum
> >>> which is saved to file, and I am not sure how to implement this.
> >>>
> >>> Any advice would be much appreciated! If I can provide any 

Re: [Discuss-gnuradio] Problem building gr-display

[Volker Schroer]

Now the gr-display master branch builds against gnuradio 3.8.0.0-rc2


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

Re: [Discuss-gnuradio] Problem building gr-display

[Volker Schroer]

Sorry I forgot: This is a outdated version as it was setup before
gnuradio switched to modern cmake. I have to publish my latest
gr-display version, but first I want to test it against the latest gnuradio.



Am 25.07.19 um 13:56 schrieb Ron Economos:

That OOT is just not up to date with GNU Radio 3.8. It needs to be
redone with the current gr_modtool.

Ron

On 7/25/19 04:36, Barry Duggan wrote:

Hi Chris,

Thank you for that. I'm still a newbie with git.

That process worked as far as cloning, but I am still getting the same
error:

"""
CMake Error at CMakeLists.txt:102 (message):
  GnuRadio Runtime required to compile display
"""

from CMakeLists.txt:
find_package(Gnuradio "3.8" REQUIRED PATHS ${CMAKE_INSTALL_PREFIX}
${GNURADIO_MODULE_DIRECTORY})

So I still don't know the correct path for GNURADIO_MODULE_DIRECTORY.

Thanks,
---
Barry Duggan


On 2019-07-25 02:48, Palmer, Chris wrote:

Barry,

Try this:

git clone https://github.com/dl1ksv/gr-display.git
cd gr-display
git checkout gnuradio3.8

-cp

From: Discuss-gnuradio
 on behalf
of Barry Duggan 
Sent: Wednesday, July 24, 2019 3:47 PM
To: Volker Schroer
Cc: Discuss Gnuradio
Subject: Re: [Discuss-gnuradio] Problem building gr-display

Hi Volker,

1) What specific URL should I use? I tried:

git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8
Cloning into 'gnuradio3.8'...
fatal: repository
'https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/' not found

and also:

git clone
https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/gr-display

2) Does the cmake command need to define GNURADIO_MODULE_DIRECTORY? If
so, what is the path?

Thanks,
--
Barry Duggan KV4FV

On Wed, 24 Jul 2019 16:30:02 +0200, Volker Schroer wrote:

On github in gr-display exists a gnuradio3.8 branch. Try this one.
Now that gnuradio switched to 3.8 I should switch the master branch to
3.8, 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


___
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] Problem building gr-display

[Ron Economos]

That OOT is just not up to date with GNU Radio 3.8. It needs to be 
redone with the current gr_modtool.


Ron

On 7/25/19 04:36, Barry Duggan wrote:

Hi Chris,

Thank you for that. I'm still a newbie with git.

That process worked as far as cloning, but I am still getting the same 
error:


"""
CMake Error at CMakeLists.txt:102 (message):
  GnuRadio Runtime required to compile display
"""

from CMakeLists.txt:
find_package(Gnuradio "3.8" REQUIRED PATHS ${CMAKE_INSTALL_PREFIX} 
${GNURADIO_MODULE_DIRECTORY})


So I still don't know the correct path for GNURADIO_MODULE_DIRECTORY.

Thanks,
---
Barry Duggan


On 2019-07-25 02:48, Palmer, Chris wrote:

Barry,

Try this:

git clone https://github.com/dl1ksv/gr-display.git
cd gr-display
git checkout gnuradio3.8

-cp

From: Discuss-gnuradio
 on behalf
of Barry Duggan 
Sent: Wednesday, July 24, 2019 3:47 PM
To: Volker Schroer
Cc: Discuss Gnuradio
Subject: Re: [Discuss-gnuradio] Problem building gr-display

Hi Volker,

1) What specific URL should I use? I tried:

git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8
Cloning into 'gnuradio3.8'...
fatal: repository
'https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/' not found

and also:

git clone
https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/gr-display

2) Does the cmake command need to define GNURADIO_MODULE_DIRECTORY? If
so, what is the path?

Thanks,
--
Barry Duggan KV4FV

On Wed, 24 Jul 2019 16:30:02 +0200, Volker Schroer wrote:

On github in gr-display exists a gnuradio3.8 branch. Try this one.
Now that gnuradio switched to 3.8 I should switch the master branch to
3.8, 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


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

Re: [Discuss-gnuradio] Problem building gr-display

[Barry Duggan]

Hi Chris,

Thank you for that. I'm still a newbie with git.

That process worked as far as cloning, but I am still getting the same 
error:


"""
CMake Error at CMakeLists.txt:102 (message):
  GnuRadio Runtime required to compile display
"""

from CMakeLists.txt:
find_package(Gnuradio "3.8" REQUIRED PATHS ${CMAKE_INSTALL_PREFIX} 
${GNURADIO_MODULE_DIRECTORY})


So I still don't know the correct path for GNURADIO_MODULE_DIRECTORY.

Thanks,
---
Barry Duggan


On 2019-07-25 02:48, Palmer, Chris wrote:

Barry,

Try this:

git clone https://github.com/dl1ksv/gr-display.git
cd gr-display
git checkout gnuradio3.8

-cp

From: Discuss-gnuradio
 on behalf
of Barry Duggan 
Sent: Wednesday, July 24, 2019 3:47 PM
To: Volker Schroer
Cc: Discuss Gnuradio
Subject: Re: [Discuss-gnuradio] Problem building gr-display

Hi Volker,

1) What specific URL should I use? I tried:

git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8
Cloning into 'gnuradio3.8'...
fatal: repository
'https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/' not found

and also:

git clone
https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/gr-display

2) Does the cmake command need to define GNURADIO_MODULE_DIRECTORY? If
so, what is the path?

Thanks,
--
Barry Duggan KV4FV

On Wed, 24 Jul 2019 16:30:02 +0200, Volker Schroer wrote:

On github in gr-display exists a gnuradio3.8 branch. Try this one.
Now that gnuradio switched to 3.8 I should switch the master branch to
3.8, 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

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Sumit Kumar]

Hi Johannes,
Thanks, it works now, but the input will be without quotes, i.e., False not
`False`.
Regards
Sumit

On Thu, Jul 25, 2019 at 10:22 AM Johannes Demel 
wrote:

> Hi Sumit,
>
> this is not an installation error. Your configuration is wrong. The
> argument `enb` must be of type bool but it is a string in your case.
> I assume you use GRC to generate this flowgraph.
> Open your USRP source block. Go to the `FE Corrections` tab and put in
> `False` in both fields. No `, ' or ". This will generate a line that says:
> `self.uhd_usrp_source_0.set_auto_dc_offset(False, 0)`
> instead of
> `self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)`.
> This should fix your issue.
>
> Cheers
> Johannes
>
> Am 24.07.19 um 19:33 schrieb Sumit Kumar:
> > Hi Michael,
> > Any update on this? I downgraded my install of uhd and gnuradio as
> > follows but I have the same error.
> >
> > Traceback (most recent call last):
> >File "/home/sumit/Desktop/top_block.py", line 122, in 
> >  main()
> >File "/home/sumit/Desktop/top_block.py", line 110, in main
> >  tb = top_block_cls()
> >File "/home/sumit/Desktop/top_block.py", line 78, in __init__
> >  self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)
> >File
> >
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> > line 3499, in set_auto_dc_offset
> >  return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb,
> chan)
> > TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2
> > of type 'bool'
> >
> > sumit@PP0380:~/gradio/src/gnuradio$ uhd_find_devices
> > [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> > *UHD_3.14.1.HEAD-0-g5491b80e*
> > --
> > -- UHD Device 0
> > --
> > Device Address:
> >  serial: 317DD1E
> >  addr: 192.168.10.2
> >  fpga: HG
> >  name:
> >  product: X310
> >  type: x300
> >
> >
> > sumit@PP0380:~/gradio/src/gnuradio$ gnuradio-companion --version
> > *GNU Radio Companion 3.7.13.5
> > *
> > This program is part of GNU Radio
> > GRC comes with ABSOLUTELY NO WARRANTY.
> > This is free software, and you are welcome to redistribute it.
> >
> > sumit@PP0380:~/gradio/src/gnuradio$ git status
> > On branch maint-3.7
> > *Your branch is up to date with 'origin/maint-3.7'.*
> > *
> > *
> > Regards
> > Sumit
> >
> > On Thu, Jun 27, 2019 at 8:07 PM Michael Dickens
> > mailto:michael.dick...@ettus.com>> wrote:
> >
> > __
> > I guess for your need so long as it works that's what matters, yes?
> >
> > We'll work on fixing the issue you found anyway ... seems like it's
> > legit & undesirable LOL.
> >
> > Good luck with your demo! - MLD
> >
> > On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
> >> Well it worked after compiling old checkouts (but not giving me
> >> the usual satisfaction of a fresh install... but anyways)
> >>
> >> On Thu, 27 Jun 2019 at 19:45, sumit kumar  >> > wrote:
> >>
> >> Its overwhelming :D, I have a demo on Monday and I was 100%
> >> assured gr-ieee-80211 will work as usual.
> >>
> >> Before I saw your mail, I already checked out GR to 3.7.12,
> >> UHD to 003 009 006 and compiling now.
> >> Yes I used pybombs for installation.
> >>
> >> I have a USB with gnuradio installed into it. It works good
> >> and it has GR 3.7.11, uhd 003 009 006 and gr-ieee-80211
> >> version I dint check.
> >
> >
> >
> > --
> > --
> > Sumit kumar
> > Postdoc
> > SnT, Luxembourg
> >
> >
> >
> > ___
> > 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
>


-- 
-- 
Sumit kumar
Postdoc
SnT, Luxembourg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Johannes Demel]

Hi Sumit,

this is not an installation error. Your configuration is wrong. The 
argument `enb` must be of type bool but it is a string in your case.
I assume you use GRC to generate this flowgraph.
Open your USRP source block. Go to the `FE Corrections` tab and put in 
`False` in both fields. No `, ' or ". This will generate a line that says:
`self.uhd_usrp_source_0.set_auto_dc_offset(False, 0)`
instead of
`self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)`.
This should fix your issue.

Cheers
Johannes

Am 24.07.19 um 19:33 schrieb Sumit Kumar:
> Hi Michael,
> Any update on this? I downgraded my install of uhd and gnuradio as 
> follows but I have the same error.
> 
> Traceback (most recent call last):
>    File "/home/sumit/Desktop/top_block.py", line 122, in 
>      main()
>    File "/home/sumit/Desktop/top_block.py", line 110, in main
>      tb = top_block_cls()
>    File "/home/sumit/Desktop/top_block.py", line 78, in __init__
>      self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)
>    File 
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
> line 3499, in set_auto_dc_offset
>      return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 
> of type 'bool'
> 
> sumit@PP0380:~/gradio/src/gnuradio$ uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
> *UHD_3.14.1.HEAD-0-g5491b80e*
> --
> -- UHD Device 0
> --
> Device Address:
>      serial: 317DD1E
>      addr: 192.168.10.2
>      fpga: HG
>      name:
>      product: X310
>      type: x300
> 
> 
> sumit@PP0380:~/gradio/src/gnuradio$ gnuradio-companion --version
> *GNU Radio Companion 3.7.13.5
> *
> This program is part of GNU Radio
> GRC comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to redistribute it.
> 
> sumit@PP0380:~/gradio/src/gnuradio$ git status
> On branch maint-3.7
> *Your branch is up to date with 'origin/maint-3.7'.*
> *
> *
> Regards
> Sumit
> 
> On Thu, Jun 27, 2019 at 8:07 PM Michael Dickens 
> mailto:michael.dick...@ettus.com>> wrote:
> 
> __
> I guess for your need so long as it works that's what matters, yes?
> 
> We'll work on fixing the issue you found anyway ... seems like it's
> legit & undesirable LOL.
> 
> Good luck with your demo! - MLD
> 
> On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
>> Well it worked after compiling old checkouts (but not giving me
>> the usual satisfaction of a fresh install... but anyways)
>>
>> On Thu, 27 Jun 2019 at 19:45, sumit kumar > > wrote:
>>
>> Its overwhelming :D, I have a demo on Monday and I was 100%
>> assured gr-ieee-80211 will work as usual.
>>
>> Before I saw your mail, I already checked out GR to 3.7.12,
>> UHD to 003 009 006 and compiling now.
>> Yes I used pybombs for installation.
>>
>> I have a USB with gnuradio installed into it. It works good
>> and it has GR 3.7.11, uhd 003 009 006 and gr-ieee-80211
>> version I dint check.
> 
> 
> 
> -- 
> -- 
> Sumit kumar
> Postdoc
> SnT, Luxembourg
> 
> 
> 
> ___
> 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] Development environment for GNURadio (python and C++)

[Jonas Manthey]

Hi all,

For developing python and C++ OOT modules and maybe working on GNURadio itself 
I am looking for a good combination of development environments. OS could be 
Linux, currently I am tending towards Debian 10. Windows 10 is also available 
with Visual Studio, but I think this doesn't go well with the GNURadio 
ecosystem.

For python I'd like to use PyCharm, for C++ I would like to not use Eclipse, so 
does someone know an alternative? Minimum requirements would be: GUI, 
breakpoints, watches.

Thanks & have a nice day,
Jonas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio