Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: b205 mini and gnuradio companion (Marcus M?ller)
2. Re: How do timed commands work? (Marcus M?ller)
3. Re: Separate thread for each streaming channel (Martin Braun)
4. Re: How do timed commands work? (Dave NotTelling)
5. Environmental Questions About the X310 and N210 (Dave NotTelling)
6. Error while re-building file-system for E310 (Joshua Monson)
7. Re: How do timed commands work? (De Picker Laurent)
8. 'create the usrp device' fails==Unhandled exception at
0x000007FEE74B14A8 (uhd.dll) (Nik B.)
9. Re: Error while re-building file-system for E310 (Philip Balister)
10. gnuradio - windows (rv pellarin)
11. Received power changing in sinusoidal manner (Vladica Sark)
12. Re: gnuradio - windows (Marcus M?ller)
13. Re: Received power changing in sinusoidal manner (Marcus M?ller)
14. Re: gnuradio - windows (rv pellarin)
15. Re: gnuradio - windows (Marcus M?ller)
16. Re: gnuradio - windows (rv pellarin)
17. Re: gnuradio - windows (Marcus M?ller)
18. Re: Received power changing in sinusoidal manner (Vladica Sark)
----------------------------------------------------------------------
Message: 1
Date: Fri, 20 May 2016 18:12:42 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] b205 mini and gnuradio companion
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi RV,
what does "failing" mean here?
Any flow graph that generally works with USRPs will work with the
B205mini. My main suspicion here is that your setup is not functional.
So: does
http://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for
lead you anywhere?
Best regards,
Marcus
On 05/20/2016 10:26 AM, rv pellarin via USRP-users wrote:
> hi folks,
> happy to join the community, i just received my b205 mini
> i ve started to get into gnuradio companion, but i fail getting the
> b205mini
> do you guys have one or two grc file to share that i can look into,
> flowcharts that would work with the b205 mini?
> would be great
> thx for your time
> best regards
>
> ?
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/fdabff28/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 20 May 2016 18:40:11 +0200
From: Marcus M?ller <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do timed commands work?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Dave,
On 05/20/2016 04:19 PM, Dave NotTelling wrote:
> Marcus,
>
> Thank you for the in depth explanation!! My apologies for not
> listing the devices. I am using an X310 with the UBX-160 and an N210
> with the UBX-40.
>
> I brought up the property tree because from what I can see in the
> X300 source code, the property tree is used
> @ uhd/host/lib/usrp/x300/x300_impl.cpp line 998 (version 3.9.4). That
> shows something subscribing to samp rate changes. The actual method
> that changes the freq is located
> at uhd/host/lib/usrp/x300/x300_io_impl.cpp line 67. What I don't see
> is how timed commands are treated differently than normal commands.
That's because they are *not* treated differently. You set a command
time, which informs the FPGA, and from then on, every command that
reaches the FPGA will take effect at that time, and no earlier.
> Honestly it doesn't really matter that I have a full understanding of
> it so long as I can be promised that for the X310 and N210 with UBX
> daughterboards that sample rate, gain, and freq can all be changed via
> timed commands.
They can!
> I would like to be able to pack as many timed commands as
> possible as close in time as possible. In order to do that I need to
> figure out how long the various operations take (tuning, sample rate
> changes, and gain settings).
* Tuning:
o Digital part: from one sample to the next.
o Analog part: depends on the before/after frequencies, but on
UBX, let's say ~ 4ms
o Watch for the DC removal (which you can disable), which can take
up to about 60ms on N2xx, half of that on X3xx, if I remember
correctly
* Sample rate change:
o good question; not long (same order of magnitude, ie. a couple
of samples),
o but you'll have to take into account that this operation changes
filters, and hence, you'll see the step response of the newly
added FIR (if any).
* Gain change: Haven't tested that, but I think that would probably be
pretty quick; a couple of samples. The gain change is mostly done by
the adjustable attenuator, which should work in <2?s
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/870008d5/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 20 May 2016 09:57:28 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/19/2016 01:16 PM, Rob Kossler via USRP-users wrote:
> Thanks Marcus, Michael,
>
> I was able to implement the channel per streamer concept successfully
> and the performance is quite a bit better. I am using a relatively
> recent (last week or so) version of the master head on Ubuntu 14.04 LTS.
>
> Here are some approximate numbers obtained by visually monitoring CPU
> performance via 'htop'. My CPU is i7-4770 (3.4GHz). These were
> measured with my own version of rx_samples_to_file where I was streaming
> to RAM files for a 5 second capture.
>
> * Single streamer with 4 channel
> o at 50 MS/s, max CPU usage around 50% and no overruns
> o at 100 MS/s, several (4-5) CPU above 95% and multiple Overruns
> * Four streamers with 1 channel each
> o at 100 MS/s, max CPU usage around 30% and no overruns
>
> So, although as you say the alignment issue is more complicated in the
> event of bad things, the likelihood of bad things appears to be much
> reduced.
One thing you can do to increase robustness is to observe the RX
metadata and check for overruns yourself. When they occur, you have no
more guarantee of alignment. You can re-start the stream to ensure
alignment in that case.
Cheers,
Martin
------------------------------
Message: 4
Date: Fri, 20 May 2016 13:05:42 -0400
From: Dave NotTelling <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do timed commands work?
Message-ID:
<cak6gvuo_rkmo9ak4s80mibbhksv-jw07ajjjy4ro8ke6di_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
That really helps me! Thank you very much :D
-Dave
On Fri, May 20, 2016 at 12:40 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Dave,
>
> On 05/20/2016 04:19 PM, Dave NotTelling wrote:
>
> Marcus,
>
> Thank you for the in depth explanation!! My apologies for not
> listing the devices. I am using an X310 with the UBX-160 and an N210 with
> the UBX-40.
>
> I brought up the property tree because from what I can see in the
> X300 source code, the property tree is used
> @ uhd/host/lib/usrp/x300/x300_impl.cpp line 998 (version 3.9.4). That
> shows something subscribing to samp rate changes. The actual method that
> changes the freq is located at uhd/host/lib/usrp/x300/x300_io_impl.cpp line
> 67. What I don't see is how timed commands are treated differently than
> normal commands.
>
> That's because they are *not* treated differently. You set a command time,
> which informs the FPGA, and from then on, every command that reaches the
> FPGA will take effect at that time, and no earlier.
>
> Honestly it doesn't really matter that I have a full understanding of it
> so long as I can be promised that for the X310 and N210 with UBX
> daughterboards that sample rate, gain, and freq can all be changed via
> timed commands.
>
> They can!
>
> I would like to be able to pack as many timed commands as possible as
> close in time as possible. In order to do that I need to figure out how
> long the various operations take (tuning, sample rate changes, and gain
> settings).
>
>
> - Tuning:
> - Digital part: from one sample to the next.
> - Analog part: depends on the before/after frequencies, but on UBX,
> let's say ~ 4ms
> - Watch for the DC removal (which you can disable), which can take
> up to about 60ms on N2xx, half of that on X3xx, if I remember correctly
> - Sample rate change:
> - good question; not long (same order of magnitude, ie. a couple of
> samples),
> - but you'll have to take into account that this operation changes
> filters, and hence, you'll see the step response of the newly added FIR
> (if
> any).
> - Gain change: Haven't tested that, but I think that would probably be
> pretty quick; a couple of samples. The gain change is mostly done by the
> adjustable attenuator, which should work in <2?s
>
> Best regards,
> Marcus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/e2307096/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 20 May 2016 13:21:43 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Environmental Questions About the X310 and N210
Message-ID:
<cak6gvuom0xq4rn9de1-dwh90pv3p3uzg-hev2vjl1q_9n72...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is there any information about the max and min temps, and max humidity for
both radios using the UBX-160 and UBX-40 daugherboards? What about MTBF
numbers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/1b8f6a03/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 20 May 2016 14:10:02 -0400
From: "Joshua Monson" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Error while re-building file-system for E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I'm trying to rebuild the file-system for my E310 in Ubuntu 14.04. However,
the process fails with the following error:
DEBUG: Executing shell function do_compile
NOTE: make -j 24 -e MAKEFLAGS=
scripts/reversion.sh
gcc
-isystem/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/b
uild/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe
-L/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/build/t
mp-glibc/sysroots/x86_64-linux/usr/lib
-L/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/build/t
mp-glibc/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe
-build/build/tmp-glibc/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe
-build/build/tmp-glibc/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-buil
d/build/tmp-glibc/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-buil
d/build/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1 -o unifdef unifdef.c
In file included from unifdef.h:29:0,
from unifdef.c:46:
/usr/local/include/err.h:8:1: error: unknown type name 'namespace'
namespace stasm
^
/usr/local/include/err.h:9:1: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
{
^
make: *** [unifdef] Error 1
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at
/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/build/tmp
-glibc/work/x86_64-linux/unifdef-native/2.10-r0/temp/log.do_compile.11332)
After this error is encountered the bitbake continues to run until all other
processes have completed and then it hangs (waiting for the failed build
process to complete) and the file system never finishes building. Any ideas?
Thanks,
Josh
BTW, my gcc version is 4.8.4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/91bdde49/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 20 May 2016 17:35:25 +0000
From: De Picker Laurent <[email protected]>
To: Dave NotTelling <[email protected]>, Marcus M?ller
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do timed commands work?
Message-ID:
<9aad20cc0756944b87ac18b767690e565ad0f...@bafmailmbx002.idcn.mil.intra>
Content-Type: text/plain; charset="iso-8859-1"
Dave, Marcus,
I was following your discussion on the timings of the N210 and X310 and have a
similar question.
I'm currently working on a project that does a constant spectral analysis and
automatically jams a detected signal. the transmitted signal is that of the
PMR446 (446 MHz). I use Windows 7 with LabVIEW 15 and de USRP N210 with WBX.
I made the most simplistic program that's possible (see annex). Now the
reactiontime of the program is 69ms (the time to detect a signal and transmit a
jamming signal). It's a little long but acceptable. The time that the program
needs to go back to the receiving state and jam a signal again however is 629ms.
Are these timings normal for the N210? is there a datasheet were the
performance of the N210 is tested? Why is there such a big difference in
reactiontime for the first time and reacting for a second time? Where did you
get the timings?
thanks in advance,
DE PICKER Laurent
OnderLuitenant KBO
KMS-DFBO-ASEA-151SSMW
[email protected]
0032 494 44 43 01
www.rma.ac.be<http://www.rma.ac.be>
________________________________
Van: USRP-users [[email protected]] namens Dave NotTelling via
USRP-users [[email protected]]
Verzonden: vrijdag 20 mei 2016 19:05
Aan: Marcus M?ller
CC: [email protected]
Onderwerp: Re: [USRP-users] How do timed commands work?
Marcus,
That really helps me! Thank you very much :D
-Dave
On Fri, May 20, 2016 at 12:40 PM, Marcus M?ller
<[email protected]<mailto:[email protected]>> wrote:
Hi Dave,
On 05/20/2016 04:19 PM, Dave NotTelling wrote:
Marcus,
Thank you for the in depth explanation!! My apologies for not listing the
devices. I am using an X310 with the UBX-160 and an N210 with the UBX-40.
I brought up the property tree because from what I can see in the X300
source code, the property tree is used @ uhd/host/lib/usrp/x300/x300_impl.cpp
line 998 (version 3.9.4). That shows something subscribing to samp rate
changes. The actual method that changes the freq is located at
uhd/host/lib/usrp/x300/x300_io_impl.cpp line 67. What I don't see is how timed
commands are treated differently than normal commands.
That's because they are *not* treated differently. You set a command time,
which informs the FPGA, and from then on, every command that reaches the FPGA
will take effect at that time, and no earlier.
Honestly it doesn't really matter that I have a full understanding of it so
long as I can be promised that for the X310 and N210 with UBX daughterboards
that sample rate, gain, and freq can all be changed via timed commands.
They can!
I would like to be able to pack as many timed commands as possible as
close in time as possible. In order to do that I need to figure out how long
the various operations take (tuning, sample rate changes, and gain settings).
* Tuning:
* Digital part: from one sample to the next.
* Analog part: depends on the before/after frequencies, but on UBX,
let's say ~ 4ms
* Watch for the DC removal (which you can disable), which can take up to
about 60ms on N2xx, half of that on X3xx, if I remember correctly
* Sample rate change:
* good question; not long (same order of magnitude, ie. a couple of
samples),
* but you'll have to take into account that this operation changes
filters, and hence, you'll see the step response of the newly added FIR (if
any).
* Gain change: Haven't tested that, but I think that would probably be
pretty quick; a couple of samples. The gain change is mostly done by the
adjustable attenuator, which should work in <2?s
Best regards,
Marcus
***************************************************************
Your E-mail has been scanned against Potential Virus and Spyware/Grayware
dangers by the MOD BE SECURITY SYSTEMS.
Email secured by the 'Nemesis' Systems.
This e-mail and any attachments may contain sensitive and
privileged information. If you are not the intended recipient,
please notify the sender immediately by return e-mail,
delete this e-mail and destroy any copies.
Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/460f7552/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Desktop.zip
Type: application/octet-stream
Size: 238980 bytes
Desc: Desktop.zip
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/460f7552/attachment-0001.zip>
------------------------------
Message: 8
Date: Fri, 20 May 2016 17:55:43 +0000
From: Nik B. <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] 'create the usrp device' fails==Unhandled
exception at 0x000007FEE74B14A8 (uhd.dll)
Message-ID:
<kl1pr02mb1368b4002c4d72a009fd6067d0...@kl1pr02mb1368.apcprd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-2022-jp"
All day today, I wanted to make the following program work, without success.
It is straight out of someone else's posting in the internet.
int main(int argc, char *argv[]) {
string args = "addr=192.168.10.2";
// create the usrp device
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
//<<-- this seems to create problem
some::other::codes
return 1;
}
When I build, I get an exe file (it's an Win32-ConsoleApplication) file, and
when I run that exe file, I got this error:
The thread 0x1870 has exited with code 0 (0x0).
Unhandled exception at 0x000007FEE74B14A8 (uhd.dll) in USRPReader4.exe:
0xC0000005: Access violation reading location 0x00000000003FC00.
Please check the attached picture.
Test environment:
Win 7-64
UHD driver: tried 4 different version: uhd_003.009.001-release_Win64_VS2015,
uhd_003.009.002-release_Win64_VS2015, uhd_003.009.003-release_Win64_VS2015 and
uhd_003.009.004-release_Win64_VS2015
all failed.
Boost library is in C:\boost_1_58_0.
The UHD/bin is in the 'path', so when I issue "uhd_find_devices", I get proper
response, like:
c:\UHD\bin>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.001-release
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.10.2
name: sn014
serial: 1339
--------------------------------------------------
-- UHD Device 1
--------------------------------------------------
..looks like Device 0....
Working with other sample files from the internet, I get "Error:bad allocation"
error at the same place.
***
I have successfully built and run sample files like this under the same
environment.
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_file.cpp
The above sample does not set ipaddr of the usrp device, like this:
("args", po::value<std::string>(&args)->default_value(""), "multi uhd device
address args")
But I want to be able to pass the ipaddr while creating the device.
If the conncted device's ipaddr is not "192.168.10.2", then I want to be told
"not found".
Thank you for reading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/1c48e970/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AccessViolation.PNG
Type: image/png
Size: 115724 bytes
Desc: AccessViolation.PNG
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/1c48e970/attachment-0001.PNG>
------------------------------
Message: 9
Date: Fri, 20 May 2016 15:49:52 -0400
From: Philip Balister <[email protected]>
To: Joshua Monson <[email protected]>, [email protected]
Subject: Re: [USRP-users] Error while re-building file-system for E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Can you post the exact log? Are you following the instructions in the
uhd manual?
Philip
On 05/20/2016 02:10 PM, Joshua Monson via USRP-users wrote:
> Hi,
>
>
>
> I'm trying to rebuild the file-system for my E310 in Ubuntu 14.04. However,
> the process fails with the following error:
>
>
>
> DEBUG: Executing shell function do_compile
>
> NOTE: make -j 24 -e MAKEFLAGS=
>
> scripts/reversion.sh
>
> gcc
> -isystem/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/b
> uild/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe
> -L/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/build/t
> mp-glibc/sysroots/x86_64-linux/usr/lib
> -L/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/build/t
> mp-glibc/sysroots/x86_64-linux/lib
> -Wl,-rpath-link,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe
> -build/build/tmp-glibc/sysroots/x86_64-linux/usr/lib
> -Wl,-rpath-link,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe
> -build/build/tmp-glibc/sysroots/x86_64-linux/lib
> -Wl,-rpath,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-buil
> d/build/tmp-glibc/sysroots/x86_64-linux/usr/lib
> -Wl,-rpath,/home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-buil
> d/build/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1 -o unifdef unifdef.c
>
> In file included from unifdef.h:29:0,
>
> from unifdef.c:46:
>
> /usr/local/include/err.h:8:1: error: unknown type name 'namespace'
>
> namespace stasm
>
> ^
>
> /usr/local/include/err.h:9:1: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before '{' token
>
> {
>
> ^
>
> make: *** [unifdef] Error 1
>
> ERROR: oe_runmake failed
>
> WARNING: exit code 1 from a shell command.
>
> ERROR: Function failed: do_compile (log file is located at
> /home/jmonson/linux_home/Projects/combat/yocto_build/e300-oe-build/build/tmp
> -glibc/work/x86_64-linux/unifdef-native/2.10-r0/temp/log.do_compile.11332)
>
>
>
> After this error is encountered the bitbake continues to run until all other
> processes have completed and then it hangs (waiting for the failed build
> process to complete) and the file system never finishes building. Any ideas?
>
>
>
>
> Thanks,
>
>
>
> Josh
>
>
>
> BTW, my gcc version is 4.8.4.
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Sat, 21 May 2016 14:10:24 +0200
From: rv pellarin <[email protected]>
To: [email protected]
Subject: [USRP-users] gnuradio - windows
Message-ID:
<cahlh5kffu7jcg5wswnpmqe59oann+2v7xtqgs8tcvx9znym...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi guys,
i try to install gnuradio on windows 10 and i think i gonna giveup, even
with pothos sdr, can t get it working.
can somebody explain me why such program can t have a classic windows
installer, and the open when you clic on the icon?
why is it so complicated?
thxxx
herve
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/545ae0ca/attachment-0001.html>
------------------------------
Message: 11
Date: Sat, 21 May 2016 14:45:54 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Received power changing in sinusoidal manner
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi there,
I use 2x N210 with 2x XCVR2450 daughter boards and I transmit frames at
5785 MHz. The frames are received, but the problem is that the power of
the received frames varies in sinusoidal manner. The scenario is static
and the both stations are on 2 meters distance.
I use 50 MSps with sc8 wire format. The modulation is BPSK and the
symbols are 4x oversampled and filtered with SRRC at the transmitter and
at the receiver. The frames burst sent is the same frame repeated.
In power.jpg the instant power averaged over a short interval is shown.
The sine modulation can be easily seen.
The frames.jpg shows the instant power of the frames not averaged.
The frame.jpg shows the instant power of one frame not averaged.
I noticed that from the TX side I have relatively strong (more than I
would expect) carrier, due to dc bias probably. This is probably not the
issue.
Any idea what can it be, or have you seen something similar?
BR,
Vladica
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frame.jpg
Type: image/jpeg
Size: 177814 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/d3714475/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frames.jpg
Type: image/jpeg
Size: 91604 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/d3714475/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: power.jpg
Type: image/jpeg
Size: 71855 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/d3714475/attachment-0005.jpg>
------------------------------
Message: 12
Date: Sat, 21 May 2016 15:07:08 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] gnuradio - windows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Herve,
I'd like to respectfully point out that this is a GNU Radio, not a USRP
usage, question. GNU Radio is not a product of Ettus ? though we really
try to make sure the USRPs work as nicely as possible with GNU Radio,
GNU Radio itself is a community project; the fact that Windows
installations aren't really easy is nobody's fault in particular. In
fact, making a complete ecosystem of software (which GNU Radio and its
out-of-tree modules have become) is really hard ? and a really really
significant amount of time currently goes into just making things work
under a couple of "usual" environments.
Now, being a part (like many others on this list, and many of my Ettus
colleagues) of the GNU Radio community myself, I can assure you that
you're not alone with your frustration regarding Windows ? it's a really
awkward system to develop for if you're used to the comfort of the
conventions you can follow on a Unixoid system like Linux, or Mac OS X;
now, originally, and over the last couple of years, those were
practically the only platforms GNU Radio was developed on. We, as a
community, really owe Geof who's currently very actively bringing out
Windows installers for GNU Radio (which seems to be the thing that
doesn't work for you?) for making it possible for us Windows-Amateurs to
actually make it possible to at least try to improve how well GNU Radio
supports Windows.
Still, it's a long way till most things will work as well under the, for
us, more or less esoteric platform that is Windows, as they do under our
"home" operating systems. A lot of things that you'd normally just
expect to work simply don't work as specified under Windows ? see the
current discussion on UDP sockets on the GNU Radio mailing list, for
example.
So, first of all, I'd like to point you to the discuss-gnuradio mailing
list (sign up under [1]), which is really much more the place to discuss
problems related to GNU Radio. However, make sure to give meaningful,
comprehensive, description of the problems you encounter when contacting
that list ? we spent far too much time just asking people what they
meant with "does not work" when trying to figure out how to help them,
in our spare time.
So, knowing that setting up GNU Radio isn't trivial, even on anything
that isn't Linux Debian 8+, Ubuntu 14.04, 16.04, Fedora 22/23 or Mac OS
X, Corganlabs has gone through the effort of creating a bootable,
ready-to-run Linux DVD image, which you can use, without installing
anything, to try, and use, GNU Radio, including UHD, to work with your
USRP hardware. I can heartily recommend trying it! (In fact, I believe
in that image enough to be running mirror servers just so you can
download it faster.)
Best regards,
Marcus
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
On 21.05.2016 14:10, rv pellarin via USRP-users wrote:
> hi guys,
> i try to install gnuradio on windows 10 and i think i gonna giveup,
> even with pothos sdr, can t get it working.
> can somebody explain me why such program can t have a classic windows
> installer, and the open when you clic on the icon?
> why is it so complicated?
> thxxx
> herve
> ?
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/ce6e2701/attachment-0001.html>
------------------------------
Message: 13
Date: Sat, 21 May 2016 15:16:24 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Received power changing in sinusoidal manner
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Vladica,
no, sorry, never seen that myself; however, I don't have an XCVR2450 to
test.
So, what's important to my understanding here: Is the power.jpg,
frames.jpg taken *before* or after the root raised cosine filter?
And: are the USRPs somehow frequency synced, or do they run off their
own oscillators?
Best regards,
Marcus
On 21.05.2016 14:45, Vladica Sark via USRP-users wrote:
> Hi there,
>
> I use 2x N210 with 2x XCVR2450 daughter boards and I transmit frames
> at 5785 MHz. The frames are received, but the problem is that the
> power of the received frames varies in sinusoidal manner. The scenario
> is static and the both stations are on 2 meters distance.
>
> I use 50 MSps with sc8 wire format. The modulation is BPSK and the
> symbols are 4x oversampled and filtered with SRRC at the transmitter
> and at the receiver. The frames burst sent is the same frame repeated.
>
> In power.jpg the instant power averaged over a short interval is
> shown. The sine modulation can be easily seen.
> The frames.jpg shows the instant power of the frames not averaged.
> The frame.jpg shows the instant power of one frame not averaged.
>
> I noticed that from the TX side I have relatively strong (more than I
> would expect) carrier, due to dc bias probably. This is probably not
> the issue.
>
> Any idea what can it be, or have you seen something similar?
>
> BR,
> Vladica
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/28fc7e9f/attachment-0001.html>
------------------------------
Message: 14
Date: Sat, 21 May 2016 16:02:30 +0200
From: rv pellarin <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] gnuradio - windows
Message-ID:
<CAHLh5KG8OmwCy81gyERV=mrif0+drabddpt7en5arp09cq5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi marcus,
thxx a lot
i ll focus on usrp question now, sorry for that.
best regards
herve
?
On 21 May 2016 at 15:07, Marcus M?ller <[email protected]> wrote:
> Hi Herve,
>
> I'd like to respectfully point out that this is a GNU Radio, not a USRP
> usage, question. GNU Radio is not a product of Ettus ? though we really try
> to make sure the USRPs work as nicely as possible with GNU Radio, GNU Radio
> itself is a community project; the fact that Windows installations aren't
> really easy is nobody's fault in particular. In fact, making a complete
> ecosystem of software (which GNU Radio and its out-of-tree modules have
> become) is really hard ? and a really really significant amount of time
> currently goes into just making things work under a couple of "usual"
> environments.
>
> Now, being a part (like many others on this list, and many of my Ettus
> colleagues) of the GNU Radio community myself, I can assure you that you're
> not alone with your frustration regarding Windows ? it's a really awkward
> system to develop for if you're used to the comfort of the conventions you
> can follow on a Unixoid system like Linux, or Mac OS X; now, originally,
> and over the last couple of years, those were practically the only
> platforms GNU Radio was developed on. We, as a community, really owe Geof
> who's currently very actively bringing out Windows installers for GNU Radio
> (which seems to be the thing that doesn't work for you?) for making it
> possible for us Windows-Amateurs to actually make it possible to at least
> try to improve how well GNU Radio supports Windows.
> Still, it's a long way till most things will work as well under the, for
> us, more or less esoteric platform that is Windows, as they do under our
> "home" operating systems. A lot of things that you'd normally just expect
> to work simply don't work as specified under Windows ? see the current
> discussion on UDP sockets on the GNU Radio mailing list, for example.
>
> So, first of all, I'd like to point you to the discuss-gnuradio mailing
> list (sign up under [1]), which is really much more the place to discuss
> problems related to GNU Radio. However, make sure to give meaningful,
> comprehensive, description of the problems you encounter when contacting
> that list ? we spent far too much time just asking people what they meant
> with "does not work" when trying to figure out how to help them, in our
> spare time.
>
> So, knowing that setting up GNU Radio isn't trivial, even on anything that
> isn't Linux Debian 8+, Ubuntu 14.04, 16.04, Fedora 22/23 or Mac OS X,
> Corganlabs has gone through the effort of creating a bootable, ready-to-run
> Linux DVD image, which you can use, without installing anything, to try,
> and use, GNU Radio, including UHD, to work with your USRP hardware. I can
> heartily recommend trying it! (In fact, I believe in that image enough to
> be running mirror servers just so you can download it faster.)
>
> Best regards,
> Marcus
>
> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>
>
> On 21.05.2016 14:10, rv pellarin via USRP-users wrote:
>
> hi guys,
> i try to install gnuradio on windows 10 and i think i gonna giveup, even
> with pothos sdr, can t get it working.
> can somebody explain me why such program can t have a classic windows
> installer, and the open when you clic on the icon?
> why is it so complicated?
> thxxx
> herve
> ?
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/de4a9c3c/attachment-0001.html>
------------------------------
Message: 15
Date: Sat, 21 May 2016 16:07:18 +0200
From: Marcus M?ller <[email protected]>
To: rv pellarin <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] gnuradio - windows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Herve,
really, don't worry, we're really open for all kind of usage-related or
just loosely related questions here; but your problem was really GNU
Radio-centric, and also, the mail you wrote really indicated no way we
could help you here or you could be helped on [email protected],
as we'd really need more background on what you've tried, what exactly
failed etc. So I tried to give you a feeling for what problems we (the
GR community) have ourselves with Windows currently, and why you're not
alone, and why a helpful error report will probably meet an interested
audience, and what would be considered helpful.
Best regards,
Marcus
On 21.05.2016 16:02, rv pellarin wrote:
> hi marcus,
> thxx a lot
> i ll focus on usrp question now, sorry for that.
> best regards
> herve
> ?
>
> On 21 May 2016 at 15:07, Marcus M?ller <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Herve,
>
> I'd like to respectfully point out that this is a GNU Radio, not a
> USRP usage, question. GNU Radio is not a product of Ettus ? though
> we really try to make sure the USRPs work as nicely as possible
> with GNU Radio, GNU Radio itself is a community project; the fact
> that Windows installations aren't really easy is nobody's fault in
> particular. In fact, making a complete ecosystem of software
> (which GNU Radio and its out-of-tree modules have become) is
> really hard ? and a really really significant amount of time
> currently goes into just making things work under a couple of
> "usual" environments.
>
> Now, being a part (like many others on this list, and many of my
> Ettus colleagues) of the GNU Radio community myself, I can assure
> you that you're not alone with your frustration regarding Windows
> ? it's a really awkward system to develop for if you're used to
> the comfort of the conventions you can follow on a Unixoid system
> like Linux, or Mac OS X; now, originally, and over the last couple
> of years, those were practically the only platforms GNU Radio was
> developed on. We, as a community, really owe Geof who's currently
> very actively bringing out Windows installers for GNU Radio (which
> seems to be the thing that doesn't work for you?) for making it
> possible for us Windows-Amateurs to actually make it possible to
> at least try to improve how well GNU Radio supports Windows.
> Still, it's a long way till most things will work as well under
> the, for us, more or less esoteric platform that is Windows, as
> they do under our "home" operating systems. A lot of things that
> you'd normally just expect to work simply don't work as specified
> under Windows ? see the current discussion on UDP sockets on the
> GNU Radio mailing list, for example.
>
> So, first of all, I'd like to point you to the discuss-gnuradio
> mailing list (sign up under [1]), which is really much more the
> place to discuss problems related to GNU Radio. However, make sure
> to give meaningful, comprehensive, description of the problems you
> encounter when contacting that list ? we spent far too much time
> just asking people what they meant with "does not work" when
> trying to figure out how to help them, in our spare time.
>
> So, knowing that setting up GNU Radio isn't trivial, even on
> anything that isn't Linux Debian 8+, Ubuntu 14.04, 16.04, Fedora
> 22/23 or Mac OS X, Corganlabs has gone through the effort of
> creating a bootable, ready-to-run Linux DVD image, which you can
> use, without installing anything, to try, and use, GNU Radio,
> including UHD, to work with your USRP hardware. I can heartily
> recommend trying it! (In fact, I believe in that image enough to
> be running mirror servers just so you can download it faster.)
>
> Best regards,
> Marcus
>
> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> [2]
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>
>
> On 21.05.2016 14:10, rv pellarin via USRP-users wrote:
>> hi guys,
>> i try to install gnuradio on windows 10 and i think i gonna
>> giveup, even with pothos sdr, can t get it working.
>> can somebody explain me why such program can t have a classic
>> windows installer, and the open when you clic on the icon?
>> why is it so complicated?
>> thxxx
>> herve
>> ?
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/a2573c53/attachment-0001.html>
------------------------------
Message: 16
Date: Sat, 21 May 2016 16:10:15 +0200
From: rv pellarin <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] gnuradio - windows
Message-ID:
<cahlh5khcb3afqkj-jzaudybhxku3zmssrrb490ybsxur_8s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
thxx marcus,
i ll do a video if i dont succeed over the week end, and if i do , i ll
also do a tutorial video explaining how i ve succeed.
thxx for your time
i am very excited to have my b205 mini, pitty i haven t been able to use it
yet :)
?
On 21 May 2016 at 16:07, Marcus M?ller <[email protected]> wrote:
> Hi Herve,
>
> really, don't worry, we're really open for all kind of usage-related or
> just loosely related questions here; but your problem was really GNU
> Radio-centric, and also, the mail you wrote really indicated no way we
> could help you here or you could be helped on [email protected],
> as we'd really need more background on what you've tried, what exactly
> failed etc. So I tried to give you a feeling for what problems we (the GR
> community) have ourselves with Windows currently, and why you're not alone,
> and why a helpful error report will probably meet an interested audience,
> and what would be considered helpful.
>
> Best regards,
> Marcus
>
>
> On 21.05.2016 16:02, rv pellarin wrote:
>
> hi marcus,
> thxx a lot
> i ll focus on usrp question now, sorry for that.
> best regards
> herve
> ?
>
> On 21 May 2016 at 15:07, Marcus M?ller <[email protected]> wrote:
>
>> Hi Herve,
>>
>> I'd like to respectfully point out that this is a GNU Radio, not a USRP
>> usage, question. GNU Radio is not a product of Ettus ? though we really try
>> to make sure the USRPs work as nicely as possible with GNU Radio, GNU Radio
>> itself is a community project; the fact that Windows installations aren't
>> really easy is nobody's fault in particular. In fact, making a complete
>> ecosystem of software (which GNU Radio and its out-of-tree modules have
>> become) is really hard ? and a really really significant amount of time
>> currently goes into just making things work under a couple of "usual"
>> environments.
>>
>> Now, being a part (like many others on this list, and many of my Ettus
>> colleagues) of the GNU Radio community myself, I can assure you that you're
>> not alone with your frustration regarding Windows ? it's a really awkward
>> system to develop for if you're used to the comfort of the conventions you
>> can follow on a Unixoid system like Linux, or Mac OS X; now, originally,
>> and over the last couple of years, those were practically the only
>> platforms GNU Radio was developed on. We, as a community, really owe Geof
>> who's currently very actively bringing out Windows installers for GNU Radio
>> (which seems to be the thing that doesn't work for you?) for making it
>> possible for us Windows-Amateurs to actually make it possible to at least
>> try to improve how well GNU Radio supports Windows.
>> Still, it's a long way till most things will work as well under the, for
>> us, more or less esoteric platform that is Windows, as they do under our
>> "home" operating systems. A lot of things that you'd normally just expect
>> to work simply don't work as specified under Windows ? see the current
>> discussion on UDP sockets on the GNU Radio mailing list, for example.
>>
>> So, first of all, I'd like to point you to the discuss-gnuradio mailing
>> list (sign up under [1]), which is really much more the place to discuss
>> problems related to GNU Radio. However, make sure to give meaningful,
>> comprehensive, description of the problems you encounter when contacting
>> that list ? we spent far too much time just asking people what they meant
>> with "does not work" when trying to figure out how to help them, in our
>> spare time.
>>
>> So, knowing that setting up GNU Radio isn't trivial, even on anything
>> that isn't Linux Debian 8+, Ubuntu 14.04, 16.04, Fedora 22/23 or Mac OS X,
>> Corganlabs has gone through the effort of creating a bootable, ready-to-run
>> Linux DVD image, which you can use, without installing anything, to try,
>> and use, GNU Radio, including UHD, to work with your USRP hardware. I can
>> heartily recommend trying it! (In fact, I believe in that image enough to
>> be running mirror servers just so you can download it faster.)
>>
>> Best regards,
>> Marcus
>>
>> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>>
>>
>> On 21.05.2016 14:10, rv pellarin via USRP-users wrote:
>>
>> hi guys,
>> i try to install gnuradio on windows 10 and i think i gonna giveup, even
>> with pothos sdr, can t get it working.
>> can somebody explain me why such program can t have a classic windows
>> installer, and the open when you clic on the icon?
>> why is it so complicated?
>> thxxx
>> herve
>> ?
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/779f1628/attachment-0001.html>
------------------------------
Message: 17
Date: Sat, 21 May 2016 16:25:30 +0200
From: Marcus M?ller <[email protected]>
To: rv pellarin <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] gnuradio - windows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ah, a b205mini means that you'll really need at least UHD 3.9.2; that's
not even yet included in the liveDVD I linked to (which is what I'd
normally have recommended using first instead of trying overly long to
get GNU Radio to run under Windows).
I think the easiest way out here is really:
1. Get a fresh Ubuntu 14.04LTS installation (it's probably easier than
you think), don't install anything special
2. Go to https://github.com/gnuradio/pybombs/ and follow the
installation instructions, i.e. open a terminal and run
|sudo apt-get install -y git pip sudo pip install --upgrade
git+https://github.com/gnuradio/pybombs.git ||pybombs recipes add gr-recipes
git+https://github.com/gnuradio/gr-recipes.git ||pybombs recipes add gr-etcetera
git+https://github.com/gnuradio/gr-etcetera.git ||pybombs prefix init ~/prefix
-a myprefix -R gnuradio-default|
and wait while pybombs installs latest UHD, GNU Radio, all of their
dependencies, on the fly.
Then, from a terminal
source ~/prefix/setup_env.sh
gnuradio-companion
will start the GNU Radio Companion, which is your starting point for
developing GNU Radio applications. Replace "gnuradio-companion" by
"gqrx", and you'll start the popular radio scanner application GQRX.
Best regards,
Marcus
On 21.05.2016 16:10, rv pellarin wrote:
> thxx marcus,
> i ll do a video if i dont succeed over the week end, and if i do , i
> ll also do a tutorial video explaining how i ve succeed.
> thxx for your time
> i am very excited to have my b205 mini, pitty i haven t been able to
> use it yet :)
> ?
>
> On 21 May 2016 at 16:07, Marcus M?ller <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Herve,
>
> really, don't worry, we're really open for all kind of
> usage-related or just loosely related questions here; but your
> problem was really GNU Radio-centric, and also, the mail you wrote
> really indicated no way we could help you here or you could be
> helped on [email protected]
> <mailto:[email protected]>, as we'd really need more
> background on what you've tried, what exactly failed etc. So I
> tried to give you a feeling for what problems we (the GR
> community) have ourselves with Windows currently, and why you're
> not alone, and why a helpful error report will probably meet an
> interested audience, and what would be considered helpful.
>
> Best regards,
> Marcus
>
>
> On 21.05.2016 16:02, rv pellarin wrote:
>> hi marcus,
>> thxx a lot
>> i ll focus on usrp question now, sorry for that.
>> best regards
>> herve
>> ?
>>
>> On 21 May 2016 at 15:07, Marcus M?ller
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> Hi Herve,
>>
>> I'd like to respectfully point out that this is a GNU Radio,
>> not a USRP usage, question. GNU Radio is not a product of
>> Ettus ? though we really try to make sure the USRPs work as
>> nicely as possible with GNU Radio, GNU Radio itself is a
>> community project; the fact that Windows installations aren't
>> really easy is nobody's fault in particular. In fact, making
>> a complete ecosystem of software (which GNU Radio and its
>> out-of-tree modules have become) is really hard ? and a
>> really really significant amount of time currently goes into
>> just making things work under a couple of "usual" environments.
>>
>> Now, being a part (like many others on this list, and many of
>> my Ettus colleagues) of the GNU Radio community myself, I can
>> assure you that you're not alone with your frustration
>> regarding Windows ? it's a really awkward system to develop
>> for if you're used to the comfort of the conventions you can
>> follow on a Unixoid system like Linux, or Mac OS X; now,
>> originally, and over the last couple of years, those were
>> practically the only platforms GNU Radio was developed on.
>> We, as a community, really owe Geof who's currently very
>> actively bringing out Windows installers for GNU Radio (which
>> seems to be the thing that doesn't work for you?) for making
>> it possible for us Windows-Amateurs to actually make it
>> possible to at least try to improve how well GNU Radio
>> supports Windows.
>> Still, it's a long way till most things will work as well
>> under the, for us, more or less esoteric platform that is
>> Windows, as they do under our "home" operating systems. A lot
>> of things that you'd normally just expect to work simply
>> don't work as specified under Windows ? see the current
>> discussion on UDP sockets on the GNU Radio mailing list, for
>> example.
>>
>> So, first of all, I'd like to point you to the
>> discuss-gnuradio mailing list (sign up under [1]), which is
>> really much more the place to discuss problems related to GNU
>> Radio. However, make sure to give meaningful, comprehensive,
>> description of the problems you encounter when contacting
>> that list ? we spent far too much time just asking people
>> what they meant with "does not work" when trying to figure
>> out how to help them, in our spare time.
>>
>> So, knowing that setting up GNU Radio isn't trivial, even on
>> anything that isn't Linux Debian 8+, Ubuntu 14.04, 16.04,
>> Fedora 22/23 or Mac OS X, Corganlabs has gone through the
>> effort of creating a bootable, ready-to-run Linux DVD image,
>> which you can use, without installing anything, to try, and
>> use, GNU Radio, including UHD, to work with your USRP
>> hardware. I can heartily recommend trying it! (In fact, I
>> believe in that image enough to be running mirror servers
>> just so you can download it faster.)
>>
>> Best regards,
>> Marcus
>>
>> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> [2]
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>>
>>
>>
>> On 21.05.2016 14:10, rv pellarin via USRP-users wrote:
>>> hi guys,
>>> i try to install gnuradio on windows 10 and i think i gonna
>>> giveup, even with pothos sdr, can t get it working.
>>> can somebody explain me why such program can t have a
>>> classic windows installer, and the open when you clic on the
>>> icon?
>>> why is it so complicated?
>>> thxxx
>>> herve
>>> ?
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/5795e3f1/attachment-0001.html>
------------------------------
Message: 18
Date: Sat, 21 May 2016 17:39:51 +0200
From: Vladica Sark <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Received power changing in sinusoidal manner
Message-ID:
<CALCRFZEswbOYg7acM0t=mipRN6Bh8LnHFOKF=qffmjgptak...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus, Anselm,
These are before the root rised cosine at the receiver. So, directly the
samples from the uhd.
The radios are not synced. Run on their own oscillator. Anyway, the
frequency offset is around 600 Hz, which is not too much. However, each
symbol is sampled with 4 samples. I tried with 8 times oversampling, but
the problem still exists. It is maybe worser. Also in this case sample rate
was 50 MSps, and each symbol represented with 8 samples. On Monday I would
be able to use heavy artilery - scope and signal generator to see what
happens. I think that the problem comes from the receiver, according to
what I remember from the past.
Just to mention, there is no frequencu offset correction neither timing
recovery, but with 8x oversampling this should not make problems.
Best regards'
Vladica
On May 21, 2016 3:17 PM, "Marcus M?ller" <[email protected]> wrote:
>
> Hi Vladica,
>
> no, sorry, never seen that myself; however, I don't have an XCVR2450 to
test.
>
> So, what's important to my understanding here: Is the power.jpg,
frames.jpg taken *before* or after the root raised cosine filter?
> And: are the USRPs somehow frequency synced, or do they run off their own
oscillators?
>
> Best regards,
> Marcus
>
>
> On 21.05.2016 14:45, Vladica Sark via USRP-users wrote:
>>
>> Hi there,
>>
>> I use 2x N210 with 2x XCVR2450 daughter boards and I transmit frames at
5785 MHz. The frames are received, but the problem is that the power of the
received frames varies in sinusoidal manner. The scenario is static and the
both stations are on 2 meters distance.
>>
>> I use 50 MSps with sc8 wire format. The modulation is BPSK and the
symbols are 4x oversampled and filtered with SRRC at the transmitter and at
the receiver. The frames burst sent is the same frame repeated.
>>
>> In power.jpg the instant power averaged over a short interval is shown.
The sine modulation can be easily seen.
>> The frames.jpg shows the instant power of the frames not averaged.
>> The frame.jpg shows the instant power of one frame not averaged.
>>
>> I noticed that from the TX side I have relatively strong (more than I
would expect) carrier, due to dc bias probably. This is probably not the
issue.
>>
>> Any idea what can it be, or have you seen something similar?
>>
>> BR,
>> Vladica
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/d2b19c1d/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 69, Issue 21
******************************************
