On Oct 26, 2011 9:31 PM, <
address@hidden> wrote:
Send Discuss-gnuradio mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. .bit file not loading on usrp n210 (Clark Pope)
2. Trouble with multiple installs or how i learned to love make
uninstall (Paul M. Bendixen)
3. Re: Trouble with multiple installs or how i learned to love
make uninstall (Tom Rondeau)
4. Re: .bit file not loading on usrp n210 (Ian Buckley)
5. Re: .bit file not loading on usrp n210 (Nick Foster)
6. cannot import name packet_utils (David L)
7. Problem with WXGUI Widgets (Jordan Otomo)
8. Re: cannot import name packet_utils (Tom Rondeau)
9. Re: Problem with WXGUI Widgets (Tom Rondeau)
10. Re: .bit file not loading on usrp n210 (Clark Pope)
11. Re: Problem with WXGUI Widgets (Jordan Otomo)
12. Problems after upgrading to UHD with USRP2 (Sam Keene)
13. Re: Problem with WXGUI Widgets (Tom Rondeau)
14. No packet reception in higher modulation (Nazmul Islam)
15. Re: Problem with WXGUI Widgets (Jordan Otomo)
16. Re: Problem with WXGUI Widgets (Tom Rondeau)
17. Re: Problem with WXGUI Widgets (Marcus D. Leech)
18. Re: Fwd: Introducing noise/ considerable BER
(shantharam balasubramanian)
19. Re: Fwd: Introducing noise/ considerable BER (Marcus D. Leech)
20. Re: Problem with WXGUI Widgets (Jason Abele)
21. Re: Problem with WXGUI Widgets (Jordan Otomo)
22. Re: Problem with WXGUI Widgets (Jordan Otomo)
23. Re: Problems after upgrading to UHD with USRP2 (Josh Blum)
24. Re: No packet reception in higher modulation (Josh Blum)
25. Re: Problem with WXGUI Widgets (Josh Blum)
26. Re: gr-trellis broken on next branch (Tom Rondeau)
27. available sample rates for USRP2 (Kyle Zhou)
28. Re: available sample rates for USRP2 (Josh Blum)
29. Re: available sample rates for USRP2 (Nick Foster)
30. New build-gnuradio (Marcus D. Leech)
31. Re: New build-gnuradio (Tom Rondeau)
32. Re: New build-gnuradio (Dan CaJacob)
33. Re: New build-gnuradio (Dan CaJacob)
34. Re: Trouble with multiple installs or how i learned to love
make uninstall (Paul M. Bendixen)
35. Re: How to reconfigure automatically the channel used to
received data in USRPs (Lebowski80)
36. recovering timing after overflow (Juha Vierinen)
37. Errors of missing modulators in gnuradio-companion
(Paul M. Bendixen)
38. Re: Errors of missing modulators in gnuradio-companion
(Tom Rondeau)
39. Re: Errors of missing modulators in gnuradio-companion
(Tom Rondeau)
40. Re: Errors of missing modulators in gnuradio-companion
(Paul M. Bendixen)
41. Re: New build-gnuradio (Nowlan, Sean)
42. Packet-based communication & underrun / Possible solution?
(Mattia Rizzi)
43. Re: Packet-based communication & underrun / Possible
solution? (Mattia Rizzi)
44. Re: New build-gnuradio (Marcus D. Leech)
45. Re: recovering timing after overflow (Josh Blum)
46. Re: New build-gnuradio (Nowlan, Sean)
47. Coarse Frequency and related stuff (Vanessa Gardellin)
48. Re: Errors of missing modulators in gnuradio-companion
(Paul M. Bendixen)
49. Re: recovering timing after overflow (Juha Vierinen)
50. Re: Measuring RSSI on USRPN200 (Vanessa Gardellin)
51. Re: Measuring RSSI on USRPN200 (Marcus D. Leech)
52. Building on Mac OSX (Jeff Scaparra)
53. Re: Segmentation Fault (Vanessa Gardellin)
54. Re: Segmentation Fault (Marcus D. Leech)
55. Re: Building on Mac OSX (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Oct 2011 12:06:51 -0400
From: Clark Pope <address@hidden>
To: <address@hidden>
Subject: [Discuss-gnuradio] .bit file not loading on usrp n210
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
When I download a .bit file to the N210 using JTAG and Xilinx Impact the programmer says all is good:
// *** BATCH CMD : Program -p 1
PROGRESS_START - Starting Operation.
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
Boundary-scan chain validated successfully.
'1': Programming device...
LCK_cycle = NoWait.
LCK cycle: NoWait
done.
'1': Reading status register contents...
CRC error : 0
IDCODE not validated while writing FDRI : 0
DCM matched : 1
status of GTS_CFG_B : 1
status of GWE : 1
status of GHIGH : 1
value of VSEL pin 0 : 1
value of VSEL pin 1 : 1
value of VSEL pin 2 : 1
value of MODE pin M0 : 1
value of MODE pin M1 : 0
value of MODE pin M2 : 0
value of CFG_RDY (INIT_B) : 1
DONEIN input from Done Pin : 1
POST_CRC_ERR error : 0
SYNC word not found : 0
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 0011 1111 1100 1100
INFO:iMPACT:579 - '1': Completed downloading bit file to device.
INFO:iMPACT:188 - '1': Programming completed successfully.
LCK_cycle = NoWait.
LCK cycle: NoWait
INFO:iMPACT - '1': Checking done pin....done.
'1': Programmed successfully.
PROGRESS_END - End Operation.
Elapsed time = 13 sec.
but the .bit file isn't actually active. I know because my changes aren't present and the idcode reads the old value. I can reflash with the corresponding .bin file and cycle power and it does become active.
Is it possible the download is triggering a reload of the bit stored in flash? Any ideas are appreciated. Thanks
------------------------------
Message: 2
Date: Tue, 25 Oct 2011 18:19:49 +0200
From: "Paul M. Bendixen" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Trouble with multiple installs or how i
learned to love make uninstall
Message-ID:
<CAAvei9o19w1dGaKQ=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello
It seems it might be a good idea if it were possible to uninstall gnuradio
propper.
I currently have two systems faling (hard) using the new build.
My gentoo box (configured using cmake in another thread)
gives me the error :
ImportError: libgruel-3.4.2git.so.0: cannot open shared object file: No such
file or directory
Whenever i try
from gnuradio import digital.
funny part is: I never succeeded in installing 3.4.2, so I don't blame it
for not finding it.
I tried doing a manual ldconfig, but it didn't seem to do the trick.
On an ubuntu machine (xubuntu to be specific) using the build-gnuradio
script, most of the digital schemes fails
due to the reallocation of packets to digital. This includes stuff that
should be updated.
Is it possible that the python stuff does not get properly updated and is
there any way to fix this?
Downgrading, by adding a "git checkout v3.4.2" fixes makes the build run
fine again.
On both systems the building of the system is without problems.
--
* - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */-
- */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/1eb9e2f2/attachment.html>
------------------------------
Message: 3
Date: Tue, 25 Oct 2011 12:47:21 -0400
From: Tom Rondeau <address@hidden>
To: "Paul M. Bendixen" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Trouble with multiple installs or how
i learned to love make uninstall
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 25, 2011 at 12:19 PM, Paul M. Bendixen
<address@hidden>wrote:
> Hello
>
> It seems it might be a good idea if it were possible to uninstall gnuradio
> propper.
>
> I currently have two systems faling (hard) using the new build.
>
> My gentoo box (configured using cmake in another thread)
> gives me the error :
> ImportError: libgruel-3.4.2git.so.0: cannot open shared object file: No
> such file or directory
> Whenever i try
> from gnuradio import digital.
>
> funny part is: I never succeeded in installing 3.4.2, so I don't blame it
> for not finding it.
>
> I tried doing a manual ldconfig, but it didn't seem to do the trick.
>
> On an ubuntu machine (xubuntu to be specific) using the build-gnuradio
> script, most of the digital schemes fails
> due to the reallocation of packets to digital. This includes stuff that
> should be updated.
>
> Is it possible that the python stuff does not get properly updated and is
> there any way to fix this?
>
> Downgrading, by adding a "git checkout v3.4.2" fixes makes the build run
> fine again.
>
> On both systems the building of the system is without problems.
>
make uninstall does work and removes all of the GNU Radio files from the
system. The twist that you need to remember is that you have to do it BEFORE
upgrading to a new version. The 3.5 will try to uninstall it's stuff, which
will be different from 3.4. So you have to have to run 'make uninstall' when
you've configured for what's installed on your system. Then you can upgrade
and shouldn't have any conflicts.
When you say that you didn't have 3.4.2 installed, do you mean that you
never installed from master before? For the past few weeks, the master
branch reflected the 3.4.2, so any installs will have that in their name.
You did help me find a bug in our cmake install, though. Some of our
specially-built files are not being removed by uninstall.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/325429ac/attachment.html>
------------------------------
Message: 4
Date: Tue, 25 Oct 2011 10:15:46 -0700
From: Ian Buckley <address@hidden>
To: Clark Pope <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] .bit file not loading on usrp n210
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
I've only done a little FPGA work on the N210 so this is a bit of a guess, Nick or Josh can answer better, but I would imagine you probably need to understand how the FPGA image "bootstraps". The N210 stores 2 FPGA images so that there is a safe image to restore from if you upload a bad image. This is because the normal FPGA image update mechanism is via TCP/IP and hence uses the FPGA...a chicken and egg problem as it were. Unless you are developing an FPGA image that throws away the Ettus boot mechanism I'd suggest sticking to the regular FPGA image update methodology and restrict your use of JTAG to Chipscope etc.
-Ian
On Oct 25, 2011, at 9:06 AM, Clark Pope wrote:
>
> When I download a .bit file to the N210 using JTAG and Xilinx Impact the programmer says all is good:
> // *** BATCH CMD : Program -p 1
> PROGRESS_START - Starting Operation.
> Maximum TCK operating frequency for this device chain: 10000000.
> Validating chain...
> Boundary-scan chain validated successfully.
> '1': Programming device...
> LCK_cycle = NoWait.
> LCK cycle: NoWait
> done.
> '1': Reading status register contents...
> CRC error : 0
> IDCODE not validated while writing FDRI : 0
> DCM matched : 1
> status of GTS_CFG_B : 1
> status of GWE : 1
> status of GHIGH : 1
> value of VSEL pin 0 : 1
> value of VSEL pin 1 : 1
> value of VSEL pin 2 : 1
> value of MODE pin M0 : 1
> value of MODE pin M1 : 0
> value of MODE pin M2 : 0
> value of CFG_RDY (INIT_B) : 1
> DONEIN input from Done Pin : 1
> POST_CRC_ERR error : 0
> SYNC word not found : 0
> INFO:iMPACT:2219 - Status register values:
> INFO:iMPACT - 0011 1111 1100 1100
> INFO:iMPACT:579 - '1': Completed downloading bit file to device.
> INFO:iMPACT:188 - '1': Programming completed successfully.
> LCK_cycle = NoWait.
> LCK cycle: NoWait
> INFO:iMPACT - '1': Checking done pin....done.
> '1': Programmed successfully.
> PROGRESS_END - End Operation.
> Elapsed time = 13 sec.
> but the .bit file isn't actually active. I know because my changes aren't present and the idcode reads the old value. I can reflash with the corresponding .bin file and cycle power and it does become active.
> Is it possible the download is triggering a reload of the bit stored in flash? Any ideas are appreciated. Thanks
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 5
Date: Tue, 25 Oct 2011 10:27:13 -0700
From: Nick Foster <address@hidden>
To: Ian Buckley <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] .bit file not loading on usrp n210
Message-ID:
<CALALHJURX=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Just hold down the "safe mode" button S2 when booting. The image
you're loading is probably bootstrapping the production FPGA image out
of Flash.
--n
On Tue, Oct 25, 2011 at 10:15 AM, Ian Buckley <address@hidden> wrote:
> I've only done a little FPGA work on the N210 so this is a bit of a guess, Nick or Josh can answer better, but I would imagine you probably need to understand how the FPGA image "bootstraps". The N210 stores 2 FPGA images so that there is a safe image to restore from if you upload a bad image. This is because the normal FPGA image update mechanism is via TCP/IP and hence uses the FPGA...a chicken and egg problem as it were. Unless you are developing an FPGA image that throws away the Ettus boot mechanism I'd suggest sticking to the regular FPGA image update methodology and restrict your use of JTAG to Chipscope etc.
> -Ian
>
> On Oct 25, 2011, at 9:06 AM, Clark Pope wrote:
>
>>
>> When I download a .bit file to the N210 using JTAG and Xilinx Impact the programmer says all is good:
>> // *** BATCH CMD : Program -p 1
>> PROGRESS_START - Starting Operation.
>> Maximum TCK operating frequency for this device chain: 10000000.
>> Validating chain...
>> Boundary-scan chain validated successfully.
>> '1': Programming device...
>> LCK_cycle = NoWait.
>> LCK cycle: NoWait
>> done.
>> '1': Reading status register contents...
>> CRC error ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 0
>> IDCODE not validated while writing FDRI ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 0
>> DCM matched ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> status of GTS_CFG_B ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> status of GWE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> status of GHIGH ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> value of VSEL pin 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> value of VSEL pin 1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> value of VSEL pin 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> value of MODE pin M0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : ? ? ? ? 1
>> value of MODE pin M1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : ? ? ? ? 0
>> value of MODE pin M2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : ? ? ? ? 0
>> value of CFG_RDY (INIT_B) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 1
>> DONEIN input from Done Pin ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : ? ? ? ? 1
>> POST_CRC_ERR error ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : ? ? ? ? 0
>> SYNC word not found ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: ? ? ? ? 0
>> INFO:iMPACT:2219 - Status register values:
>> INFO:iMPACT - 0011 1111 1100 1100
>> INFO:iMPACT:579 - '1': Completed downloading bit file to device.
>> INFO:iMPACT:188 - '1': Programming completed successfully.
>> LCK_cycle = NoWait.
>> LCK cycle: NoWait
>> INFO:iMPACT - '1': Checking done pin....done.
>> '1': Programmed successfully.
>> PROGRESS_END - End Operation.
>> Elapsed time = ? ? 13 sec.
>> but the .bit file isn't actually active. I know because my changes aren't present and the idcode reads the old value. I can reflash with the corresponding .bin file and cycle power and it does become active.
>> Is it possible the download is triggering a reload of the bit stored in flash? Any ideas are appreciated. Thanks
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 6
Date: Tue, 25 Oct 2011 10:39:25 -0700
From: David L <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] cannot import name packet_utils
Message-ID:
<CANyeoMt4xhVmKHm9wv-oW3ST_NrMbLswuCtnEfyfHKdr5AP=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
I installed gnuradio on a new computer (Ubuntu 11.10) last night using the
build_gnuradio script. I ran a python script that is working on on another
11.10 computer and got the following error:
from grc_gnuradio import blks2 as grc_blks2
File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/blks2/__init__.py",
line 22, in <module>
from packet import options, packet_encoder, packet_decoder, \
File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/blks2/packet.py",
line 21, in <module>
from gnuradio import gr, packet_utils
ImportError: cannot import name packet_utils
Any ideas what I'm doing wrong?
Thanks,
Dave
------------------------------
Message: 7
Date: Tue, 25 Oct 2011 11:43:40 -0700 (PDT)
From: Jordan Otomo <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
Hi,
I seem to be having an issue with a few of the GRC WX GUI Widgets, namely the FFT Sink and Scope Sink, in the latest release (3.5.0). My flowgraphs now exit immediately, without error. I've constructed a simple flowgraph consisting of a signal source, throttle, and FFT Sink/Scope Sink to test this and it exits immediately after execution. The only message I receive is ">>> Done". Any help would be greatly appreciated.
Thanks,
Jordan
------------------------------
Message: 8
Date: Tue, 25 Oct 2011 14:56:57 -0400
From: Tom Rondeau <address@hidden>
To: David L <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] cannot import name packet_utils
Message-ID:
<CANc0s2OWdiZzqBR0U8Q=pDsp2MKxK=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 25, 2011 at 1:39 PM, David L <address@hidden> wrote:
> I installed gnuradio on a new computer (Ubuntu 11.10) last night using the
> build_gnuradio script. I ran a python script that is working on on another
> 11.10 computer and got the following error:
>
> from grc_gnuradio import blks2 as grc_blks2
> File
> "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/blks2/__init__.py",
> line 22, in <module>
> from packet import options, packet_encoder, packet_decoder, \
> File
> "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/blks2/packet.py",
> line 21, in <module>
> from gnuradio import gr, packet_utils
> ImportError: cannot import name packet_utils
>
> Any ideas what I'm doing wrong?
>
> Thanks,
>
> Dave
>
You're running a new version of GNU Radio with lots of changes:
http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
All digital modulation blocks are now under the digital namespace. You can
get the packet_utils block from that module, now.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/9596fd07/attachment.html>
------------------------------
Message: 9
Date: Tue, 25 Oct 2011 15:01:30 -0400
From: Tom Rondeau <address@hidden>
To: Jordan Otomo <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 25, 2011 at 2:43 PM, Jordan Otomo <address@hidden>wrote:
> Hi,
>
> I seem to be having an issue with a few of the GRC WX GUI Widgets, namely
> the FFT Sink and Scope Sink, in the latest release (3.5.0). My flowgraphs
> now exit immediately, without error. I've constructed a simple flowgraph
> consisting of a signal source, throttle, and FFT Sink/Scope Sink to test
> this and it exits immediately after execution. The only message I receive
> is ">>> Done". Any help would be greatly appreciated.
>
> Thanks,
> Jordan
>
It might help to remove all of the old GNU Radio installed files from your
system (in prefix/lib/libgnuradio*,
prefix/lib/python2.X/dist-packages/gnuradio, prefix/include/gnuradio,
prefix/share/doc/gnuradio, prefix/share/gnuradio).
You shouldn't have to do this, but it seems a common cause of problems when
upgrading.
Then reinstall and make sure to run ldconfig.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/df53e2d9/attachment.html>
------------------------------
Message: 10
Date: Tue, 25 Oct 2011 15:14:21 -0400
From: Clark Pope <address@hidden>
To: <address@hidden>, <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] .bit file not loading on usrp n210
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Thanks. Looks like holding down S2 while IMPACT loads the .bit file does make the .bit file become active. However, I can never establish ethernet connection until cycling power. I assume the fpga is loaded but the software isn't running? The activity lights flash rapidly but I only get:
RuntimeError: LookupError: KeyError: No devices found for ----->
Device Address:
addr: 192.168.10.2
----------------------------------------
> Date: Tue, 25 Oct 2011 10:27:13 -0700
> Subject: Re: [Discuss-gnuradio] .bit file not loading on usrp n210
> From: address@hidden
> To: address@hidden
> CC: address@hidden; address@hidden
>
> Just hold down the "safe mode" button S2 when booting. The image
> you're loading is probably bootstrapping the production FPGA image out
> of Flash.
>
> --n
>
------------------------------
Message: 11
Date: Tue, 25 Oct 2011 12:53:11 -0700 (PDT)
From: Jordan Otomo <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
Hi Tom,
Thanks for the help. I've tried manually deleting all of the GNU Radio files in the recommended locations, reinstalling, and performing a 'sudo ldconfig', but the problem still persists. You mentioned a few install directories not listed in the FAQ's "The problem of multiple installs" section. Do you know if there are any other install files I should delete before reinstalling? Thanks again!
Jordan
----- Original Message -----
From: "Tom Rondeau" <address@hidden>
To: "Jordan Otomo" <address@hidden>
Cc: address@hidden
Sent: Tuesday, October 25, 2011 12:01:30 PM
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
On Tue, Oct 25, 2011 at 2:43 PM, Jordan Otomo < address@hidden > wrote:
Hi,
I seem to be having an issue with a few of the GRC WX GUI Widgets, namely the FFT Sink and Scope Sink, in the latest release (3.5.0). My flowgraphs now exit immediately, without error. I've constructed a simple flowgraph consisting of a signal source, throttle, and FFT Sink/Scope Sink to test this and it exits immediately after execution. The only message I receive is ">>> Done". Any help would be greatly appreciated.
Thanks,
Jordan
It might help to remove all of the old GNU Radio installed files from your system (in prefix/lib/libgnuradio*, prefix/lib/python2.X/dist-packages/gnuradio, prefix/include/gnuradio, prefix/share/doc/gnuradio, prefix/share/gnuradio).
You shouldn't have to do this, but it seems a common cause of problems when upgrading.
Then reinstall and make sure to run ldconfig.
Tom
------------------------------
Message: 12
Date: Tue, 25 Oct 2011 12:53:06 -0700 (PDT)
From: Sam Keene <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Problems after upgrading to UHD with USRP2
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hello all,
We recently upgraded to the UHD drivers, and now some basic stuff we had working with the older drivers just isn't working anymore. For example, I'm just trying to transmit and receive a raised cosine pulse, but I'm not getting anything at the receiver. I've eliminated all warnings that I was getting, to no avail. We're using USRP2s with the RFX2400 daughterboards.
I'm attaching 2 GRC files as examples of what we're doing. I'm not getting any received signal. Any idea what I'm doing wrong.
thanks,
-Sam Keene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/ebc96149/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simpleRx.grc
Type: application/octet-stream
Size: 14861 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/ebc96149/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simpleTx.grc
Type: application/octet-stream
Size: 19708 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/ebc96149/attachment-0001.obj>
------------------------------
Message: 13
Date: Tue, 25 Oct 2011 16:38:11 -0400
From: Tom Rondeau <address@hidden>
To: Jordan Otomo <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID:
<CANc0s2NA0yBSYyzfC3ejpyNY9vD0=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 25, 2011 at 3:53 PM, Jordan Otomo <address@hidden>wrote:
> Hi Tom,
>
> Thanks for the help. I've tried manually deleting all of the GNU Radio
> files in the recommended locations, reinstalling, and performing a 'sudo
> ldconfig', but the problem still persists. You mentioned a few install
> directories not listed in the FAQ's "The problem of multiple installs"
> section. Do you know if there are any other install files I should delete
> before reinstalling? Thanks again!
>
> Jordan
That FAQ does list all of the install directories; I was just a bit more
explicit in my email about where they are (subdirs in lib and share, for
example; and I missed the bin directories). That should be it; anything else
shouldn't be causing you problems.
What OS are you running? Are you building with cmake or autotools? Any
configure-time failures?
Tom
> ----- Original Message -----
> From: "Tom Rondeau" <address@hidden>
> To: "Jordan Otomo" <address@hidden>
> Cc: address@hidden
> Sent: Tuesday, October 25, 2011 12:01:30 PM
> Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
>
>
> On Tue, Oct 25, 2011 at 2:43 PM, Jordan Otomo < address@hidden >
> wrote:
>
>
> Hi,
>
> I seem to be having an issue with a few of the GRC WX GUI Widgets, namely
> the FFT Sink and Scope Sink, in the latest release (3.5.0). My flowgraphs
> now exit immediately, without error. I've constructed a simple flowgraph
> consisting of a signal source, throttle, and FFT Sink/Scope Sink to test
> this and it exits immediately after execution. The only message I receive is
> ">>> Done". Any help would be greatly appreciated.
>
> Thanks,
> Jordan
>
>
>
>
>
> It might help to remove all of the old GNU Radio installed files from your
> system (in prefix/lib/libgnuradio*,
> prefix/lib/python2.X/dist-packages/gnuradio, prefix/include/gnuradio,
> prefix/share/doc/gnuradio, prefix/share/gnuradio).
>
>
>
> You shouldn't have to do this, but it seems a common cause of problems when
> upgrading.
>
>
> Then reinstall and make sure to run ldconfig.
>
>
> Tom
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/05ebdbe0/attachment.html>
------------------------------
Message: 14
Date: Tue, 25 Oct 2011 16:48:01 -0400
From: Nazmul Islam <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] No packet reception in higher modulation
Message-ID:
<CAFtrfEZ272KpUp354WasSFUL4uYSN6M4t=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am running my codes in basic TX/RX with gnuradio-3.3.0 image. I am using
benchmark_tx and benchmark_rx codes in the gnuradio-examples/python/digital
folder to find packet loss for different modulation schemes (I believe that
these files have been transferred to the gr-digital/examples/narrowband
folder in the new image). When I run my the benchmark codes with dbpsk and
dqpsk modulation, the receiver receives packets. However, when I run the
codes with d8psk modulation scheme, the receiver just sits idle waiting for
the packets but does not receive anything !
I am giving the following commands in the benchmark programs:
./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --tx-ampl 0.5
./benchmark_rx.py -f 2.4G -r 1M -e eth2 -m d8psk
I am getting the following packet reception ratios for different modulation
schemes:
dbpsk: 99%, dqpsk: 92%, d8psk: 0% !!
I expected to get less packets (higher packet loss) through d8psk modulation
since it is transmitting at a higher data rate. But the receiver is not
receiving anything at all !!
Your feedback will be highly appreciated.
Thanks,
Nazmul
--
Muhammad Nazmul Islam
Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/8d1c3640/attachment.html>
------------------------------
Message: 15
Date: Tue, 25 Oct 2011 13:53:40 -0700
From: Jordan Otomo <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
On Oct 25, 2011, at 1:38 PM, Tom Rondeau wrote:
> That FAQ does list all of the install directories; I was just a bit more explicit in my email about where they are (subdirs in lib and share, for example; and I missed the bin directories). That should be it; anything else shouldn't be causing you problems.
>
> What OS are you running? Are you building with cmake or autotools? Any configure-time failures?
I'm running Ubuntu 11.04 and am building with cmake. I don't have any configure-time failures. The only disabled components are gr-comedi and gr-shd. Again, I appreciate your help.
------------------------------
Message: 16
Date: Tue, 25 Oct 2011 17:02:40 -0400
From: Tom Rondeau <address@hidden>
To: Jordan Otomo <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 25, 2011 at 4:53 PM, Jordan Otomo <address@hidden>wrote:
>
> On Oct 25, 2011, at 1:38 PM, Tom Rondeau wrote:
>
> > That FAQ does list all of the install directories; I was just a bit more
> explicit in my email about where they are (subdirs in lib and share, for
> example; and I missed the bin directories). That should be it; anything else
> shouldn't be causing you problems.
> >
> > What OS are you running? Are you building with cmake or autotools? Any
> configure-time failures?
>
>
> I'm running Ubuntu 11.04 and am building with cmake. I don't have any
> configure-time failures. The only disabled components are gr-comedi and
> gr-shd. Again, I appreciate your help.
At a loss right now. Have you tried any of the examples in the code?
uhd_fft.py or anything in gnuradio-examples/grc?
How about the qtgui? gr-qtgui/examples/pyqt_example_c.py?
I have run all of these on both Ubuntu 10.04 and 11.10.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/a1e3daaa/attachment.html>
------------------------------
Message: 17
Date: Tue, 25 Oct 2011 17:03:27 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> On Tue, Oct 25, 2011 at 3:53 PM, Jordan Otomo
> <address@hidden <mailto:address@hidden>> wrote:
>
> Hi Tom,
>
> Thanks for the help. I've tried manually deleting all of the GNU
> Radio files in the recommended locations, reinstalling, and
> performing a 'sudo ldconfig', but the problem still persists. You
> mentioned a few install directories not listed in the FAQ's "The
> problem of multiple installs" section. Do you know if there are
> any other install files I should delete before reinstalling?
> Thanks again!
>
> Jordan
>
>
> That FAQ does list all of the install directories; I was just a bit
> more explicit in my email about where they are (subdirs in lib and
> share, for example; and I missed the bin directories). That should be
> it; anything else shouldn't be causing you problems.
>
> What OS are you running? Are you building with cmake or autotools? Any
> configure-time failures?
>
> Tom
>
>
> ----- Original Message -----
> From: "Tom Rondeau" <address@hidden
> <mailto:address@hidden>>
> To: "Jordan Otomo" <address@hidden
> <mailto:address@hidden>>
> Cc: address@hidden <mailto:address@hidden>
> Sent: Tuesday, October 25, 2011 12:01:30 PM
> Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
>
>
> On Tue, Oct 25, 2011 at 2:43 PM, Jordan Otomo <
> address@hidden <mailto:address@hidden> > wrote:
>
>
> Hi,
>
> I seem to be having an issue with a few of the GRC WX GUI Widgets,
> namely the FFT Sink and Scope Sink, in the latest release (3.5.0).
> My flowgraphs now exit immediately, without error. I've
> constructed a simple flowgraph consisting of a signal source,
> throttle, and FFT Sink/Scope Sink to test this and it exits
> immediately after execution. The only message I receive is ">>>
> Done". Any help would be greatly appreciated.
>
> Thanks,
> Jordan
>
>
>
>
>
> It might help to remove all of the old GNU Radio installed files
> from your system (in prefix/lib/libgnuradio*,
> prefix/lib/python2.X/dist-packages/gnuradio,
> prefix/include/gnuradio, prefix/share/doc/gnuradio,
> prefix/share/gnuradio).
>
>
>
> You shouldn't have to do this, but it seems a common cause of
> problems when upgrading.
>
>
> Then reinstall and make sure to run ldconfig.
>
>
> Tom
>
>
>
>
I did a build-from-cmake on a Ubuntu 10.10 system this afternoon, and
the WX GUI sinks work just fine afterwards. I did have to
do a "sudo ldconfig" when I was done, but that was it.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/493116b3/attachment.html>
------------------------------
Message: 18
Date: Tue, 25 Oct 2011 17:08:26 -0400
From: shantharam balasubramanian <address@hidden>
To: "Marcus D. Leech" <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Fwd: Introducing noise/ considerable
BER
Message-ID:
<CALdBQaviWHChLv8wUxWT6ZgeRmjV6KMX8kkOijYkUTo=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello Marcus,
You sent the forwarded email a few months ago.
The benchmark stuff doesn't, as far as I know, have FEC in it. I think
Tom was referring to single-bit errors in the so-called "accesscode"
at the beginning of the frame. If there are bit errors there, then
the frame is necessarily discarded, since it's not *recognized* as a
valid frame. But apart from that, if the frame sequence is valid, then
the packet is "recognized", and punted up through the RX packet
callback mechanism, which means there could still be bit errors in the
payload section of the packet.
We implemented a CRC checking block in the benchmark_rx code using
binascii.crc32 python code. We observed a very interesting thing in
the following portion of the benchmark_rx code:
def rx_callback(ok, payload):
global n_rcvd, n_right
(pktno,) = struct.unpack('!H', payload[0:2])
if ok:
n_right += 1
Whenever the packet was received as 'OK' (i.e. 'OK = True') and
n_right increased, the packet also passed our CRC check. Every packet
that did not pass our CRC check was also not received as 'OK' (i.e.
'OK = False' in those packets). Our CRC checking portion is completely
independent of the main benchmark_rx code. We just look at the
received data and see if there is any bit error or not.
Now, if the above the mentioned portion of the code does not do CRC
checking on its own, how does it completely match with our CRC based
results? Does it mean that errors occur in bursts. Therefore, whenever
there is any single bit error in the data, there are errors in the
header as well ??
Your feedback will be very appreciated.
Thanks,
Shantharam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/b2b9ed1e/attachment.html>
------------------------------
Message: 19
Date: Tue, 25 Oct 2011 17:15:43 -0400
From: "Marcus D. Leech" <address@hidden>
To: shantharam balasubramanian <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Fwd: Introducing noise/ considerable
BER
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> Hello Marcus,
>
> You sent the forwarded email a few months ago.
>
> The benchmark stuff doesn't, as far as I know, have FEC in it. I think Tom was referring to single-bit errors in the so-called "accesscode" at the beginning of the frame. If there are bit errors there, then the frame is necessarily discarded, since it's not *recognized* as a valid frame. But apart from that, if the frame sequence is valid, then the packet is "recognized", and punted up through the RX packet callback mechanism, which means there could still be bit errors in the payload section of the packet.
> We implemented a CRC checking block in the benchmark_rx code using binascii.crc32 python code. We observed a very interesting thing in the following portion of the benchmark_rx code:
> def rx_callback(ok, payload):
> global n_rcvd, n_right
> (pktno,) = struct.unpack('!H', payload[0:2])
> if ok:
> n_right +=1
>
> Whenever the packet was received as 'OK' (i.e. 'OK = True') and n_right increased, the packet also passed our CRC check. Every packet that did not pass our CRC check was also not received as 'OK' (i.e. 'OK = False' in those packets). Our CRC checking portion is completely independent of the main benchmark_rx code. We just look at the received data and see if there is any bit error or not.
> Now, if the above the mentioned portion of the code does not do CRC checking on its own, how does it completely match with our CRC based results? Does it mean that errors occur in bursts. Therefore, whenever there is any single bit error in the data, there are errors in the header as well ??
> Your feedback will be very appreciated.
>
I'll let other people who are more familiar with the code comment. My
comments from months ago were from a cursory inspection of
code that I don't use, or have any particular vested-interest in.
> Thanks,
> Shantharam
>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/1529a101/attachment.html>
------------------------------
Message: 20
Date: Tue, 25 Oct 2011 14:19:01 -0700
From: Jason Abele <address@hidden>
To: Jordan Otomo <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Oct 25, 2011 at 2:02 PM, Tom Rondeau <address@hidden> wrote:
> On Tue, Oct 25, 2011 at 4:53 PM, Jordan Otomo <address@hidden>
> wrote:
>>
>> On Oct 25, 2011, at 1:38 PM, Tom Rondeau wrote:
>>
>> > That FAQ does list all of the install directories; I was just a bit more
>> > explicit in my email about where they are (subdirs in lib and share, for
>> > example; and I missed the bin directories). That should be it; anything else
>> > shouldn't be causing you ?problems.
>> >
>> > What OS are you running? Are you building with cmake or autotools? Any
>> > configure-time failures?
>>
>>
>> I'm running Ubuntu 11.04 and am building with cmake. ?I don't have any
>> configure-time failures. ?The only disabled components are gr-comedi and
>> gr-shd. ?Again, I appreciate your help.
>
> At a loss right now. Have you tried any of the examples in the code?
> uhd_fft.py or anything in gnuradio-examples/grc?
> How about the qtgui? gr-qtgui/examples/pyqt_example_c.py?
> I have run all of these on both Ubuntu 10.04 and 11.10.
So I had a weird thing happen to my wx on Ubuntu 11.04 the other day.
After an update of something not wx-related, my python-wx was horribly
broken.
You can test if that is the case with:
python -c "import wx; print wx.version()"
I was able to remedy the issue by removing and reinstalling wx:
sudo apt-get --purge remove python-wxgtk2.8 wx2.8-headers
libwxgtk2.8-0 libwxbase2.8-dev libwxbase2.8-0
sudo apt-get install python-wxgtk2.8 wx2.8-headers libwxgtk2.8-0
libwxbase2.8-dev libwxbase2.8-0 gnuplot gnuplot-x11 isag
libwxbase2.8-0 libwxbase2.8-dev libwxgtk2.8-0 libwxgtk2.8-dev
python-wxgtk2.8 wx2.8-headers
Hope that helps you
Jason
------------------------------
Message: 21
Date: Tue, 25 Oct 2011 14:37:18 -0700 (PDT)
From: Jordan Otomo <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
The WX GUI examples exhibit the same behavior, but the QT examples do work. However, if I try to use a QT time sink in GRC, I get the following error:
Traceback (most recent call last):
File "/home/jotomo/Desktop/top_block.py", line 57, in <module>
tb = top_block()
File "/home/jotomo/Desktop/top_block.py", line 39, in __init__
self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 94, in __getattr__
return getattr(self._tb, name)
AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
There seems to be many problems with my installation, as other blocks fail in GRC too. For example, the PSK demod block from gr-digital gives:
Traceback (most recent call last):
File "/home/jotomo/Desktop/top_block.py", line 64, in <module>
tb = top_block()
File "/home/jotomo/Desktop/top_block.py", line 35, in __init__
mod_code=gray,
NameError: global name 'gray' is not defined
I will try Jason's solution and see if that cures anything. Thanks for all the help!
------------------------------
Message: 22
Date: Tue, 25 Oct 2011 15:04:54 -0700 (PDT)
From: Jordan Otomo <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
Unfortunately, I was not successful in solving the WX GUI problem. The QT problem was solved (of course) by changing the Generate Options parameter in the Options block to QT GUI.
------------------------------
Message: 23
Date: Tue, 25 Oct 2011 15:25:48 -0700
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Problems after upgrading to UHD with
USRP2
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/25/2011 12:53 PM, Sam Keene wrote:
> Hello all,
>
> We recently upgraded to the UHD drivers, and now some basic stuff we
> had working with the older drivers just isn't working anymore. For
> example, I'm just trying to transmit and receive a raised cosine
> pulse, but I'm not getting anything at the receiver. I've eliminated
> all warnings that I was getting, to no avail. We're using USRP2s with
> the RFX2400 daughterboards.
>
> I'm attaching 2 GRC files as examples of what we're doing. I'm not
> getting any received signal. Any idea what I'm doing wrong.
>
What version of UHD? Can you repeat the experiment with a higher
sampling rate? Also, make sure that filter isnt outputting more than
magnitude 1.0/
-josh
------------------------------
Message: 24
Date: Tue, 25 Oct 2011 15:26:32 -0700
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] No packet reception in higher
modulation
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/25/2011 01:48 PM, Nazmul Islam wrote:
> Hello,
>
> I am running my codes in basic TX/RX with gnuradio-3.3.0 image. I am using
> benchmark_tx and benchmark_rx codes in the gnuradio-examples/python/digital
> folder to find packet loss for different modulation schemes (I believe that
> these files have been transferred to the gr-digital/examples/narrowband
> folder in the new image). When I run my the benchmark codes with dbpsk and
> dqpsk modulation, the receiver receives packets. However, when I run the
> codes with d8psk modulation scheme, the receiver just sits idle waiting for
> the packets but does not receive anything !
>
> I am giving the following commands in the benchmark programs:
>
> ./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --tx-ampl 0.5
>
> ./benchmark_rx.py -f 2.4G -r 1M -e eth2 -m d8psk
>
> I am getting the following packet reception ratios for different modulation
> schemes:
>
> dbpsk: 99%, dqpsk: 92%, d8psk: 0% !!
>
> I expected to get less packets (higher packet loss) through d8psk modulation
> since it is transmitting at a higher data rate. But the receiver is not
> receiving anything at all !!
>
> Your feedback will be highly appreciated.
>
Have you observed frequency offset?
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#I-have-two-USRPs-and-when-I-transmit-on-one-and-receive-on-the-other-at-the-same-frequency-I-get-an-offset
-Josh
------------------------------
Message: 25
Date: Tue, 25 Oct 2011 15:28:44 -0700
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Problem with WXGUI Widgets
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/25/2011 02:37 PM, Jordan Otomo wrote:
> The WX GUI examples exhibit the same behavior, but the QT examples do work. However, if I try to use a QT time sink in GRC, I get the following error:
>
>
> Traceback (most recent call last):
> File "/home/jotomo/Desktop/top_block.py", line 57, in <module>
> tb = top_block()
> File "/home/jotomo/Desktop/top_block.py", line 39, in __init__
> self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 94, in __getattr__
> return getattr(self._tb, name)
> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>
>
> There seems to be many problems with my installation, as other blocks fail in GRC too. For example, the PSK demod block from gr-digital gives:
>
> Traceback (most recent call last):
> File "/home/jotomo/Desktop/top_block.py", line 64, in <module>
> tb = top_block()
> File "/home/jotomo/Desktop/top_block.py", line 35, in __init__
> mod_code=gray,
> NameError: global name 'gray' is not defined
>
>
Those errors make me think this is the problem of multiple installs. -josh
------------------------------
Message: 26
Date: Tue, 25 Oct 2011 19:02:24 -0400
From: Tom Rondeau <address@hidden>
To: Ben Reynwar <address@hidden>
Cc: Achilleas Anastasopoulos <address@hidden>, discuss-gnuradio
Discussion Group <address@hidden>
Subject: Re: [Discuss-gnuradio] gr-trellis broken on next branch
Message-ID:
<CANc0s2OghT5mpeGbWg=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Oct 21, 2011 at 11:51 PM, Ben Reynwar <address@hidden> wrote:
> The block I added into gr-trellis is trellis_constellation_metrics_cf.
> This block is equivalent to trellis_metrics_c in that it takes a
> stream of symbols and outputs a stream of metrics. The difference is
> that treliis_constellation_metrics_cf uses a constellation object
> (which is passed to it upon initialisation) to perform the symbol to
> metrics conversion. trellis_metrics_c calculates the distance between
> each symbol and each constellation point, which could clearly be
> improved upon by the modulation specific method in a constellation
> object, especially for large constellations.
>
> The constellation classes themselves are defined in gr-digital, so all
> modulation specific code would be contained in gr-digital. The
> dependency on gr-digital enables modulation specific code to be
> accessed by the gr-trellis code without requiring that modulation
> specific code be in gr-trellis itself. I think that's a pretty
> logical arrangement.
>
> >>> from gnuradio import digital, trellis
> >>> constellation = digital.qam.qam_constellation(16)
> >>> symbols_to_metrics = trellis.constellation_metrics_cf(constellation,
> digital.TRELLIS_EUCLIDEAN)
>
> Although currently there's just the one block with a dependency on
> gr-digital, going forward it might be nice to have combined blocks
> using constellation objects, so I would be disinclined to move it out
> of gr-trellis.
>
> Cheers,
> Ben
So I have the same opinion as Ben here with regards to the use and location
of these things, especially to avoid duplication of code.
I have fixed the trellis examples and will be pushing updates to master that
should fix things.
Tom
> On Fri, Oct 21, 2011 at 1:06 PM, Achilleas Anastasopoulos
> <address@hidden> wrote:
> > Tom,
> >
> > this requires some further discussion.
> >
> > We need to know what is the plan with gr-digital.
> > In some sense EVERYTHING can be included in there,
> > however this is not a good design.
> >
> > gr-trellis is not an "implementation of digital
> > modulation"; it provides digital encoding/decoding techniques
> > that is important to keep modulation INDEPENDENT.
> > This was the design philosophy from the first line of
> > code that went into this and can be seen in all the examples
> > that are provided: the only aspect of these examples that depends on
> > a specific modulation is the lookuptable of the constellation.
> >
> > I would like to welcome more users/developers to comment
> > on this before we make any significant changes to the module.
> >
> > best,
> > Achilleas
> >
> >
> > On 10/21/2011 3:19 PM, Tom Rondeau wrote:
> >>
> >> On Thu, Oct 20, 2011 at 10:34 PM, Achilleas Anastasopoulos
> >> <address@hidden <mailto:address@hidden>> wrote:
> >>
> >> After installing the next branch i realized that gr-trellis is not
> >> working properly!
> >>
> >> This is due to some work (by Ben Raynwar) that makes gr-trellis
> >> dependent on gr-digital (???)
> >> In particular the constants related to trellis_metric_type.h cannot
> be
> >> accessed in python/grc
> >> as part of the trellis module, but as part of the digital module
> >> (this problem appears for instance if you run some of the pccc/sccc
> >> examples in gnuradio-examples/grc/trellis).
> >>
> >> This can be an easy fix (import digital in all the grc blocks
> >> requiring metric types, and make appropriate changes).
> >>
> >> However I wonder what is the point of making a self-contained
> >> module like gr-trellis dependent on another module (gr-digital)
> >> If the only reason is to to use the "constellation" object in the
> >> "metrics" blocks then these blocks should
> >> reside in the gr-digital module instead of the gr-trellis, so that
> the
> >> latter can still be self-contained.
> >>
> >> Ben, can you please explain what is your rational in doing these
> >> changes.
> >>
> >> thanks,
> >> Achilleas
> >>
> >>
> >>
> >> Achilleas,
> >> This was my doing. Ben had moved the metric types into gnuradio-core to
> >> work with his constellation work, so I moved them over with everything
> >> else into gr-digital. I then made gr-trellis depend on gr-digital
> >> because of this. Because gr-trellis is an implementation of digital
> >> modulation, it makes sense that it should depend on gr-digital.
> >>
> >> I made sure that gr-trellis would both build and pass 'make check,' so
> >> the QA code is obviously not testing all of the proper dependencies and
> >> cases in gr-trellis. We need to fix that to make sure the applications
> >> still run as we move stuff around.
> >>
> >> Depending on what gr-trellis requires out of gr-digital, we could
> >> possibly import digital into the trellis module inside of the
> >> __init__.py file.
> >>
> >> Tom
> >>
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/3b6dcff1/attachment.html>
------------------------------
Message: 27
Date: Wed, 26 Oct 2011 12:18:35 +1100
From: "Kyle Zhou" <address@hidden>
To: <address@hidden>
Subject: [Discuss-gnuradio] available sample rates for USRP2
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
When I use uhd_fft.py -s 8M -f ..
It reported that
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 8.000000 MSps
Actual sample rate: 7.692308 MSps
I am wondering how the actual rate 7.692308M is determined?
Is there any formula that I can use to ascertain that a given sample rate is
available on USRP2?
Thanks
KZ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/e6c57838/attachment.html>
------------------------------
Message: 28
Date: Tue, 25 Oct 2011 18:20:56 -0700
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] available sample rates for USRP2
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/25/2011 06:18 PM, Kyle Zhou wrote:
> When I use uhd_fft.py -s 8M -f ..
>
> It reported that
>
> UHD Warning:
>
> The hardware does not support the requested RX sample rate:
>
> Target sample rate: 8.000000 MSps
>
> Actual sample rate: 7.692308 MSps
>
>
>
> I am wondering how the actual rate 7.692308M is determined?
>
> Is there any formula that I can use to ascertain that a given sample rate is
> available on USRP2?
>
Only integer divisor rates of the master clock is possible. In this case
100Mhz/decimation = sample rate.
Querying the possible sample rates will be part of my next API revision.
-Josh
------------------------------
Message: 29
Date: Tue, 25 Oct 2011 18:21:03 -0700
From: Nick Foster <address@hidden>
To: Kyle Zhou <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] available sample rates for USRP2
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=windows-1252
On Tue, Oct 25, 2011 at 6:18 PM, Kyle Zhou <address@hidden> wrote:
> When I use uhd_fft.py ?s 8M ?f ?.
>
> It reported that
>
> UHD Warning:
>
> ??? The hardware does not support the requested RX sample rate:
>
> ??? Target sample rate: 8.000000 MSps
>
> ??? Actual sample rate: 7.692308 MSps
>
>
>
> I am wondering how the actual rate 7.692308M is determined?
>
> Is there any formula that I can use to ascertain that a given sample rate is
> available on USRP2?
100Msps / x, where x is an integer (in your case, 13).
--n
>
> Thanks
>
> KZ
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
------------------------------
Message: 30
Date: Tue, 25 Oct 2011 21:55:48 -0400
From: "Marcus D. Leech" <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] New build-gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I worked-over build-gnuradio tonight rather thoroughly, and it now uses
the Cmake infrastructure to do its Gnu Radio builds.
It also has built-in help:
build-gnuradio --help
Yields:
Usage: build-gnuradio [--help|-h] [-v|--verbose] [-jN] [-ja]
[-l|--logfile logfile ] funcs
-v|--verbose - turn on verbose logging to stdout
-jN - have make use N concurrent jobs
-ja - have make use N concurrent jobs with auto setting of N
(based on number of cpu cores on build system)
-l|--logfile lf - log messages to 'lf'
available funcs are:
all - do all functions
prereqs - install prerequisites
gitfetch - use GIT to fetch Gnu Radio and UHD
uhd_build - build only UHD
firmware - fetch firmware/FPGA
gnuradio_build - build only Gnu Radio
mod_groups - modify the /etc/groups and user to group 'usrp'
mod_udev - add UDEV rule for USRP1
mod_sysctl - modify SYSCTL for larger net buffers
I'd love people to add support for systems other than Ubuntu and Fedora,
but those are the most popular Linux distros in use.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 31
Date: Tue, 25 Oct 2011 22:02:53 -0400
From: Tom Rondeau <address@hidden>
To: "Marcus D. Leech" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] New build-gnuradio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 25, 2011 at 9:55 PM, Marcus D. Leech <address@hidden> wrote:
> I worked-over build-gnuradio tonight rather thoroughly, and it now uses the
> Cmake infrastructure to do its Gnu Radio builds.
>
> It also has built-in help:
>
> build-gnuradio --help
>
> Yields:
>
> Usage: build-gnuradio [--help|-h] [-v|--verbose] [-jN] [-ja] [-l|--logfile
> logfile ] funcs
>
> -v|--verbose - turn on verbose logging to stdout
>
> -jN - have make use N concurrent jobs
>
> -ja - have make use N concurrent jobs with auto setting of N
> (based on number of cpu cores on build system)
>
> -l|--logfile lf - log messages to 'lf'
>
> available funcs are:
>
> all - do all functions
> prereqs - install prerequisites
> gitfetch - use GIT to fetch Gnu Radio and UHD
> uhd_build - build only UHD
> firmware - fetch firmware/FPGA
> gnuradio_build - build only Gnu Radio
> mod_groups - modify the /etc/groups and user to group 'usrp'
> mod_udev - add UDEV rule for USRP1
> mod_sysctl - modify SYSCTL for larger net buffers
>
>
> I'd love people to add support for systems other than Ubuntu and Fedora,
> but those are the most popular Linux distros in use.
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
Wonderful, Marcus, thanks!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/ef44e109/attachment.html>
------------------------------
Message: 32
Date: Tue, 25 Oct 2011 23:51:54 -0400
From: Dan CaJacob <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] New build-gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 10/25/2011 10:02 PM, Tom Rondeau wrote:
> On Tue, Oct 25, 2011 at 9:55 PM, Marcus D. Leech <address@hidden
> <mailto:address@hidden>> wrote:
>
> I worked-over build-gnuradio tonight rather thoroughly, and it now
> uses the Cmake infrastructure to do its Gnu Radio builds.
>
> It also has built-in help:
>
> build-gnuradio --help
>
> Yields:
>
> Usage: build-gnuradio [--help|-h] [-v|--verbose] [-jN] [-ja]
> [-l|--logfile logfile ] funcs
>
> -v|--verbose - turn on verbose logging to stdout
>
> -jN - have make use N concurrent jobs
>
> -ja - have make use N concurrent jobs with auto setting
> of N
> (based on number of cpu cores on build system)
>
> -l|--logfile lf - log messages to 'lf'
>
> available funcs are:
>
> all - do all functions
> prereqs - install prerequisites
> gitfetch - use GIT to fetch Gnu Radio and UHD
> uhd_build - build only UHD
> firmware - fetch firmware/FPGA
> gnuradio_build - build only Gnu Radio
> mod_groups - modify the /etc/groups and user to group 'usrp'
> mod_udev - add UDEV rule for USRP1
> mod_sysctl - modify SYSCTL for larger net buffers
>
>
> I'd love people to add support for systems other than Ubuntu and
> Fedora, but those are the most popular Linux distros in use.
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> Wonderful, Marcus, thanks!
>
Cool! I want to mention a problem I have encountered a few times when
using the build-gnuradio script so that others can be wary themselves.
It's my own fault, but occasionally, I will go to build the newest
gnuradio and forget that I have a grc instance left running. This seems
to really mess things up and nothing short of hunting down every last
bit of gnuradio in the operating system will allow you to start over
from scratch. Has anyone else had this problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111025/40ce301f/attachment.html>
------------------------------
Message: 33
Date: Wed, 26 Oct 2011 01:19:09 -0400
From: Dan CaJacob <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] New build-gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 10/25/2011 11:51 PM, Dan CaJacob wrote:
> On 10/25/2011 10:02 PM, Tom Rondeau wrote:
>> On Tue, Oct 25, 2011 at 9:55 PM, Marcus D. Leech <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>> I worked-over build-gnuradio tonight rather thoroughly, and it
>> now uses the Cmake infrastructure to do its Gnu Radio builds.
>>
>> It also has built-in help:
>>
>> build-gnuradio --help
>>
>> Yields:
>>
>> Usage: build-gnuradio [--help|-h] [-v|--verbose] [-jN] [-ja]
>> [-l|--logfile logfile ] funcs
>>
>> -v|--verbose - turn on verbose logging to stdout
>>
>> -jN - have make use N concurrent jobs
>>
>> -ja - have make use N concurrent jobs with auto
>> setting of N
>> (based on number of cpu cores on build system)
>>
>> -l|--logfile lf - log messages to 'lf'
>>
>> available funcs are:
>>
>> all - do all functions
>> prereqs - install prerequisites
>> gitfetch - use GIT to fetch Gnu Radio and UHD
>> uhd_build - build only UHD
>> firmware - fetch firmware/FPGA
>> gnuradio_build - build only Gnu Radio
>> mod_groups - modify the /etc/groups and user to group 'usrp'
>> mod_udev - add UDEV rule for USRP1
>> mod_sysctl - modify SYSCTL for larger net buffers
>>
>>
>> I'd love people to add support for systems other than Ubuntu and
>> Fedora, but those are the most popular Linux distros in use.
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>>
>> Wonderful, Marcus, thanks!
>>
> Cool! I want to mention a problem I have encountered a few times when
> using the build-gnuradio script so that others can be wary
> themselves. It's my own fault, but occasionally, I will go to build
> the newest gnuradio and forget that I have a grc instance left
> running. This seems to really mess things up and nothing short of
> hunting down every last bit of gnuradio in the operating system will
> allow you to start over from scratch. Has anyone else had this problem?
>
By they way, 7 minutes, 18 seconds from start of UHD build to end of
gnuradio build on a quad-core Mac Book Pro (bought in June). They
actually abstract it into 8 cores - I used all 8 for the test build.
Really nice!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/76bb721a/attachment.html>
------------------------------
Message: 34
Date: Wed, 26 Oct 2011 10:39:58 +0200
From: "Paul M. Bendixen" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Trouble with multiple installs or how
i learned to love make uninstall
Message-ID:
<CAAvei9qPgfboBUCWApA6ukscbWNEMZ1QvHe=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
So I started today off by doing a make uninstall on the gentoo box. Then I
went hunting.
As it turns out, I had to manually remove 3.5.0git files from a lot of the
locations mentioned in the post concerning the WX Gui problem (
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-10/msg00355.html).
After removing these (along with a set of old installation files) i tried
rebuilding. (after git clean -dfx; git pull)
Only error i got was:
.../git/uhd/firmware/zpu/lwip/lwip-1.3.1/src/include/lwip/memp.h:45:
Warning: include file lwip/memp_std.h not found, perhaps you forgot to add
its directory to INCLUDE_PATH?
with some warnings that:
Warning: explicit link request to 'define' could not be resolved
in the zpu firmware image.
It all works fine now, however due to moving around (i guess) i get a lot of
warnings like:
Error: Connection between gr_interleave_0(0) and blks2_ofdm_mod_0(0) could
not be made.
sink block id "blks2_ofdm_mod_0" not in block ids
in gnuradio-companion
When I use the modulation->gmsk it results in the error:
self.blks2_gmsk_mod_0 = blks2.gmsk_mod(
AttributeError: 'module' object has no attribute 'gmsk_mod'
which is correct, it is now in digital.
Should this be fixed or are the XML files that grc uses not fully updated?
If so, should the git clean -dfx not have fixed this?
The last example is the same on the xubuntu box (which was installed using
the new build-gnuradio script).
Maybe I should start splitting this out into different mails?
Best
Paul
2011/10/25 Tom Rondeau <address@hidden>
> On Tue, Oct 25, 2011 at 12:19 PM, Paul M. Bendixen <address@hidden
> > wrote:
>
>> Hello
>>
>> It seems it might be a good idea if it were possible to uninstall gnuradio
>> propper.
>>
>> I currently have two systems faling (hard) using the new build.
>>
>> My gentoo box (configured using cmake in another thread)
>> gives me the error :
>> ImportError: libgruel-3.4.2git.so.0: cannot open shared object file: No
>> such file or directory
>> Whenever i try
>> from gnuradio import digital.
>>
>> funny part is: I never succeeded in installing 3.4.2, so I don't blame it
>> for not finding it.
>>
>> I tried doing a manual ldconfig, but it didn't seem to do the trick.
>>
>> On an ubuntu machine (xubuntu to be specific) using the build-gnuradio
>> script, most of the digital schemes fails
>> due to the reallocation of packets to digital. This includes stuff that
>> should be updated.
>>
>> Is it possible that the python stuff does not get properly updated and is
>> there any way to fix this?
>>
>> Downgrading, by adding a "git checkout v3.4.2" fixes makes the build run
>> fine again.
>>
>> On both systems the building of the system is without problems.
>>
>
>
> make uninstall does work and removes all of the GNU Radio files from the
> system. The twist that you need to remember is that you have to do it BEFORE
> upgrading to a new version. The 3.5 will try to uninstall it's stuff, which
> will be different from 3.4. So you have to have to run 'make uninstall' when
> you've configured for what's installed on your system. Then you can upgrade
> and shouldn't have any conflicts.
>
> When you say that you didn't have 3.4.2 installed, do you mean that you
> never installed from master before? For the past few weeks, the master
> branch reflected the 3.4.2, so any installs will have that in their name.
>
> You did help me find a bug in our cmake install, though. Some of our
> specially-built files are not being removed by uninstall.
>
> Tom
>
>
--
* - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */-
- */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/ac868ed5/attachment.html>
------------------------------
Message: 35
Date: Wed, 26 Oct 2011 02:04:19 -0700 (PDT)
From: Lebowski80 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] How to reconfigure automatically the
channel used to received data in USRPs
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi Johnny,
These are the line of the code I used in the script benchmark_rx.py where
the selected channel was 2484 MHz:
id_process = os.getpid()
p = Popen('python benchmark_rxr.py', preexec_fn = os.kill(id_process, 2),
close_fds = True, shell = True)
killing and closing the process where benchmark_rx.py was running allowed me
to run benchmark_rxr.py in another channel.
Regards
Tuan (Johnny) Ta wrote:
>
> Can you elaborate on how exactly you solved this problem without using
> GRC?
> What kind of interprocess communication did you use?
>
> Thanks,
> Johnny
>
> On Tue, Sep 13, 2011 at 10:08 AM, Lebowski80
> <address@hidden>wrote:
>
>>
>> Hi Nick,
>>
>> I just wanted tell you that I solved my problem using interprocess
>> communication, thank you for your advice!
>>
>> Regards
>>
>>
>> Lebowski80 wrote:
>> >
>> > Ok, thank you for your advice, I will try with interprocess
>> communication.
>> >
>> > Regards
>> >
>> >
>> > Nick Foster-4 wrote:
>> >>
>> >> Short answer: You cannot open a new USRP instance to reconfigure an
>> >> already-running USRP instance. You must reconfigure the existing
>> >> instance.
>> >>
>> >> The best advice I can give is that only one flowgraph can be
>> operational
>> >> per
>> >> USRP device. In your setup, USRP#1 will run a single flowgraph with a
>> >> source
>> >> and/or sink, USRP#2 will run a single flowgraph with a source and/or
>> >> sink,
>> >> and USRP#3 will run a single flowgraph with a source and/or sink. If
>> you
>> >> wish to change the parameters of USRP#2 while it is running, rather
>> than
>> >> try
>> >> to open a new USRP device in your benchmark_rxr.py flowgraph, use any
>> of
>> >> the
>> >> standard interprocess communication methods to talk to your
>> >> already-running
>> >> USRP#2 script and reconfigure it as necessary.
>> >>
>> >> --n
>> >>
>> >> On Wed, Sep 7, 2011 at 9:31 AM, Lebowski80 <address@hidden>
>> >> wrote:
>> >>
>> >>>
>> >>> Hello Nick,
>> >>>
>> >>> What do you mean? Actually I'm running RX and TX in two different
>> >>> flowgraphs
>> >>> on USRP1, the first one in usrp_spectrum_sense.py to look for a free
>> >>> channel
>> >>> (so the RX). In this script I also run benchmark_tx.py by the command
>> p
>> >>> =
>> >>> Popen('python benchmark_tx.py', shell = True), then my second
>> >>> flowgrapgh
>> >>> (the TX).
>> >>>
>> >>> My problem is that on USRP2 I want to reconfigure the RX channel by
>> >>> python
>> >>> (RX channel = 2484 MHz in the script benchmark_rx.py and RX channel =
>> >>> channel received by USRP1 in the script benchamrk_rxr.py run by
>> >>> benchmark_rx.py with the command p = Popen('python benchmark_rxr.py',
>> >>> shell
>> >>> = True)).
>> >>>
>> >>> So I'm wondering if there exists the possibility to reconfigure the
>> >>> parameters of a script in the same USRP (i.e. RX frequency channel)
>> >>> while
>> >>> it
>> >>> is running and if this is not possible what do people mean with "USRP
>> >>> reconfigurability?"
>> >>>
>> >>> I really need an answer to understand the potentiality of my
>> hardware,
>> >>> thanks a lot!
>> >>>
>> >>> Regards
>> >>>
>> >>>
>> >>>
>> >>> Nick Foster-4 wrote:
>> >>> >
>> >>> > On Wed, Sep 7, 2011 at 3:27 AM, Lebowski80
>> <address@hidden>
>> >>> > wrote:
>> >>> >
>> >>> >>
>> >>> >> Hello everyone,
>> >>> >>
>> >>> >> Before to explain my problem I give some technical information
>> about
>> >>> my
>> >>> >> hardaware. I'm using USRPs v1 and the boards integrated are
>> XCVR2450
>> >>> >> Transceivers.
>> >>> >>
>> >>> >> I'm using the script usrp_spectrum_sense.py in a USRP (called
>> USRP1)
>> >>> to
>> >>> >> make
>> >>> >> sensing in the ISM band, after a few seconds it sends to another
>> USRP
>> >>> >> (Called USRP2) a free sensed channel on the central frequency 2484
>> >>> MHz.
>> >>> >> USRP2 listens to the channel 2484 MHz through the script
>> >>> benchmark_rx.py
>> >>> >> and
>> >>> >> it can properly receive the free ISM channel sent by USRP1. Then,
>> I
>> >>> want
>> >>> >> to
>> >>> >> use the USRP2 to receive data from another USRP (called USRP3)
>> that
>> >>> uses
>> >>> >> the
>> >>> >> script benchmark_tx.py.
>> >>> >>
>> >>> >> In the script benchmark_rx.py (used by USRP2) that listens to
>> channel
>> >>> >> 2484
>> >>> >> MHz I want to run another script that I called benchmark_rxr.py
>> that
>> >>> >> waits
>> >>> >> for data sent by USRP3 to be received in the free ISM channel sent
>> by
>> >>> >> USRP1.
>> >>> >>
>> >>> >> Relevant line of the code in the script benchmark_rx.py is
>> attached
>> >>> >> below:
>> >>> >>
>> >>> >> p = Popen('python benchmark_rxr.py', shell = True)
>> >>> >>
>> >>> >> While this is the error that I get:
>> >>> >>
>> >>> >> usrp_open_interface:usb_claim_interface: failed interface 2
>> >>> >> could not claim interface 2: Device or resource busy
>> >>> >> usrp_basic_rx: can't open rx interface
>> >>> >> Traceback (most recent call last):
>> >>> >> File "benchmark_rxr.py", line 153, in <module>
>> >>> >> main()
>> >>> >> File "benchmark_rxr.py", line 138, in main
>> >>> >> tb = my_top_block(demods[options.modulation],
>> >>> >> mods[options.modulation],
>> >>> >> rx_callback, options)
>> >>> >> File "benchmark_rxr.py", line 46, in __init__
>> >>> >> self.rxpath = usrp_receive_path.usrp_receive_path(demodulator,
>> >>> >> rx_callback, options)
>> >>> >> File
>> >>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
>> >>> >> line 65, in __init__
>> >>> >> self._setup_usrp_source(options)
>> >>> >> File
>> >>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
>> >>> >> line 78, in _setup_usrp_source
>> >>> >> self.u = usrp_options.create_usrp_source(options)
>> >>> >> File
>> >>> "/usr/local/lib/python2.6/dist-packages/gnuradio/usrp_options.py",
>> >>> >> line 88, in create_usrp_source
>> >>> >> gain=options.rx_gain,
>> >>> >> File
>> >>> >>
>> >>> >>
>> >>>
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py",
>> >>> >> line 138, in __init__
>> >>> >> _generic_usrp_base.__init__(self, **kwargs)
>> >>> >> File
>> >>> >>
>> >>> >>
>> >>>
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py",
>> >>> >> line 63, in __init__
>> >>> >> except: raise Exception, 'Failed to automatically setup a usrp
>> >>> >> device.'
>> >>> >> Exception: Failed to automatically setup a usrp device.
>> >>> >>
>> >>> >> I read different post with this problem such as "Full duplex and
>> half
>> >>> >> duplex
>> >>> >> does not work" and "help: cannot send after transport endpoint
>> >>> shutdown"
>> >>> >> but
>> >>> >> I could not solve the problem yet. I need to close the reception
>> in
>> >>> 2484
>> >>> >> MHz
>> >>> >> channel for a new reception in another channel in USRP2. The only
>> way
>> >>> to
>> >>> >> do
>> >>> >> that seems to close the port manually (i.e. pressing ctrl+c) but I
>> >>> want
>> >>> >> to
>> >>> >> do that by code. I tried different things before the line "p =
>> >>> >> Popen('python
>> >>> >> benchmark_rxr.py', shell = True)" such as "id_process =
>> os.getpid()"
>> >>> and
>> >>> >> "os.killpg(id_process, 2)", or by "tb.lock()" and "tb.unlock" and
>> so
>> >>> on,
>> >>> >> but
>> >>> >> nothing helped me, I keep obtaining the same error. I don't know
>> what
>> >>> to
>> >>> >> do
>> >>> >> else, can I change by code reception frequency in USRP2? Any
>> advice
>> >>> will
>> >>> >> be
>> >>> >> welcome, thanks a lot!
>> >>> >>
>> >>> >
>> >>> > You need to run both RX and TX in the same flowgraph. You can't
>> open
>> >>> them
>> >>> > in
>> >>> > separate flowgraphs.
>> >>> >
>> >>> > --n
>> >>> >
>> >>> >
>> >>> >
>> >>> >>
>> >>> >> Regards
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> View this message in context:
>> >>> >>
>> >>>
>> http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32414957.html
>> >>> >> Sent from the GnuRadio mailing list archive at Nabble.com.
>> >>> >>
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Discuss-gnuradio mailing list
>> >>> >> address@hidden
>> >>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>> >>
>> >>> >
>> >>> > _______________________________________________
>> >>> > Discuss-gnuradio mailing list
>> >>> > address@hidden
>> >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>> >
>> >>> >
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32417577.html
>> >>> Sent from the GnuRadio mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Discuss-gnuradio mailing list
>> >>> address@hidden
>> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>
>> >>
>> >> _______________________________________________
>> >> Discuss-gnuradio mailing list
>> >> address@hidden
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32456030.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context: http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32722439.html
Sent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 36
Date: Wed, 26 Oct 2011 13:41:02 +0300
From: Juha Vierinen <address@hidden>
To: gnuradio mailing list <address@hidden>
Subject: [Discuss-gnuradio] recovering timing after overflow
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I have been able to use the stream tagging to determine the accurate
timing for the first sample of the stream. However, I run into
problems after an overflow. It does seem to be feasible to recover
timing by looking for new tags (the uhd_usrp block applies a new tag
after an overflow is detected). However, this pmt is too alien to me
still and I'm not exactly sure how to query for the sample index
corresponding to the new tag. Are there any examples anywhere? I know
how to query for the tags between some interval of samples, but I
cannot get the exact sample corresponding to the first sample of the
packet arriving after overflow.
juha
------------------------------
Message: 37
Date: Wed, 26 Oct 2011 13:49:06 +0200
From: "Paul M. Bendixen" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Errors of missing modulators in
gnuradio-companion
Message-ID:
<CAAvei9r5hWm=SJJ1ko+UPYbibDDujhhOfe-9BU5-pT4Ax6=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Did a little more digging
cd [gitdir]/grc/
find . -name "*" | xargs grep digital
Returns nothing, on the other hand grepping blks2.gmsk_mod returns:
./Makefile.am: blks2_gmsk_mod.xml \
./block_tree.xml: <block>blks2_gmsk_mod</block>
./blks2_gmsk_mod.xml: <key>blks2_gmsk_mod</key>
./blks2_gmsk_mod.xml: <make>blks2.gmsk_mod(
In other words: the XML structure of the grc that has to do with anything
moved to digital must be updated, before 3.5 can be compared to a stable
environment.
XML has never been my strong suit, so I won't start looking into it.
Furthermore some of the blocks have changed input parameters (e.g.
gmsk_demod).
Perhaps merging next into master was a little premature?
Best regards
Paul
--
* - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */-
- */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/9d13f65a/attachment.html>
------------------------------
Message: 38
Date: Wed, 26 Oct 2011 07:55:54 -0400
From: Tom Rondeau <address@hidden>
To: "Paul M. Bendixen" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Errors of missing modulators in
gnuradio-companion
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Oct 26, 2011 at 7:49 AM, Paul M. Bendixen <address@hidden>wrote:
> Did a little more digging
> cd [gitdir]/grc/
> find . -name "*" | xargs grep digital
>
> Returns nothing, on the other hand grepping blks2.gmsk_mod returns:
> ./Makefile.am: blks2_gmsk_mod.xml \
> ./block_tree.xml: <block>blks2_gmsk_mod</block>
> ./blks2_gmsk_mod.xml: <key>blks2_gmsk_mod</key>
> ./blks2_gmsk_mod.xml: <make>blks2.gmsk_mod(
>
Fixing these now. About to push the patch.
> In other words: the XML structure of the grc that has to do with anything
> moved to digital must be updated, before 3.5 can be compared to a stable
> environment.
>
> XML has never been my strong suit, so I won't start looking into it.
> Furthermore some of the blocks have changed input parameters (e.g.
> gmsk_demod).
>
> Perhaps merging next into master was a little premature?
>
> Best regards
> Paul
>
I don't think so at all. The problem is there are no automated test for this
kind of stuff, and there's a lot of code that's of concern here. The only
way we could get these kinds of error reports was to get the real users of
GNU Radio to test them. These problems have been around in the old 'next'
branch for a while, but without being used, there was no way for us to get
these kinds of bug reports that is allowing us to fix them.
In other words, I really appreciate you checking these things out and
reporting the errors. This is also why we have stable releases. For people
who have environments where stability is a concern, they should stick with
the releases.
I went through and checked the GRC blocks against everything I moved into
gr-digital, so hopefully there is nothing left that I missed. I wonder if we
can make a piece of automatic test code that would try to load each of the
GRC XML blocks and report an error if it can't be loaded properly?
Thanks! Let me know if you find anything else.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/71302c0e/attachment.html>
------------------------------
Message: 39
Date: Wed, 26 Oct 2011 08:19:47 -0400
From: Tom Rondeau <address@hidden>
To: "Paul M. Bendixen" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Errors of missing modulators in
gnuradio-companion
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
The master branch has been updated with the fixes to the GRC blocks.
Thanks again for the reports!
Tom
On Wed, Oct 26, 2011 at 7:55 AM, Tom Rondeau <address@hidden> wrote:
> On Wed, Oct 26, 2011 at 7:49 AM, Paul M. Bendixen <address@hidden>wrote:
>
>> Did a little more digging
>> cd [gitdir]/grc/
>> find . -name "*" | xargs grep digital
>>
>> Returns nothing, on the other hand grepping blks2.gmsk_mod returns:
>> ./Makefile.am: blks2_gmsk_mod.xml \
>> ./block_tree.xml: <block>blks2_gmsk_mod</block>
>> ./blks2_gmsk_mod.xml: <key>blks2_gmsk_mod</key>
>> ./blks2_gmsk_mod.xml: <make>blks2.gmsk_mod(
>>
>
>
> Fixing these now. About to push the patch.
>
>
>
>> In other words: the XML structure of the grc that has to do with anything
>> moved to digital must be updated, before 3.5 can be compared to a stable
>> environment.
>>
>> XML has never been my strong suit, so I won't start looking into it.
>> Furthermore some of the blocks have changed input parameters (e.g.
>> gmsk_demod).
>>
>> Perhaps merging next into master was a little premature?
>>
>> Best regards
>> Paul
>>
>
> I don't think so at all. The problem is there are no automated test for
> this kind of stuff, and there's a lot of code that's of concern here. The
> only way we could get these kinds of error reports was to get the real users
> of GNU Radio to test them. These problems have been around in the old 'next'
> branch for a while, but without being used, there was no way for us to get
> these kinds of bug reports that is allowing us to fix them.
>
> In other words, I really appreciate you checking these things out and
> reporting the errors. This is also why we have stable releases. For people
> who have environments where stability is a concern, they should stick with
> the releases.
>
> I went through and checked the GRC blocks against everything I moved into
> gr-digital, so hopefully there is nothing left that I missed. I wonder if we
> can make a piece of automatic test code that would try to load each of the
> GRC XML blocks and report an error if it can't be loaded properly?
>
> Thanks! Let me know if you find anything else.
>
> Tom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/bc516366/attachment.html>
------------------------------
Message: 40
Date: Wed, 26 Oct 2011 15:07:52 +0200
From: "Paul M. Bendixen" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Errors of missing modulators in
gnuradio-companion
Message-ID:
<CAAvei9pnJR1yFBjq57ZkUqZxzn7JefVM7wKvLfnp=+address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Thanks, building now
Just one thing, shouldn't the xml files go into /gr-digital/grc/ like the
other blocks instead of /gr-digital all by them selves?
Will get back to you on how it went.
Best
Paul
2011/10/26 Tom Rondeau <address@hidden>
> The master branch has been updated with the fixes to the GRC blocks.
>
> Thanks again for the reports!
>
> Tom
>
>
>
>
> On Wed, Oct 26, 2011 at 7:55 AM, Tom Rondeau <address@hidden>wrote:
>
>> On Wed, Oct 26, 2011 at 7:49 AM, Paul M. Bendixen <address@hidden
>> > wrote:
>>
>>> Did a little more digging
>>> cd [gitdir]/grc/
>>> find . -name "*" | xargs grep digital
>>>
>>> Returns nothing, on the other hand grepping blks2.gmsk_mod returns:
>>> ./Makefile.am: blks2_gmsk_mod.xml \
>>> ./block_tree.xml: <block>blks2_gmsk_mod</block>
>>> ./blks2_gmsk_mod.xml: <key>blks2_gmsk_mod</key>
>>> ./blks2_gmsk_mod.xml: <make>blks2.gmsk_mod(
>>>
>>
>>
>> Fixing these now. About to push the patch.
>>
>>
>>
>>> In other words: the XML structure of the grc that has to do with anything
>>> moved to digital must be updated, before 3.5 can be compared to a stable
>>> environment.
>>>
>>> XML has never been my strong suit, so I won't start looking into it.
>>> Furthermore some of the blocks have changed input parameters (e.g.
>>> gmsk_demod).
>>>
>>> Perhaps merging next into master was a little premature?
>>>
>>> Best regards
>>> Paul
>>>
>>
>> I don't think so at all. The problem is there are no automated test for
>> this kind of stuff, and there's a lot of code that's of concern here. The
>> only way we could get these kinds of error reports was to get the real users
>> of GNU Radio to test them. These problems have been around in the old 'next'
>> branch for a while, but without being used, there was no way for us to get
>> these kinds of bug reports that is allowing us to fix them.
>>
>> In other words, I really appreciate you checking these things out and
>> reporting the errors. This is also why we have stable releases. For people
>> who have environments where stability is a concern, they should stick with
>> the releases.
>>
>> I went through and checked the GRC blocks against everything I moved into
>> gr-digital, so hopefully there is nothing left that I missed. I wonder if we
>> can make a piece of automatic test code that would try to load each of the
>> GRC XML blocks and report an error if it can't be loaded properly?
>>
>> Thanks! Let me know if you find anything else.
>>
>> Tom
>>
>>
>
--
* - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */-
- */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/996de8bd/attachment.html>
------------------------------
Message: 41
Date: Wed, 26 Oct 2011 13:23:55 +0000
From: "Nowlan, Sean" <address@hidden>
To: "Marcus D. Leech" <address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] New build-gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Can you add docutils and PyQwt to the dependency installation? I think those are missing.
(Excellent script, by the way. Saves a lot of grunt work.)
Sean
-----Original Message-----
From: discuss-gnuradio-bounces+sean.nowlan=address@hidden [mailto:discuss-gnuradio-bounces+sean.nowlan=address@hidden] On Behalf Of Marcus D. Leech
Sent: Tuesday, October 25, 2011 9:56 PM
To: address@hidden
Subject: [Discuss-gnuradio] New build-gnuradio
I worked-over build-gnuradio tonight rather thoroughly, and it now uses the Cmake infrastructure to do its Gnu Radio builds.
It also has built-in help:
build-gnuradio --help
Yields:
Usage: build-gnuradio [--help|-h] [-v|--verbose] [-jN] [-ja] [-l|--logfile logfile ] funcs
-v|--verbose - turn on verbose logging to stdout
-jN - have make use N concurrent jobs
-ja - have make use N concurrent jobs with auto setting of N
(based on number of cpu cores on build system)
-l|--logfile lf - log messages to 'lf'
available funcs are:
all - do all functions
prereqs - install prerequisites
gitfetch - use GIT to fetch Gnu Radio and UHD
uhd_build - build only UHD
firmware - fetch firmware/FPGA
gnuradio_build - build only Gnu Radio
mod_groups - modify the /etc/groups and user to group 'usrp'
mod_udev - add UDEV rule for USRP1
mod_sysctl - modify SYSCTL for larger net buffers
I'd love people to add support for systems other than Ubuntu and Fedora, but those are the most popular Linux distros in use.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 42
Date: Wed, 26 Oct 2011 15:30:32 +0200
From: Mattia Rizzi <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Packet-based communication & underrun /
Possible solution?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I want a gnu radio application that send packets (messages) in AIR when
pressing ENTER with USRP. Since i don't want any underun on USRP side, i
need a block that send zero-filled packets when there's no data to send.
I solved it with a modify of message_source block.
Instead of call delete->head() and wait for a message, i check if there's a
new message to send with empty_p(). If there isn't, then zero-fill the data
(to the USRP)
The code
//my code
if (d_msgq->empty_p())
{
memset (out, 0, noutput_items*d_itemsize);
return noutput_items;
}
// end of my code
d_msg = d_msgq->delete_head(); //blocking call
d_msg_offset = 0;
It's okay? There are other ways to do it better? Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/44f16e12/attachment.html>
------------------------------
Message: 43
Date: Wed, 26 Oct 2011 15:32:59 +0200
From: Mattia Rizzi <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Packet-based communication & underrun
/ Possible solution?
Message-ID:
<CADv+7GgLoyqiH-61yRNpz3LF_T6=rEdXpj=2=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
>Instead of call delete->head() and wait for a message
It's not "instead". Before calling it i check if there's an empty queue.
2011/10/26 Mattia Rizzi <address@hidden>
> I want a gnu radio application that send packets (messages) in AIR when
> pressing ENTER with USRP. Since i don't want any underun on USRP side, i
> need a block that send zero-filled packets when there's no data to send.
> I solved it with a modify of message_source block.
> Instead of call delete->head() and wait for a message, i check if there's a
> new message to send with empty_p(). If there isn't, then zero-fill the data
> (to the USRP)
>
> The code
> //my code
> if (d_msgq->empty_p())
> {
> memset (out, 0, noutput_items*d_itemsize);
> return noutput_items;
> }
> // end of my code
>
> d_msg = d_msgq->delete_head(); //blocking call
> d_msg_offset = 0;
>
> It's okay? There are other ways to do it better? Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20111026/258bb6fc/attachment.html>
------------------------------
Message: 44
Date: Wed, 26 Oct 2011 09:41:18 -0400
From: "Marcus D. Leech" <address@hidden>
To: "Nowlan, Sean" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] New build-gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 26/10/2011 9:23 AM, Nowlan, Sean wrote:
> Can you add docutils and PyQwt to the dependency installation? I think those are missing.
>
> (Excellent script, by the way. Saves a lot of grunt work.)
>
> Sean
>
Can you suggest package names for both Fedora and Ubuntu that would
satisfy this request, and I'll add them this evening.
------------------------------
Message: 45
Date: Wed, 26 Oct 2011 07:16:19 -0700
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] recovering timing after overflow
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/26/2011 03:41 AM, Juha Vierinen wrote:
> Hi,
>
> I have been able to use the stream tagging to determine the accurate
> timing for the first sample of the stream. However, I run into
> problems after an overflow. It does seem to be feasible to recover
> timing by looking for new tags (the uhd_usrp block applies a new tag
> after an overflow is detected). However, this pmt is too alien to me
> still and I'm not exactly sure how to query for the sample index
> corresponding to the new tag. Are there any examples anywhere? I know
> how to query for the tags between some interval of samples, but I
> cannot get the exact sample corresponding to the first sample of the
> packet arriving after overflow.
>
The tag's offset field provides the absolute sample c...