B. Siva Kumar Reddy
Research Scholar
Department of ECE
National Institute of Technology Warangal (NITW)
Andhra Pradesh, India-506004
09948065756
On Thu, May 2, 2013 at 9:01 AM, <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. Re: usrp_n200_r3_fpga.bin build error (Ian Buckley)
2. HOw to send and receive packets in grc? (karimkhan)
3. Re: HOw to send and receive packets in grc? (M. Ranganathan)
4. Re: usrp_n200_r3_fpga.bin build error
(Rahman, Muhammad Mahboob Ur)
5. gr_timer.h on next branch (Alexandru Csete)
6. Re: usrp_n200_r3_fpga.bin build error (Ian Buckley)
7. Re: peak near center freq for noise signal, how to fix it
(Alex Zhang)
8. Re: gr_timer.h on next branch (Johnathan Corgan)
9. About "FPGA-ADC/DAC and RF frontend" Latency (NaceurElOuni)
10. Re: Error in Building UHD on Windows (Zooz Engineer)
11. Re: Error in Building UHD on Windows (Zooz Engineer)
12. Why other correlators(ml or pnac) can not work in ofdm
example except for Schmidl and Cox correlator(default)? (Yingjie Chen)
13. Re: Why other correlators(ml or pnac) can not work in ofdm
example except for Schmidl and Cox correlator(default)?
(Martin Braun (CEL))
14. Re: Why other correlators(ml or pnac) can not work in ofdm
example except for Schmidl and Cox correlator(default)? (Yingjie Chen)
15. GSoC Students: Application deadline (Martin Braun (CEL))
16. I have a Question about channel model parameters (Irfan Ullah)
17. Re: I have a Question about channel model parameters (Adeel Anwar)
18. Re: I have a Question about channel model parameters (Tom Rondeau)
19. 4rx FPGA image issue (Nada ABDELKADER)
20. Re: 4rx FPGA image issue (address@hidden)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 May 2013 09:01:23 -0700
From: Ian Buckley <address@hidden>
To: "Rahman, Muhammad Mahboob Ur" <address@hidden>
Cc: "address@hidden forum" <address@hidden>,
Ian Buckley <address@hidden>, "address@hidden list"
<address@hidden>
Subject: Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
OK, if you have yet to change any files from the default and that is the result of a build then I strongly suspect the ISE version.
2013.1 has not been used to try to build any of the USRP databases yet.
2012.4 (14.4) is known to work for N200, and production images for N200 as supplied by Ettus are still built using ISE12.1.
I'll load 2013.1 later today and see if I can reproduce your problems.
On May 1, 2013, at 8:08 AM, "Rahman, Muhammad Mahboob Ur" <address@hidden> wrote:
> Hi Ian,
>
>
>> USRP specific questions (especially FPGA/Hardware) are best directed
>> at the USRP mailing list, rather than the GNURadio one.
>
> You are right in your suggestion :)
>
>> It's hard to say exactly what has caused this error, but basically it;s
>> failing to identify the module name that is the root/top of the FPGA hierarchy.
>> I'm curious to know if the following lines are present in "build-N200R3/u2plus.xise" :
>> <property xil_pn:name="Implementation Top" xil_pn:value="Module|u2plus" xil_pn:valueState="non-default"/>
>> <property xil_pn:name="Implementation Top File" xil_pn:value="../u2plus.v" xil_pn:valueState="non-default"/>
>> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value="/u2plus" xil_pn:valueState="non-default"/>
>
> Not exactly, but this is what I see inside u2plus.xise file:
> <property xil_pn:name="Implementation Top" xil_pn:value="" xil_pn:valueState="default"/>
> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value="" xil_pn:valueState="default"/>
>
> So should I edit it by hand to match what we expect?
>
>> To help further more information will be needed:
>> * What files in the design have you touched to make your changes
>
> None. But I will do some changes in u2plus_core.v in future.
>
>> * Have you been running ISE in a the gui mode on this project or altered Makefiles or scripts.
>
> No.
>
>> * What version of ISE are you using
>
> 2013.1
>
>> * Detailed log file of your attempt to compile (make -f Makefile.N200R3 bin 2>&1 | tee build.log)
>
> See attached.
>
>> As a sanity check it might be wise to prove that you can compile
>> an un-altered version of the FPGA using the same command line first.
>
> This is what I am currently doing.
>
>
>
> Thanks,
> Mahboob
> <build.log>_______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 2
Date: Thu, 2 May 2013 01:17:59 +0800 (SGT)
From: karimkhan <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] HOw to send and receive packets in grc?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
We can send and receive data using USRP in grc, but what if we want to do the same in packet format? Like I am working with some pre recorded USRP file and want to see all packet I am receiving from it that what is the procedure. I have created packet sniffer in java but no idea how to work in grc.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/b912d018/attachment.html>
------------------------------
Message: 3
Date: Wed, 1 May 2013 13:39:49 -0400
From: "M. Ranganathan" <address@hidden>
To: karimkhan <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] HOw to send and receive packets in
grc?
Message-ID:
<CAHiu4JNO-PvNXCdU5RPnzfipRadAcM=PN+x6_z7=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
You will need an IP layer on top of gnu radio to introduce the notion of IP
packets. Luckily there is an easy way to do it in linux using tunneling --
i.e. via the dev/tun interface. Read more about it (uncle google knows
where information can be found).
As an example, you can look at examples/ofdm/tunnel.py but there's a few
things that are missing there. The configuration can be a bit tricky. You
will have to configure the tun device and allow for local packets to be
delivered with remote IP addresses in the IP header. I forgot how to do
this already but there's a setting in the proc file system to do this.
Otherwise, the kernel will drop such packets.
Also, do not expect ICMP to work.
On Wed, May 1, 2013 at 1:17 PM, karimkhan <address@hidden> wrote:
> We can send and receive data using USRP in grc, but what if we want to do
> the same in packet format? Like I am working with some pre recorded USRP
> file and want to see all packet I am receiving from it that what is the
> procedure. I have created packet sniffer in java but no idea how to work in
> grc.
>
> Thanks.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
M. Ranganathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130501/1cc793fd/attachment.html>
------------------------------
Message: 4
Date: Wed, 1 May 2013 20:27:02 +0000
From: "Rahman, Muhammad Mahboob Ur" <address@hidden>
To: Ian Buckley <address@hidden>
Cc: "address@hidden forum" <address@hidden>,
Ian Buckley <address@hidden>, "address@hidden list"
<address@hidden>
Subject: Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hi Ian,
I have tried to build using 14.4; it took me about 40 minutes but eventually the process finished gracefully. So, we will stick to 14.4 for the time being.
Now, I can see u2plus.bin file in /build-N200R3. I hope this is the intended file; i.e., it is equivalent to pre-compiled usrp_n200_fpga_r3.bin file. Right?
Thanks,
Mahboob
________________________________________
From: Ian Buckley [address@hidden]
Sent: 01 May 2013 11:01
To: Rahman, Muhammad Mahboob Ur
Cc: Ian Buckley; address@hidden forum; address@hidden list
Subject: Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
OK, if you have yet to change any files from the default and that is the result of a build then I strongly suspect the ISE version.
2013.1 has not been used to try to build any of the USRP databases yet.
2012.4 (14.4) is known to work for N200, and production images for N200 as supplied by Ettus are still built using ISE12.1.
I'll load 2013.1 later today and see if I can reproduce your problems.
On May 1, 2013, at 8:08 AM, "Rahman, Muhammad Mahboob Ur" <address@hidden> wrote:
> Hi Ian,
>
>
>> USRP specific questions (especially FPGA/Hardware) are best directed
>> at the USRP mailing list, rather than the GNURadio one.
>
> You are right in your suggestion :)
>
>> It's hard to say exactly what has caused this error, but basically it;s
>> failing to identify the module name that is the root/top of the FPGA hierarchy.
>> I'm curious to know if the following lines are present in "build-N200R3/u2plus.xise" :
>> <property xil_pn:name="Implementation Top" xil_pn:value="Module|u2plus" xil_pn:valueState="non-default"/>
>> <property xil_pn:name="Implementation Top File" xil_pn:value="../u2plus.v" xil_pn:valueState="non-default"/>
>> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value="/u2plus" xil_pn:valueState="non-default"/>
>
> Not exactly, but this is what I see inside u2plus.xise file:
> <property xil_pn:name="Implementation Top" xil_pn:value="" xil_pn:valueState="default"/>
> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value="" xil_pn:valueState="default"/>
>
> So should I edit it by hand to match what we expect?
>
>> To help further more information will be needed:
>> * What files in the design have you touched to make your changes
>
> None. But I will do some changes in u2plus_core.v in future.
>
>> * Have you been running ISE in a the gui mode on this project or altered Makefiles or scripts.
>
> No.
>
>> * What version of ISE are you using
>
> 2013.1
>
>> * Detailed log file of your attempt to compile (make -f Makefile.N200R3 bin 2>&1 | tee build.log)
>
> See attached.
>
>> As a sanity check it might be wise to prove that you can compile
>> an un-altered version of the FPGA using the same command line first.
>
> This is what I am currently doing.
>
>
>
> Thanks,
> Mahboob
> <build.log>_______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 5
Date: Wed, 1 May 2013 23:15:02 +0200
From: Alexandru Csete <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] gr_timer.h on next branch
Message-ID:
<CAHG=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Greetings,
There is a gr_timer.h header in the gnuradio/next installation
directory, however, when I try to use this class I get
receiver.cpp:(.text+0x1ccf): undefined reference to
`gr_make_timer(void (*)(gr_timer*, void*), void*)'
receiver.cpp:(.text+0x1d6a): undefined reference to
`gr_timer::schedule_periodic(double, double)'
I can't find any implementation for this class. Is this some leftover
from old times?
I need a framework to execute something periodically (like a QTimer
but without Qt) so if there is a different class or framework I'd be
interested to know.
Alex
------------------------------
Message: 6
Date: Wed, 1 May 2013 14:43:25 -0700
From: Ian Buckley <address@hidden>
To: "Rahman, Muhammad Mahboob Ur" <address@hidden>
Cc: "address@hidden forum" <address@hidden>,
Ian Buckley <address@hidden>, "address@hidden list"
<address@hidden>
Subject: Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Correct, all the build products for N series USRP's are prefixed "u2plus" when they are generated directly via ISE, the name of the build directory identifies the specific hardware they are built for.
On May 1, 2013, at 1:27 PM, "Rahman, Muhammad Mahboob Ur" <address@hidden> wrote:
> Hi Ian,
>
> I have tried to build using 14.4; it took me about 40 minutes but eventually the process finished gracefully. So, we will stick to 14.4 for the time being.
>
> Now, I can see u2plus.bin file in /build-N200R3. I hope this is the intended file; i.e., it is equivalent to pre-compiled usrp_n200_fpga_r3.bin file. Right?
>
>
> Thanks,
> Mahboob
> ________________________________________
> From: Ian Buckley [address@hidden]
> Sent: 01 May 2013 11:01
> To: Rahman, Muhammad Mahboob Ur
> Cc: Ian Buckley; address@hidden forum; address@hidden list
> Subject: Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
>
> OK, if you have yet to change any files from the default and that is the result of a build then I strongly suspect the ISE version.
> 2013.1 has not been used to try to build any of the USRP databases yet.
> 2012.4 (14.4) is known to work for N200, and production images for N200 as supplied by Ettus are still built using ISE12.1.
> I'll load 2013.1 later today and see if I can reproduce your problems.
>
>
> On May 1, 2013, at 8:08 AM, "Rahman, Muhammad Mahboob Ur" <address@hidden> wrote:
>
>> Hi Ian,
>>
>>
>>> USRP specific questions (especially FPGA/Hardware) are best directed
>>> at the USRP mailing list, rather than the GNURadio one.
>>
>> You are right in your suggestion :)
>>
>>> It's hard to say exactly what has caused this error, but basically it;s
>>> failing to identify the module name that is the root/top of the FPGA hierarchy.
>>> I'm curious to know if the following lines are present in "build-N200R3/u2plus.xise" :
>>> <property xil_pn:name="Implementation Top" xil_pn:value="Module|u2plus" xil_pn:valueState="non-default"/>
>>> <property xil_pn:name="Implementation Top File" xil_pn:value="../u2plus.v" xil_pn:valueState="non-default"/>
>>> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value="/u2plus" xil_pn:valueState="non-default"/>
>>
>> Not exactly, but this is what I see inside u2plus.xise file:
>> <property xil_pn:name="Implementation Top" xil_pn:value="" xil_pn:valueState="default"/>
>> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value="" xil_pn:valueState="default"/>
>>
>> So should I edit it by hand to match what we expect?
>>
>>> To help further more information will be needed:
>>> * What files in the design have you touched to make your changes
>>
>> None. But I will do some changes in u2plus_core.v in future.
>>
>>> * Have you been running ISE in a the gui mode on this project or altered Makefiles or scripts.
>>
>> No.
>>
>>> * What version of ISE are you using
>>
>> 2013.1
>>
>>> * Detailed log file of your attempt to compile (make -f Makefile.N200R3 bin 2>&1 | tee build.log)
>>
>> See attached.
>>
>>> As a sanity check it might be wise to prove that you can compile
>>> an un-altered version of the FPGA using the same command line first.
>>
>> This is what I am currently doing.
>>
>>
>>
>> Thanks,
>> Mahboob
>> <build.log>_______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 7
Date: Wed, 1 May 2013 18:04:11 -0500
From: Alex Zhang <address@hidden>
To: vegihat vegihat <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] peak near center freq for noise
signal, how to fix it
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="windows-1252"
Veghihat, Hope this can help you
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-October/005376.html
On Mon, Apr 29, 2013 at 8:24 AM, vegihat vegihat <address@hidden>wrote:
> Well as you advice me, i set the --lo-offset=1M , for the following
> command
>
> uhd_rx_cfile -a serial=4759a751 -N 100000 -f 2.53G --samp-rate=2M
> --lo-offset=1M noise.dat -v
>
> However the peak is still there. I give below the output of
> uhd_rx_cfile.py.
> As you can see the Rx DDC frequency is -2M (if I have understood
> correctly, it should be 1M,right? )
>
> Any idea what is the wrong..
>
>
> linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.005.002-47-g4a860d74
>
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.000000MHz...
> Using mid-point gain of 45.0 ( 0.0 - 90.0 )
> Motherboard: USRP1 (4759a751)
> Daughterboard: RFX2400 (no serial, RX2, A:0)
> Rx gain: 45.0
> Rx baseband frequency: 2.528G
> Rx DDC frequency: -2M
> Rx Sample Rate: 2M
> Receving 100k samples
> Writing 32-bit complex floats
> Output filename: noise.dat
>
>
>
> 2013/4/28 Alex Zhang <address@hidden>
>
>> I remember that some DC is manually added into the frequency point which
>> can be divided by 5Mhz or 10Mhz? Besides the DC at the your central freq,
>> be aware of that if the lo offset setting makes your bandwidth cover these
>> frequency point, you still can see the peaks.
>> Hope I am not wrong, at least It seems that I observed that thing before.
>>
>>
>> On Fri, Apr 26, 2013 at 1:44 PM, Marcus D. Leech <address@hidden>wrote:
>>
>>> On 04/26/2013 02:27 PM, vegihat vegihat wrote:
>>>
>>>> if i have understand i need to use the --lo-offset of uhd_rx_cfile
>>>>
>>>> i have gave various values to --lo-offset and only one value has moved
>>>> the DC offset (--lo-offset=1G) and the plotfft gives many small spikes
>>>> (maybe this is caused to aliasing, but i am not sure)
>>>>
>>>> which is the rule (value of --lo-offset) to set the DC offset out of my
>>>> band?
>>>>
>>> What I do is set my LO offset to about half my bandwidth, so in your
>>> case:
>>>
>>> --lo-offset 1.0e6
>>>
>>>
>>> --
>>> 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<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>
>>
>>
>>
>> --
>>
>> Alex,
>> *Dreams can come true ? just believe.*
>>
>
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130501/98632dc9/attachment.html>
------------------------------
Message: 8
Date: Wed, 1 May 2013 17:06:23 -0700
From: Johnathan Corgan <address@hidden>
To: Alexandru Csete <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] gr_timer.h on next branch
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, May 1, 2013 at 2:15 PM, Alexandru Csete <address@hidden> wrote:
> There is a gr_timer.h header in the gnuradio/next installation
> directory, however, when I try to use this class I get
>
> receiver.cpp:(.text+0x1ccf): undefined reference to
> `gr_make_timer(void (*)(gr_timer*, void*), void*)'
> receiver.cpp:(.text+0x1d6a): undefined reference to
> `gr_timer::schedule_periodic(double, double)'
>
> I can't find any implementation for this class. Is this some leftover
> from old times?
>
This looks like a stray header file that was never deleted, or something
that never got implemented from back in 2005.
I'll delete this on next.
As for getting timer callback functionality, you could use POSIX timers,
but I'd rather chew on broken glass than try to get process signal-based
notifications working correctly in multithreaded code.
--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130501/a0ba9647/attachment.html>
------------------------------
Message: 9
Date: Wed, 1 May 2013 23:36:35 -0700 (PDT)
From: NaceurElOuni <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] About "FPGA-ADC/DAC and RF frontend"
Latency
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi,
I am working on estimating the delay between a Tx and an Rx using a stream
of packets modulated in a BPSK scheme (1 Mb/s) with a pair of N210.
(Sampling of 8 Mbits/s)
I want to know if the latency added by the portion(*) of [ FPGA - DAC - RF
front end to the antenna *2 (Rx Part) ] could be determined for a giving set
of parameters (transmission-reception)
I am interested in estimating the range of this latency (tens? hundreds of
microseconds?)
Then, could this latency be considered as insignifiant versus the latency of
the local network and the latency of Ethernet queue processing
(Encapsulation/Decapsulation). (for eg. both Rx and tx ethernet latency are
fluctuating between 1 to 1.5 msec.)
Another point, how is the latency of the portion (*) varying.
All explanation are appreciated, thank you in advance.
--
View this message in context: http://gnuradio.4.n7.nabble.com/About-FPGA-ADC-DAC-and-RF-frontend-Latency-tp41091.html
Sent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 10
Date: Thu, 2 May 2013 07:34:12 +0000
From: Zooz Engineer <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Error in Building UHD on Windows
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear Josh,
Thanks for the hint. The issue occurred after Visual Studio 2012 installation and is resolved by replacing the cvtres.exe from VS2010 with the one from VS2012.
Best,
Zo
Date: Thu, 25 Apr 2013 14:54:37 -0700
From: address@hidden
To: address@hidden
Subject: Re: Error in Building UHD on Windows
On 04/25/2013 03:27 PM, Zooz Engineer wrote:
>
>
>
> Dear All,
>
> I am trying to install UHD on windows from source code. I have
> installed the prerequisites:
>
> cmake-2.8.10.2-win32-x86 boost_1_51_setup32 python-2.6.6
> Cheetah-2.2.2.win32-py2.6
> msysGit-fullinstall-1.8.1.2-preview20130201 Visual studio 2010
> express
>
> I follwowed the steps detailed here:
> http://files.ettus.com/uhd_docs/manual/html/build.html#build-instructions-windows.
> After applying the fifth step in CMake I get the following error
> message.
>
> Do you have any idea why this is happening?
>
If you google for "failure during conversion to COFF: file invalid",
have tried any of the things suggested in the stack overflow forums?
Many of the posts seem to indicate that its a visual studio 2012
stomping on files in 2010 or some .net installer doing something similar.
-josh
> Thank you,
>
> Zo
>
> The C compiler identification is MSVC 16.0.30319.1 The CXX compiler
> identification is MSVC 16.0.30319.1 Check for working C compiler
> using: Visual Studio 10 Check for working C compiler using: Visual
> Studio 10 -- broken CMake Error at C:/Program Files (x86)/CMake
> 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):
> The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
> 10.0/VC/bin/cl.exe" is not able to compile a simple test program.
>
> It fails with the following output:
>
> Change Dir: C:/UHD/host/build/CMakeFiles/CMakeTmp
>
>
>
> Run Build
> Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
> cmTryCompileExec215809703.vcxproj /p:Configuration=Debug
> /p:VisualStudioVersion=10.0
>
> Microsoft (R) Build Engine version 4.0.30319.17929
>
> [Microsoft .NET Framework, version 4.0.30319.18034]
>
> Copyright (C) Microsoft Corporation. All rights reserved.
>
>
>
> Build started 25/04/2013 21:57:38.
>
> Project
> "C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj"
>
>
on node 1 (default targets).
>
> PrepareForBuild:
>
> Creating directory "cmTryCompileExec215809703.dir\Debug\". Creating
> directory "C:\UHD\host\build\CMakeFiles\CMakeTmp\Debug\".
>
> InitializeBuildStatus:
>
> Creating
> "cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.unsuccessfulbuild"
> because "AlwaysCreate" was specified.
>
> ClCompile:
>
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c
> /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D
> "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
> /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec215809703.dir\Debug\\"
> /Fd"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.pdb"
> /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
> for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.
>
> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D
> "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
> /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec215809703.dir\Debug\\"
> /Fd"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.pdb"
> /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000
>
> testCCompiler.c
>
> ManifestResourceCompile:
>
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\rc.exe
> /nologo
> /fo"cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.exe.embed.manifest.res"
> cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703_manifest.rc
>
>
> Link:
>
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.exe
> /ERRORREPORT:QUEUE
> /OUT:"C:\UHD\host\build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec215809703.exe"
> /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib
> shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
> /MANIFEST
> /ManifestFile:"cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.exe.intermediate.manifest"
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
> /PDB:"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.pdb"
> /SUBSYSTEM:CONSOLE /STACK:"10000000" /TLBID:1 /DYNAMICBASE /NXCOMPAT
> /IMPLIB:"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.lib"
> /MACHINE:X86
> cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.exe.embed.manifest.res
>
>
cmTryCompileExec215809703.dir\Debug\testCCompiler.obj /machine:X86 /debug
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file
> invalid or corrupt
> [C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj]
>
> Done Building Project
> "C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj"
>
>
(default targets) -- FAILED.
>
>
>
> Build FAILED.
>
>
>
> "C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj"
>
>
(default target) (1) ->
>
> (Link target) ->
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file
> invalid or corrupt
> [C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj]
>
>
>
>
> 0 Warning(s) 1 Error(s)
>
>
>
> Time Elapsed 00:00:00.64
>
>
>
>
>
> CMake will not be able to correctly generate this project. Call Stack
> (most recent call first):
>
>
>
> CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required
> command is present. A line of code such as
>
> cmake_minimum_required(VERSION 2.8)
>
> should be added at the top of the file. The version specified may be
> lower if you wish to support older CMake versions for this project.
> For more information run "cmake --help-policy CMP0000". This warning
> is for project developers. Use -Wno-dev to suppress it.
>
> Configuring incomplete, errors occurred!
>
>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
If you reply to this email, your message will be added to the discussion below:
http://gnuradio.4.n7.nabble.com/Error-in-Building-UHD-on-Windows-tp41004p41007.html
To start a new topic under GnuRadio, email address@hidden
To unsubscribe from GnuRadio, click here.
NAML
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/2cf5780c/attachment.html>
------------------------------
Message: 11
Date: Thu, 2 May 2013 08:42:46 +0000
From: Zooz Engineer <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Error in Building UHD on Windows
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
However, I have some 27 warnings in MSVC and I don't know how important they are:
C4244: '=' : conversion from 'double' to 'uint32_t', possible loss of data
C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)
C4305: '=' : truncation from 'double' to 'float'
Can they be fixed or I can just ignore them?
Best,
Zo
From: address@hidden
To: address@hidden
Subject: RE: Error in Building UHD on Windows
Date: Thu, 2 May 2013 07:34:12 +0000
Dear Josh,
Thanks for the hint. The issue occurred after Visual Studio 2012 installation and is resolved by replacing the cvtres.exe from VS2010 with the one from VS2012.
Best,
Zo
Date: Thu, 25 Apr 2013 14:54:37 -0700
From: address@hidden
To: address@hidden
Subject: Re: Error in Building UHD on Windows
On 04/25/2013 03:27 PM, Zooz Engineer wrote:
>
>
>
> Dear All,
>
> I am trying to install UHD on windows from source code. I have
> installed the prerequisites:
>
> cmake-2.8.10.2-win32-x86 boost_1_51_setup32 python-2.6.6
> Cheetah-2.2.2.win32-py2.6
> msysGit-fullinstall-1.8.1.2-preview20130201 Visual studio 2010
> express
>
> I follwowed the steps detailed here:
> http://files.ettus.com/uhd_docs/manual/html/build.html#build-instructions-windows.
> After applying the fifth step in CMake I get the following error
> message.
>
> Do you have any idea why this is happening?
>
If you google for "failure during conversion to COFF: file invalid",
have tried any of the things suggested in the stack overflow forums?
Many of the posts seem to indicate that its a visual studio 2012
stomping on files in 2010 or some .net installer doing something similar.
-josh
> Thank you,
>
> Zo
>
> The C compiler identification is MSVC 16.0.30319.1 The CXX compiler
> identification is MSVC 16.0.30319.1 Check for working C compiler
> using: Visual Studio 10 Check for working C compiler using: Visual
> Studio 10 -- broken CMake Error at C:/Program Files (x86)/CMake
> 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):
> The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
> 10.0/VC/bin/cl.exe" is not able to compile a simple test program.
>
> It fails with the following output:
>
> Change Dir: C:/UHD/host/build/CMakeFiles/CMakeTmp
>
>
>
> Run Build
> Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
> cmTryCompileExec215809703.vcxproj /p:Configuration=Debug
> /p:VisualStudioVersion=10.0
>
> Microsoft (R) Build Engine version 4.0.30319.17929
>
> [Microsoft .NET Framework, version 4.0.30319.18034]
>
> Copyright (C) Microsoft Corporation. All rights reserved.
>
>
>
> Build started 25/04/2013 21:57:38.
>
> Project
> "C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj"
>
>
on node 1 (default targets).
>
> PrepareForBuild:
>
> Creating directory "cmTryCompileExec215809703.dir\Debug\". Creating
> directory "C:\UHD\host\build\CMakeFiles\CMakeTmp\Debug\".
>
> InitializeBuildStatus:
>
> Creating
> "cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.unsuccessfulbuild"
> because "AlwaysCreate" was specified.
>
> ClCompile:
>
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c
> /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D
> "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
> /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec215809703.dir\Debug\\"
> /Fd"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.pdb"
> /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
> for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.
>
> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D
> "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise
> /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec215809703.dir\Debug\\"
> /Fd"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.pdb"
> /Gd /TC /analyze- /errorReport:queue testCCompiler.c /Zm1000
>
> testCCompiler.c
>
> ManifestResourceCompile:
>
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\rc.exe
> /nologo
> /fo"cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.exe.embed.manifest.res"
> cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703_manifest.rc
>
>
> Link:
>
> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.exe
> /ERRORREPORT:QUEUE
> /OUT:"C:\UHD\host\build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec215809703.exe"
> /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib
> shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
> /MANIFEST
> /ManifestFile:"cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.exe.intermediate.manifest"
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
> /PDB:"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.pdb"
> /SUBSYSTEM:CONSOLE /STACK:"10000000" /TLBID:1 /DYNAMICBASE /NXCOMPAT
> /IMPLIB:"C:/UHD/host/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec215809703.lib"
> /MACHINE:X86
> cmTryCompileExec215809703.dir\Debug\cmTryCompileExec215809703.exe.embed.manifest.res
>
>
cmTryCompileExec215809703.dir\Debug\testCCompiler.obj /machine:X86 /debug
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file
> invalid or corrupt
> [C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj]
>
> Done Building Project
> "C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj"
>
>
(default targets) -- FAILED.
>
>
>
> Build FAILED.
>
>
>
> "C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj"
>
>
(default target) (1) ->
>
> (Link target) ->
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file
> invalid or corrupt
> [C:\UHD\host\build\CMakeFiles\CMakeTmp\cmTryCompileExec215809703.vcxproj]
>
>
>
>
> 0 Warning(s) 1 Error(s)
>
>
>
> Time Elapsed 00:00:00.64
>
>
>
>
>
> CMake will not be able to correctly generate this project. Call Stack
> (most recent call first):
>
>
>
> CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required
> command is present. A line of code such as
>
> cmake_minimum_required(VERSION 2.8)
>
> should be added at the top of the file. The version specified may be
> lower if you wish to support older CMake versions for this project.
> For more information run "cmake --help-policy CMP0000". This warning
> is for project developers. Use -Wno-dev to suppress it.
>
> Configuring incomplete, errors occurred!
>
>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
If you reply to this email, your message will be added to the discussion below:
http://gnuradio.4.n7.nabble.com/Error-in-Building-UHD-on-Windows-tp41004p41007.html
To start a new topic under GnuRadio, email address@hidden
To unsubscribe from GnuRadio, click here.
NAML
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/aaadbb93/attachment.html>
------------------------------
Message: 12
Date: Thu, 2 May 2013 16:52:53 +0800
From: Yingjie Chen <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Why other correlators(ml or pnac) can not
work in ofdm example except for Schmidl and Cox correlator(default)?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
HI guy,
I have checked the code in ofdm_receiver.py and found that gnuradio uses
Schmidl and Cox as default correlator for frame detection. However, when I
change to other correlators like* ml or pnac*,the receiver cannot receiver
any more. Is there any problem with that? Thanks so much.
Best,
Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/284ab6b0/attachment.html>
------------------------------
Message: 13
Date: Thu, 2 May 2013 10:56:38 +0200
From: "Martin Braun (CEL)" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Why other correlators(ml or pnac) can
not work in ofdm example except for Schmidl and Cox
correlator(default)?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
On Thu, May 02, 2013 at 04:52:53PM +0800, Yingjie Chen wrote:
> I have checked the code in ofdm_receiver.py and found that gnuradio uses
> Schmidl and Cox as default correlator for frame detection. However, when I
> change to other correlators like ml or pnac,the receiver cannot receiver any
> more. Is there any problem with that? Thanks so much.
The OFDM code is under heavy maintenance right now. The code you're
inspecting is a bit outdated and it's quite likely it doesn't work
properly.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/c5d3e404/attachment.pgp>
------------------------------
Message: 14
Date: Thu, 2 May 2013 17:09:03 +0800
From: Yingjie Chen <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Why other correlators(ml or pnac) can
not work in ofdm example except for Schmidl and Cox
correlator(default)?
Message-ID:
<CAFFXVuUOse_SnUJfr=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for you reply. Can you tell me what should I do next? Update the
code or other things? Cause I am very urgent with my project and need to
use other correlator(like pnac). Thanks in advance.
2013/5/2 Martin Braun (CEL) <address@hidden>
> On Thu, May 02, 2013 at 04:52:53PM +0800, Yingjie Chen wrote:
> > I have checked the code in ofdm_receiver.py and found that gnuradio uses
> > Schmidl and Cox as default correlator for frame detection. However, when
> I
> > change to other correlators like ml or pnac,the receiver cannot receiver
> any
> > more. Is there any problem with that? Thanks so much.
>
> The OFDM code is under heavy maintenance right now. The code you're
> inspecting is a bit outdated and it's quite likely it doesn't work
> properly.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstra?e 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-W?rttemberg and
> National Laboratory of the Helmholtz Association
>
> _______________________________________________
> 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/20130502/5e173296/attachment.html>
------------------------------
Message: 15
Date: Thu, 2 May 2013 13:06:11 +0200
From: "Martin Braun (CEL)" <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] GSoC Students: Application deadline
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi all,
don't forget the deadline for the GSoC application is tomorrow, 1900
UTC.
Good luck,
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/86426ea4/attachment.pgp>
------------------------------
Message: 16
Date: Thu, 2 May 2013 04:13:32 -0700 (PDT)
From: Irfan Ullah <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] I have a Question about channel model
parameters
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
hi all,
????????
???????? Now a days i am working on cooperative communication and i am simulating my communication on channel model block but i don't know the purpose of the some parameters of channel model block like epsilon?, taps?, and frequency offset? can somebody tell me the purpose of these parameters
regards, Irfan Ullah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/286dea58/attachment.html>
------------------------------
Message: 17
Date: Thu, 2 May 2013 18:33:04 +0500
From: Adeel Anwar <address@hidden>
To: Irfan Ullah <address@hidden>, address@hidden
Subject: Re: [Discuss-gnuradio] I have a Question about channel model
parameters
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Irfan,
epsilon: Simulates Sampling-Clock-Mismatch. It uses rational-resampling for
interpolation/decimation. value=1 means no-mismatch i.e.
in-samp-rate=out-samp-rate. value=1.00001 means receiver clock is
fast(sample added). value=0.9999 means rcvr clock is slow (sample-skipped).
useful for testing Timing-Synch. Algo's
taps: Filter taps to simulate channel-response. Useful for testing
Equalization Algo's
frequency offset: Simulates Tx/Rx-Freq Mismatch. Useful for testing
Freq-Synch. Algo's
-Adeel
On Thu, May 2, 2013 at 4:13 PM, Irfan Ullah <address@hidden> wrote:
> hi all,
>
> Now a days i am working on cooperative communication and i am
> simulating my communication on channel model block but i don't know the
> purpose of the some parameters of channel model block like epsilon?, taps?,
> and frequency offset? can somebody tell me the purpose of these parameters
>
> regards, Irfan Ullah
>
>
>
> _______________________________________________
> 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/20130502/83b5a97a/attachment.html>
------------------------------
Message: 18
Date: Thu, 2 May 2013 09:50:46 -0400
From: Tom Rondeau <address@hidden>
To: Adeel Anwar <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] I have a Question about channel model
parameters
Message-ID:
<CA+SzT6i_+-U7n=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, May 2, 2013 at 9:33 AM, Adeel Anwar <address@hidden> wrote:
> Irfan,
>
> epsilon: Simulates Sampling-Clock-Mismatch. It uses rational-resampling for
> interpolation/decimation. value=1 means no-mismatch i.e.
> in-samp-rate=out-samp-rate. value=1.00001 means receiver clock is
> fast(sample added). value=0.9999 means rcvr clock is slow (sample-skipped).
> useful for testing Timing-Synch. Algo's
>
> taps: Filter taps to simulate channel-response. Useful for testing
> Equalization Algo's
>
> frequency offset: Simulates Tx/Rx-Freq Mismatch. Useful for testing
> Freq-Synch. Algo's
>
> -Adeel
>
>
> On Thu, May 2, 2013 at 4:13 PM, Irfan Ullah <address@hidden> wrote:
>>
>> hi all,
>>
>> Now a days i am working on cooperative communication and i am
>> simulating my communication on channel model block but i don't know the
>> purpose of the some parameters of channel model block like epsilon?, taps?,
>> and frequency offset? can somebody tell me the purpose of these parameters
>>
>> regards, Irfan Ullah
They are also described in the manual:
http://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1channel__model.html
Tom
------------------------------
Message: 19
Date: Thu, 02 May 2013 17:45:11 +0200
From: Nada ABDELKADER <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] 4rx FPGA image issue
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
format="flowed"
Hi all,
I'm using two USRP1 as transmitter and receiver.
I'm trying to make the receiver listening to three channels. I found
that I have to use the 4rx FPGA image for 4 RX DSPs on the USRP1.
But when I run my command with the <<
--args="fpga=usrp1_fpga_4rx.rbf" >> option and I got this error:
thread[thread-per-block[0]: <gr_block gr uhd usrp source (6)>]:
LookupError: KeyError: Cannot find a conversion routine for conversion
ID
Input format: sc16_item16_usrp1
Num inputs: 1
Output format: fc32
Num outputs: 3
I did not understand the origin of the problem and how to resolve it.
Can anybody help me plz?
Regards,
Nada
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
------------------------------
Message: 20
Date: Thu, 02 May 2013 11:59:42 -0400
From: address@hidden
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] 4rx FPGA image issue
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
On 02 May 2013 11:45, Nada ABDELKADER wrote:
> Hi all,
>
> I'm
using two USRP1 as transmitter and receiver.
> I'm trying to make the
receiver listening to three channels. I found
> that I have to use the
4rx FPGA image for 4 RX DSPs on the USRP1.
> But when I run my command
with the <<
> --args="fpga=usrp1_fpga_4rx.rbf" >> option and I got this
error:
>
> thread[thread-per-block[0]: ]:
> LookupError: KeyError:
Cannot find a conversion routine for conversion
> ID
> Input format:
sc16_item16_usrp1
> Num inputs: 1
> Output format: fc32
> Num outputs:
3
>
> I did not understand the origin of the problem and how to resolve
it.
> Can anybody help me plz?
>
> Regards,
> Nada
>
>
----------------------------------------------------------------
> This
message was sent using IMP, the Internet Messaging Program.
>
>
_______________________________________________
> Discuss-gnuradio
mailing list
> address@hidden
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Clutching at
straws here, but what happens if you use 4 channels, and just attach the
fourth channel to a NULL sink?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130502/71745842/attachment.html>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 126, Issue 2
************************************************