Re: [Discuss-gnuradio] S printouts and then either U printouts (and fails/stops transmitting) or seg fault with 4 USRPs

[Ed Criscuolo]

Do you have four unique IP addresses assigned to the four USRPs?
If they all have the same default address, this could cause the four
packet streams to look like one stream, but the sequence numbers
wouldn't track, hence the ""s.

@(^.^)@  Ed


On 6/23/16 10:24 PM, Pavan Yedavalli wrote:

Just an update on this:

I switched everything to a desktop with a dedicated ethernet port, and
connected all 4 USRPs to a switch, which is then directly connected via
ethernet to the computer. This has eliminated the Us, which means that
it is actually working decently (and not crapping out). Thanks to all
who advised with that. However, multiple Ss still get printed out at
basically every transmission. In addition, there are sometimes warnings
that say:

SSS
UHD Error:
 Control packet attempt 0, sequence number 452:
 RuntimeError: no control response, possible packet loss

This happens occasionally, but the Ss get printed out every time. While
it isn't blocking, since I am actually getting transmissions and it is
not crashing, I am still curious about how to solve this S problem.
Thanks again!

--
Pavan


___
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] samples/symbols CPFSK

[Ed Criscuolo]

Your flowgraph intrinsically has one symbol per sample in the data generation 
portion. You need a resampler just ahead of the throttle to interpolate in 
order to increase the number of samples per symbol. 

@(^.^)@ Ed
Sent from my iPhone

> On Jul 21, 2016, at 3:15 PM, Olivier Goyette  
> wrote:
> 
> Hi all !
> 
> I've been working on this flowgraph for a while now and I've been able to 
> pinpoint what is not working, but I don't understand how to resolve this so, 
> that's why i'm asking for your guidance.
> 
> Take a look at the flowgraph i've joined. The thing that doesn't seem to be 
> working on this setup is the samples/symbol in th CPFSK mod block. 
> 
> When I set this parameter to 1 i'm able to retrieve my message at the file 
> sink. So it tells me that what I did is okay in some way.
> 
> What is not working is when I set the same parameter to 6. At the beginning I 
> wasn't using the rational resampler and it wasn't working. So I thought I 
> would need something to "divide" the number of samples to retrieve each 
> symbols. I tried it with the rational resampler block and set decimation to 
> 6, but then, Daah..not working again.
> 
> There is something I can't work around here because I do not have sufficient 
> knowledge about this samples/symbol thing.
> 
> I'd like to hear from you pals if you could give me a bit of information 
> about how to make this work properly.
> 
> thank you ! 
> 
> ___
> 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] 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 &input_items,
   gr_vector_void_star   &output_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// Process a single incoming packet on the tun/tap pseudo 
network device
// by bitstuffing it, encapsulating it in an MPoFR frame, and 
pushing

// it into the bit_buf fifo.
encapsulate_incoming_packet();
  }

// If bit_buf fifo is still empty, push a FLAG into it
if(d_fifo.empty())
  {
push_flag();
  }

// Output a bit from the bitbuf in the low-order bit of the output byte
outbuf[i] = d_fifo.pop();
  }

  return noutput_items;
}


@(^.^)@  Ed


On 8/16/16 8:12 PM, Inspire Me wrote:

Hi Ed

Thank you for the response.
I like the idea of the second option. Could please expand the
explaination. I am new to gnuradio and don't yet fully grasp how the
scheduler works in detail. How do you terminate the work function early
and ensure the single 0x7E gets streamed immediately to the modulator so
that we don't get under runs. How quickly will the work function be re
executed by the scheduler ? As fas as CPU is concerned, I have a machine
with 16 cores ( 32 threads). I am not concened if one thread is consumed
by this. Could you send me a snippet of the work function you implemented.

Your assitance is much appreciated.

Kind Regards
Frank

On 17 August 2016 at 02:00, Ed Criscuolo mailto:e...@chessie.com>> 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 sy

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 mailto:e...@chessie.com>> 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 

[Discuss-gnuradio] CommRadio CR-1a

[Ed Criscuolo]

I've just ordered one of these SDR standalone radios, and it has the capability 
of outputting its I/Q samples on a USB port. 

Has anyone tried to interface one of these to GnuRadio yet?  Seems that it 
would be one solution for HF (aka shortwave) reception. 

http://www.commradio.com/cr-1-cr-1a-reference/

@(^.^)@ Ed
Sent from my iPhone

> On Sep 6, 2016, at 4:34 AM, Marcus Müller  wrote:
> 
> Yes, you can :) Offering synchronization using external 10MHz and PPS signals 
> is the purpose of the Octoclock-G !
> 
> However, the B210's LOs will have a random phase after every tuning, so you 
> must calibrate the relative phase offsets every time you tune
> Best regards,
> 
> Marcus
> 
>> On 06.09.2016 10:21, Samith Abeywickrama wrote:
>> Hi all,
>> 
>> I'm going to implement MUSIC(Multiple Signal Classification) algorithm to 
>> find Angle of Arrival of signal using two USRP B210s. Therefore I have 4 
>> antennas. But I need to synchronise my two USRP B210s. May I know that can I 
>> use Octoclock-G with my USRP B210s without any problem? Thank you in 
>> advance. 
>> 
>> -- 
>> Best Regards!
>> Samith
> 
> @(^.^)@ Ed
> Sent from my iPhone
> 
> 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] CommRadio CR-1a

[Ed Criscuolo]

On 9/6/16 10:56 PM, Cinaed Simson wrote:

On 09/06/2016 02:05 PM, Ed Criscuolo wrote:

I've just ordered one of these SDR standalone radios,


It appears to be a radio - not a SDR.


No, it is an SDR internally, with a self-contained User interface
and sound output that makes it a complete stand-alone radio.
It uses a PIC microcontroller and a DSP chip to perform
all radio functions, and the SW for both of these is upgradable.


and it has the
capability of outputting its I/Q samples on a USB port.


Evidently only under Windows using the vendors software.

Their Windows Spectrum display Software is irrelevant to
the I/Q protocol used on the USB port by the SDR.



3rd parties can write software based on their protocol.


Which is exactly what I want to do: Write a GnuRadio source
block. Hence, my first question is to see if any one has already
done this.  I've already put in a request to the manufacturer for
the details of the protocol.





Has anyone tried to interface one of these to GnuRadio yet?  Seems that
it would be one solution for HF (aka shortwave) reception.

http://www.commradio.com/cr-1-cr-1a-reference/

@(^.^)@ Ed
Sent from my iPhone



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

Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[Ed Criscuolo]

What about an RFNoC solution?

@(^.^)@ Ed
Sent from my iPhone

> On Sep 26, 2016, at 7:16 PM, Sylvain Munaut <246...@gmail.com> wrote:
> 
> Hi,
> 
> 
>> It seems like a perfect fit for a poly phase filter - however this is
>> something that I believe needs to be done in hardware (128 channels *
>> 200khz = about 60mhz sample rate this will not go over a USB cable, and
>> I doubt I can get this bandwidth into a laptop PC.
> 
> !?!?
> 
> 128 channels of 200 kHz = 25.6 MHz of bandwidth. You can totally get
> that to a laptop.
> B2xx or BladeRF will do that without issues given a sufficiently good laptop.
> Even a hackRF with USB2 only can nearly do it ( 20 MHz ).
> 
> If the transmission are "infrequent" you can even use the same trick
> that researchers used a while back to listen to all of bluetooth and
> deliberately alias the signal to fold the spectrum over itself.
> 
> 
>>Am I going to have to do FPGA work on my own?
> 
> Very likely.
> 
> 
>>Or - is there some existing cook book solution with the FPGA
>> configuration pre-cooked?
> 
> Very unlikely to find something "all done".
> Especially that if you don't want to ship the samples, a PFB is not
> all you need. You'd need demod for each channel in the hardware as
> well.
> 
> 
>> What I am looking for is the FPGA channelizer solution... hopefully an
>> existing one I could start with?
> 
> There is an embryon of one in the ettus rfnoc repo and AFAIK they
> might also replace it with another version soon.
> 
> But it's written for RFNoC and Series-7 Xilinx fpga. It'll need quite
> some adaptation to run on anything else.
> Also, AFAIU, it's incomplete and non-tested currently so ... YMMV.
> 
> 
> Cheers,
> 
>Sylvain
> 
> ___
> 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] OSX 10.10

[Ed Criscuolo]

Michael,

A few months ago, I upgraded to OSX 10.10.1  Yosemite.
My existing install of GnuRadio 3.7.5 continued to work,
but today I tried to recompile an OOT module and it
failed.  Something about a library incompatibility
change between Mountain Lion and Mavericks.

So I did a port selfupdate and tried to upgrade to
3.7.7.1.  The build failed, with:

--->  Computing dependencies for swig
--->  Building swig
Error: org.macports.build for port swig returned: command execution failed

The log file shows:

...
:info:build In file included from /usr/local/include/sys/file.h:26:
:info:build /usr/local/include/sys/Conf.h:28:12: fatal error: 'iosfwd' 
file not found

:info:build #  include 
:info:build^
...

Is this a known problem?

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] OSX 10.10

[Ed Criscuolo]

Mike,

  After spending the better part of 8 hrs doing the whole migration
procedure, as specified at the link you provided, I'm pretty much
worse off than before.  The restore script failed when building a
component (this time TCL instead of swig) with the same error.

"fatal error: 'iosfwd' file not found"

And of course, now all my ports are wiped out.

In digging into it, it seems to be somehow related to a mix of
different variants requested for the same port.  In particular,
requests that have and don't have the +universal, but are otherwise
identical.

I may try editing my "myports.txt" file to omit all but the most recent
versions of each port and try again.  Failing that, the only course
I see is to wipe everything again and start installing them one by one,
by hand. :((

Any suggestions would be welcome.

@(^.^)@  Ed



On 7/1/15, 8:58 AM, Michael Dickens wrote:

Hi Ed - When updating to a new major OS version (e.g., 10.[5-9] ->
10.10), you'll need to reinstall MacPorts. The recommended migration
procedure when using MacPorts is found at <
http://trac.macports.org/wiki/Migration >. I, personally, just start
from an empty disk, install the OS, migrate over my login & anything
else necessary, install MacPorts & selfupdate, then install GNU Radio
and other ports that I need. In this manner, I'm guaranteed that the
install is correct for the new OS, without any cruft.

It is certainly possible that programs compiled on 10.9 will still work
on 10.10, if the ABI usage is compatible. But, there's no guarantee.
Further, as you found out, updating doesn't always work. Hence the
reason for a clean migration as per the wiki page above.

Hope this helps! - MLD

On Tue, Jun 30, 2015, at 09:06 PM, Ed Criscuolo wrote:

A few months ago, I upgraded to OSX 10.10.1  Yosemite.
My existing install of GnuRadio 3.7.5 continued to work,
but today I tried to recompile an OOT module and it
failed.  Something about a library incompatibility
change between Mountain Lion and Mavericks.

So I did a port selfupdate and tried to upgrade to
3.7.7.1.  The build failed, with:

--->  Computing dependencies for swig
--->  Building swig
Error: org.macports.build for port swig returned: command execution
failed

The log file shows:

...
:info:build In file included from /usr/local/include/sys/file.h:26:
:info:build /usr/local/include/sys/Conf.h:28:12: fatal error: 'iosfwd'
file not found
:info:build #  include 
:info:build^
...

Is this a known problem?


___
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] OSX 10.10

[Ed Criscuolo]

Mu saga continues unhappily.

Cleared out everything again with

  sudo port-f uninstall installed
  sudo port clean all

Already had done a "sudo port selfupdate" on Wednesday, so port and
my tree are up to date.

Checked the macports.conf file and didn't see anything egregious.

Then, starting with a blank slate, entered a single line:

sudo port install gnuradio 
+docs+grc+jack+orc+portaudio+python27+qtgui+sdl+swig+uhd+wavelet+wxgui-full


This ran for an hour or so before failing while building swig (again)!
Excerpt from the log follows:

...
:info:build make[1]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_distfiles.macports.org_ports_devel_swig/swig/work/swig-3.0.5/CCache'
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o 
ccache.o ccache.c
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o 
mdfour.o mdfour.c
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o hash.o 
hash.c
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o 
execute.o execute.c
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o util.o 
util.c
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o args.o 
args.c
:info:build /usr/bin/clang -Os -arch x86_64 -Wall -W -I.   -c -o stats.o 
stats.c
:info:build make[1]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_distfiles.macports.org_ports_devel_swig/swig/work/swig-3.0.5/Source'

:info:build /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
:info:build In file included from args.c:21:
:info:build In file included from ./ccache.h:28:
:info:build In file included from /usr/local/include/sys/file.h:26:
:info:build /usr/local/include/sys/Conf.h:28:12: fatal error: 'iosfwd' 
file not found

:info:build #  include 
:info:build^
...


Help!

@(^.^)@  Ed



On 7/2/15, 12:43 PM, Michael Dickens wrote:

Hi Ed - Sorry to hear of your troubles migrating / upgrading MacPorts.
Yes, it can be a real pain. If you stick with default variants, then
most of the ports will be downloaded as pre-compiled binary. If you just
use MacPorts for GNU Radio related ports, then the easier way is to:

1) wipe all MP stuff ("sudo port -f uninstall installed");
2) "sudo port reclaim" and answer yes, to remove binary / tarball cruft;
3) "sudo port selfupdate"
4) install the ports you want (without dependencies; those will be taken
care of now, hopefully correctly).

The header 'iosfwd' provides the I/O stream Forward Declarations, so it
should be available in any C++ header install (whether clang or gcc, old
or new, Apple or MacPorts). Maybe your install is trying to mix C++
runtime libraries and headers? That would not be good.

You might want to check your MacPorts conf file to make sure it's still
appropriate for your new OS.

I -highly- recommend not using +universal unless you have to, by default
or otherwise; most ports work with it but some critical ones don't yet
(e.g., NumPy, SciPy).

Hope this helps! - MLD

On Thu, Jul 2, 2015, at 12:30 PM, Ed Criscuolo wrote:

After spending the better part of 8 hrs doing the whole migration
procedure, as specified at the link you provided, I'm pretty much
worse off than before.  The restore script failed when building a
component (this time TCL instead of swig) with the same error.

"fatal error: 'iosfwd' file not found"

And of course, now all my ports are wiped out.

In digging into it, it seems to be somehow related to a mix of
different variants requested for the same port.  In particular,
requests that have and don't have the +universal, but are otherwise
identical.

I may try editing my "myports.txt" file to omit all but the most recent
versions of each port and try again.  Failing that, the only course
I see is to wipe everything again and start installing them one by one,
by hand. :((

Any suggestions would be welcome.



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

Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable

[Ed Criscuolo]

On 7/23/15 8:56 AM, Ashraf Younis wrote:

Thank you for the examples and the explanation.
I believe I understand. Sticking with a square wave or anything that
involves a sinc envelop will always raise the spectrum.
Is there something that I can transmit that won't let this occur?


A pure sine wave should have a single peak on the spectrum.

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] USRP Competition

[Ed Criscuolo]

A "channel" is really just a high-level, somewhat arbitrary, agreement
berween a sender and a receiver on how to view a particular hunk of
spectrum.  It will vary, depending on the application.

For example, broadcast television divides its spectrum up into
6 MHz wide channels.  Broadcast FM, on the other hand, uses 200 KHz
wide channels.  And voice VHF uses 50 KHz wide channels.  There is no
innate concept of "channel"; its all in the application.

GnuRadio and the USRP are completely capable of implementing any of
these concepts of "channel", anywhere in the spectrum.  Its up to you.

But you'll be REALLY unpopular if you plop a 6 MHZ wide channel right
in the middle of the voice VHF band!  Not to mention earning a visit
from the FCC (if you're in the US)!

@(^.^)@  Ed



On 11/17/15 5:07 PM, Rama V wrote:

Thanks for the reply Marcus. So this channel concept lies in GNU Radio.
How can I really set from what channel I need to send the data or which
channels are free for the transmission. Do I need to write any code for
that? I am performing DARPA Spectrum competition wherein I need to
perform data transmission between two USRP by sensing which channels are
free and sending the data. Please suggest
Thank you

Regards,
Dave

On Nov 17, 2015 5:29 AM, "Marcus Müller" mailto:marcus.muel...@ettus.com>> wrote:

Dave,

the USRP has no notion of "channels". It's a concept that you have
in your software that deals with the samples coming from the USRP.
You can configure the USRP to arbitrary center frequencies.

Best regards,
Marcus

On 16.11.2015 03:06, Rama V wrote:


I would like to send data through specific channels among the
USRP. How do I know what channels are available? I have tried to
search for channels but I was not successful.  Are there any
commands that I need to provide for the available channels? Kindly
help.
Thank you

Regards,
Dave

On Nov 11, 2015 5:29 PM, "Rama V"
<ramav...@gmail.com
> wrote:

Hey all,
I would like to perform a specific application of competitive
strategy(competition) with my two USRP available by detecting
which channel is available for doing that. I have used the
command of ./usrp_spectrum_sense.py 2.434G 2.438G which have
 shown me the results which is attached in the picture below.
I would like to know of how to select which channel or
frequency band is available for performing my competition and
how will I be able to perform? Any suggestions are kindly
appreciated. Sorry if I am not too brief with that. Thanks

Regards,
Dave



___
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] DSSS sync question

[Ed Criscuolo]

On 2/5/16 6:46 PM, Richard Bell wrote:

No it wouldn't work. You have to synchronize before you start de-spreading.


I disagree.  Mathematically, its the same result if you synchronize,
then despread, or despread then synchronize.  In the real world,
however, its a different ballgame!

DSSS spread spectrum signals are usually spread out over enough
bandwidth that the energy per spread bit is BELOW the noise
floor.  This makes it impossible to do anything with the spread
bits directly.  You have to despread them first so that the
energy per bit gets up above the noise floor. What you end up
having to do is starting out _close_ to your chip rate, and try
correlating with your PN sequence over enough chips to cover
just one bit, and see if you get a correlation, if you don't,
you have to add an offset of one chip time  to the PN sequence
and try again.  When you reach the point that the average of
all of N despread chips you're looking at peaks, then you've got
the correct offset.

In addition, in order to allow for chip rate mismatch between the 
transmitter and receiver, you will have to actually work at twice

the chip rate so you can check -1/2, 0, and +1/2 offsets on each
try.  This guarantees that you will find the correct offset within
one chip time.

Once you have roughly acquired the chip clock and offset, you can
use a PLL in your despreader to lock onto it and track it, so you
can reliably despread the bits.

Note that, at this point, you still just have a _bitstream_,
with no idea where the byte or packet boundaries are.  For that,
you'll need some kind of packet structure, with a known header
or sync pattern, to find the byte and PDU boundaries.

This type of despreading is called unassisted despreading, in that
does not depend on knowing any data content.  Its weakness is that
it requires a largish number of chips per bit to work well.

There are also data-assisted despreaders that depend on knowing
something in advance about the data content, such as a fixed
sync word or preamble.  The algorithm for those is roughly the same,
except that you're looking for a correlation over a bigger chunk
of data (ie - a whole sync word) instead of over just one bit.

@(^.^)@  Ed

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

[Discuss-gnuradio] Adding Accessor Methods in GR 3.7

[Ed Criscuolo]

I've recently converted to GR 3.7, and am currently on 3.7.3.

I have created and run a new block in C++, but now want to add
an accessor method to the block's class.  I defined it in
_impl.h , in the public part of the
class declaration as follows:

  float get_samples_per_second(void)
{
  return d_samples_per_second;
}

This compiles fine, but when I try to access it from
GRC via a function probe, I get:

AttributeError: 'acq_test_1_cc_sptr' object has no attribute 
'get_samples_per_second'



Is there some additional 3.7 swig magic I have to go through
to make this accessor available from python?


@(^.^)@  Ed

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

Re: [Discuss-gnuradio] Adding Accessor Methods in GR 3.7

[Ed Criscuolo]

On 6/6/14 1:50 PM, Martin Braun wrote:


You also need to add the accessor in the include/*.h file as a virtual
member function.



Thanks Martin.  That did it, although I had to rerun cmake to get it
to propagate into the swig files.

@(^.^)@  Ed



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

Re: [Discuss-gnuradio] Adding Accessor Methods in GR 3.7

[Ed Criscuolo]

On 6/6/14 2:30 PM, Ed Criscuolo wrote:

On 6/6/14 1:50 PM, Martin Braun wrote:


You also need to add the accessor in the include/*.h file as a virtual
member function.



Thanks Martin.  That did it, although I had to rerun cmake to get it
to propagate into the swig files.



Guess I spoke too soon. :(  Although it worked fine on my OSX platform,
as soon as I moved it to an Ubuntu 12.04LTS platform and tried to
build it in a fresh build directory, the cmake ran ok but the make
failed somewhere in the swig stuff, on a cryptically named xml file
"_8__acq__test__1__cc_8h.xml"  with the error

" 'NoneType' object has no attribute 'compounddef' "

Prior to this change, I had been moving this OOT module
back and forth successfully between the two systems.

@(+.+)@ Ed


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

Re: [Discuss-gnuradio] Adding Accessor Methods in GR 3.7

[Ed Criscuolo]

On 6/6/14 3:20 PM, Tom Rondeau wrote:

On Fri, Jun 6, 2014 at 3:02 PM, Ed Criscuolo
mailto:edward.l.criscu...@nasa.gov>> wrote:

On 6/6/14 2:30 PM, Ed Criscuolo wrote:

On 6/6/14 1:50 PM, Martin Braun wrote:


You also need to add the accessor in the include/*.h file as
a virtual
member function.


Thanks Martin.  That did it, although I had to rerun cmake to get it
to propagate into the swig files.


Guess I spoke too soon. :(  Although it worked fine on my OSX platform,
as soon as I moved it to an Ubuntu 12.04LTS platform and tried to
build it in a fresh build directory, the cmake ran ok but the make
failed somewhere in the swig stuff, on a cryptically named xml file
"_8__acq__test__1__cc_8h.xml"  with the error

" 'NoneType' object has no attribute 'compounddef' "

Prior to this change, I had been moving this OOT module
back and forth successfully between the two systems.

@(+.+)@ Ed



Can you post more of the output so we can see where this is being
generated (maybe post the build log to pastebin or something)? Off the
top of my head, that doesn't look familiar.

Tom



It's not real long, so I'll post it here


edwardc@sdr-dev2:~/Gnu-Radio/gr-tdrss/build$ make
Scanning dependencies of target gnuradio-tdrss
[  5%] Building CXX object 
lib/CMakeFiles/gnuradio-tdrss.dir/acq_test_1_cc_impl.cc.o

Linking CXX shared library libgnuradio-tdrss.so
[ 10%] Built target gnuradio-tdrss
Linking CXX executable test-tdrss
[ 21%] Built target test-tdrss
[ 26%] Built target _tdrss_swig_swig_tag
[ 31%] Built target _tdrss_swig_doc_tag
[ 36%] Generating tdrss_swig_doc.i
Error in xml in file 
/home/edwardc/Gnu-Radio/gr-tdrss/build/swig/tdrss_swig_doc_swig_docs/xml/_8__acq__test__1__cc_8h.xml

Traceback (most recent call last):
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/swig_doc.py", 
line 255, in 
make_swig_interface_file(di, swigdocfilename, 
custom_output=custom_output)
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/swig_doc.py", 
line 198, in make_swig_interface_file

blocks = di.in_category(Block)
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py", 
line 140, in in_category

self.confirm_no_error()
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py", 
line 206, in confirm_no_error

self.check_parsed()
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py", 
line 203, in check_parsed

self._parse()
  File 
"/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/doxyindex.py", 
line 51, in _parse

self._members += converted.members()
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py", 
line 174, in members

self.confirm_no_error()
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py", 
line 206, in confirm_no_error

self.check_parsed()
  File "/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/base.py", 
line 203, in check_parsed

self._parse()
  File 
"/home/edwardc/Gnu-Radio/gr-tdrss/docs/doxygen/doxyxml/doxyindex.py", 
line 163, in _parse

self.set_descriptions(self._retrieved_data.compounddef)
AttributeError: 'NoneType' object has no attribute 'compounddef'
make[2]: *** [swig/tdrss_swig_doc.i] Error 1
make[1]: *** [swig/CMakeFiles/_tdrss_swig.dir/all] Error 2
make: *** [all] Error 2
edwardc@sdr-dev2:~/Gnu-Radio/gr-tdrss/build$




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

Re: [Discuss-gnuradio] Adding Accessor Methods in GR 3.7

[Ed Criscuolo]

On 6/6/14 3:50 PM, Tom Rondeau wrote:

On Fri, Jun 6, 2014 at 3:37 PM, Ed Criscuolo
mailto:edward.l.criscu...@nasa.gov>> wrote:

On 6/6/14 3:20 PM, Tom Rondeau wrote:

On Fri, Jun 6, 2014 at 3:02 PM, Ed Criscuolo
mailto:edward.l.criscu...@nasa.gov>
<mailto:edward.l.criscuolo@__nasa.gov
<mailto:edward.l.criscu...@nasa.gov>>> wrote:

     On 6/6/14 2:30 PM, Ed Criscuolo wrote:

 On 6/6/14 1:50 PM, Martin Braun wrote:


 You also need to add the accessor in the
include/*.h file as
 a virtual
 member function.


 Thanks Martin.  That did it, although I had to rerun
cmake to get it
 to propagate into the swig files.


 Guess I spoke too soon. :(  Although it worked fine on my
OSX platform,
 as soon as I moved it to an Ubuntu 12.04LTS platform and
tried to
 build it in a fresh build directory, the cmake ran ok but
the make
 failed somewhere in the swig stuff, on a cryptically named
xml file
 "_8__acq__test__1__cc_8h.xml"  with the error

 " 'NoneType' object has no attribute 'compounddef' "

 Prior to this change, I had been moving this OOT module
 back and forth successfully between the two systems.

 @(+.+)@ Ed



Can you post more of the output so we can see where this is being
generated (maybe post the build log to pastebin or something)?
Off the
top of my head, that doesn't look familiar.

Tom



It's not real long, so I'll post it here

==__==
edwardc@sdr-dev2:~/Gnu-Radio/__gr-tdrss/build$ make
Scanning dependencies of target gnuradio-tdrss
[  5%] Building CXX object
lib/CMakeFiles/gnuradio-tdrss.__dir/acq_test_1_cc_impl.cc.o
Linking CXX shared library libgnuradio-tdrss.so
[ 10%] Built target gnuradio-tdrss
Linking CXX executable test-tdrss
[ 21%] Built target test-tdrss
[ 26%] Built target _tdrss_swig_swig_tag
[ 31%] Built target _tdrss_swig_doc_tag
[ 36%] Generating tdrss_swig_doc.i
Error in xml in file

/home/edwardc/Gnu-Radio/gr-__tdrss/build/swig/tdrss_swig___doc_swig_docs/xml/_8__acqtest__1__cc_8h.xml
Traceback (most recent call last):
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/swig_doc.__py",
line 255, in 
 make_swig_interface_file(di, swigdocfilename,
custom_output=custom_output)
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/swig_doc.__py",
line 198, in make_swig_interface_file
 blocks = di.in_category(Block)
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
line 140, in in_category
 self.confirm_no_error()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
line 206, in confirm_no_error
 self.check_parsed()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
line 203, in check_parsed
 self._parse()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__doxyindex.py",
line 51, in _parse
 self._members += converted.members()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
line 174, in members
 self.confirm_no_error()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
line 206, in confirm_no_error
 self.check_parsed()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__base.py",
line 203, in check_parsed
 self._parse()
   File
"/home/edwardc/Gnu-Radio/gr-__tdrss/docs/doxygen/doxyxml/__doxyindex.py",
line 163, in _parse
 self.set_descriptions(self.___retrieved_data.compounddef)
AttributeError: 'NoneType' object has no attribute 'compounddef'
make[2]: *** [swig/tdrss_swig_doc.i] Error 1
make[1]: *** [swig/CMakeFiles/_tdrss_swig.__dir/all] Error 2
make: *** [all] Error 2
edwardc@sdr-dev2:~/Gnu-Radio/__gr-tdrss/build$


Ok, looks like your swig files weren't updated correctly. I'm not sure
here what the exact reason is. When you were converting over to the new
3.7 api, did you use gr_modtool to create the project space or did you
start with your current one and modify it? If the former, we'll have to
take a closer look. If the latter, I'd suggest looking at the
swig/tdrss_swig.i and swig/CMakeLists.txt files to see that they were
updated correctly.


Nope, I started fresh with gr_modtool for that very reason.
And when I mo

Re: [Discuss-gnuradio] Analog video modulation.

[Ed Criscuolo]

On 7/16/14 9:50 PM, Jordan Johnson wrote:

After finishing my AM Stereo transmitter, I have decided to build an
NTSC modulator. I think I have the actually modulation and filter blocks
down, I just need to firgure out how to get the right signals from a
digital video file. The file source wouldn't work; I would probably have
to use gstreamer. Anyone know exactly what I'm looking for and how to
get it? I need brightness, hue, saturation, and I believe that is it.

Thanks.
- Jordan



Try ffmpeg:

https://www.ffmpeg.org/

It's sort of the swiss army knife of video file processing.

@(^.^)@  Ed




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

Re: [Discuss-gnuradio] state of offline signal analysis tools in 2014?

[Ed Criscuolo]

On 7/16/14 10:52 AM, Peter A. Bigot wrote:

GNU Radio is a great tool for applications and dynamic experimentation,
but it doesn't have a lot of support for static/offline analysis of
time-series data.  I.e. I've captured some signal data and I want to
explore its properties interactively so I can figure out what I want to
do with it in GNU Radio.

The sort of capabilities I'm looking for include: Read time-series data
from files of different formats (some too large to fit in physical
memory).  Display the data, optionally applying linear transformations.
Interactively pan and zoom.  Jump forwards and backwards among
time-registered events.  Enable/disable/time-shift data overlays. Export
selected data to new files.  Calculate and display statistics and other
non-linear transformations of selected data.



If you have access to a Mac, DataGraph has much of this.  We use it
a lot to interactively manipulate large quantities of logged data.

http://www.visualdatatools.com/DataGraph/

@(^.^)@  Ed



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

Re: [Discuss-gnuradio] gr-mac in MacPorts

[Ed Criscuolo]

Michael,

  Thanks for the rapid response!

  Did a sync and tried installing it, and got the following
error while it was working off the dependencies:


[eds-mac:edwardc] edwardc% sudo port
MacPorts 2.2.1
Entering interactive mode... ("help" for help, "quit" to quit)
[edwardc] > install gr-mac
--->  Computing dependencies for libidn
--->  Fetching archive for libidn
.
.
.
--->  Installing icu @53.1_1
--->  Cleaning icu
--->  Deactivating icu @51.2_1
--->  Cleaning icu
--->  Activating icu @53.1_1
--->  Cleaning icu
Error: Unable to open port: can't read "configure.cxx_stdlib": no such 
variable

Error: Unable to execute port: upgrade gnuradio failed

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

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Ed Criscuolo]

Yep, that was me.  I was getting to pipe-in with the same suggestion.

@(^.^)@  Ed


On 10/10/14 8:20 PM, Vanush Vaswani wrote:

I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is regarded as a dodgy hack by all the GR developers here, but it
worked for me (and I read the article on latency). I believe the guy
who wrote GMSKSpacecraftGroundstation had the same problem, and found
it in one of his old threads.

On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob  wrote:

Hey John,

I am way out of my depth here, but while working on a custom python block
the other day, I saw some weird behavior in 3.7.5 that was similar.  Setting
the global max output had no effect, but setting the just-upstream block(s)
min/max output buffer size(s) low fixed my apparent slowliness.

Very Respectfully,

Dan CaJacob

On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury
 wrote:


Default scheduler.

tb.start(1024), with different values, etc, etc.

Most of the downstream blocks are stock GNU Radio blocks - a delay block
(max delay is 1 sample), logical operators, etc.  I guess I'll add some
printf debugging?

-John




On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller 
wrote:


Hi John,
On 10.10.2014 19:33, John Malsbury wrote:

Toward the end of the receive chain, there are a multitude of blocks that
are used for Viterbi node synchronization. I've found that the number of
blocks in series (3-5), combined with the low datarates at this point in
the flowgraph, lead to latencies on the order of 1-2 minutes.  That is to
say, once the node synchronization is accomplished, it takes 1-2 minutes
to
flush these blocks and get the fresh, good data through.  This is
measured
with function probes on the state of the sync process, and BERT analysis
of
the demodulator output [through TCP/IP socket].

I see you found the hidden interplanetary signal delay simulator.
Congrats! Watch out for the red shift in downstream samples.

No, seriously, that sounds like a lot.
You are using 3.6.4.1 with the default scheduler, tpb?

- I've tried messing around with the output buffer size option in the
flowgraph, but this seems l to have a negligible impact.

That surprises me. How did you mess around? top_block->run(1024)?
  Do your blocks really get called with smaller input item sizes? (do a
little printf-debugging)

- I can write some custom blocks to reduce the overall block count,
but
I have demonstrated that this provides a linear improvement, rather
than
the two-order-magnitude improvement I need.

Any general advice anyone can offer?  It feels like the right solution is
to force small buffer sizes on the relevant blocks...

agreed. But still. That sounds *bad*. Are you sure none of the block
demands a large input/output multiple?


Greetings,
Marcus

-John



___
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



___
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] High Flowgraph Latency in 3.6.4.1

[Ed Criscuolo]

On 10/10/14 9:15 PM, John Malsbury wrote:

Sounds dangerous if you also happen to have very high throughput
applications to run?  Am I wrong?



Yes, it was a fine line between getting it small enough for acceptable
latency while still maintaining enough throughput to not overrun.
Fortunately for our application we were able to strike that balance.

Your mileage may vary.

@(^.^)@  Ed


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

[Discuss-gnuradio] Packet sequence numbers

[Ed Criscuolo]

I'm using a vector-insert block to add a fixed-size header to a
stream of interleaved short samples at a fixed interval, and
then running it though

stream-to-tagged-stream => tagged-stream-to-PDU => Socket-PDU

to wrap it up in a UDP packet and send it out the network.
The header consists of 28 shorts, and the data of 512 shorts
(actually 256 complex short samples), to yield a UDP packet
payload of 540 shorts (1080 bytes).

This works fine for the fixed fields in the header, but two
of them are variable:  Sequence-number and timestamp.

Is there any convenient way from within GRC to insert an
incrementing number into one of the shorts in the header?
I know it can be done by writing a custom block, but is there
any way to use existing blocks from within GRC?

And what about the timestamp?  Any easy way _within GRC_ to
use and track the timetag from the USRP and the sample number
to gen up a timestamp value for the header?

@(^.^)@  Ed

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

[Discuss-gnuradio] Packet Header Generator

[Ed Criscuolo]

I'm trying to use the Packet Header Generator block
(not the Default one) from within GRC to generate a
packet header formatted to my own specification in
order to match an existing protocol.

I assume that an appropriate "formatter object" can
be submitted to this block to instruct it to build an
arbitrary header, but I'm having difficulty finding
any documentation or example of using a formatter object.
All I found points to the packet_header_default::header_formatter
method, which composes a fixed format that is of no use to me.

Any help point me in the right direction?  Am I just missing
it or is there no "generic" header formatter capability?

@(^.^)@  Ed



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

Re: [Discuss-gnuradio] Packet Header Generator

[Ed Criscuolo]

On 11/14/14 4:49 PM, Tom Rondeau wrote:

On Fri, Nov 14, 2014 at 3:14 PM, Ed Criscuolo
mailto:edward.l.criscu...@nasa.gov>> wrote:

I'm trying to use the Packet Header Generator block
(not the Default one) from within GRC to generate a
packet header formatted to my own specification in
order to match an existing protocol.

I assume that an appropriate "formatter object" can
be submitted to this block to instruct it to build an
arbitrary header, but I'm having difficulty finding
any documentation or example of using a formatter object.
All I found points to the packet_header_default::header___formatter
method, which composes a fixed format that is of no use to me.

Any help point me in the right direction?  Am I just missing
it or is there no "generic" header formatter capability?

@(^.^)@  Ed



Hey Ed,

Funny enough, I was just working on this today. I'm adding a similar
packet header generator for async (PDU-based) packets. The concept is
similar with a default base class that you'd overload for your own
purposes for packet formatting. I'll be documenting this behavior more
in the blocks themselves, and this should eventually become the basis
for another level of our tutorials.

I have it working here in simulation, but I know there's going to be
some trouble going over the air. I suspect I'll have something that's is
worth sharing and reasonably documented early next week.

Tom



OK.  Meanwhile, is there some clever Python hack I can use in the
interim?  I'm trying to get a timetag in a specific format
(64-bit integer, LSB=250 picoSeconds) into the header I'm generating.
It has to increment by 0x00028000 for each packet.

For example, for my sequence number field, I needed a 16-bit unsigned
number that skipped over any value where the last 5 bits are '1',
and rolled over at 2**16.  I used a repeating short vector source
with the Python list comprehension

[s for s in range(0,32768)+range(-32768,0) if s%32 != 31]

as the vector entry in the GR block.  This got merged with the
other header fields via stream mux block. It worked great.

But for the timetag, I don't have the rollover which allowed
me to pregenerate a a fixed (large) vector.  Any ideas?

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] gnuradio on OS X without X11

[Ed Criscuolo]

Thanks Kai.

Which OSX are you using: Mountain Lion, Mavericks, or Yosemite?

@(^.^)@  Ed

Sent from my iPod

On Dec 29, 2014, at 6:44 AM, Kai Garrels  wrote:

> Dear all,
> 
> not sure if this is still interesting: I managed to install gnuradio without 
> X11 on Mac OS X using these steps:
> 
> {{
> sudo port uninstall installed
> sudo port install py27-pygtk +quartz
> sudo port install gtk-osx-application -python27
> sudo port install gnuradio +quartz +no_x11
> grc
> }}
> 
> Best regards,
> kai
> ___
> 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] QPSK Receiver and Processing Power

[Ed Criscuolo]

On 2/18/15, 6:45 PM, Richard Bell wrote:

Hello all,

I am testing a QPSK Tx/Rx I made in grc across two USRP N210's. I can
demodulate and decode the data fine at the receiver to produce the bits
I transmitted. The problem is, when watching the frequency sink at the
output of the USRP source (picture attached), there is typically 4
seconds of latency between making a change at the transmitter and seeing
the change at the frequency sink block. I'm worried this is a bad sign
of things to come.


Richard,

  The lag is not due to processing power, but instead due to buffering
latency.  Every flow between blocks has a default buffer size of 64k
bytes.  This means that the LOWER sample rates will take longer to
traverse the buffer.

The latest versions of GRC include a block parameter to restrict the
buffer size.  This should be set to a much lower value than the default
for the portions of the flowgraph that are dealing with packed or
unpacked data bits, as these are at a MUCH lower rate than the I/Q
samples going into the demodulator.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Ed Criscuolo]

My blood pressure spiked for the first sentence and a half! (then I
remembered the date)

@(^.^)@  Ed


On 4/1/15, 3:30 PM, Martin Braun wrote:

*Move to .NET*: This is probably the biggest change for now. Because of
our continuing troubles with SWIG, we decided to move to a different
platform for interoperating between a high-performance language and an
easy scripting language, and .NET serves this cause. So, anything
previously written in C++ is now in C#, and for the simple stuff
(previously Python blocks) we now use ASP.NET. This is also fantastic as
it finally allows graphical development using Visual Basic. ...



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

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Ed Criscuolo]

Priyanka,

Based on what you've described so far, it sounds like the most
likely place for it is right after the signal source (UHD, Osmocom,
FCD, etc).

For example, if your source is sampling at a rate of 1e6 (one million)
samples per second, put the head block after it and set the count to
1000. This will shut down after 1 millisecond.

@(^.^)@ Ed


On 3/27/18 7:41 AM, Priyanka Priyadarshini wrote:

Thanks for your reply. But where should I connect the input and output
port of this head block?

Thanks

On Tue, Mar 27, 2018 at 1:26 PM, Gilad Beeri (ApolloShield)
mailto:gi...@apolloshield.com>> wrote:

Check out the Head block, which takes N as input, and stops (the
whole flowgraph as a result of how GNU Radio works) after N samples.
N = sample_rate * desired_duration


On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini
mailto:ppriyadarshin...@gmail.com>> wrote:

Hello,

I am very new to GNURadio and I have made a FM radio receiver in
which I am recording the data in a file sink.

But, I want to record the data for one millisecond(means i want
to stop the flow graph after 1 millisecond). How can I run the
execution of the flow graph for this specified time?

Any help would be appreciated. Thank you.

Priyanka
___
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] Discuss-gnuradio Digest, Vol 187, Issue 13

[Ed Criscuolo]

If you just hit reply, it only goes back to the poster. You need to hit "reply 
all" to get it to go back to the list. 

@(^.^)@ Ed
Sent from my iPhone

> On May 11, 2018, at 1:40 PM, F salem  wrote:
> 
> Dear all 
> 
> I made alot of post but it didn't shown in the list why?
> 
> sincerely
> Fahad Alqurashi
> 
>  
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length

[Ed Criscuolo]

But this would only work well if there is enough gap time and/or preamble bits 
and/or fill bytes between the packets. Otherwise, you will consume and discard 
the beginning of the next packet. 

@(^.^)@ Ed
Sent from my iPhone

> On Dec 31, 2018, at 4:52 AM, Daniel Estévez  wrote:
> 
> Hi,
> 
> Besides using the Header Payload Demuxer as Julian suggested, a simple
> trick when the packet size is unknown but limited to a (not very large)
> maximum size is to cut a PDU with the maximum packet size and then throw
> away everything you don't need.
> 

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

Re: [Discuss-gnuradio] Generating a preamble for an AX.25 Packet (HDLC Framer)

[Ed Criscuolo]

I believe you want to use event_stream

@(^.^)@ Ed
Sent from my iPhone

> On Jul 27, 2019, at 1:08 PM, Ido Bronfeld  wrote:
> 
> Hi everyone! I am trying to generate an AX.25 Packet with the HDLC Framer, my 
> issue is generating the preamble per the AX.25 spec (Repeating flags - 0x7e)
> 
> My previous setup was using a custom HDLC Framer block that generates the 
> preamble, and I am now trying to accomplish this task using "vanilla" Gnu 
> Radio blocks.
> 
> I tried using the Vector Source with the Tagged Stream Mux, but that does not 
> seem to work, I might not be doing it correctly.
> 
> I will include an image of my flowgraph, with the parameters.
> 
> Thanks,
> Ido Bronfeld
> Herzliya Space Laboratory
> 
> 
> 
> ___
> 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

Subject Line Prefix Missing

[Ed Criscuolo]

I've noticed that recent postings to the list are missing
the "[Discuss-gnuradio] prefix that was automatically
added to the subject line.

Was this  a deliberate change? I hope not, as I find that
feature very useful in picking out the list messages
from amid all the spam.


@(^.^)@  Ed

Re: Measure bit error rate.

[Ed Criscuolo]

On 3/6/20 6:00 AM, Md. Atiqur Rahman wrote:

Hello Everyone,
Again I have a question for another issue. In my project work, the
baseband complex signal generation and later on convert it to RF signal
is the main idea. These task is completed and I can successfully
demodulate the RF signal from the spectrum analyzer.
However, the signal generation was from a 'random signal' source and I
need to measure the BER. How can I do it? I read some documents and it
is mostly saying need a file sink, but what would be the file formate of
the sink?
I hope I will get some response.
Thank you in advance.


The typical way to measure BER is to use a repeating pseudo-random data
sequence of some known fixed length for the transmitted data.

The receiver needs to try and do a correlation between this repeatable
sequence and the received bits, sliding the comparison offset one bit at 
a time until the maximum correlation is found.  Then, you can count
the number of wrong bits vs the total bits in the sequence to get a BER 
figure.


Note; when using phase modulation, you may need to use two (BPSK) or
four (QPSK) possible symbol-to-bit decodings for each comparison in
order to find the right rotation of the phase constellation.

As a side note, this is essentially the same algorithm that is used
to acquire a spread-spectrum signal.

@(^.^)@  Ed

Re: .docx attachments (was Problems with the GNU WiFi and the USRP B210)

[Ed Criscuolo]

I too had the same immediate reaction, and did not look at the file.

For what its worth, I ran it through Jotti's Malware scanner, and
it found nothing suspicious.

@(^.^)@  Ed


On 6/26/20 4:12 AM, Johannes Demel wrote:

Hi Silvio,

please do not send docx Files. After reading Marcus answer, I assume
your file contains valid info. But I thought this was just a spam or
phishing mail. I'd totally expect some malicious macro in such a file. I
see such malicious attachments regularly going through my spam filter.
Also, use pdf please.

Since we are on a publicly archived mailing list, it is really
preferable to describe your issue directly in your email and just
reference illustrations. In the past, people were asked to upload files
to a platform and just add a link to their email.

Cheers
Johannes


On 26.06.20 01:21, Silvio Cardero wrote:

Please open and read the document

​

signature_658765992



Silvio Cardero

Chief Scientist

520.247.7275 (cell)

Web www.ed2corp.com 

Email Silvio@ed2corp _.com_

7636 N. Oracle Road

Tucson, Az. 85704

Re: Problems with packet communication using BPSK

[Ed Criscuolo]

Did you account for the 0-180 phase ambiguity when demodulating BPSK?
This would produce an inverted bitstream which wouldn't be noticeable
when transmitting alternating 1s & 0s.

@(^.^)@  Ed


On 8/10/20 2:50 AM, Shruti Gupta wrote:

Hi all!

I am working on implementing  BPSK communication system with SDR in
GNURadio. I tried implementing packet-communication in GNURadio using
two systems each acting as TX and RX. Using the examples provided in
gr-digital , I tried running TX and RX with LimeSDR Mini, but was unable
to get them to work. In order to identify and solve the issues, I moved
on to implementing everything in step-wise approach, as in-

 1. Transmit just alternating 1’s and 0’s using BPSK modulation and
receiving it on other end using synchronization and demodulation.
 2. Introduce packet structure into the previous raw-communication model .
 3. Then add FEC into the system and finally include CRC and achieve the
same packet-communication as provided with gr-digital.

In this step-wise approach, I was able to get raw communication model
(point 1 in above) work properly. However, I am not able to get packet
version (number 2) working. I used the same system settings just the
introduction of packet structure at TX and correlation estimation &
header-payload demux at RX but still no luck. Is there some issue with
the way I am implementing packet formation at TX or the correlation
estimator is the problem? You can find my implementation at following link:

https://drive.google.com/drive/folders/1TIWhNuVmclenhLj4qJK2HT-er6RoCcco?usp=sharing

Any suggestions/pointers in order to resolve the issue will be helpful.

Thanks and Regards
SG

Re: [Discuss-gnuradio] Looking for DSSS demodulator

[Ed Criscuolo]

Outstanding!  Thanks for putting in the time to make this happen!

What version of gnuRadio was it built against?

@(^.^)@  Ed


On 11/20/13 4:05 PM, Achilleas Anastasopoulos wrote:

I have been working on a DSSS system for some time now.
You can find our work-in-progress here:

https://github.com/anastas/gr-cdma.git

A few comments:

this project grew out of the DARPA spectrum challenge:
our team eventually dropped out of the race because of other time
commitments but
I decided to finish up the design and make it publicly available
since DARPA was generous enough to send us USRPs for testing etc.



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

[Discuss-gnuradio] GR 3.7.2.1 on OSX 10.8.5

[Ed Criscuolo]

I just upgraded my ports-installed version of GR 3.6.3 to
GR 3.7.2.1 with a simple "port upgrade gnuradio".
The install went smoothly without errors and installed
a working copy of 3.7.2.1 with only a few operational
issues.

Hats off to Michael Dickens for his superb job of supporting
GnuRadio on OSX!!  :)


Michael,

  I got the following when starting gnuradio-companion:

===
** (process:51809): WARNING **: Trying to register gtype 
'GMountMountFlags' as enum when in fact it is of type 'GFlags'


** (process:51809): WARNING **: Trying to register gtype 
'GDriveStartFlags' as enum when in fact it is of type 'GFlags'


** (process:51809): WARNING **: Trying to register gtype 
'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Warning: Block key "blocks_ctrlport_monitor_performance" not found when 
loading category tree.
Warning: Block key "blocks_ctrlport_monitor_performance" not found when 
loading category tree.
Mac OS; Clang version 4.1 ((tags/Apple/clang-421.11.66)); Boost_105500; 
UHD_003.007.000-0-unknown


<<< Welcome to GNU Radio Companion 3.7.2.1 >>>
===


Also, when I run a flowgraph, I see this in the output:

===
Executing: "/Users/edwardc/Work/gnu_radio/DAS_Test_01.py"

Warning: failed to XInitThreads()
Using Volk machine: sse4_1_64_orc
===


Are either of these significant?

@(^.^)@  Ed



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

[Discuss-gnuradio] Possible bug in gr::digital::mpsk_receiver_cc

[Ed Criscuolo]

GnuRadio 3.7.2.1
OSX 10.8.5

I was setting up a flowgraph in GRC using the
mpsk_receiver_cc block and encountered a problem.
Don't know if it is a bug in the GRC xml or a
missing method in the block code.

In GRC, the mpsk_receiver's "loop_bandwidth" parameter
is underlined in the properties popup, indicating
that it can be changed during runtime.  I entered the
name of a variable that was created in a Wx Slider widget.

At runtime, when I try to change the value, I get:

=
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/forms.py", 
line 180, in _handle

def _handle(self, event): self[INT_KEY] = self._slider.GetValue()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/gr/pubsub.py", 
line 52, in __setitem__

sub(val)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/forms.py", 
line 138, in _translate_internal_to_external

if self._callback: self._callback(self[EXT_KEY])
  File "/Users/edwardc/Work/gnu_radio/DAS_Test_01.py", line 181, in 
set_loop_bw

self.digital_mpsk_receiver_cc_0.set_loop_bandwidth(self.loop_bw)
AttributeError: 'mpsk_receiver_cc_sptr' object has no attribute 
'set_loop_bandwidth'

=

I checked the code, and indeed, there is no method by any name
for setting the loop_bandwidth attribute.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] Imcompatibility between GRC version and the USRP FW

[Ed Criscuolo]

On 3/26/14 8:08 PM, Gayathri Ramasubramanian wrote:
...


Though I have burned the latest images of usrp_n210_fw.bin and
usrp_n210_fpga_r4.bin  into usrp ,still it is not working. I get the foll
error message:

Error:Runtime Error
Please update the firmware and fpga images for your device
Expected protocol compatibility number [7 t 11], got 12
The firmware is not compatible with the host code build.


It looks like still have the wrong fpga & fw images.  You need to
uninstall UHD and reinstall the latest version from ettus.
This will get you the latest fw & fpga.  THEN burn them
into the USRP N210.  You should probably rerun make and
make install on gnuradio as well to insure you are linked
to the new UHD libraries.

@(^.^)@  Ed


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

[Discuss-gnuradio] SOQPSK

[Ed Criscuolo]

I've seen it stated here on the list that the MPSK receiver
block will work for either QPSK or OQPSK (Offset QPSK).

Anyone know if it will work with Shaped Offset QPSK
(SOQPSK) or the ARTM defined SOQPSK-TG?

@(^.^)@  Ed

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

[Discuss-gnuradio] GR 3.7.2.1 on OSX 10.8 (Mountain Lion)

[Ed Criscuolo]

Hi Michael,

  A short while ago, I installed 3.7.2.1 from your macports
implementation.  The install went without trouble, and
I've been composing and running flowgraphs from GRC
with no issues.

I recently tried to port one of my custom blocks up to
the 3.7 api, and I encountered problems.  In order
to try and eliminate as much as possible, I tried creating
a new gr-howto module, as per the tutorial.  It succeeds
the cmake but fails make during the link stage.

The first few errors emitted are
==
[  5%] Building CXX object 
lib/CMakeFiles/gnuradio-howto.dir/square_ff_impl.cc.o

Linking CXX shared library libgnuradio-howto.dylib
Undefined symbols for architecture x86_64:
  "pmt::dict_has_key(boost::intrusive_ptr const&, 
boost::intrusive_ptr const&)", referenced from:


gr::basic_block::has_msg_port(boost::intrusive_ptr) in 
square_ff_impl.cc.o

  "pmt::intrusive_ptr_add_ref(pmt::pmt_base*)", referenced from:

gr::basic_block::dispatch_msg(boost::intrusive_ptr, 
boost::intrusive_ptr) in square_ff_impl.cc.o
  std::map, 
boost::function)>, 
pmt::comparator, 
std::allocator const, 
boost::function)> > > 
>::operator[](boost::intrusive_ptr const&) in 
square_ff_impl.cc.o

...


It would seem to be a boost problem.  Port shows me as
having boost 1.55.0 installed.

The same exact module makes fine on a different system
running 3.7.2.1 under Ubuntu 12.04lts.

Any ideas?   Thanks!

@(^.^)@  Ed

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

[Discuss-gnuradio] Terminology Translation

[Ed Criscuolo]

Being more of an implementer than a mathematical theorist, I'm
having trouble "translating" the "language" spoken by our
local Matlab/Simulink boffins.

What's the proper way to implement an "Integrate and Dump"
operation in GnuRadio.  I've come across several mutually
contradictory suggestions.

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] Using GRC without UHD

[Ed Criscuolo]

Connect up a null sink and null source in parallel with the uhd blocks. Then 
right- mouse on the uhd blocks and select "disable".  This will gray-out the 
blocks and not compile them, but will leave them there preserving all your 
parameters.

@(^.^)@  Ed

Sent from my iPod

On Apr 8, 2014, at 11:36 AM, Ruecan  wrote:

> Hello GR,
> 
> Are there any fake sink and source blocks which simulates the uhd sink and
> source.
> I would like to test some flow graphs but for the moment I don't have access
> to the radios.
> 
> Or is there any other option, let's say using a channel block between the Tx
> and the Rx.
> 
> Any hints or explanation are well appreciated.
> 
> Regards,
> Ruecan
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Using-GRC-without-UHD-tp47451.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] New GRC behavior request for comment

[Ed Criscuolo]

On 4/10/14 3:55 PM, Tom Rondeau wrote:

I personally like this new method a lot. The downside is that if you
aren't paying attention, you might enter the wrong thing and hit ok or
enter only to find out then that you made an error and will have to
reopen the properties box to fix it.


In general, I like it too, but I see your point about "not paying
attention", as I'm a "hunt n peck" two-finger typist, and am
often looking down at the keyboard instead of at the screen.

How hard would it be to pop up a bother box if you attempt
to enter with outstanding parameter error(s).  Give you
a chance to confirm or cancel the enter, because you may want to
deliberately enter something that's wrong now but will be
fixed later (for instance a variable name that you haven't
created yet).


@(^.^)@  Ed


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

[Discuss-gnuradio] Freq Xlating FIR Filter Question

[Ed Criscuolo]

When using a Freq. Xlating FIR filter with decimation and taps
both set to 1, what determines the practical lower limit
for the resolution of the freq change?

@(^.^)@  Ed

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

[Discuss-gnuradio] Finding max index in a vector

[Ed Criscuolo]

How do I find the index of the max value in a vector from GRC?
The max_xx block outputs the max value, but not its
index, despite what it's documentation says:

"Data is passed in as a vector of length  from multiple input sources. 
It will look through these streams of  data items and output two 
streams. Stream 0 will contain the index value in the vector where the 
maximum value occurred."



I checked the code template for max (GR v3.7.3), and it doesn't even
seem to retain the index of the max it reports.

@(^.^)@  Ed

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

[Discuss-gnuradio] GR 3.7 Namespace Question

[Ed Criscuolo]

With the new use of C++ namespaces in the 3.7 API, is
it possible for an Out-of-tree (OOT) module to create blocks
that are part of an existing GR namespace?

For instance, if I have a new block that processes digital
data streams, can I create an OOT module called "digital"
and add my block to it?  Or will this cause a confusion
at link time, by creating two libraries with the same name?

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit

[Ed Criscuolo]

Marcel Maatkamp wrote:
I had the same error, but by upgrading port and cleaning gnuradio this 
error went away:
 
  % sudo port selfupdate

 % sudo port upgrade outdated
 % sudo port clean gnuradio
 % sudo port install gnuradio

After that it somehow still tries to install wxPython and will halt with 
this error:


Error: Target org.macports.build returned: shell command " cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py26-wxpython/work/wxPython-src-2.8.9.1/wxPython" 
&& 
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 
setup.py build " returned error 1

Command output:  from include/wx/wxPython/wxPython.h:22,
 from src/mac/_gdi_wrap.cpp:2736:
/opt/local/lib/wx/include/mac-unicode-release-2.8/wx/setup.h:962:1: 
warning: "SIZEOF_SIZE_T" redefined


I too tried this and got the same error.  I'm running OSX 10.6.2 on a
late model intel MacBook Pro.



If you get that error, omit the package py26-wxpython and install the 
other missing packages with:


 % sudo port install py26-cheetah py26-gtk atk gtk-doc docbook-xml 
docbook-xml-4.1.2 xmlcatmgr docbook-xml-4.2 docbook-xml-4.3 
docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl 
gnome-doc-utils iso-codes p5-xml-parser py26-libxml2 rarian getopt 
intltool gnome-common p5-getopt-long p5-pathtools p5-scalar-list-utils 
gtk2 cairo libpixman jasper pango shared-mime-info xorg-libXcomposite 
xorg-compositeproto xorg-libXfixes xorg-fixesproto xorg-libXcursor 
xorg-libXdamage xorg-damageproto xorg-libXi xorg-libXinerama 
xorg-xineramaproto libglade2 py26-cairo py26-gobject libffi py26-lxml 
gnuradio-gsm-fr-vocoder gnuradio-pager gnuradio-radar-mono 
gnuradio-radio-astronomy gnuradio-sounder gnuradio-trellis gnuradio-usrp 
gnuradio-video-sdl


After that everything is installed except gnuradio-utils which seems to 
depend on gnuradio-wxgui and py26-wxpython




This seemed to work, but grc is not installed either.  Attempting
to install gnuradio-grc yields the same original error.  Seems its still
trying to install the non-existent 64-bit version of wxPython.

@(^.^)@  Ed




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

Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit

[Ed Criscuolo]

Michael Dickens wrote:
Thanks for all the feedback thus far!  Can those of you on this thread  
return back to me the following (as executed in a terminal,  
individually):


gcc -v
machine
uname -a



% gcc -v

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure 
--disable-checking --enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
--build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 
--target=i686-apple-darwin10

Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)


% machine

i486


% uname -a

Darwin eds-mac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 
10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386



@(^.^)@  Ed


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

[Discuss-gnuradio] Status of VRT work

[Ed Criscuolo]

I was wondering what the status was for the VRT work.

Are there any dates set or expected for being able to
use the USRP2 on Mac OSX?

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit

[Ed Criscuolo]

Did you ever make these changes to the portfile for wxgui?

@(^.^)@  Ed


Michael Dickens wrote:
Hi Ed - Thanks for the feedback, it's useful; I don't mind being  
wrong!  I'll have to set up my Mac to do multi-boot (10.5 and 10.6) in  
order to further test this issue out.  That said, the kernel bit-tage  
doesn't really matter since it's the compiler that determines the  
applications bit-tage.  My guess is that, just like under 10.5, one  
can compile and execute 64-bit applications ... but under 10.5, 32-bit  
was the default while under 10.6, 64-bit is the default.  !...@#$% Apple  
for making all of this so %$#! complex ... I guess that's *&^%  
progress; not that I'm giving Linux cudos here for making the 32/64  
bit "easy"   I'll see if I can put some changes into the wxgui  
portfile so that it disallows 64-bit compiling for now, since that  
seems to be the common factor in the feedback I've received and in my  
testing. - MLD



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

Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit

[Ed Criscuolo]

Michael Dickens wrote:
Hi Ed - I never got multi-boot installed, so, no, I haven't gotten  
those changes in place.  That said, the MacPorts folks are discussing  
ways to get WX stuff to be 64-bit compatible under 10.6, so I might  
not need to do anything if they succeed soon enough.  How badly do you  
want / need them? - MLD


I have a meeting with a prospective client tomorrow and I want to
pitch the use of gnuradio for his spacecraft's groundstation.
It would be good if I could do development on my laptop instead
of having to use a desktop at their location.

I don't need 64-bit, I just need GRC to run.

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated

[Ed Criscuolo]

Michael,

  Some time back, I was trying to get a 32-bit version of GnuRadio,
including grc, to build and install on OSX 10.6.  That project went
on hold for a while, but is now starting to wake back up, so I gave
it another try, using your 3.3.0 macport.  Here's the
results:

OS is 10.6.4, on a 1-year old 17" MackBook Pro
2.8GHz Intel Core 2 Duo with 4GB of ram.
It came with 10.6 installed, and has Xcode installed.

First I upgraded ports with "sudo port selfupdate" .

Next, I removed all installed packages with
"sudo port -f uninstall installed"
and
"sudo port clean --work --archive all"

Next, I edited /opt/local/etc/macports/macports.conf to add
the line   "build_arch  i386"  to make the default
arch 32-bit instead of 64-bit.

Next, I did "sudo port install gnuradio".  This ground away
for a while and failed on Boost.  What I found was that the
Boost port seems to be broken when trying to build  32-bit
only.  Manually installing Boost by doing
"sudo port clean boost"  and
"sudo port install boost +universal"
got both 32-bit and 64-bit versions successfully built.

I then repeated "sudo install gnuradio" and came to the next
similar problem, this time with gcc44.  Again, cleaning, building
with +universal and then re-trying to install gnuradio
got past it.

Eventually, after a largish number of these, I was down to
only gnuradio-qtgui not installed.  A quick test of
gnuradio-companion brought up it's gui, and I was able
to construct and save a simple graph.

After more fighting with broken ports, I finally got
gnuradio-qtgui to install.  But then when I tried to
run gnuradio-companion, it failed, claiming it could not
find some files.

I (perhaps foolishly) uninstalled gnuradio-companion and
tried to reinstall it.  The build now fails!  The error from
the build log is:

.
.
.
:info:configure Component gr-wxgui will be included from a pre-installed 
library and includes.

:info:configure checking for PyQt4 for Qt4... no
:info:configure Not building component gr-qtgui.
:info:configure Not building component gr-sounder.
:info:configure Not building component gr-utils.
:info:configure Not building component gnuradio-examples.
:info:configure checking for xdg-mime... false
:info:configure checking for Python >= 2.5... yes
:info:configure checking for Python Cheetah templates >= 2.0.0... yes
:info:configure checking for Python lxml wrappers >= 1.3.6... no
:info:configure checking for Python gtk wrappers >= 2.10.0... no
:info:configure configure: error: Component grc has errors; stopping.
.
.
.

Checking my installed ports shows

  py26-gtk @2.17.0_1 (active)
  py26-wxpython @2.8.10.1_0+gtk (active)
  wxWidgets-python @2.8.10.1_1+gtk (active)



After two days, I'm stuck.  Any ideas?

@(^.^)@  Ed





Michael Dickens wrote:

I've updated the GNU Radio install via MacPorts to 3.3.0.
For those OSX users out there who are using GNU Radio and MacPorts, could you give this 
a shot & see if it works for you?  If you do install them for testing purposes 
& want to use a non-MacPorts GIT install for your actual work, make sure to 
deactivate / uninstall those from MacPorts -- usually there is no conflict between 
multiple GNU Radio installs, but it's just safer this way.

>

If you have thoughts or comments on the MacPorts install of GNU Radio on OSX, 
I'd love to hear from you. - MLD



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

[Discuss-gnuradio] WBX and USRP1 on GnuRadio 3.3

[Ed Criscuolo]

Is it possible to use a WBX daughtercard on a USRP1 with the
3.3 stable release of GnuRadio, or is it necessary to go to the
latest development code (or the UHD code)?

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] How to hold a values from file source

[Ed Criscuolo]

On 10/27/10 1:23 PM, Marcus D. Leech wrote:

Looking at the flow-graph, it seems like the modulation "bits" are
running at the same rate as the carrier frequency, which won't work--not
   even slightly.

Generally in AM/ASK, the modulation frequency is *much* lower than the
carrier frequency, my gut is that you'd need at least several cycles
   of carrier between each bit.




In addition, the two sample rates flowing into the multiplier are
different.  The 47 kHz "carrier" has a sample rate of 3Meg, while the
digital data has a sample rate of 47K.  You will need to upsample
your data stream to the same sample rate as the carrier. Since there
isn't an integer ratio between the two rates, you'll have to use
the rational_resampler block.

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] Does GNUradio have an envelope detector block?

[Ed Criscuolo]

gr_complex_to_mag will produce the envelope of an amplitude modulated carrier.

@(^.^)@  Ed

Sent from my iPod

On Oct 28, 2010, at 10:50 PM, songsong gee  wrote:

> Now I'm trying to build an ASK demodulator. I use GRC.
> 
> However, I REALLY REALLY couldn't find an envelope detector.
> 
> Does GNUradio have an envelope detector block?
> 
> Or, do I have to make that one?
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GRC 3.3.0 block documentation missing

[Ed Criscuolo]

On 10/29/10 10:42 AM, Rickard Nilsson wrote:

Hi list,

After reinstalling and upgrading the GNU Radio from version 3.2.2 to 3.3.0, on 
two different platforms, I have lost some of the valuable GRC documentation 
which was available earlier in the blocks. Many of the blocks now have much 
less (or none at all) information, and I need every bit.



I've noticed this too. :(

(^.^)@  Ed

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

Re: [Discuss-gnuradio] GRC 3.3.0 block documentation missing

[Ed Criscuolo]

On 10/29/10 12:29 PM, Josh Blum wrote:

Did you build and install the doxygen documentation?



I installed under OSX 10.6.4 using Michael Dickens' macports
packaging of 3.3.0


Look at/etc/gnuradio/conf.d/grc.conf
Is there documentation in the directory specified by doc_dir?



No, there is not.

I did further checking, and there is no doxygen package installed.
Further, doing a search of all "gnuradio*" packages in the
repository showed nothing that looked like a documentation package.

Michael, is this an oversight, or am I missing something?

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] GRC 3.3.0 block documentation missing

[Ed Criscuolo]

On 10/29/10 7:55 PM, Michael Dickens wrote:

I think it's not an oversight; maybe it's a feature?  If you installed GNU Radio via MacPorts' 
"gnuradio" port (or "gnuradio-*"), you need to do "sudo port install gnuradio 
+docs" to get the docs.  I made them separate because not everyone wants them&  they do take extra time 
to be created.

You (or someone) need to install "doxygen" to get documentation.  Looks like 
GNU Radio's build system auto-magically, and quietly, disables documentation if doxygen 
isn't available (meaning, 'configure' says it cannot find doxygen but 'docs' is still 
enabled in the list of components to be build; the disabling comes when it is time to 
actually build the docs).  This should probably be fixed, since it is confusing.

It's very straight forward to get documentation on OSX using MacPorts:

sudo port install doxygen

then re-run configure&  make if you're building from GIT.  Hope this helps! - 
MLD



Thanks Mike!  That did the trick.  I ran

"sudo port install doxygen"

followed by

"sudo port -f install gnuradio-companion +docs"

Had to use the "force" switch since gnuradio-companion was already
installed without the "-docs" variant, and install complains if
the variants don't match.

Just for reference, I'm using OSX 10.6.4 on a 17" MacBook Pro,
installing GR 3.3.0 via MacPorts, and building everything
32-bit by default.


@(^.^)@  Ed

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

[Discuss-gnuradio] Ubuntu 10.04 LTS

[Ed Criscuolo]

I just followed the build instructions for GnuRadio 3.3.0 on
Ubuntu 10.04 LTS. All the dependencies updated/installed without
trouble, and the

./configure
make
sudo make install

worked fine. However, trying to run gnuradio-compainion failed, and
produced a misleading suggestion to check the PYTHONPATH environment
variable.

The real solution was to run "sudo ldconfig".  After this, everytning
ran without problems.

Perhaps the 10.04 build instructions should be updated.

In any event, it would seem that the "make install" target should
include running ldconfig at the end.

@(^.^)@  Ed

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

[Discuss-gnuradio] RFX2200 and GnuRadio 3.3.0

[Ed Criscuolo]

I just tried to use a new RFX2200 daughterboard in a USRP1 with
the latest stable release GnuRadio 3.3.0, and it didn't recognize it.
Usrp_probe reported a Name of "Unknown (0x002C)".

What's the deal here? Do I need to go to the latest development
version to get it to recognize this card?  If so, that's a
problem, as we really want to stick with the release version
for configuration management reasons.

If I can't use 3.3.0 as-is, what are my options?  Is there a patch
for 3.3.0 to use this board?

Thanks for any help.

@(^.^)@  Ed


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

[Discuss-gnuradio] RFX2200 driver broken in latest git code

[Ed Criscuolo]

Since the RFX2200 does not seem to be supported by GR 3.3.0, I switched
over to the latest git source and tried it.  It seems to be broken
with respect to the RFX2200.  Probing the USRP now detects the card's
name correctly (Flex 2200 Rx MIMO B), but still complains that it
has "... invalid EEPROM contents ..."  and will be treated as a
"Basic Rx" board.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] RFX2200 and GnuRadio 3.3.0

[Ed Criscuolo]

On 12/9/10 4:07 PM, Jason Abele wrote:


Looks like the rfx2200 code for usrp1 is incomplete.  I have attached
a patch that should apply rfx2200 support to any gnuradio tree>=
3.3.0



Thanks Jason! You're a lifesaver!  I've got a pending delivery
in the next week or so that depends on this.  I'll try it out tonight.

One note.  After looking at the patch, it looks like it won't work on
on GR 3.3.0, as it has NO support at all for the RFX2200.  Specifically,
the definitions for USRP_DBID_FLEX_2200_TX_MIMO_B and
USRP_DBID_FLEX_2200_RX_MIMO_B are not present.

But this patch looks like it will work on the clone I made from
git://gnuradio.org/gnuradio, which has the incomplete support.  I'll
let you know how it goes.


I guess I'm the first one to try using the RFX2200 on an USRP1.
(or maybe anywhere?)

@(^.^)@  Ed

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

[Discuss-gnuradio] Weird List Behavior

[Ed Criscuolo]

Something strange is going on with the list server.

Posts are showing up in the archives within a few hours, but I'm not
getting them in my inbox until almost a day later!

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] RFX2200 driver broken in latest git code

[Ed Criscuolo]

On 12/10/10 12:24 PM, Jason Abele wrote:

On Thu, Dec 9, 2010 at 5:15 AM, Ed Criscuolo
  wrote:

Since the RFX2200 does not seem to be supported by GR 3.3.0, I switched
over to the latest git source and tried it.  It seems to be broken
with respect to the RFX2200.  Probing the USRP now detects the card's
name correctly (Flex 2200 Rx MIMO B), but still complains that it
has "... invalid EEPROM contents ..."  and will be treated as a
"Basic Rx" board.



Jason,  as I mentioned in another post, the list server is behaving
strangely, not delivering some posts until almost a day later.  I
sent the above post BEFORE I ever got any of your e-mails!


Could you clarify this a bit ... is usrp_probe telling you "invalid
EEPROM contents", is that usrp_fft.py or usrp_siggen.py or some other
app using the usrp?


Both usrp_probe and gnuradio-companion are producing this message.



Is this on gnuradio.org "master"?  .


Yes.


Did you apply the patch I sent?



I tried applying the first patch you sent to a clone of the GnuRadio
master, but the patch application failed, so I couldn't test it.


You can get working usrp1 GNURadio 3.3 or master support for RFX2200
from my github repos while we get it merged into gnuradio.org
maint/master/next branches.

git remote add jabele-github git://github.com/jasonabele/gnuradio.git

Then, for GNUradio 3.3 support:
git checkout jabele-github/rfx2200_maint

For GNUradio "master":
git checkout jabele-github/rfx2200

If you build one of those and confirm it works on the mailing list, it
will speed up the merge into gnuradio.org


Last night (Thurs) did a clone from
git://github.com/jasonabele/gnuradio.git ,
and successfully built and installed it on Ubuntu 10.04LTS.
Both usrp_probe and gnuradio-companion are now able to talk to the
RFX2200 on a USRP1 without getting any error. It seems to work.

Thanks again for all your help.

Any idea when a 3.3.1 maintenance release will be officially out?

@(^.^)@ Ed

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

Re: [Discuss-gnuradio] Fw: Need Advice for SDR choice

[Ed Criscuolo]

On 1/3/11 3:49 AM, Andrew Rich wrote:


3. I would like to be able to decode AX25 packet (ISS)


Check out the CGRAN repository.  The GMSK Spacecraft Groundstation
Project ( https://cgran.org/wiki/GMSKSpacecraftGroundstation ) has
an HDLC decoder block in it.  AX.25 is built on top of HDLC, so
this would give you a good start.

@(^.^)@  Ed

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

[Discuss-gnuradio] E100 Suitability for Space Applications

[Ed Criscuolo]

Matt,

  I'm considering the E100 for use with GnuRadio/UHD
aboard a small spacecraft, and I have a few of questions:

1.  What's the power drain?  Watt-hours are always at a
premium aboard a small spacecraft.

2.  Are there any vacuum-sensitive components?  For example,
electrolytic capacitors are no good (they dry out or rupture)
but tantalum's are ok.

3.  Is cooling an issue?  Air-cooled heatsinks don't work in
vacuum, and have to be replaced with conduction cooling.

4.  Any Lithium batteries?  They are considered hazardous for
space and require special provisions or removal.

5.  Without writing any FPGA or DSP code, what's the ballpark
sample rate that the ARM can keep up with?

TIA for any answers you can give.

@(^.^)@  Ed

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

[Discuss-gnuradio] Who actually *does* use GNU Radio?

[Ed Criscuolo]

On 1/21/11 4:19 AM, Martin Braun wrote:

Talking of which: Who actually *does* use GNU Radio? I can't see a whole
lot of active projects going on, not on this list or on CGRAN.


I'm currently implementing my third spacecraft groundstation using
GnuRadio. It's due to go into operation late this year.  The
improvements in GnuRadio & GRC between 3.1, 3.2, and 3.3 have
been significant, and made each one easier.

I'm also in the process of planning how to use GnuRadio
(plus USRP2 & WBX) to bench-test new modems for the
TDRSS spacecraft groundstations.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] USRP2 transmission issues

[Ed Criscuolo]

On 1/31/11 11:51 AM, nyquist82 wrote:


I do not understand what you mean by "proper" bandwidth. And what are these
"proper" USRP2 `s bandwidth? Thanks anyway for your reply.


The USRP2 runs at 100 Msamples/sec.  There is no integer decimation
factor that will yield exactly 8 Msamples/sec for an 8 MHz bandwidth.

100 / 12 = 8.3...

100 / 13 = 7.69230769


@(^.^)@  Ed

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

[Discuss-gnuradio] GR 3.6.1 and OSX

[Ed Criscuolo]

What's the current status of GR 3.6.1 on OSX 10.6 (Snow Leopard)?

Will it install?  I've been chasing my tail on dependencies for
two days.  At one point I got it to build, but almost all of the
tests failed with dynamic library problems.  I've attempted
to track down all of the dependencies and make sure they're built with
x86_64 or universal, but having no luck.

The OSX build instructions on the wiki are woefully out-of-date
(for GR 3.3.0).  The README that came with 3.6.1 says that
the dependency list was removed to avoid maintaining it in two
locations, and points to the build page on the wiki.  The build
page on the wiki simply has a link that takes you back to the
3.6.1 README!

Any suggestions or help would be appreciated.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] IF value of the RF front end

[Ed Criscuolo]

Broadcast FM has a channel bandwidth of 150 kHz, so a sampling rate of 200 or 
256 ksps should work fine. Don't confuse the sampling rate of the zero-IF data 
with the sampling rate of the front-end, which is 64 msps (USRP1) or 100 msps 
(USRP2).

The UHD API tends to hide this. In the old classic interface, you directly set 
the  decimation factor, so you had to know the hardware sample rate in order to 
know what sample rate you would end up with.

@(^.^)@  Ed

Sent from my iPod

On Jul 11, 2012, at 8:36 AM, Jamie Wo  wrote:

> Hi Nick,
> 
> Thanks for your reply. 
> 
> But I am not sure whether I understand what you said. My understanding is 
> that the WBX converts RF signal into baseband signal directly, while for 
> TVRX2, the RF signal is converted into low IF signal firstly by TVRX2 and 
> then converted into basebad signal by USRP's FPGA. Am I right?
> 
> Then, what is the sampling rate should I set to sample the signal of 
> interest. For example, FM radio signal at 106.3MHz. 
> 
> Best regards,
> Jamie 
> 
> On Wed, Jul 11, 2012 at 12:34 AM, Nick Foster  wrote:
> Jamie,
> 
> WBX is a direct-conversion receiver, meaning there is no IF: it is a 
> quadrature receiver where the LO frequency is equal to the RF frequency.
> 
> TVRX2 is a low-IF receiver using a 12.5MHz IF.
> 
> Both daughterboards can be treated as zero-IF direct conversion receivers for 
> tuning purposes, as the digital downconverter in the USRP's FPGA will 
> downconvert any residual IF to baseband before returning samples to the host. 
> In other words, when you tune the USRP to 2.2GHz, the resulting samples will 
> have a center frequency of 2.2GHz.
> 
> If you have a need to tune the LO frequency separately from the DDC/DUC 
> frequency, you can do that using the advanced tuning parameters: 
> http://files.ettus.com/uhd_docs/manual/html/general.html#two-stage-tuning-process
> 
> Best,
> Nick
> 
> On Mon, Jul 9, 2012 at 11:14 PM, Jamie Wo  wrote:
> 
> Hi all, 
> 
> As far as I know the maximum sampling rate for USRP N210 is 25M sps. To 
> receive signal with high frequency, such as 300 MHz to 2.2 GH, the RF front 
> end converts the RF into IF, so the ADC can sample the IF signal. My question 
> is what  the IF value is for daughter-board WBX?  Where can I reset the 
> immediate frequency of the daughter-board, such as WBX and TVRX2?
> 
> It may be a simple question, but I cannot find the answer. Any explanation 
> will be appreciated.
> 
> Best regards,
> Jamie
> 
> ___
> 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] base band signal sample frequency in RFX 900 daughter board

[Ed Criscuolo]

On 8/9/12 11:09 AM, pengyu zhang wrote:


Receiver's configuration code:
rx = usrp.source_c(0, dec_rate, fusb_block_size = 512, fusb_nblocks = 8)


The decimation rate determines the final sample rate.

For example:
  Since the USRP1 digitizes at 64 Msamples/sec, a decimation factor
of 64 would yield baseband complex samples at 1 MSamples/sec.

@(^.^)@  Ed

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

[Discuss-gnuradio] WBX upper range limit

[Ed Criscuolo]

I have an application that requires transmitting at 2287.5 MHz.

Can the GR3.6.1/UHD/USRP2/WBX combination tune to that freq?
I know it's above the published range for the WBX (2200 Mhz)
but these ranges are often rounded.

Assuming the WBX will/can get there (Matt?),  is there any
limit checking in the daughtercard driver sw that hard limits
the WBX to 2200 MHz?

TIA.

@(^.^)@  Ed




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

[Discuss-gnuradio] Stream Tags

[Ed Criscuolo]

I'm starting up on another R&D project using GnuRadio.

The project is a transponder, used by NASA for ranging.
It uses DSSS on both the uplink and the downlink.  The
transponder has to be coherent, and it synchronizes the
PN epochs of the received uplink and the transmitted downlink.
This allows the groundstation to compute the round-trip time,
(and hence the range), by comparing the offset of the
received epoch to that of the one originally transmitted
to the transponder.

My plan is to use stream tags to accomplish the
synchronization.  This will require getting a time tag
for each received sample, identifying the time of the
first sample associated with the epoch of the received
uplink, and using that time to start the transmission
of the first sample of the downlink epoch a small integer
number of epochs later (to allow for GnuRadio latency).

I have not yet used stream tags, and have a number of
questions:

1. Is it possible to get timetags for every sample?  My
   readings on time tags seemed to imply that only one
   is created at the beginning of a stream.

2. What is the accuracy/precision of the time tags?  Jitter
   is going to be the make-or-break factor on this project.

3. It looks like the Start-Of-Burst (SOB) tag is the only
   way to control the time of transmission.  Is there any
   limitation on the length of a burst?  In my case, I would
   want to start the transmitter in response to receiving
   the uplink, and not stop it until the uplink ceases,
   about 4 minutes later.

4. Is there any good tutorial or example information on
   the use of stream tags? (I'm using GR 3.6.1)

5. Does all this sound like I'm headed in the right direction,
   or is there something fundamental that I'm missing?

Thanks in advance for any help!

@(^.^)@  Ed

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

[Discuss-gnuradio] MPSK Receiver Class

[Ed Criscuolo]

In my current project, I'm using the MPSK Receiver Class to receive
a QPSK modulated signal.  We have requirements to log the frequency
and phase offsets from the spec more-or-less continuously in order to
do doppler-related post-processing.

Is there any way to get the current frequency & phase values that
the MPSK Receiver Class's loop(s) are locked to?  I've looked
through the 3.6.1 Doxygen docs for this class, but didn't find any
accessor methods for these values.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] IIR Filter taps

[Ed Criscuolo]

On 11/19/12 10:11 AM, Tom Rondeau wrote:


used? Should be change the way gr_iif_filter takes in the taps, or
should we change how gr_filter_design produces them?

Thanks for the feedback!

Tom


I agree that changing the way gr_iir_filter takes in the taps could
be disruptive, unless backward compatibility is maintained. Some of
the group are using GnuRadio for operational systems.

Here's two more suggestions for solutions:

1.  Add an optional flag parameter to the constructor, with values
of "Old_API" and "New_API",  with the default set to "Old_API".
This flag would control how gr_iif_filter interprets the taps.
It could be maintained this way for some time, with the Old_API
being deprecated, and eventually change the default to
New_API, or even make the default a cmake option.

2. Create two subclasses of filter taps that are identical in
   format, and use C++ overloading to determine which constructor
   or set method to use.

@(^.^)@  Ed

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

[Discuss-gnuradio] Raspberry Pi Activity?

[Ed Criscuolo]

Has anyone been using Gnu Radio on a Raspberry Pi lately? (just got one for 
Xmas :) )  Any special build procedures for 3.6.3?

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] Raspberry Pi Activity?

[Ed Criscuolo]

On 1/17/13 10:35 AM, Philip Balister wrote:

On 01/17/2013 08:57 AM, Ed Criscuolo wrote:

Has anyone been using Gnu Radio on a Raspberry Pi lately? (just got one for 
Xmas :) )  Any special build procedures for 3.6.3?


Please remember the R-pi is an armv6 based processor with a vfp unit
(not a NEON SIMD unit). Do not expect much signal processing performance
from this.

Armv7 + NEON is much better.

Philip


I thought it has an Arm11!  From Wikipedia:

"The Raspberry Pi has a Broadcom BCM2835 system on a chip (SoC),[3] 
which includes an ARM1176JZF-S 700 MHz processor VideoCore IV 
GPU,[12] and originally shipped with 256 megabytes of RAM, later 
upgraded to 512MB."


Wikipedia also states:

"ARM11 is an ARM architecture 32-bit RISC microprocessor family which 
introduced the ARMv6 architectural additions. These include SIMD media 
instructions, multiprocessor support and a new cache architecture."


These would seem to imply that the R-Pi has SIMD instructions available.

In addition, the VideoCore IV GPU looks like it's a pretty capable
DSP in it's own, capable of running it's own applications without the
CPU.  Sounds like Volk could take advantage of it as well.




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

Re: [Discuss-gnuradio] Raspberry Pi Activity?

[Ed Criscuolo]

Marcus, Phillip, Thomas, Aylons, & Iain,

  Thanks for all the good ARM info.  Obviously ARM is not
my area of expertise.

  As for the R-Pi, yes its a toy.  I'm just casting about
for interesting things to do with it, and wondered if it,
combined with a B100 or a USRP1, might make up a low-power/
low-cost transceiver with just enough capability to make it
suitable for a small spacecraft.

 Hopefully, someone with time on their hands will feel challenged
enough to try and reverse-engineer the GPU driver code to the
point where it can be incorporated into volk.

  Meanwhile, it sounds like the Beagle Bone would be a better choice.


@(^.^)@  Ed

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

Re: [Discuss-gnuradio] GNU Radio release 3.6.3 available for download

[Ed Criscuolo]

Mike,

  I've been avidly following this thread, since I recently had to
upgrade (company policy) to OSX 10.8, and I wanted to get my
gnuradio install running again at the 3.6.3 release.

  It looked like things had mostly settled down, so I made sure any
old files were uninstalled, and tried
the steps below, gleaned from this thread, but in the end
there was no executable command "gnuradio-companion" anywhere
to be run.  All that showed up was gnuradio-config-info, even after
reboot.

Any ideas?  $PATH & $PYTHONPATH appear to be set right:

[eds-mac:~] edwardc% echo $PATH
/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin

[eds-mac:~] edwardc% echo $PYTHONPATH
/opt/local/lib/python2.7/site-packages:/usr/local/lib/python2.7/site-packages
[eds-mac:~] edwardc%


I'm stumped! Even spotlight can't find gnuradio-companion, so something
must have failed, but what?  I got no error messages during the builds.

@(^.^)@  Ed



STEP 1. Downgrade Boost
--

bash-3.2$ mkdir tmpboost
bash-3.2$ cd tmpboost/
bash-3.2$ svn co -r 98466 http://svn.macports.org/repository/macports
... svn messages...
bash-3.2$ cd boost
bash-3.2$ sudo port build
... port messages ...
bash-3.2$ sudo port installed boost*
The following ports are currently installed:
  boost @1.50.0_0
  boost @1.52.0_1+no_single+no_static+python27 (active)
bash-3.2$ sudo port
[tmpboost/boost] > activate boost@1.50.0_0
--->  Computing dependencies for boost
--->  Deactivating boost @1.52.0_1+no_single+no_static+python27
--->  Cleaning boost
--->  Activating boost @1.50.0_0
--->  Cleaning boost
[tmpboost/boost] >

STEP 2. Install uhd
---
[tmpboost/boost] > variants uhd
uhd has the variants:
   debug: Enable debug binaries
   docs: build documentation
   examples: enable examples
   libusb: enable USB support via libusb version 1.0
   manual: build manual
   python26: Build UHD for Python 2.6
 * conflicts with python27
[+]python27: Build UHD for Python 2.7
 * conflicts with python26
   tests: enable tests
   universal: Build for multiple architectures
[tmpboost/boost] > install uhd +libusb +docs +python27 
configure.compiler=llvm-gcc-4.2

... lots of ports messages ...
[tmpboost/boost] > installed boost* 


The following ports are currently installed:
  boost @1.50.0_0
  boost @1.52.0_1+no_single+no_static+python27 (active)

[tmpboost/boost] > activate boost@1.50.0_0 


--->  Computing dependencies for boost
--->  Deactivating boost @1.52.0_1+no_single+no_static+python27
--->  Cleaning boost
--->  Activating boost @1.50.0_0
--->  Cleaning boost
[tmpboost/boost] >

STEP 3. Install gnuradio
-
[tmpboost/boost] > variants gnuradio
gnuradio has the variants:
   debug: Enable debug binaries
   docs: Install GNU Radio documentation
   full: Enable all variants except python (and, for next, ctrlport)
 * requires docs grc jack orc portaudio qtgui sdl swig uhd wavelet 
wxgui

   grc: Install GNU Radio Companion
 * requires swig
   jack: Install GNU Radio with support for JACK audio
   orc: Install GNU Radio Volk with support for ORC
   portaudio: Install GNU Radio with support for portaudio audio
   python26: Build GNU Radio using Python 2.6
 * conflicts with python27
[+]python27: Build GNU Radio using Python 2.7
 * conflicts with python26
   qtgui: Install GNU Radio with support for Qt GUI
   sdl: Install GNU Radio with support for SDL-based video
   swig: Install GNU Radio with support for SWIG-base Python bindings
   uhd: Install GNU Radio with support for UHD
   universal: Build for multiple architectures
   wavelet: Install GNU Radio Wavelet component
   wxgui: Install GNU Radio with support for Wx GUI

[tmpboost/boost] > install gnuradio +orc +uhd +docs +grc +jack 
+portaudio +python27 +qtgui +sdl +swig +wavelet +wxgui 
configure.compiler=llvm-gcc-4.2

... Lots of port messages ...
[tmpboost/boost] > installed boost* 



The following ports are currently installed:
  boost @1.50.0_0
  boost @1.52.0_1+no_single+no_static+python27 (active)
[tmpboost/boost] > activate boost@1.50.0_0 



--->  Computing dependencies for boost
--->  Deactivating boost @1.52.0_1+no_single+no_static+python27
--->  Cleaning boost
--->  Activating boost @1.50.0_0
--->  Cleaning boost
[tmpboost/boost] >

STEP 4. Reboot
--



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

[Discuss-gnuradio] GnuRadio 3.3 on Ubuntu 12.04LTS

[Ed Criscuolo]

I have an odd question.

I've been requested to duplicate a system I built a couple of years ago
based on GnuRadio 3.3 and Ubuntu 10.04LTS.  Unfortunately, the laptop
that was used is no longer made, and it's new equivalent uses an
ethernet chipset that does not not have drivers in 10.04LTS, but
does in 12.04LTS.

Ideally, I'd like to find backported drivers for 10.04LTS. so I can
just duplicate everything without modification. Failing that, I'm
going to have to use 12.04LTS.

My question is, are there any showstoppers for able to run
GnuRadio 3.3 on Ubuntu 12.04LTS?  My customer _really_ wants all the
SDRs to be the same for CM purposes, and does not have the schedule
time for me to port his custom blocks and flowgraphs from GR3.3 to
GR3.6.

I know over the last year or two there's been a lot of Boost and
Qt version issues, and I want to know if I'm about to paint myself
into a corner here.

@(^.^)@  Ed



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

Re: [Discuss-gnuradio] GnuRadio 3.3 on Ubuntu 12.04LTS

[Ed Criscuolo]

Thanks Jonathan!  That tidbit probably saved me an hour of
 troubleshooting right there! :)

@(^.^)@  Ed


On 2/12/13 10:16 AM, Johnathan Corgan wrote:

On Sat, Feb 9, 2013 at 10:24 AM, Ed Criscuolo
mailto:edward.l.criscu...@nasa.gov>> wrote:

My question is, are there any showstoppers for able to run
GnuRadio 3.3 on Ubuntu 12.04LTS?  My customer _really_ wants all the
SDRs to be the same for CM purposes, and does not have the schedule
time for me to port his custom blocks and flowgraphs from GR3.3 to
GR3.6.

I know over the last year or two there's been a lot of Boost and
Qt version issues, and I want to know if I'm about to paint myself
into a corner here.


Well, I'm not aware of anything that would prevent 3.3 from working on
Ubuntu 12.04, but of course I don't think anyone has actually tried it.

The Boost version in 12.04 defaults to 1.46, which has a known bug that
affects GNU Radio, but 1.48 is also available on that distro.

Johnathan



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

Re: [Discuss-gnuradio] GRC + USRP2 + WBFM: synchronization problem?

[Ed Criscuolo]

Looks like you have your interpolator and your multiply blocks switched.

The way you have it, the L-R audio is interpolated up to a 200k
sample rate, and then multiplied with a 19khz subcarrier at
a 44.1k sample rate.

Do the multiply first, then interpolate the product.

Or alternately,  simply change the 19 kHz sample rate to 200k.

@(^.^)@  Ed


On 3/28/11 3:23 PM, Marcin Szelest wrote:

Hello,

I have created FM transmitter in GRC:
http://szelest.org/question/TX_RX.grc.png

Unfortunately demodulated audio has poor quality and annoying
distortions. I have spent a lot of time on it without positive effect.
Here is how demodulated audio sounds like:
http://szelest.org/question/recorded.wav

When I have created FM receiver in GRC (bottom part of the schematic),
demodulated audio sounds perfectly on my PC.
Any ideas?

I'm using gnuradio3.3.0 + USRP2(with interpolation changed from 4 to
2) + BasicTX + FT857D as hardware receiver.
GRC file: http://szelest.org/question/TX_RX.grc
input WAV: http://szelest.org/question/indiana.wav

Regards,
Marcin SQ9DJJ

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



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

Re: [Discuss-gnuradio] USRP network based spectrum analyzer

[Ed Criscuolo]

On 9/28/11 4:54 PM, Marcus D. Leech wrote:

On 28/09/2011 4:50 PM, Phelps Williams wrote:

I have a usrp and computer in a remote location without much network
bandwidth available to the system and I'm using it as a spectrum
analyzer.  I'd like to run the fft on the remote system and then send
the results to a connected client for display.  This would allow me to
get greater fidelity than xwindows forwarding or the ascii dft example
while also using less bandwidth.  I would imagine the client side
would potentially reuse some of the existing wx or qt interfaces for
display and control.

This seems like a pretty useful / simple use of this hardware.  Does
anybody know of any implementations floating around that does this?
  I'd prefer not to reinvent the wheel.

-Phelps


You could use a GRC-based flow-graph that computes the FFT, and outputs
the results to a FIFO, and have a small C program that simply puts
"snapshots" in an appropriate place.  Once it's in an "appropriate
place" (and perhaps in a form that you like), you could use a web server
to observe the results.  Roughly 1e6 ways of skinning this particular
cat.



Why not just use VNC?  Its generally much lower bandwidth than X forwarding.

@(^.^)@  Ed

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

[Discuss-gnuradio] USRP1 Ext Clock

[Ed Criscuolo]

What frequency does the USRP1 want to see on its "ext clk" input?

10 MHz or 64 MHz?

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] gmsk on GRC

[Ed Criscuolo]

Have a look at the GMSK Spacecraft Groundstation Project
on CGRAN:

https://cgran.org/wiki/GMSKSpacecraftGroundstation

@(^.^)@  Ed


On 11/3/11 9:14 AM, ahmad wrote:

Hi all
I am new on working with GRC. I am researching on gmsk modulators.I could not
make a proper GRC model or example. anybody has a working example?
thanks all
Ahmad


___
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] About USRP's Bandwidth

[Ed Criscuolo]

On 11/8/11 9:29 AM, 弓长张 wrote:
> I'm a starter in using the USRP, it's known that the bandwidth of USRP 
> is 8M beacause of the USB bandwidth ,my question is the 8M refers to the 
> Nquist Bandwith or the actual signal bandwidth?If it refers to the 
> Nquist Bandwith, it is mean that USRP can only process the signal with 
> 4M bandwidth,so if a signal larger than 4M, how can USRP deals with it ?

Because the USRP does complex samples, an 8 megasample/sec rate
is enough to resolve up to 8 MHz.  This is in contrast  to magnitude-only
real samples, where an 8 megasample/sec rate would only resolve up to
4 MHz.

A qualitative way to think about it is that complex samples provide
twice the data as magnitude-only real samples, providing that
"factor of 2".

Nyquist will not be cheated!

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] GRUG meeting tonight!

[Ed Criscuolo]

Since I'm local, I plan to be there!

@(^.^)@  Ed

On 11/30/11 10:10 AM, Tom Rondeau wrote:

The GNU Radio Users Group (GRUG) meeting is tonight at the WinnForum's
conference!

8PM in Regency C of the Hyatt Regency Crystal City (in Arlington, VA).
We'll chat for an hour or so then head on to the pub, the Bailey's
(otherwise known as The Fox and Hound).

Hope to see many of your there!
Tom




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

Re: [Discuss-gnuradio] Please tell me about recommend GPS antena and High Frequency Amplifier

[Ed Criscuolo]

In a less mathematical and more qualitative explanation, consider that
at any point in time, one bit of your signal is spread out over a wide
frequency spectrum.  If you think of adding up all of the measurements
of little frequency bins across the whole spread spectrum, the noise
in each bin, being random, will average to zero and cancel out, while
signal, being consistently the same, will add up in one direction.

@(^.^)@  Ed

On 12/8/11 3:32 PM, Nick Foster wrote:

http://en.wikipedia.org/wiki/Process_gain

On Thu, Dec 8, 2011 at 12:30 PM, Matt Mills  wrote:

2011/12/8 Dan CaJacob


Hi Kouki,

I don't think you will see the signal in an FFT window. GPS is spread
spectrum and the signal is below the noise floor. But the signal is
still decodable.



I thought this was the case; but as someone without any DSP experience this
boggles the mind... Does anyone have any more info on GPS or how you decode
it even though you cant "see" a signal?

___
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] Vector operation in GRC

[Ed Criscuolo]

I have a vector quantity (size 1024), and I want to do a calculation
on it such that v_out[i] = v_in[i] - v_in[i-1]

Is such a calculation possible in GRC?  I haven't found any way to
get a hold of the individual elements of a vector.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] Vector operation in GRC

[Ed Criscuolo]

Will that preserve the absolute positions of the original vector
elements?  The initial vector represents an FFT, so it's
important to me that I keep the same positions.

@(^.^)@  Ed

On 12/19/11 4:33 PM, Allen, Cam wrote:

I would probably try converting the vector to a stream, delay the stream by 1 
sample, subtract one stream from the other, and then convert the resulting 
(difference) stream back to a vector.

-Cam

-Original Message-
From: discuss-gnuradio-bounces+callen=mitre@gnu.org 
[mailto:discuss-gnuradio-bounces+callen=mitre@gnu.org] On Behalf Of Ed 
Criscuolo
Sent: Monday, December 19, 2011 4:21 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Vector operation in GRC

I have a vector quantity (size 1024), and I want to do a calculation
on it such that v_out[i] = v_in[i] - v_in[i-1]

Is such a calculation possible in GRC?  I haven't found any way to
get a hold of the individual elements of a vector.

@(^.^)@  Ed

___
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] Vector operation in GRC

[Ed Criscuolo]

I did a hand-contrived case with a simple 16-element vector, and it
seems to work.

@(^.^)@  Ed

On 12/19/11 4:58 PM, Allen, Cam wrote:

Hmm... I'm not sure about that.  Seems reasonable to assume that the 
stream-to-vector and vector-to-stream blocks would be inverses of each other.  
Mostly I'd just be worried about the first or last subtraction - you might only 
get a length 1023 vector out at the end.

When you link it up, can you tell whether it produces reasonable results?


-Original Message-----
From: Ed Criscuolo [mailto:edward.l.criscu...@nasa.gov]
Sent: Monday, December 19, 2011 4:42 PM
To: Allen, Cam
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Vector operation in GRC

Will that preserve the absolute positions of the original vector
elements?  The initial vector represents an FFT, so it's
important to me that I keep the same positions.

@(^.^)@  Ed



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

Re: [Discuss-gnuradio] Vector operation in GRC

[Ed Criscuolo]

Yes, I can do my own blocks.  It would be pretty trivial to do it
there.   I just wanted to know if there was an easy way to do it
solely using GRC.

@(^.^)@  Ed



On 12/19/11 5:05 PM, Nowlan, Sean wrote:

If you're somewhat familiar with how to write/modify blocks, it probably 
wouldn't be difficult to implement that functionality by making a new block 
that is a copy of gr_multiply_const_vcc.cc (for instance) and changing the work 
function to do what you want.

Sean


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

[Discuss-gnuradio] Full Duplex with RFX2200

[Ed Criscuolo]

I'm working on an application that will do full-duplex using an RFX2200
daughterboard in a USRP1.

The transmit frequency will be about 2.055 GHz, and the receive freq
will be about 2.255 GHz.

Up until now, we've been working with only the transmit or the receive
flowgraph separately.  Now we're about to integrate the two and I have
concerns.

In the lab, the transmit and receive sides will be hooked to separate
antennas.  I am aware that the input to the receiver should not exceed
-10dBm in order to avoid damaging it.  I'm concerned that the transmit
antenna will be a short distance away, blasting out 100mW (+20dBm).

Am I right to be concerned?  By my rough back-of-the-napkin
calculations,  with 3dB antennas, and about 1 1/2 meters separation,
I should be between -20 dBm and -10 dBm at the receiver.


@(^.^)@  Ed

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

[Discuss-gnuradio] External Manual control of T/R Switch

[Ed Criscuolo]

The RFX (FLEX) series of transceiver daughtercards include an onboard
T/R switch to allow a half-duplex setup using the Tx/Rx connector
and a single antenna.

In GnuRadio 3.3.0, under GRC, the choices for the "Transmit" parameter
on a USRP Sink Block seem to be limited to "Unconfigured",
"Enabled", or "Auto T/R".

Since my application continuously produces transmit data, even while
idle, I want to be able to manually control the T/R switch from
an external entity, probably via a GRC variable that is set from
a message source or UDP source.

Is this even doable?  GRC's block parameter editor does not show
this parameter as underlined, meaning it cannot be changed dynamically.

Would it be possible to dynamically control the transmit_enable by
calling the appropriate method using a probe block?


Although this application is locked into using GR 3.3.0, I've also
looked at the GR 3.5.1 xml description for a GRC UHD_sink block, and
can't even find where the transmit enable is.

Any help on this?

@(^.^)@  Ed

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

[Discuss-gnuradio] GR 3.5.1 & OSX

[Ed Criscuolo]

Has anyone built 3.5.1 release and UHD 3.3.2 on OSX 10.6 (Snow Leopard) yet?

@(^.^)@  Ed

Sent from my iPod

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

[Discuss-gnuradio] GR 3.5.1 release tarball bugs

[Ed Criscuolo]

Tom,

I was just trying to install the GnuRadio 3.5.1 release tarball, and I
found two problems:

1. The tarball does not appear to contain the CMakeLists.txt file.
   This forces the use of the autotools instead of cmake.

2. After successfully installing UHD release 3.3.2,  the GnuRadio
   configure script failed to configure gr-uhd.  The reported reason was
   ==

   configure:28430: $PKG_CONFIG --exists --print-errors "uhd >=3.0.0 
uhd < 4.0.0

   Package libusb-1.0 was not found in the pkg-config search path.
   ...
   Package 'libusb-1.0' , required by 'UHD', not found.

   ==

   This error message is incorrect.  libusb-1.0-0 WAS installed.  What
   was actually missing was libusb-1.0-0-dev.  Installing that package
   allowed gr-uhd to be configured.

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] GR 3.5.1 release tarball bugs

[Ed Criscuolo]

On 1/11/12 4:59 PM, Josh Blum wrote:

I dont think this is a tarball of the source tree. Rather, its a tarball
produced by autotools with only files listed by makefile.ams or
generated in autotools.


But what of the future? If autotools goes away in favor of cmake, does
this mean that tarballs will go away too?  I hope not, as a tarball is
the preferred way of installation on a number of the machines that I use
because they are in isolated labs and are not allowed to be connected
to the internet.


Technically, that seems to be the correct thing to do for pc files. But
the side effect seems to be that package config complains when it cant
find a pc file for the "Requires.private" entries. But you shouldnt
actually need the development libraries required by uhd to be installed
to develop against uhd.

I'm happy to not have UHD populate Requires.private if its just trouble.
In anycase, this probably isnt an issue with the gr tarball. A good test
of that might be to uninstall the libusb-1.0 dev and see if pkg-config
uhd --libs gives the same error. That way we can tell if auto* is doing
something different with pkg-config or not.


I don't know about this pkg-config behavior, as I installed UHD release
3.3.2 from the prebuilt binary package for Ubuntu.

And just as a side note (I know this should really go on the ettus
list),  the aforementioned UHD binary Ubuntu package did not unpack the
images subdirectory properly.  All that was there was the .tar.gz and
.zip files.  I had to manually gunzip/untar and move all the image
files to the proper locations by hand.

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