GNU Radio, One Step at a Time: October 2011

Monday, October 31, 2011

Re: [Discuss-gnuradio] Can't link against libgnuradio-core (cmake)

On Mon, Oct 31, 2011 at 15:44, Josh Blum <josh@ettus.com> wrote:

Basically, the build system is generating .la files for each library
using this macro: http://www.vtk.org/Wiki/CMakeMacroLibtoolFile
I dont know why we are doing this or why we want it.

If you link against libraries in the normal way, everything should be
fine. So my best guess is that the generated la files are confusing for
autotools.

Try deleting the la files. You can also turn the generation off w/
-DLIBRARY_EXTRAS=OFF

You're right, I don't think the .la files are necessary for linking against when using cmake.

Johnathan

Re: [Discuss-gnuradio] Can't link against libgnuradio-core (cmake)

On Mon, Oct 31, 2011 at 11:44 PM, Josh Blum <josh@ettus.com> wrote:
>
> On 10/31/2011 01:50 PM, Alexandru Csete wrote:
>> Greetings,
>>
>> I'm trying to rebuild my gr-fcd block
>> (https://github.com/csete/gr-fcd) with gnuradio v3.5.0rc0-1-g037c5f60
>> When I build gnuradio using the autotools everything is fine and I can
>> build gr-fcd without problems.
>> When I build using cmake gnuradio still builds and install fine, but
>> when I try to build gr-fcd I get:
>>
>> libtool: link: `/opt/gnuradio/v3.5.0rc0-1-g037c5f60/lib/libgnuradio-core.la'
>> is not a valid libtool archive
>> make[3]: *** [libgnuradio-fcd.la] Error 1
>> make[3]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib'
>> make[2]: *** [all] Error 2
>> make[2]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git'
>> make: *** [all] Error 2
>>
>> Looking at the contents of gnuradio-core.la from the two builds I can
>> indeed see many differences, actually they seem to be more different
>> than similar.
>>
>
> Basically, the build system is generating .la files for each library
> using this macro: http://www.vtk.org/Wiki/CMakeMacroLibtoolFile
> I dont know why we are doing this or why we want it.
>
> If you link against libraries in the normal way, everything should be
> fine. So my best guess is that the generated la files are confusing for
> autotools.
>
> Try deleting the la files. You can also turn the generation off w/
> -DLIBRARY_EXTRAS=OFF
>

Thanks for the tip! Using -DLIBRARY_EXTRAS=OFF works :)

Alex

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

Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

On 10/31/2011 06:40 PM, Tuan (Johnny) Ta wrote:
> Marcus,
>
> What do you mean my zero-stuffing the TX frames? And how would it help
> with the turn-around time of the XCVR2450 daughterboard? Do you mean I
> should transmit a zero-filled packet before any real packet, so that
> the receiving side (A in my scenario) has time to switch back to
> receiving before the real packet arrives?
>
The transmit side assumes that the combination of RX-to-TX and TX-to-RX
transition experienced by both sides is non-zero. So, you get
the transmit side to simply send some idle 0s, and *then* the actual
start-of-frame data, etc. What happens in these situations in my experience
is that the start-of-frame gets missed during the switchover
interval. So if the transmit side sends zeros (or, really, anything
other than
the start-of-frame sequence) for a "little while" after commencing a
transmit burst, you're less likely to run into TX-to-RX transition issues.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Can't link against libgnuradio-core (cmake)

On 10/31/2011 01:50 PM, Alexandru Csete wrote:
> Greetings,
>
> I'm trying to rebuild my gr-fcd block
> (https://github.com/csete/gr-fcd) with gnuradio v3.5.0rc0-1-g037c5f60
> When I build gnuradio using the autotools everything is fine and I can
> build gr-fcd without problems.
> When I build using cmake gnuradio still builds and install fine, but
> when I try to build gr-fcd I get:
>
> libtool: link: `/opt/gnuradio/v3.5.0rc0-1-g037c5f60/lib/libgnuradio-core.la'
> is not a valid libtool archive
> make[3]: *** [libgnuradio-fcd.la] Error 1
> make[3]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git'
> make: *** [all] Error 2
>
> Looking at the contents of gnuradio-core.la from the two builds I can
> indeed see many differences, actually they seem to be more different
> than similar.
>

Basically, the build system is generating .la files for each library
using this macro: http://www.vtk.org/Wiki/CMakeMacroLibtoolFile
I dont know why we are doing this or why we want it.

If you link against libraries in the normal way, everything should be
fine. So my best guess is that the generated la files are confusing for
autotools.

Try deleting the la files. You can also turn the generation off w/
-DLIBRARY_EXTRAS=OFF

-Josh

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

Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

Marcus,

What do you mean my zero-stuffing the TX frames? And how would it help with the turn-around time of the XCVR2450 daughterboard? Do you mean I should transmit a zero-filled packet before any real packet, so that the receiving side (A in my scenario) has time to switch back to receiving before the real packet arrives?

Johnny

On Mon, Oct 31, 2011 at 6:22 PM, Marcus D. Leech <mleech@ripnet.com> wrote:

On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote:
I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread.

My setting:

USRP2

XCVR2450

Ubuntu 10.04 (32bit)

The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply.

I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis.

Can anyone help me?

Thank you,

Johnny

We used to have this problem "back in the day" with packet-radio, using analog FM transceivers--they were often notoriously sluggish
in turning around the TX/RX logic.

You might try zero-stuffing the TX frames--that's basically what we did back in the day. Although the XCVR2450 short turn around fairly
quickly, it's not infinitely quick.

-- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org

Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote:

I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread.

My setting:

USRP2

XCVR2450

Ubuntu 10.04 (32bit)

The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply.

I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis.

Can anyone help me?

Thank you,

Johnny

We used to have this problem "back in the day" with packet-radio, using analog FM transceivers--they were often notoriously sluggish
in turning around the TX/RX logic.

You might try zero-stuffing the TX frames--that's basically what we did back in the day. Although the XCVR2450 short turn around fairly
quickly, it's not infinitely quick.

--  Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org

Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread.

My setting:

USRP2

XCVR2450

Ubuntu 10.04 (32bit)

The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply.

I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis.

Can anyone help me?

Thank you,

Johnny

On Thu, Oct 20, 2011 at 11:24 AM, Marcus D. Leech <mleech@ripnet.com> wrote:

On 20/10/2011 10:25 AM, David Barton wrote:

I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are:

Tx Gain: 15 dB

Rx Gain: 10 dB

Carrier Threshold: -80

Rx Tunnel Freq: 400 MHz

Modulation: GMSK

Bit Rate: 1Mb/sec

When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers.

Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets!

[ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448
[ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186
[ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310
[ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448
[ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021
[ 63.61 ] Backing off for 0.001 sec
[ 63.62 ] Backing off for 0.002 sec
[ 63.62 ] Backing off for 0.004 sec
[ 63.63 ] Backing off for 0.008 sec
[ 63.64 ] Backing off for 0.016 sec
[ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448
[ 63.66 ] Backing off for 0.032 sec
[ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186
[ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310
[ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448
[ 63.67 ] Backing off for 0.064 sec
[ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021
[ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70
[ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150
[ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448
[ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248
[ 63.72 ] Backing off for 0.001 sec
[ 63.72 ] Backing off for 0.002 sec
[ 63.73 ] Backing off for 0.004 sec
[ 63.74 ] Backing off for 0.008 sec
[ 63.75 ] Backing off for 0.016 sec
[ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70
[ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448
[ 63.76 ] Backing off for 0.032 sec
[ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150
[ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448
[ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248
[ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448
[ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566
[ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448
[ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987
[ 63.78 ] Backing off for 0.001 sec
[ 63.79 ] Backing off for 0.002 sec
[ 63.79 ] Backing off for 0.004 sec
[ 63.79 ] Backing off for 0.008 sec
[ 63.8 ] Backing off for 0.016 sec
[ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566
[ 63.82 ] Backing off for 0.032 sec
[ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448
[ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987
[ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321
[ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448
[ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855
[ 63.84 ] Backing off for 0.001 sec
[ 63.84 ] Backing off for 0.002 sec
[ 63.85 ] Backing off for 0.004 sec
[ 63.85 ] Backing off for 0.008 sec
[ 63.86 ] Backing off for 0.016 sec
[ 63.87 ] Backing off for 0.032 sec
[ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448
[ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448
[ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321
[ 63.89 ] Rx: ok = True | seq_no = 100073 | len(payload) = 1448
[ 63.9 ] Backing off for 0.064 sec
[ 63.9 ] Rx: ok = True | seq_no = 100074 | len(payload) = 855

Does anyone have any idea why this could be occurring? I thought maybe it would be a physical reflection but dont understand why ping packets would not be reflected in that case.

Thanks,

Dave

There's generally only about 45dB of isolation available between TX and RX, so if you're running in full-duplex, your receiver will see its
own transmissions.

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

[Discuss-gnuradio] Can't link against libgnuradio-core (cmake)

Greetings,

I'm trying to rebuild my gr-fcd block
(https://github.com/csete/gr-fcd) with gnuradio v3.5.0rc0-1-g037c5f60
When I build gnuradio using the autotools everything is fine and I can
build gr-fcd without problems.
When I build using cmake gnuradio still builds and install fine, but
when I try to build gr-fcd I get:

libtool: link: `/opt/gnuradio/v3.5.0rc0-1-g037c5f60/lib/libgnuradio-core.la'
is not a valid libtool archive
make[3]: *** [libgnuradio-fcd.la] Error 1
make[3]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git'
make: *** [all] Error 2

Looking at the contents of gnuradio-core.la from the two builds I can
indeed see many differences, actually they seem to be more different
than similar.

Alex

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

Re: [Discuss-gnuradio] ld search path on mac os x

On 10/31/2011 12:49 PM, Michael Dickens wrote:
> Last I checked, volk didn't compile on OSX yet -- but my knowledge is
> probably a month old now, so things might have changed. I just
> compile with volk disabled. Maybe Johnathan can comment more about
> volk working on OSX? - MLD
>

It built just fine on the macmini at my office w/ cmake (off of master
branch). Im building the rest of gnuradio to see if thats ok too. -josh

> On Oct 31, 2011, at 12:02 PM, Dimitris Symeonidis wrote:
>> I'm trying to build gnu radio from source on a MacOSX 10.6, using
>> MacPorts.
>>
>> I tried both with the git master tree and the 3.4.2 tarball, and
>> both fail at the same point: linking fails in volk/lib with
>> "library not found for -lboost_unit_test_framework-mt".
>>
>> The library files (libboost_unit_test_framework-mt.a and
>> libboost_unit_test_framework-mt.dylib) are installed in
>> /opt/local/lib, along with all the other boost libraries.
>> Compiling and linking works fine in other directories of the source
>> tree.
>>
>> I don't know autotools well enough to identify the source of the
>> problem. Any hints?
>
>
> _______________________________________________ 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] Wanted TVRX daughtercard USRP1 SN < 500

Want to buy a TVRX with no UHD support for an USRP1 serial number < 500

Shipping address: Los Angeles (Los Alamitos)

Patrik

Re: [Discuss-gnuradio] ld search path on mac os x

Last I checked, volk didn't compile on OSX yet -- but my knowledge is probably a month old now, so things might have changed. I just compile with volk disabled. Maybe Johnathan can comment more about volk working on OSX? - MLD

On Oct 31, 2011, at 12:02 PM, Dimitris Symeonidis wrote:
> I'm trying to build gnu radio from source on a MacOSX 10.6, using MacPorts.
>
> I tried both with the git master tree and the 3.4.2 tarball, and both
> fail at the same point: linking fails in volk/lib with "library not
> found for -lboost_unit_test_framework-mt".
>
> The library files (libboost_unit_test_framework-mt.a and
> libboost_unit_test_framework-mt.dylib) are installed in
> /opt/local/lib, along with all the other boost libraries. Compiling
> and linking works fine in other directories of the source tree.
>
> I don't know autotools well enough to identify the source of the
> problem. Any hints?

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

Re: [Discuss-gnuradio] grc/gnuradio-companion architecture

On 10/31/2011 10:50 AM, Marcus D. Leech wrote:
> On 10/31/2011 01:45 PM, Chris Lirakis wrote:
>> gnuradio-companion is a really cool piece of software. I'd like to
>> emulate the style in which blocks are connected together. It is rather
>> intricately tied to gnuradio. Does a design document exist that shows
>> the philosophy of the internal layout, ie how blocks are connected etc?
>> Chris
>>
>> --
>> Chris Lirakis
>>
> I don't think there's an architecture document.
>
> But GRC "knows" remarkably little about Gnu Radio, per se. Most of that
> knowledge is encapsulated in the various .XML files that describe
> blocks semantics, and in particular, the code that needs to be emitted
> when one of those blocks is instantiated.
>
> So, conceivably, you could use GRC to layout "blocks" for an entirely
> different reason/subsystem--might require *bit* of tweaking, but probably
> not a complete overhaul.
>

I had done exactly this for a project that connected VHDL blocks. It
used the same gui and base classes as grc. The link seems to be down
now: http://www.flexhdr.org/projects/flexhdr/wiki

-josh

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

Re: [Discuss-gnuradio] QPSK with direct-sequence spread spectrum

In general you're right, but it depends on the details. Its usually quite
straightforward, but a common mistake is to use the wrong bit-to-symbol
mapping. 0 -> +1 and 1 -> -1 means that an XOR applied to bits is
equivalent to multiplication applied to symbols.

Nowlan, Sean wrote:
>
> Hi all,
>
> I'm wondering if spreading a bitstream (XOR-ing each bit with
> SPREAD_FACTOR bits of sequence) before QPSK modulation is equivalent to
> operating on the modulated stream, i.e., multiplying the complex output
> with -1's and 1's from the sequence. So far I can't get the math to work
> out. Any suggestions?
>
> Thanks,
> Sean
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context: http://old.nabble.com/QPSK-with-direct-sequence-spread-spectrum-tp32752034p32754111.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

Re: [Discuss-gnuradio] grc/gnuradio-companion architecture

On 10/31/2011 01:45 PM, Chris Lirakis wrote:
> gnuradio-companion is a really cool piece of software. I'd like to
> emulate the style in which blocks are connected together. It is rather
> intricately tied to gnuradio. Does a design document exist that shows
> the philosophy of the internal layout, ie how blocks are connected etc?
> Chris
>
> --
> Chris Lirakis
>
I don't think there's an architecture document.

But GRC "knows" remarkably little about Gnu Radio, per se. Most of that
knowledge is encapsulated in the various .XML files that describe
blocks semantics, and in particular, the code that needs to be
emitted when one of those blocks is instantiated.

So, conceivably, you could use GRC to layout "blocks" for an entirely
different reason/subsystem--might require *bit* of tweaking, but probably
not a complete overhaul.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] grc/gnuradio-companion architecture

gnuradio-companion is a really cool piece of software. I'd like to emulate the style in which blocks are connected together. It is rather intricately tied to gnuradio. Does a design document exist that shows the philosophy of the internal layout, ie how blocks are connected etc?
Chris

--
Chris Lirakis

Re: [Discuss-gnuradio] Can not login USRP E100

On 10/31/2011 01:36 PM, Philip Balister wrote:
>
> By usb, you mean the usb console?
>
> You can put the sd card in an sd card reader attached to another linux
> computer and edit the file /etc/passwd to remove the password. That
> should let you login in again. It might be in the shadow password file also.
>
> Yes, it looks like the actual password is in /etc/shadow. Edit this file
> to remove the password hash.
>
> Also, this question is better suited to the usrp-users list, so I copied
> that list also.
>
> Philip
>
>
If the filesystem is trashed, mounting it on another machine may not
help. If it's a password issue, then how did the
password get changed? Someone else logged into it? Some malware
logged into it? These are questions the
security-geek-instance of myself would be asking.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Can not login USRP E100

On 10/31/2011 12:50 PM, Zhonghua wrote:
> Hi list,
>
> I used USRP E100 for several months and it has been working well. But
> today when I was using it and want to open another terminal to login it
> with SSH, I failed and got the message that "Permission denied, please
> try again". I closed the terminal and tried to login it again with
> USB,then I could not login it any more and got the hint that "login
> incorrect". I can login another E100 box with SSH. So I guess maybe
> there are something wrong with the file system of the bad box but I
> don't know exactly what the matter and how to fix it. Do I have to
> reinstall it? Any suggestion is appreciated.

By usb, you mean the usb console?

You can put the sd card in an sd card reader attached to another linux
computer and edit the file /etc/passwd to remove the password. That
should let you login in again. It might be in the shadow password file also.

Yes, it looks like the actual password is in /etc/shadow. Edit this file
to remove the password hash.

Also, this question is better suited to the usrp-users list, so I copied
that list also.

Philip

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

[Discuss-gnuradio] Can not login USRP E100

Hi list,

I used USRP E100 for several months and it has been working well. But
today when I was using it and want to open another terminal to login it
with SSH, I failed and got the message that "Permission denied, please
try again". I closed the terminal and tried to login it again with
USB,then I could not login it any more and got the hint that "login
incorrect". I can login another E100 box with SSH. So I guess maybe
there are something wrong with the file system of the bad box but I
don't know exactly what the matter and how to fix it. Do I have to
reinstall it? Any suggestion is appreciated.

BR,
Zhonghua

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

[Discuss-gnuradio] ld search path on mac os x

Hi list,

I'm trying to build gnu radio from source on a MacOSX 10.6, using MacPorts.

I tried both with the git master tree and the 3.4.2 tarball, and both
fail at the same point: linking fails in volk/lib with "library not
found for -lboost_unit_test_framework-mt".

The library files (libboost_unit_test_framework-mt.a and
libboost_unit_test_framework-mt.dylib) are installed in
/opt/local/lib, along with all the other boost libraries. Compiling
and linking works fine in other directories of the source tree.

I don't know autotools well enough to identify the source of the
problem. Any hints?

Thanks!

Dimitrios Symeonidis
"If you think you're too small to make a difference, try sleeping with
a mosquito!" - Amnesty International

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

Re: [Discuss-gnuradio] TVRX2

Roger, Thanks

Patrik

----- Original Message -----
From: "Josh Blum" <josh@ettus.com>
To: <discuss-gnuradio@gnu.org>
Sent: Monday, October 31, 2011 6:07
Subject: Re: [Discuss-gnuradio] TVRX2

>
>
> On 10/30/2011 03:50 PM, Patrik Tast wrote:
>> Does a TVRX2 work on a no UHD USRP1?
>>
> Nope, sorry. Its UHD only.
>
> The driver was only written *once* this time. :-)
>
> -Josh
>
>> Patrik
>>
>>
>>
>> _______________________________________________
>> 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] QPSK with direct-sequence spread spectrum

Hi all,

I'm wondering if spreading a bitstream (XOR-ing each bit with SPREAD_FACTOR bits of sequence) before QPSK modulation is equivalent to operating on the modulated stream, i.e., multiplying the complex output with -1's and 1's from the sequence. So far I can't get the math to work out. Any suggestions?

Thanks,
Sean

Re: [Discuss-gnuradio] proper antenna for RFX900

Hi,

Perhaps a Yagi then? It is very easy to build and inexpensive.

I used 3 mm Al tig welding rods for elements and a PVC electrical tube as boom.

My 900 MHz Yagi photos, wire list and EZNEC design can be found at http://www.poes-weather.com/~patrik/Yagi-900MHz/

Here is a yagi calculator http://www.vk5dj.com/yagi.html

Patrik

----- Original Message -----

From: davood ahmady

To: Patrik Tast

Sent: Monday, October 31, 2011 13:02

Subject: Re: [Discuss-gnuradio] proper antenna for RFX900

On Sun, Oct 30, 2011 at 2:37 PM, Patrik Tast <patrik@poes-weather.com> wrote:

It helps us alot if you specify what you are about to RX/TX.
Q's:
-frequency
-signal is linear (vertical or horizontal) or circular (right or left)

Patrik
hello Patrik
thanks for reply. I am new in this subject. I am planning to work on 900-1200MHz frequency range. the polarization of the antenna is vertical

Ahmad

Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault

Hello Josh,

thanks for your answer.

I have run the programm once again using gdb and the
output is:

----------------------------------------------------------------------------------------------
Starting program: /usr/bin/python uhd_fft.py -a type=usrp2
-f 935M -s 2M
[Thread debugging using libthread_db enabled]
linux; GNU C++ version 4.5.2; Boost_104200;
UHD_003.001.000-a7927ae

[New Thread 0xb2295b70 (LWP 32150)]
[New Thread 0xb1a94b70 (LWP 32151)]
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- mboard0 is MIMO master

Program received signal SIGSEGV, Segmentation fault.
0xb6fdf26f in boost::thread::start_thread() () from
/usr/lib/libboost_thread.so.1.46.1
--------------------------------------------------------------------------------------------------------

I just used the version that was online Thursday last
week. I think this one is up to date... (?)

Sebastian

On Fri, 28 Oct 2011 07:41:17 -0700
Josh Blum <josh@ettus.com> wrote:
>
>
> On 10/28/2011 04:03 AM, doering.bas@googlemail.com
>wrote:
>> Hello list,
>>
>> I tried to launch the "uhd_fft.py" script with the
>>following command line:
>>
>> "uhd_fft.py -a type=usrp2 -f 935M -s 2M"
>>
>>
>> My problem is that my terminal always returns this
>>output:
>>
>> linux; GNU C++ version 4.5.2; Boost_104200;
>>UHD_003.001.000-a7927ae
>>
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- mboard0 is MIMO master
>> Segmentation fault
>>
>>
>
> Does uhd_usrp_probe work? If so, is there a particular
>line in
> uhd_fft.py that causes the seg fault? Have you debugged
>w/ gdb?
>
> In any case, I recommend upgrading to the latest
>release, then see if
> there is still a problem.
>
> -Josh
>
>
>> I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo
>>CPU P8600 @
>> 2.40GHz × 2, USRP N210 with WBX.
>> I also use ClockTamer as reference for the internal XO
>>and 2 normal GSM
>> 900 antennas.
>>
>> I would really appreciate if someone has an idea on what
>>I am doing
>> wrong here.
>>
>> Thanks in advance!
>>
>> Sebastian
>>
>> _______________________________________________
>> 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] GNU Chirp Sounder

Hi,

I released my beacon satellite receiver a while ago. Now I'm releasing
my ionosonde receiver. It can be used to perform oblique and vertical
ionospheric soundings with ionosonde (and over the horizon radar)
transmitters all around the world.

The GNU Chirp Sounder is a software defined radio based receiver for
monitoring ionospheric sounders. The software is based on gnuradio and
relies on Ettus research USRP2 and USRP N210 based digital receivers.
The receiver can be used to receive the whole HF band (typically at 25
MHz bandwidth) simultaneously, and to receive multiple sounders
simultaneously. The current receiver can be used to perform single or
dual polarization (channel) soundings. The dual channel recorded can
be used to determine the polarization form vertical soundings, or for
angle of arrival measurements for horizontal soundings.

http://www.sgo.fi/~j/gnu_chirp_sounder

juha

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

[Discuss-gnuradio] weekend coding adventure: message passing, new blocks, and integrating grblock

All the work is on my next branch, see here:
http://gnuradio.org/cgit/jblum.git/log/?h=next

##################################################
# Write gnuradio blocks in python
##################################################
This work, formally known as grblock was on my github. The project has
now been integrated into gnuradio-core on my next branch.

So basically, all of the facilities of a gr_block are now available in
python. Overload work, scheduler integration, stream tags, and also the
message passing I will mention below. See this wiki page for relevant
docs and examples.

http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython

##################################################
# Useful message passing
##################################################
I have create a message passing framework that fits in with the existing
gnuradio. Basically, each block can accept messages, and can post
messages to other blocks. The coordination of who can post messages to
who is handled by the the msg_connect() call which is the message
equivalent of the connect() call used on streams.

Messages can be used to pass arbitrary serialized data between two
blocks. The unit of message passing is the same as the stream tags,
which is the pmt library. See gruel/pmt.h for basic usage.

I have also extended the pmt blob type (memory container type) to manage
memory. This allows blocks to pass messages with bulk data; effectively
allowing for a mac/packet layer inside of gnuradio.

##################################################
# New blocks - gr_blob_to_stream/gr_stream_to_blob
##################################################
These blocks provide a cross over between the streaming domain in
gnuradio and a kind of packet-based stream of message blobs.

This is useful for testing the various blocks mentioned below:

##################################################
# New blocks - gr_blob_to_socket/gr_socket_to_blob
##################################################
These blocks read and write sockets (TCP or UDP) and output/input a
stream of message blobs. This has a few advantages of the current UDP
source/sink:

- respects packet boundaries, each blob corresponds to a packet.
Consider integration with gstreamer or VLC's udp socket streamers
- implements TCP as well, which can offer backpressure when
communicating between flowgraphs

##################################################
# New blocks - digital packet framer/deframer
##################################################
Basically that horrid packet framer in tunnel.py. I took the same packet
utils, its the same code, but the important distinction:

- the packet framer input messages
- the packet deframer outputs messages

The blocks are in grc if anyone cares to play.

##################################################
# New blocks - tuntap
##################################################
A tuntap interface with message input and message output, also available
in grc. This is the thing that implements the tunnel in tunnel.py Sorry,
linux only, unless someone wants to take a whack it for mac os, or
windows (however you do that).

##################################################
# Conclusions
##################################################
The message passing and making blocks in python work supersedes the need
for the old style message queues as the gateway between c++ and python.

Someone could make the equivalent of tunnel.py in GRC using the new
packet framer/deframer and tuntap block. The implementation would be
clearer and smarter.

Feedback and testing is welcome!
-Josh

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

Sunday, October 30, 2011

Re: [Discuss-gnuradio] TVRX2

On 10/30/2011 03:50 PM, Patrik Tast wrote:
> Does a TVRX2 work on a no UHD USRP1?
>
Nope, sorry. Its UHD only.

The driver was only written *once* this time. :-)

-Josh

> Patrik
>
>
>
> _______________________________________________
> 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] GrBlock

On 10/30/2011 08:21 PM, spino wrote:
> I hope you guys are doing well.
>
> I have a compilation problem with GrBlock. I have GNURadio 3.3 and UHD
> installed in a non standard directory (/opt/gnuradio) and (/opt/uhd).
> Please help me with this questions. Can I installed GrBlock when
> GNURadio is in a non-standard directory? What do I need to modify in
> the configuration files of GrBlock? Is Gnuradio3.3 supported or I need
> GNURadio3.4?. I have Ubuntu 10.04, 32-bits
>

It needs a more recent gnuradio (master or latest release) because of
the tags requirement. Anyway, the grblock work has been continued on my
gnuradio development branch. Its now integrated into gnuradio as well:

http://gnuradio.org/cgit/jblum.git/log/?h=next

-Josh

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

Re: [Discuss-gnuradio] uhd_fft and rx_ascii_art_dft die after 30 seconds

On 30/10/11 11:27 PM, Clark Pope wrote:
>
> I am running ubuntu 10.04 in vmware and connecting to an n210 via a gigabit ethernet USB dongle. When I run either uhd_fft.py or rx_ascii_art_dft all works fine for exactly 30 seconds and then the data display stops updating. If I rerun the app it works again for 30 seconds and stops.
>
> In wireshark the data looks good coming from 192.168.10.2 to port 49156 until it hangs then pc sends packet on 35433 and usrp reponds on 49152 and it just goes back and forth forever.
>
> there's plenty of disk space and memory and no messages in dmesg. doesn't seem to matter what sample rate I choose. I assume it has something to do with vmware but just guessing. Any ideas? Thanks
> _______________________________________________
>
>
I would suspect some combination of VMWare and your USB Ethernet
dongle. USB-2.0 operates at
480Msps *maximum*, which is just shy of *half* of the required Gigabit
rates supported by
*real* Gigabit ethernet cards.

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] uhd_fft and rx_ascii_art_dft die after 30 seconds

I am running ubuntu 10.04 in vmware and connecting to an n210 via a gigabit ethernet USB dongle. When I run either uhd_fft.py or rx_ascii_art_dft all works fine for exactly 30 seconds and then the data display stops updating. If I rerun the app it works again for 30 seconds and stops.

In wireshark the data looks good coming from 192.168.10.2 to port 49156 until it hangs then pc sends packet on 35433 and usrp reponds on 49152 and it just goes back and forth forever.

there's plenty of disk space and memory and no messages in dmesg. doesn't seem to matter what sample rate I choose. I assume it has something to do with vmware but just guessing. Any ideas? Thanks
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GrBlock

I hope you guys are doing well.

I have a compilation problem with GrBlock. I have GNURadio 3.3 and UHD
installed in a non standard directory (/opt/gnuradio) and (/opt/uhd).
Please help me with this questions. Can I installed GrBlock when
GNURadio is in a non-standard directory? What do I need to modify in
the configuration files of GrBlock? Is Gnuradio3.3 supported or I need
GNURadio3.4?. I have Ubuntu 10.04, 32-bits

I exported as env variable GRUEL_DIR=/opt/gnuradio and
GNURADIO_CORE_DIR=/opt/gnuradio, so cmake ../ performed as expected,
but when I execute make:
[ 7%] Building CXX object
lib/CMakeFiles/gnuradio-grblock.dir/grblock_gateway.cc.o
In file included from /home/sergio/grblock/lib/grblock_gateway.cc:22:
/home/sergio/grblock/lib/grblock_gateway.h:186: error: ISO C++ forbids
declaration of 'gr_tag_t' with no type
/home/sergio/grblock/lib/grblock_gateway.h:186: error: expected ',' or
'...' before '&' token
/home/sergio/grblock/lib/grblock_gateway.h:201: error: 'gr_tag_t' was
not declared in this scope
/home/sergio/grblock/lib/grblock_gateway.h:201: error: template
argument 1 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:201: error: template
argument 2 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:211: error: 'gr_tag_t' was
not declared in this scope
/home/sergio/grblock/lib/grblock_gateway.h:211: error: template
argument 1 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:211: error: template
argument 2 is invalid
/home/sergio/grblock/lib/grblock_gateway.h: In member function 'void
grblock_gateway::gr_block__add_item_tag(unsigned int, int)':
/home/sergio/grblock/lib/grblock_gateway.h:188: error: 'tag' was not
declared in this scope
/home/sergio/grblock/lib/grblock_gateway.h:188: error:
return-statement with a value, in function returning 'void'
/home/sergio/grblock/lib/grblock_gateway.h: In member function 'int
grblock_gateway::gr_block__get_tags_in_range(unsigned int, uint64_t,
uint64_t)':
/home/sergio/grblock/lib/grblock_gateway.h:206: error: 'gr_tag_t' was
not declared in this scope
/home/sergio/grblock/lib/grblock_gateway.h:206: error: template
argument 1 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:206: error: template
argument 2 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:206: error: invalid type in
declaration before ';' token
/home/sergio/grblock/lib/grblock_gateway.h:207: error: no matching
function for call to 'grblock_gateway::get_tags_in_range(int&,
unsigned int&, uint64_t&, uint64_t&)'
/opt/gnuradio3.3/include/gnuradio/gr_block.h:276: note: candidates
are: void gr_block::get_tags_in_range(std::vector<boost::intrusive_ptr<pmt::pmt_base>,
std::allocator<boost::intrusive_ptr<pmt::pmt_base> > >&, unsigned int,
uint64_t, uint64_t)
/opt/gnuradio3.3/include/gnuradio/gr_block.h:296: note:
void gr_block::get_tags_in_range(std::vector<boost::intrusive_ptr<pmt::pmt_base>,
std::allocator<boost::intrusive_ptr<pmt::pmt_base> > >&, unsigned int,
uint64_t, uint64_t, const pmt::pmt_t&)
/home/sergio/grblock/lib/grblock_gateway.h: In member function 'int
grblock_gateway::gr_block__get_tags_in_range(unsigned int, uint64_t,
uint64_t, const pmt::pmt_t&)':
/home/sergio/grblock/lib/grblock_gateway.h:217: error: 'gr_tag_t' was
not declared in this scope
/home/sergio/grblock/lib/grblock_gateway.h:217: error: template
argument 1 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:217: error: template
argument 2 is invalid
/home/sergio/grblock/lib/grblock_gateway.h:217: error: invalid type in
declaration before ';' token
/home/sergio/grblock/lib/grblock_gateway.h:218: error: no matching
function for call to 'grblock_gateway::get_tags_in_range(int&,
unsigned int&, uint64_t&, uint64_t&, const
boost::intrusive_ptr<pmt::pmt_base>&)'
/opt/gnuradio3.3/include/gnuradio/gr_block.h:276: note: candidates
are: void gr_block::get_tags_in_range(std::vector<boost::intrusive_ptr<pmt::pmt_base>,
std::allocator<boost::intrusive_ptr<pmt::pmt_base> > >&, unsigned int,
uint64_t, uint64_t)
/opt/gnuradio3.3/include/gnuradio/gr_block.h:296: note:
void gr_block::get_tags_in_range(std::vector<boost::intrusive_ptr<pmt::pmt_base>,
std::allocator<boost::intrusive_ptr<pmt::pmt_base> > >&, unsigned int,
uint64_t, uint64_t, const pmt::pmt_t&)
make[2]: *** [lib/CMakeFiles/gnuradio-grblock.dir/grblock_gateway.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-grblock.dir/all] Error 2
make: *** [all] Error 2

Thank you, Sergio Pino
University of Delaware

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

[Discuss-gnuradio] TVRX2

Does a TVRX2 work on a no UHD USRP1?

Patrik

Re: [Discuss-gnuradio] Where is the signal of incoming sample in FPGA?

On 10/30/2011 01:24 PM, xi yang wrote:
> Hi, all,
> Can I add the FFT after the module fifo_to_gpmc?
> It gives an output EM_D(15:0) 16bits, an output of data_available.
> Thanks,
> Yooxi
Not to discourage you, but the overwhelming majority of people on this
list aren't involved in modifying their FPGA code. You might get
better results by using the usrp-users mailing list, which is more
focussed on non-GnuRadio uses of the USRP hardware.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Where is the signal of incoming sample in FPGA?

Hi, all,

Can I add the FFT after the module fifo_to_gpmc?

It gives an output EM_D(15:0) 16bits, an output of data_available.

Thanks,

Yooxi

Re: [Discuss-gnuradio] proper antenna for RFX900

It helps us alot if you specify what you are about to RX/TX.
Questions:
-frequency
-signal is linear (vertical or horizontal) or circular (right or left)

Patrik

----- Original Message -----
From: "Ahmad" <aassbb500@gmail.com>
To: <discuss-gnuradio@gnu.org>
Sent: Sunday, October 30, 2011 12:30
Subject: [Discuss-gnuradio] proper antenna for RFX900

> hello all
> I am planning to use RFX900. Has anybody the experience working with this
> daughter board? It helps to speed up my project. I also need to know the
> proper
> antenna for this board.
> waiting for your reply
> 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

[Discuss-gnuradio] proper antenna for RFX900

hello all
I am planning to use RFX900. Has anybody the experience working with this
daughter board? It helps to speed up my project. I also need to know the proper
antenna for this board.
waiting for your reply
thanks all
Ahmad

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

Saturday, October 29, 2011

[Discuss-gnuradio] Where is the signal of incoming sample in FPGA?

Hi, All,

We wrote codes for FFT in FPGA. In our codes, we start FFT when we get a START signal.
Where can we connect this signal? How do we know that samples are incoming?
There are lots of signals in u1e.v that look like having this function, such as input FPGA_RXD, input fpga_rxd1, input db_miso_rx.
If there exists such a signal, is it a pulse or a constant high value when FPGA is reading data from ADC?
Basically, where can we see the codes that FPGA notifies the host to read data from the FPGA?

Also, the ADC gives 12 bits representation, additions in FFT may change the values to 13 bits.
We believe that the original codes are designed to read samples as 12bits from FPGA to host.
Where is this part?
We are considering reducing 13bits to 12bits or reading samples as 13bits.

Thanks,
Yooxi

Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault

On Oct 28, 2011 11:57 PM, "Josh Blum" <josh@ettus.com> wrote:
> On 10/28/2011 12:20 PM, Vanessa Gardellin wrote:
> > Please let me know if you solve the problem, I also have a seg fault...
> >
>
> So help me help you...
>
> What version of gnuradio?
> What version of uhd?
>
> Do the uhd example apps work?
> Can you import the gnuradio python module?

A similar, more detailed report was posted a few weeks ago.

http://osdir.com/ml/discuss-gnuradio-gnu/2011-10/msg00227.html

Thomas

Re: [Discuss-gnuradio] GNU Radio release candidate 3.5.0rc0 available for download

On Sat, Oct 29, 2011 at 13:55, Arturo Rinaldi <arty.net2@gmail.com> wrote:

i expected to find the CMakelists.txt file inside to rc0 tarball to build with cmake....but there is no trace at all....will it be inserted in the final release of 3.5.0 ?

The cmake build system is still experimental, and our plan is to maintain the autotools system as the "stable" build for making tarballs during the 3.5.x release series. We do encourage people who are using git to build with cmake.

The cmake system does have the ability to generate distribution tarballs, and part of the testing needed is to compare the output of autotools generated tarballs and cmake generated tarballs and work out any differences.

Once we have 3.5.0 out the door, we'll be making a new 'next' branch in the repository that will ultimately become 3.6. It is on this 'next' branch that we'll remove autotools and rely entirely on cmake.

Johnathan

Re: [Discuss-gnuradio] GNU Radio release candidate 3.5.0rc0 available for download

Il 29/10/2011 22:03, Johnathan Corgan ha scritto:

GNU Radio release candidate 3.5.0rc0 has been tagged on the master branch and made available as a tarball:

http://gnuradio.org/redmine/attachments/download/281/gnuradio-3.5.0rc0.tar.gz

As a release candidate, this tarball represents what will be in the 3.5.0 release, absent bug fixes discovered in testing.

To avoid issues with multiple versions of GNU Radio being installed, it is important to uninstall an existing installation using the "make uninstall" command from your source tree.

Also, please remember that when building GNU Radio from a tarball, one does not need to run the "bootstrap" step.

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

i expected to find the CMakelists.txt file inside to rc0 tarball to build with cmake....but there is no trace at all....will it be inserted in the final release of 3.5.0 ?

Regards, Arturo

[Discuss-gnuradio] GNU Radio release candidate 3.5.0rc0 available for download

GNU Radio release candidate 3.5.0rc0 has been tagged on the master branch and made available as a tarball:

http://gnuradio.org/redmine/attachments/download/281/gnuradio-3.5.0rc0.tar.gz

As a release candidate, this tarball represents what will be in the 3.5.0 release, absent bug fixes discovered in testing.

To avoid issues with multiple versions of GNU Radio being installed, it is important to uninstall an existing installation using the "make uninstall" command from your source tree.

Also, please remember that when building GNU Radio from a tarball, one does not need to run the "bootstrap" step.

Johnathan

Friday, October 28, 2011

[Discuss-gnuradio] git clone hanging

Has the git repository been affected by the server issues experienced at gnuradio.org?

$ git clone http://gnuradio.org/git/gnuradio.git

The above hung at "Cloning into gnuradio..." for a long time and then gave this error:

error: Recv failure: Connection reset by peer while accessing http://gnuradio.org/git/gnuradio.git/info/refs

fatal: HTTP request failed

Is there a way to download over the git port?

Thanks,
Sean

Re: [Discuss-gnuradio] GNU Radio website downtime

On Fri, Oct 28, 2011 at 17:28, Johnathan Corgan <jcorgan@corganenterprises.com> wrote:

Due to disk corruption in the volume that stores the MySQL database back-end to the GNU Radio website, it has become necessary to restore from a backup. Fortunately, we have daily backups that go back several weeks, so our data loss will be limited to any changes in the website since yesterday.

I will send a note to the list when things are back up and running.

The disk volume has been replaced with the backup from approximately 20 hours ago, and the site is back up.

If you have made any wiki edits, bug reports, etc., in that time, please check to see whether they need to be redone.

Johnathan

[Discuss-gnuradio] GNU Radio website downtime

All,

Due to disk corruption in the volume that stores the MySQL database back-end to the GNU Radio website, it has become necessary to restore from a backup. Fortunately, we have daily backups that go back several weeks, so our data loss will be limited to any changes in the website since yesterday.

I will send a note to the list when things are back up and running.

Johnathan

[Discuss-gnuradio] Job posting

Hello,

The company I work for is currently looking to hire an engineer with
experience in signal processing. We are looking for someone that can
assume leadership over the complete design and development of our
client/server software.

We need an experienced engineer with the following abilities:

* writing signal processing software - filtering, fft, etc.
* complex algorithm design
* multi-threaded, C++, TCP/IP server applications on Linux
* software optimization

It would also be helpful if you have experience with any of the following:

* Qt SDK
* Intel SSE
* Intel® Threading Building Blocks
* real-time software
* Amazon AWS.

This is a full-time job for a funded, start-up company.

This is not an SDR job, but it does require expertise in many of the
disciplines required for SDR. The successful candidate can work
(telecommute) from their own home office, or in our office in Orange,
CA. Very little travel is required - maybe once or twice per year.

Please send CV, or resume to hans@spot411.com

Please feel free to pass this on to anyone that might be a good candidate.

Thank you very much,
Hans

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

Re: [Discuss-gnuradio] SDR question

On 28/10/2011 5:31 PM, Andrew Rich wrote:
> Thanks Marcus
>
> So you can go outside the useable bandwidth, you just need to
> understand that you will loose something as you move to the next chunk
> of RF ?
Generally, the hardware samples at a fixed rate (USRP1 samples at
64Msps, and USRP2/N2XX sample at 100Msps for example). From
the hosts point of view, if the tuned frequency is X, and the
requested bandwidth is Y, your baseband extends from X-(Y/2) to X+(Y/2).
Not sure what you mean by "loose something as you move to the next
chunk of bandwidth".
>
> I saw an image of several MHz and a little decode window, but I guess
> that is a decoding window, smaller than the SDR sampling window.
It is often the case that an actual application will bring in more
bandwidth than it strictly needs--usually because the application-specific
bandwidth is a little bit smaller than one of the integer fractions
of the samplers input bandwidth. So you typically bandpass-filter in
software
to whatever the bandwidth of your application is, and then possibly
down-sample, or not, depending on the application.

Let's say your sampler front-end runs at 100Msps, and you really only
want 75Khz of bandwidth.

On a USRP2 or N210, the maximum decimation value is 512, which produces
a sample rate of 195312sps, (100e6/512) since this is
complex-baseband, that 195312sps is *also* 195312Hz of usable
bandwidth (in a sense, complex sampling "cheats" Nyquist).

So, you'd place a bandpass filter in the signal path to filter it down
to 75Khz, before you did anything else with it in the signal flow.

>
> I want to use SDR for satellites and packet radio
>
> Does it meet a tnc / analogue radio specs ?
>
An SDR-based platform would have no trouble doing at least the
modulation and radio parts of a TNC, although implementing something
like AX.25 in Gnu Radio is likely a poor architectural choice.

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

Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault

On 10/28/2011 12:20 PM, Vanessa Gardellin wrote:
> Please let me know if you solve the problem, I also have a seg fault...
>

So help me help you...

What version of gnuradio?
What version of uhd?

Do the uhd example apps work?
Can you import the gnuradio python module?

What about making a quick FFT app in gnuradio companion (uhd usrp source
-> fft sink)? Does that work?

This could be an ABI mismatch, or maybe a bug.
Have you tried updating and rebuilding?

-josh

> Thanks
> Vanessa
>
> On Fri, Oct 28, 2011 at 4:41 PM, Josh Blum <josh@ettus.com> wrote:
>>
>>
>> On 10/28/2011 04:03 AM, doering.bas@googlemail.com wrote:
>>> Hello list,
>>>
>>> I tried to launch the "uhd_fft.py" script with the following command line:
>>>
>>> "uhd_fft.py -a type=usrp2 -f 935M -s 2M"
>>>
>>>
>>> My problem is that my terminal always returns this output:
>>>
>>> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae
>>>
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>> -- mboard0 is MIMO master
>>> Segmentation fault
>>>
>>>
>>
>> Does uhd_usrp_probe work? If so, is there a particular line in
>> uhd_fft.py that causes the seg fault? Have you debugged w/ gdb?
>>
>> In any case, I recommend upgrading to the latest release, then see if
>> there is still a problem.
>>
>> -Josh
>>
>>
>>> I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo CPU P8600 @
>>> 2.40GHz × 2, USRP N210 with WBX.
>>> I also use ClockTamer as reference for the internal XO and 2 normal GSM
>>> 900 antennas.
>>>
>>> I would really appreciate if someone has an idea on what I am doing
>>> wrong here.
>>>
>>> Thanks in advance!
>>>
>>> Sebastian
>>>
>>> _______________________________________________
>>> 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] SDR question

Thanks Marcus

So you can go outside the useable bandwidth, you just need to understand
that you will loose something as you move to the next chunk of RF ?

I saw an image of several MHz and a little decode window, but I guess that
is a decoding window, smaller than the SDR sampling window.

I want to use SDR for satellites and packet radio

Does it meet a tnc / analogue radio specs ?

- Andrew -

----- Original Message -----
From: "Marcus D. Leech" <mleech@ripnet.com>
To: <discuss-gnuradio@gnu.org>
Sent: Saturday, October 29, 2011 7:16 AM
Subject: Re: [Discuss-gnuradio] SDR question

> On 28/10/2011 5:08 PM, Andrew Rich wrote:
>>
>> I have a question about software defined radio
>>
>> I saw a pass band the other day on a screen which prompted me to ask
>>
>> The Software defined radio has a specific bandwidth ?
>>
>> Does it "scan" across the band very quickly to form the passband, or is
>> the bandwidth already that large it just appears as a chunk of MHz ?
>>
>> I am trying to make the connection between how a Software Defined Radio
>> would be different from an analogue system.
>>
>> For example decoding packet radio using an SDR, is there any performance
>> degradation due to the way it works ?
>>
>> Would the SDR "sweep" and miss some of the signal ?
>>
>> - Andrew VK4TEC -
>>
>
> A typical SDR hardware front-end (just taking the RX view for now) has a
> tunable direct-conversion down-converter that converts a swath of
> bandwidth at a desired center frequency into a complex (I,Q) baseband
> signal that "straddles" from -BW/2 to BW/2,
> with "DC" in the middle.
>
> That swath of (analog) bandwidth is sampled by an ADC and FPGA, and then
> decimated for delivery of a lesser bandwidth (again, in complex
> baseband form) into the host computer for further processing. The
> decimation also acts as a filter, so that there is strong alias
> suppression
> in the delivered bandwidth. It is usually the case that the FPGA
> decimator is configurable with respect to the amount of bandwidth
> delivered towards the host.
>
> Bandwidths of several MHz into the host are achievable these days, with
> all demodulation, etc, happening on the host.
>
> That is not to say that you couldn't implement a sweeper for doing SIGINT
> and spectral estimation, etc. In fact, there are Gnu Radio
> applications that do just that.
>
>
> _______________________________________________
> 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] SDR question

On 28/10/2011 5:08 PM, Andrew Rich wrote:
>
> I have a question about software defined radio
>
> I saw a pass band the other day on a screen which prompted me to ask
>
> The Software defined radio has a specific bandwidth ?
>
> Does it "scan" across the band very quickly to form the passband, or
> is the bandwidth already that large it just appears as a chunk of MHz ?
>
> I am trying to make the connection between how a Software Defined
> Radio would be different from an analogue system.
>
> For example decoding packet radio using an SDR, is there any
> performance degradation due to the way it works ?
>
> Would the SDR "sweep" and miss some of the signal ?
>
> - Andrew VK4TEC -
>

A typical SDR hardware front-end (just taking the RX view for now) has a
tunable direct-conversion down-converter that converts a swath of
bandwidth at a desired center frequency into a complex (I,Q) baseband
signal that "straddles" from -BW/2 to BW/2,
with "DC" in the middle.

That swath of (analog) bandwidth is sampled by an ADC and FPGA, and then
decimated for delivery of a lesser bandwidth (again, in complex
baseband form) into the host computer for further processing. The
decimation also acts as a filter, so that there is strong alias suppression
in the delivered bandwidth. It is usually the case that the FPGA
decimator is configurable with respect to the amount of bandwidth
delivered towards the host.

Bandwidths of several MHz into the host are achievable these days, with
all demodulation, etc, happening on the host.

That is not to say that you couldn't implement a sweeper for doing
SIGINT and spectral estimation, etc. In fact, there are Gnu Radio
applications that do just that.

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

[Discuss-gnuradio] SDR question

I have a question about software defined radio

I saw a pass band the other day on a screen which prompted me to ask

The Software defined radio has a specific bandwidth ?

Does it "scan" across the band very quickly to form the passband, or is the
bandwidth already that large it just appears as a chunk of MHz ?

I am trying to make the connection between how a Software Defined Radio
would be different from an analogue system.

For example decoding packet radio using an SDR, is there any performance
degradation due to the way it works ?

Would the SDR "sweep" and miss some of the signal ?

- Andrew VK4TEC -

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

Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault

Please let me know if you solve the problem, I also have a seg fault...

Thanks
Vanessa

On Fri, Oct 28, 2011 at 4:41 PM, Josh Blum <josh@ettus.com> wrote:
>
>
> On 10/28/2011 04:03 AM, doering.bas@googlemail.com wrote:
>> Hello list,
>>
>> I tried to launch the "uhd_fft.py" script with the following command line:
>>
>> "uhd_fft.py -a type=usrp2 -f 935M -s 2M"
>>
>>
>> My problem is that my terminal always returns this output:
>>
>> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae
>>
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- mboard0 is MIMO master
>> Segmentation fault
>>
>>
>
> Does uhd_usrp_probe work? If so, is there a particular line in
> uhd_fft.py that causes the seg fault? Have you debugged w/ gdb?
>
> In any case, I recommend upgrading to the latest release, then see if
> there is still a problem.
>
> -Josh
>
>
>> I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo CPU P8600 @
>> 2.40GHz × 2, USRP N210 with WBX.
>> I also use ClockTamer as reference for the internal XO and 2 normal GSM
>> 900 antennas.
>>
>> I would really appreciate if someone has an idea on what I am doing
>> wrong here.
>>
>> Thanks in advance!
>>
>> Sebastian
>>
>> _______________________________________________
>> 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
>

--
Vanessa GARDELLIN, Ph.D.
Researcher
Institute for Informatics and Telematics (IIT),
Italian National Research Council (CNR)
Via G. Moruzzi 1
56124 Pisa - ITALY
Phone: +390503153267
Room: B65/c
E-mail: vanessa.gardellin@iit.cnr.it
WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
Skype: gardellin.vanessa

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

Re: [Discuss-gnuradio] Going on "holiday"

On Fri, Oct 28, 2011 at 11:54, Johnathan Corgan <jcorgan@corganenterprises.com> wrote:

On Fri, Oct 28, 2011 at 11:53, Tom Rondeau <trondeau1122@gmail.com> wrote:

It actually wasn't "down," but I don't know why it was responding the way it was. I just rebooted it to fix whatever the problem was. I'm about at the airport, so I have to pass these problems off to Johnathan.

There was some issues with Amazon Web Services earlier today. The server instance is running now.

Well, partially. The disk volume that holds the mysql back-end to the Redmine website seems borked, causing *very* slow responses to links on the site, but they do seem to work eventually. Other things like the cgit interface to repositories and pushing and pulling from git seem ok.

I'm looking into it.

Johnathan

Re: [Discuss-gnuradio] Going on "holiday"

On Fri, Oct 28, 2011 at 11:53, Tom Rondeau <trondeau1122@gmail.com> wrote:

It actually wasn't "down," but I don't know why it was responding the way it was. I just rebooted it to fix whatever the problem was. I'm about at the airport, so I have to pass these problems off to Johnathan.

There was some issues with Amazon Web Services earlier today. The server instance is running now.

Johnathan

Re: [Discuss-gnuradio] Going on "holiday"

It actually wasn't "down," but I don't know why it was responding the way it was. I just rebooted it to fix whatever the problem was. I'm about at the airport, so I have to pass these problems off to Johnathan.

Sent from my iPhone

On Oct 28, 2011, at 2:48 PM, Ben Hilburn <ben@ettus.com> wrote:

Tom -

gnuradio.org is down =(

Cheers,
Ben

On Fri, Oct 28, 2011 at 11:35 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:

I just wanted to let everyone know that I'm taking a vacation for the week (and won't be taking my computer with me <gasp!>). I'm sure the list will continue to survive and function as usual with the standard amount of help and advice given by everyone, so you probably won't even notice that I'm missing.

In the mean time, Johnathan Corgan should be putting out a release candidate of 3.5.0 within the next day. We have already moved our master branch in GNU Radio to this version, anyway, so if you're keeping up that way, you've already made the transition. Please continue to report bugs, though, before we put out the full 3.5.0 release. This represents a number of big changes, so we need eyes on and hands inside the code to make sure it's working right. I recommend people submit bugs to the Issue Tracker on our Redmine page (you'll have to log in to create a new ticket, the guest account is guest:gnuradio), otherwise it might get lost in email.

Thanks!

Tom

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

Re: [Discuss-gnuradio] Going on "holiday"

Tom -

gnuradio.org is down =(

Cheers,

Ben

On Fri, Oct 28, 2011 at 11:35 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:

I just wanted to let everyone know that I'm taking a vacation for the week (and won't be taking my computer with me <gasp!>). I'm sure the list will continue to survive and function as usual with the standard amount of help and advice given by everyone, so you probably won't even notice that I'm missing.

In the mean time, Johnathan Corgan should be putting out a release candidate of 3.5.0 within the next day. We have already moved our master branch in GNU Radio to this version, anyway, so if you're keeping up that way, you've already made the transition. Please continue to report bugs, though, before we put out the full 3.5.0 release. This represents a number of big changes, so we need eyes on and hands inside the code to make sure it's working right. I recommend people submit bugs to the Issue Tracker on our Redmine page (you'll have to log in to create a new ticket, the guest account is guest:gnuradio), otherwise it might get lost in email.

Thanks!

Tom

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

Re: [Discuss-gnuradio] Going on "holiday"

http://www.downforeveryoneorjustme.com/gnuradio.org

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

[Discuss-gnuradio] Going on "holiday"

I just wanted to let everyone know that I'm taking a vacation for the week (and won't be taking my computer with me <gasp!>). I'm sure the list will continue to survive and function as usual with the standard amount of help and advice given by everyone, so you probably won't even notice that I'm missing.

In the mean time, Johnathan Corgan should be putting out a release candidate of 3.5.0 within the next day. We have already moved our master branch in GNU Radio to this version, anyway, so if you're keeping up that way, you've already made the transition. Please continue to report bugs, though, before we put out the full 3.5.0 release. This represents a number of big changes, so we need eyes on and hands inside the code to make sure it's working right. I recommend people submit bugs to the Issue Tracker on our Redmine page (you'll have to log in to create a new ticket, the guest account is guest:gnuradio), otherwise it might get lost in email.

Thanks!

Tom

Re: [Discuss-gnuradio] GrBlock Inconsistent IO Size

Just FYI, I am integrating this work into gnuradio-core as we speak :-)

On 10/28/2011 10:05 AM, Jason Bonior wrote:
> I used grblock and numpy to create a block which would calculate the
> variance of an incoming vector then pass on the result:
>
> class variance(grblock.sync_block):
>
> def __init__(self):
> grblock.sync_block.__init__(
> self,
> name = "variance",
> in_sig = [(numpy.float32, 2048)],
> out_sig = [numpy.float32],
> )
>
> def work(self, input_items, output_items):
> output_items[0][:] = numpy.var(input_items[0])
> print output_items[0][:].shape
> print input_items[0].shape
> return len(output_items[0])
>
> I added the print .shape commands to make sure that the block IO was
> performing as expected. Most of the time I get (1, 2048) and (1, ) as
> I would expect but occasionally I get (2, 2048) (2, ) up to (5, 2048)
> (5,). Has anyone else seen anything like this or know how it might
> affect the performance of the block?
>

Each element of the input vector is an array of items. In this case each
item is a vector of 2048 (I know... its a vector of vectors of vectors).
Its not guaranteed how many items the scheduler will give you. It looks
like usually you get 1 item, but sometimes several. This is consistent
with my observations when dealing with the output of the FFT block.

-Josh

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

[Discuss-gnuradio] GrBlock Inconsistent IO Size

I used grblock and numpy to create a block which would calculate the
variance of an incoming vector then pass on the result:

class variance(grblock.sync_block):

def __init__(self):
grblock.sync_block.__init__(
self,
name = "variance",
in_sig = [(numpy.float32, 2048)],
out_sig = [numpy.float32],
)

def work(self, input_items, output_items):
output_items[0][:] = numpy.var(input_items[0])
print output_items[0][:].shape
print input_items[0].shape
return len(output_items[0])

I added the print .shape commands to make sure that the block IO was
performing as expected. Most of the time I get (1, 2048) and (1, ) as
I would expect but occasionally I get (2, 2048) (2, ) up to (5, 2048)
(5,). Has anyone else seen anything like this or know how it might
affect the performance of the block?

--
Jason Bonior

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