[Discuss-gnuradio] weird interaction between start of burst and oscillator phase
Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] weird interaction between start of burst and oscillator phase
On 10/25/2010 11:20 PM, Arun Pillai wrote: Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. See line 61 of dsp_core_tx.v, which is the NCO. During a burst, run is asserted, so the NCO continues to turn. When run is deasserted (i.e. between bursts), the NCO is reset to 0. Alternative ways of handling this would be to either just freeze the NCO when run is deasserted, or allow it to run all of the time. There are various reasons why you might want one mode or another. If this behavior is not desired, you can easily change those lines to have the NCO run all the time. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] weird interaction between start of burst and oscillator phase
Thanks, Matt. That's probably it - looking at the code from tx_control.v, it seems like just twiddling the start/end of burst bits alone is not enough either, the host needs to keep sending, otherwise the FPGA thinks it is an underrun. So, it seems like the correct solution would be to change the NCO code. One other question: Where is the UHD code in terms of maturity? Will future FPGA/firmware fixes happen on the UHD code, or will the existing code also be maintained? I will have to change a bunch of my host side code to use UHD, wondering if I should invest in that effort to avail of more robust firmware/FPGA code. (I don't care about portability or for the code to work on anything other than RFX daughterboards). Rahul On 10/26/2010 2:42 AM, Matt Ettus wrote: On 10/25/2010 11:20 PM, Arun Pillai wrote: Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. See line 61 of dsp_core_tx.v, which is the NCO. During a burst, run is asserted, so the NCO continues to turn. When run is deasserted (i.e. between bursts), the NCO is reset to 0. Alternative ways of handling this would be to either just freeze the NCO when run is deasserted, or allow it to run all of the time. There are various reasons why you might want one mode or another. If this behavior is not desired, you can easily change those lines to have the NCO run all the time. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Having firmware trouble in USRP2 - txrx_wbx_udp_20100507
Thank you Josh. All the best! Josh Blum-2 wrote: You are running experimental images. You need matching experimental host code: http://gnuradio.org/cgit/jblum.git/log/?h=udp -josh On 10/25/2010 04:11 AM, Vladutzzz wrote: Hi everyone! I recently updated the USRP2 firmware to txrx_wbx_UDP_20100507.bin from http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries . I also downloaded and installed u2_rev3-udp-ise12-20100615.bin from the same link. These images are specifically designed for WBX with UDP. After putting the SD card into the USRP2, I've tried pinging the USRP2, the process ending unsuccessfully, which I've read somewhere it's expected since it doesn't have a fully implemented IP stack. But it doesn't reply to find_usrps nor benchmark_tx nor usrp2_probe. How can I test to see if the firmware and fpga images are actually functioning and the board is operating properly? I am pretty stuck with this and would really appreciate any useful input. Thanks, Vlad. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Having-firmware-trouble-in-USRP2---txrx_wbx_udp_20100507-tp30020320p30055576.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
On 10/25/2010 07:36 PM, Joshua Lackey wrote: Quoting Philip Balister (phi...@balister.org): On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote: On 10/19/2010 10:51 PM, Eric Blossom wrote: OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * PAGE_SIZE. Need to puzzle through this a little more. This is the failing check in the kernel. OK. What's PAGE_SIZE on arm? PAGE_SIZE is still 4096, there is an additional restriction on the address passed to shmat(). Is the additional restriction '4 * PAGE_SIZE'? If so, look in the circular_buffer.cc for kalibrate and change the line that reads: m_pagesize = getpagesize(); to m_pagesize = 4 * getpagesize(); It may be that easy. The rest of the logic should work. Basically, yes. Unfortunately, this didn't work. I'll double check when I get back from ELCE. It seems like the shm code returns an address that is not valid for using as an address you pass to shmat :( Alternatively, you can force the use of Posix shared memory and see if that works for kalibrate on your platform. (The easiest thing to do would be to look for D_HOST_OSX and make sure those #ifdef's are the ones that gets compiled.) I'll check this when I get home. Email me with your results and I'll add some code to make arm work in the next version of kal. Thanks! Could we use the mmap code from gnuradio? That is what ends up being used there I think. I skimmed the shm code while working on this problem, and it looks like it used mmap internally :) Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Phase Locking of 2 sine sources..
Hi, I was wondering how to lock 2 sinewaves in phase with grc. The purpose is to build a descent mpx stereo decoder which locks a local 19khz sine to a bandpassed pilot of a mpx signal, which should improve the audioquality. Thanks in advance.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX 1800 - RFX 900
Dear Matt, thank you for you answer. I did: burn-db-eeprom -A –-force -t rfx900_mimo_b However it is not solving my problem, the error i receive is (when patched RFX 1800 is receiving): A: Flex 900 Rx MIMO B Error calling tune on subdevice When i put it to transmit, the error is: terminate called after throwing and instance of 'std::invalid_argument' what():subdev_spec same errors were before, i did not wrote it correctly in previous post. Many thanks for the answers. Matt Ettus wrote: On 10/25/2010 10:31 AM, psolic wrote: Hey all, i did: burn-db-eeprom -A –force -t rfx900 You need to use rfx900_mimo_b Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/RFX-1800--%3E-RFX-900-tp30045336p30056328.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] older versions of UHD
Hi Josh and List, I tried to check out an older (ten days old :-) version of UHD. I did like this: git clone git://ettus.sourcerepo.com/ettus/uhd.git git checkout -b uhd_old 816a07bee54e998e4fb25beeb44b9ac3888189bf Then built. However, it didn't work. I got on error from boost when setting the gain (bad any_cast or something like that). The UHD also complained that I used mimo_usrp. I am very confused at the moment so it could well be that I done some other mistakes along the way. Any comments? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question GNU Radio swig Path
Matt Dunstan wrote: i have a question related to GNU Radio installation. I followed all steps described in http://gnuradio.org/redmine/wiki/1/MingwInstallMain, but when I want to install gnuradio 3.3.0 it says that it can't find swig. It finds python becasue it is decalred in Environment Variables under Path with the value of C:\Python26. Swig is installed under C:\msys\1.0\local\swigwin-1.3.40, the problem is that I don't know how I sould declare the swig path and where. The step that says export PATH=$PATH:/c/Python26:/usr/local/swigwin-1.3.40:/c/Progra~1/SDCC/bin should take care of this. Another option is to create a file called /usr/local/bin/swig with the commands: #! /bin/sh exec 'C:/msys/1.0/local/swigwin-1.3.40/swig.exe' $@ Make the file executable with chmod +x /usr/local/bin/swig. In any case, the command which swig should tell you whether swig can be found. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trying to use latest version of UHD
Hi Josh and List,
I am now trying to use the latest version of UHD. I am working with one or two
USRP2s (I have previously worked successfully with up to four USPR2s).
I tried the following which I though should be the way to handle a general
number of USRP2s (no_ant).
std::string abcd_string(ABCDEFGHIJKLMNOPQRSTUVXYZ);
uhd::usrp::subdev_spec_t abcd(:+abcd_string.substr(0,no_ant));
d_mdev-set_rx_subdev_spec(abcd, uhd::usrp::multi_usrp::ALL_MBOARDS);
d_mdev-set_tx_subdev_spec(abcd, uhd::usrp::multi_usrp::ALL_MBOARDS);
However, I get the error:
error: Validate rx subdev spec failed: :AB
assertion failed:
is not a valid rx dboard name.
possible values are: [0].
Then I made a different intepretation and tried:
uhd::usrp::subdev_spec_t e(0);
for (uint32_t i1=0;i1no_ant;i1++) {
d_mdev-set_rx_subdev_spec(e, i1);
d_mdev-set_tx_subdev_spec(e, i1);
}
However, the results are still in error.
??
BR/
Per
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] which Xilinx version for USRP2 FPGA code?
What version of Xilinx ISE and EDK do I need to build the FPGA code and firmware for USRP2? The instructions here: http://gnuradio.org/redmine/wiki/1/USRP2UserFAQ say Xilinx 10.1.03 but the mail thread here: http://old.nabble.com/USRP2-FPGA-Compiling-td29586343.html says Xilinx 12.1 Thanks. Arun. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MIMO Status
Hello All, As I have stated in the past Im interested in VNA style measurements. Specifically S21. From what I have read and found out experimentally I need two coherent recievers to do this. And thus I need MIMO or something MIMO like. The wiki provides the following information ( http://gnuradio.org/redmine/wiki/1/USRP2GenFAQ#What-are-the-different-ways-MIMO-can-be-set-up-with-more-than-one-USRP2). These methods are in development according to it with a time hack of (14 November 2008). Thus they are not available is what I understand from the wiki. Any updates? Scenario 1 - Two USRP2 systems connected by a MIMO cable: Scenario 2 - Up to Four USRP2 systems connected by MIMO cables to the not-yet-in-existence HUB: Scenario 3 - An arbitrary number of USRP2 systems, no MIMO cables, no HUB: Now it looks like MIMO is available or Scenario 1. But it requires the UHD driver and an updated GRC version. Is this correct? How do I differentiate between whether I have this functionality or not? Is there a way to query the USRP and find this? I didn't build GRC myself. I have v3.3.1git-47-gf6337c62. Is this the right version? Thanks, Justin. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] which Xilinx version for USRP2 FPGA code?
Hello, for the repository git.ettus.com/ettus/fpga.git you must use 10.x, but there is a branch (ise12) that builds with 12.x. The UHD code under http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki works with ISE 12.X, I don't know about version 10. So you can use ISE 12 (for all service packs/minor versions), sometimes 10 if you still have the licenses (I think newer service packs preferred), and not at all version 11. Matthias Am 26.10.2010 um 15:33 schrieb Arun Pillai: What version of Xilinx ISE and EDK do I need to build the FPGA code and firmware for USRP2? The instructions here: http://gnuradio.org/redmine/wiki/1/USRP2UserFAQ say Xilinx 10.1.03 but the mail thread here: http://old.nabble.com/USRP2-FPGA-Compiling-td29586343.html says Xilinx 12.1 Thanks. Arun. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] which Xilinx version for USRP2 FPGA code?
If you are using UHD, you should use the FPGA code which is bundled into the UHD git repository. This code is pulled from the regular FPGA repository and will match up with the UHD version you are using. You must compile this with ISE 12.x. You could also use the ise12 branch from the fpga repository, but make sure you update your UHD at the same time to stay in sync. If you are using the raw ethernet (the old non-UHD version), then you should check out the master branch from the fpga repository. You _must_ compile this with ISE 10.1.03. It won't work with ISE 11.x or 12.x. It is strongly recommended that you use the UHD, as this is the direction we are moving all of our efforts, and it will have the most attention. Matt On 10/26/2010 06:47 AM, Matthias Wilhelm wrote: Hello, for the repository git.ettus.com/ettus/fpga.git you must use 10.x, but there is a branch (ise12) that builds with 12.x. The UHD code under http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki works with ISE 12.X, I don't know about version 10. So you can use ISE 12 (for all service packs/minor versions), sometimes 10 if you still have the licenses (I think newer service packs preferred), and not at all version 11. Matthias Am 26.10.2010 um 15:33 schrieb Arun Pillai: What version of Xilinx ISE and EDK do I need to build the FPGA code and firmware for USRP2? The instructions here: http://gnuradio.org/redmine/wiki/1/USRP2UserFAQ say Xilinx 10.1.03 but the mail thread here: http://old.nabble.com/USRP2-FPGA-Compiling-td29586343.html says Xilinx 12.1 Thanks. Arun. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trying to use latest version of UHD
I fixed a typo and pushed it to the master. When you leave the dboard
name blank, and you have a single slot, it should use the name of the
only daughterboard slot on your usrp. Except for the typo...
So, to use the AB subdev on basic RX on usrp2, the following would work:
0:AB
:AB - was previously broken by the typo
- empty string automatically picks the first subdevice 0:AB
-josh
On 10/26/2010 05:25 AM, Per Zetterberg wrote:
Hi Josh and List,
I am now trying to use the latest version of UHD. I am working with one or two
USRP2s (I have previously worked successfully with up to four USPR2s).
I tried the following which I though should be the way to handle a general
number of USRP2s (no_ant).
std::string abcd_string(ABCDEFGHIJKLMNOPQRSTUVXYZ);
uhd::usrp::subdev_spec_t abcd(:+abcd_string.substr(0,no_ant));
d_mdev-set_rx_subdev_spec(abcd, uhd::usrp::multi_usrp::ALL_MBOARDS);
d_mdev-set_tx_subdev_spec(abcd, uhd::usrp::multi_usrp::ALL_MBOARDS);
However, I get the error:
error: Validate rx subdev spec failed: :AB
assertion failed:
is not a valid rx dboard name.
possible values are: [0].
Then I made a different intepretation and tried:
uhd::usrp::subdev_spec_t e(0);
for (uint32_t i1=0;i1no_ant;i1++) {
d_mdev-set_rx_subdev_spec(e, i1);
d_mdev-set_tx_subdev_spec(e, i1);
}
However, the results are still in error.
??
BR/
Per
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
Quoting Philip Balister (phi...@balister.org): [...] Alternatively, you can force the use of Posix shared memory and see if that works for kalibrate on your platform. (The easiest thing to do would be to look for D_HOST_OSX and make sure those #ifdef's are the ones that gets compiled.) I'll check this when I get home. Email me with your results and I'll add some code to make arm work in the next version of kal. Thanks! Could we use the mmap code from gnuradio? That is what ends up being used there I think. I skimmed the shm code while working on this problem, and it looks like it used mmap internally :) mmap is the Posix shared memory method. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: remark on custom block + python behavior on Beagleboard
On 10/25/2010 04:38 PM, Almohanad Fayez wrote: Hi, sent an email a while back about what I thought was a scheduler issue with gnuradio on the beagleboard. Basically I've been writing custom GNU Radio block for the OMAP's DSP and running them on the beagleboard. On occassions when I'm running multiple blocks, GNU Radio would parse my flowgraph but then get lost and never starts the flowgraph. I've always thought it was an issue with my code but it turned out to be a python issue and I'm not sure if it's specific to my platform or python in general. python basically generates optimizied pre-interpred python files *.pyo and *.pyc. and as it happens, some of these files are not refreshed when I make changes to my python source file I managed to debug the issue where at the point where gnuradio calls the c++ file that handles the swig call handling gnuradio_swig_py_runtime.cc. This file is able to detect the python block so the custom_blocks.cc file generated by the howto-write-a-custom-block auto tools. then there is a call placed to the constructor gr_basic_block.cc and that's where gnuradio gets lost into oblivion. I was able to finally fix this problem by writing a script that deletes all of the pyc and pyo files associated with my library and flowgraph. my question is, is this a know python issue, an issue with the custom gnuradio block, or an issue with the platform? I managed to recreate this problem using the custom block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the original how to square a number example. Are you having real time clock issues? If you do not have the battery on your beagle, it will reset time each time you cycle power. That could explain what you are seeing. I installed the battery backup on mine to avoid this problem. You can also try to set the time over the network. Philip thanks. al ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase Locking of 2 sine sources..
Use a signal source to generate one, and connect this to a skiphead block to generate the other. The skiphead will cause a set amount on samples to be thrown out initially. That should give you two sinusoids with a constant phase difference. josh On 10/26/2010 03:17 AM, Jasper Kanbier wrote: Hi, I was wondering how to lock 2 sinewaves in phase with grc. The purpose is to build a descent mpx stereo decoder which locks a local 19khz sine to a bandpassed pilot of a mpx signal, which should improve the audioquality. Thanks in advance.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: remark on custom block + python behavior on Beagleboard
The beagleboard wasn't complaining about the RTC but I installed a battery on the beagleboard expansion yesterday hoping that'll fix it, renewed the timestamps by touching everything but that didn't seem to help. The problem gets more complicated as the code i'm working with is composed of a python file importing other custom python files. The best fix I found is turning off PYO and PYC file generation all together using export PYTHONDONTWRITEBYTECODE=1. I've read a number of posts for other projects complaining about stale pyo/pyc corrupting applications I'm installing and running everything as root so I doubt file permissions is the culprit, I'm currently using Python 2.6 on the beagleboard, I plan on upgrading to 2.8 soon and see if the problem persists ... at least for now the environmental variable is good enough al -Original Message- From: Philip Balister phi...@balister.org To: discuss-gnuradio discuss-gnuradio@gnu.org Sent: Tue, Oct 26, 2010 1:48 pm Subject: [Discuss-gnuradio] Re: remark on custom block + python behavior on Beagleboard On 10/25/2010 04:38 PM, Almohanad Fayez wrote: Hi, sent an email a while back about what I thought was a scheduler issue with gnuradio on the beagleboard. Basically I've been writing custom GNU Radio block for the OMAP's DSP and running them on the beagleboard. On occassions when I'm running multiple blocks, GNU Radio would parse my flowgraph but then get lost and never starts the flowgraph. I've always thought it was an issue with my code but it turned out to be a python issue and I'm not sure if it's specific to my platform or python in general. python basically generates optimizied pre-interpred python files *.pyo and *.pyc. and as it happens, some of these files are not refreshed when I make changes to my python source file I managed to debug the issue where at the point where gnuradio calls the c++ file that handles the swig call handling gnuradio_swig_py_runtime.cc. This file is able to detect the python block so the custom_blocks.cc file generated by the howto-write-a-custom-block auto tools. then there is a call placed to the constructor gr_basic_block.cc and that's where gnuradio gets lost into oblivion. I was able to finally fix this problem by writing a script that deletes all of the pyc and pyo files associated with my library and flowgraph. my question is, is this a know python issue, an issue with the custom gnuradio block, or an issue with the platform? I managed to recreate this problem using the custom block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the original how to square a number example. Are you having real time clock issues? If you do not have the battery on your beagle, it will reset time each time you cycle power. That could explain what you are seeing. I installed the battery backup on mine to avoid this problem. You can also try to set the time over the network. Philip thanks. al ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Howto module segmentation fault
Hello, I recently got python programs to successfully import the howto module, but I cannot use the functions. Any help or suggestions would be greatly appreciated: Python code: #!/usr/bin/env python from gnuradio import gr import howto class my_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self) src_nums = (4, 5, 6) src = gr.vector_source_f (src_nums) sqr = howto.square_ff () dst = gr.vector_sink_f () self.connect (src, sqr) self.connect (sqr, dst) print src: , src print sqr: , sqr print dst.data: , dst.data() if __name__ == '__main__': my_top_block().run() Output: src: gr_block vector_source_f (1) sqr: gr_block square_ff (2) dst.data: () Segmentation fault Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Still can't install gr-ais, some help please?
I'm trying to get gr-ais working on Beagleboard running Lucid. Here is a screenshot from serial terminal: http://old.nabble.com/file/p30062049/Screenshot.png Says can't find gnuradio-core. As far as I understood, it might be possible that gnuradio-core is installed somewhere, and I just have to specify GNURADIO_CORE_LIBS and GNURADIO_CORE_CFLAGS variables (paths?) somehow. I don't get it. Help please? -- View this message in context: http://old.nabble.com/Still-can%27t-install-gr-ais%2C-some-help-please--tp30062049p30062049.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Still can't install gr-ais, some help please?
On Tue, 2010-10-26 at 14:43 -0700, Thunder87 wrote: I'm trying to get gr-ais working on Beagleboard running Lucid. Here is a screenshot from serial terminal: http://old.nabble.com/file/p30062049/Screenshot.png Says can't find gnuradio-core. As far as I understood, it might be possible that gnuradio-core is installed somewhere, and I just have to specify GNURADIO_CORE_LIBS and GNURADIO_CORE_CFLAGS variables (paths?) somehow. I don't get it. Help please? Did you set PKG_CONFIG_PATH to the location of your Gnuradio installation? If not, find the location of libgnuradio-core.so and add it to the PKG_CONFIG_PATH. On my Ubuntu box this file was installed to /usr/local/lib, so we add /usr/local/lib/pkgconfig to the PKG_CONFIG_PATH: export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig --n ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi usrp, 1 odd channel, HW problem?
On Wed, Oct 20, 2010 at 7:41 PM, Steven Clark steven.p.cl...@gmail.comwrote: On Thu, Oct 14, 2010 at 12:47 PM, Matt Ettus m...@ettus.com wrote: Probe R201 on all 4 WBX boards with an oscilloscope while running. One side of the resistor is ground and the other side is the reference clock. They should all be around the same amplitude, and have the exact same frequency and phase. Matt On 10/14/2010 09:13 AM, Steven Clark wrote: Hi all- I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have performed the clock synching described here: http://gnuradio.org/redmine/wiki/1/MultiUsrp I'm doing 4-channel receive, using a power splitter to send the same CW signal into all 4 d'cards, and tuning them all identically. 3 of the 4 channels are nicely phase-locked. The 4th seems a little...off. ClockMasterUSRP (Serial #5821): Side A: red channel ClockMasterUSRP (Serial #5821): Side B: green channel ClockSlaveUSRP (Serial #2087): Side A: blue channel ClockSlaveUSRP (Serial #2087): Side B: black channel --- problem with this guy Please see these 3 images to see the problem: http://picasaweb.google.com/steven.p.clark/MultiUsrpGlitches?feat=directlink You can see the problem in both the frequency domain, and in the time domain. I tried swapping daughtercards around, and the problem is not tied to any one daughtercard, but rather to slave USRP side B. Any idea what could be causing this? Shouldn't the same clock be going to both sides of the USRP? (why does blue look fine, but black does not?) -Steven Matt- Sorry for the delay in getting back to you. I took a look at R201 on all dboards as you suggested. All 4 looked fairly similar -- a clean-looking 64MHz sine wave. Amplitudes were close, in the 700-800mV p-p range. Comparing between 2 dboards on the same USRP, the phases matched pretty well (within a few degrees I would say). Comparing from one USRP to the other, there was a definite phase offset (~90degrees). Since the SMA cable bringing the clock from master to slave is a few feet long, this seems reasonable. What's the next step? -Steven New info. All 4 channels look fine when capturing individually on them. Furthermore, frequency-wise, all the individual captures look different from their corresponding simultaneous captures. For example, with individual captures my CW input might show up as energy in FFT bin #514 of 1024 for all 4 chans, whereas with a combined capture, the energy shows up in bin #535 for Chans 1-3, and in bin #536 for Chan 4. This is consistent with all 4 channels dropping occasional samples when used jointly, but with chan 4 dropping them slightly more frequently than the others. So I would say the problem is not as simple as one channel has HW problems, but rather there is something system-level going on. Sample rate was 250kHz, which should be plenty doable... Does anybody have any thoughts as to what might be going on? -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] unable to compile firmware with microblaze
I am running Ubuntu 10.10 2.6.35-22-generic with x86_64. I tried the prebuilt binary as per instructions here: http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ Specifically, I did the following: $ wget http://gnuradio.org/tools/mb-gcc-4.1.1.gr2.i386.tar.gz Once you've downloaded the tarball, $ sudo bash # cd /opt # tar xzvf path-to-tarball Then add /opt/microblaze/bin to PATH ( export PATH=$PATH:/opt/microblaze/bin ) == However, when I run configure.gnu in the firmware directory, I get the following error in config.log: configure:3134: error: in `/home/rahul/vmimo/code/gnuradio/usrp2/firmware': configure:3137: error: C compiler cannot create executables When I also explicitly run: mb-gcc with our without explicit path qualifier of /opt/microblaze/bin/, I get the following error: $ /opt/microblaze/bin% ./mb-gcc zsh: no such file or directory: ./mb-gcc This despite the file existing: $ /opt/microblaze/bin% ls -l mb-gcc -rwxr-xr-x 1 500 500 192961 2008-10-13 19:47 mb-gcc* Any ideas? Thanks, Arun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: unable to compile firmware with microblaze
I am also trying to build the microblaze compiler from scratch but I am unable to get the patch from svn. $ svn export http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch': 200 OK (http://gnuradio.org) Where can I get this patch? Arun On 10/26/2010 08:04 PM, Arun Pillai wrote: I am running Ubuntu 10.10 2.6.35-22-generic with x86_64. I tried the prebuilt binary as per instructions here: http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ Specifically, I did the following: $ wget http://gnuradio.org/tools/mb-gcc-4.1.1.gr2.i386.tar.gz Once you've downloaded the tarball, $ sudo bash # cd /opt # tar xzvf path-to-tarball Then add /opt/microblaze/bin to PATH ( export PATH=$PATH:/opt/microblaze/bin ) == However, when I run configure.gnu in the firmware directory, I get the following error in config.log: configure:3134: error: in `/home/rahul/vmimo/code/gnuradio/usrp2/firmware': configure:3137: error: C compiler cannot create executables When I also explicitly run: mb-gcc with our without explicit path qualifier of /opt/microblaze/bin/, I get the following error: $ /opt/microblaze/bin% ./mb-gcc zsh: no such file or directory: ./mb-gcc This despite the file existing: $ /opt/microblaze/bin% ls -l mb-gcc -rwxr-xr-x 1 500 500 192961 2008-10-13 19:47 mb-gcc* Any ideas? Thanks, Arun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze
On Tue, Oct 26, 2010 at 10:04:10PM -0400, Arun Pillai wrote: I am also trying to build the microblaze compiler from scratch but I am unable to get the patch from svn. $ svn export http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch': 200 OK (http://gnuradio.org) Where can I get this patch? Arun Arun, The microblaze compiler has been quite an annoyance. Although I haven't tried it yet, you may want to try the mb_gnu.git project at http://git.xilinx.com But see also below... On 10/26/2010 08:04 PM, Arun Pillai wrote: I am running Ubuntu 10.10 2.6.35-22-generic with x86_64. I tried the prebuilt binary as per instructions here: http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ Specifically, I did the following: $ wget http://gnuradio.org/tools/mb-gcc-4.1.1.gr2.i386.tar.gz Once you've downloaded the tarball, $ sudo bash # cd /opt # tar xzvf path-to-tarball Then add /opt/microblaze/bin to PATH ( export PATH=$PATH:/opt/microblaze/bin ) == However, when I run configure.gnu in the firmware directory, I get the following error in config.log: configure:3134: error: in `/home/rahul/vmimo/code/gnuradio/usrp2/firmware': configure:3137: error: C compiler cannot create executables When I also explicitly run: mb-gcc with our without explicit path qualifier of /opt/microblaze/bin/, I get the following error: $ /opt/microblaze/bin% ./mb-gcc zsh: no such file or directory: ./mb-gcc This despite the file existing: $ /opt/microblaze/bin% ls -l mb-gcc -rwxr-xr-x 1 500 500 192961 2008-10-13 19:47 mb-gcc* Any ideas? If you run $ ldd /opt/microblaze/bin/mb-gcc Are all of the shared libraries found? It's a 32-bit app. Depending on your OS and machine, you may need to install 32-bit versions of the required libraries. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze
Eric, The output of ldd is below: $ ldd /opt/microblaze/bin/mb-gcc not a dynamic executable Arun On 10/26/2010 10:36 PM, Eric Blossom wrote: On Tue, Oct 26, 2010 at 10:04:10PM -0400, Arun Pillai wrote: I am also trying to build the microblaze compiler from scratch but I am unable to get the patch from svn. $ svn export http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch': 200 OK (http://gnuradio.org) Where can I get this patch? Arun Arun, The microblaze compiler has been quite an annoyance. Although I haven't tried it yet, you may want to try the mb_gnu.git project at http://git.xilinx.com But see also below... On 10/26/2010 08:04 PM, Arun Pillai wrote: I am running Ubuntu 10.10 2.6.35-22-generic with x86_64. I tried the prebuilt binary as per instructions here: http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ Specifically, I did the following: $ wget http://gnuradio.org/tools/mb-gcc-4.1.1.gr2.i386.tar.gz Once you've downloaded the tarball, $ sudo bash # cd /opt # tar xzvfpath-to-tarball Then add /opt/microblaze/bin to PATH ( export PATH=$PATH:/opt/microblaze/bin ) == However, when I run configure.gnu in the firmware directory, I get the following error in config.log: configure:3134: error: in `/home/rahul/vmimo/code/gnuradio/usrp2/firmware': configure:3137: error: C compiler cannot create executables When I also explicitly run: mb-gcc with our without explicit path qualifier of /opt/microblaze/bin/, I get the following error: $ /opt/microblaze/bin% ./mb-gcc zsh: no such file or directory: ./mb-gcc This despite the file existing: $ /opt/microblaze/bin% ls -l mb-gcc -rwxr-xr-x 1 500 500 192961 2008-10-13 19:47 mb-gcc* Any ideas? If you run $ ldd /opt/microblaze/bin/mb-gcc Are all of the shared libraries found? It's a 32-bit app. Depending on your OS and machine, you may need to install 32-bit versions of the required libraries. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze
On Tue, Oct 26, 2010 at 10:48:23PM -0400, Arun Pillai wrote: Eric, The output of ldd is below: $ ldd /opt/microblaze/bin/mb-gcc not a dynamic executable What does $ file /opt/microblaze/bin/mb-gcc Give? I get: $ file /opt/microblaze/bin/mb-gcc /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped If that doesn't work, please try building the one from git.xilinx.com. With luck, it might even build out of the box. (Why Xilinx hasn't gotten the microblaze stuff accepted into the gcc main line is beyond me...) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Best practice to power up USRP
Hi all, Since there is no power switch on the USRP itself, I would like to know what the safest way to power on the device is? Is it best to leave the DC plug inserted into the unit, and power on the unit by switching on power to the switchmode supply? Or is it safe to remove and insert the DC plug into the front of the unit as needed? Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze
I get exactly what you get. $ file /opt/microblaze/bin/mb-gcc /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped Arun On 10/26/2010 11:45 PM, Eric Blossom wrote: On Tue, Oct 26, 2010 at 10:48:23PM -0400, Arun Pillai wrote: Eric, The output of ldd is below: $ ldd /opt/microblaze/bin/mb-gcc not a dynamic executable What does $ file /opt/microblaze/bin/mb-gcc Give? I get: $ file /opt/microblaze/bin/mb-gcc /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped If that doesn't work, please try building the one from git.xilinx.com. With luck, it might even build out of the box. (Why Xilinx hasn't gotten the microblaze stuff accepted into the gcc main line is beyond me...) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Best practice to power up USRP
On 10/26/2010 08:35 PM, Matt Robert wrote: Hi all, Since there is no power switch on the USRP itself, I would like to know what the safest way to power on the device is? Is it best to leave the DC plug inserted into the unit, and power on the unit by switching on power to the switchmode supply? Or is it safe to remove and insert the DC plug into the front of the unit as needed? Thanks, Matt It doesn't matter. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Best practice to power up USRP
Thanks Matt, I can relax now! Cheers, Matt On 27/10/10 2:57 PM, Matt Ettus wrote: On 10/26/2010 08:35 PM, Matt Robert wrote: Hi all, Since there is no power switch on the USRP itself, I would like to know what the safest way to power on the device is? Is it best to leave the DC plug inserted into the unit, and power on the unit by switching on power to the switchmode supply? Or is it safe to remove and insert the DC plug into the front of the unit as needed? Thanks, Matt It doesn't matter. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze
On Tue, Oct 26, 2010 at 11:50:34PM -0400, Arun Pillai wrote: I get exactly what you get. $ file /opt/microblaze/bin/mb-gcc /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped Arun I think you're missing an i386 compatibility library. Sorry, I'm not sure what it's called under Ubuntu. Eric On 10/26/2010 11:45 PM, Eric Blossom wrote: On Tue, Oct 26, 2010 at 10:48:23PM -0400, Arun Pillai wrote: Eric, The output of ldd is below: $ ldd /opt/microblaze/bin/mb-gcc not a dynamic executable What does $ file /opt/microblaze/bin/mb-gcc Give? I get: $ file /opt/microblaze/bin/mb-gcc /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped If that doesn't work, please try building the one from git.xilinx.com. With luck, it might even build out of the box. (Why Xilinx hasn't gotten the microblaze stuff accepted into the gcc main line is beyond me...) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to hold a values from file source
Currently I am trying to make an ASK (Amplitude Shift Keying) I use GNURadio Companion, The program gets the input from file source and multiplies it with signal source. And I monitors via Scope and FFT plots You can see a diagram ASK.grc (image) http://goo.gl/0WHt And the result is somewhat weird. Plots (image) http://goo.gl/UcF9 It seems sinusoidal, but the shape looks like sawtooth! I thought that the program couldn't hold values from file source So, I am wandering whether there is a method for holding a value ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to hold a values from file source
On 10/26/2010 10:17 PM, songsong gee wrote: Currently I am trying to make an ASK (Amplitude Shift Keying) I use GNURadio Companion, The program gets the input from file source and multiplies it with signal source. And I monitors via Scope and FFT plots You can see a diagram ASK.grc (image)http://goo.gl/0WHt And the result is somewhat weird. Plots (image)http://goo.gl/UcF9 It seems sinusoidal, but the shape looks like sawtooth! You are multiplying random 1s and 0s by a sinusoid. And you have a sinusoid that is randomly either 0 or sine(x). It looks correct! Perhaps you want to increase the temporal width of your symbols? In that case, I suggest using the repeat block. _josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
